פרק #77 אישה בחזית מהפיכה ושינוי ב-AT&T עם דקר שלום

בואו הקשיבו לדקר שלום מארחת את סמנכ"לית חטיבת הפיתוח של AT&T ישראל - יעל גולדברג

רקע על יעל גולדברג

יעל גולדברג היא סמנכ"לית חטיבת מרכז הפיתוח ב-AT&T ישראל.
הקריירה שלה התחילה כמפתחת תוכנה בחברת קונברס בזמן לימודיה, שם התקדמה לתפקידי ניהול (ראש צוות וקבוצה).

בהמשך:

• עברה לניהול תוכניות רחבות (Program Management)
• נחשפה לתמונה הרחבה של תהליכי פיתוח והאילוצים העסקיים
• קיבלה הזדמנות לנהל קבוצת בדיקות – למרות חוסר ניסיון קודם
• למדה את תחום הבדיקות לעומק (כולל הסמכות מקצועיות)
• פיתחה מומחיות משולבת: פיתוח + בדיקות

החיבור בין שני העולמות (פיתוח ובדיקות) הפך לבסיס הקריירה שלה.

על AT&T ומרכז הפיתוח בישראל

• AT&T היא חברה ותיקה מאוד (כ-160 שנה), שהוקמה ע"י ממציא הטלפון
• שרדה והתפתחה בזכות יכולת הסתגלות לשינויים

מרכז הפיתוח בישראל:

• קיים מעל 15 שנה
• נחשב למוביל בתוך הארגון
• התחיל כסטארטאפ ישראלי (Interwise) שנרכש ע"י AT&T
• משמש כ־Center of Excellence (מוקד מומחיות)

הייחוד המרכזי:
דגש על מצוינות טכנולוגית ושיטות פיתוח מתקדמות
לא רק “לייצר תוכנה”, אלא להביא ערך ייחודי

עקרונות מרכזיים בניהול ופיתוח

יעל מדגישה שארגון חייב לבחור ערכים ברורים.
במקרה שלהם:

• מצוינות מקצועית
• חדשנות טכנולוגית
• שיפור מתמיד

הדגש הוא על:
השקעה ארגונית במצוינות
מדידה לפי איכות התוצר והאימפקט – לא לפי כמות קוד

השינוי הגדול – Quality Built-In (Shift Left)

הבעיה:

למרות איכות גבוהה – קצב הפיתוח (Time to Market) היה איטי מדי.

הפתרון:

שינוי תפיסתי עמוק:
איכות אינה שלב בסוף – אלא חלק מובנה מהפיתוח

איך השיטה החדשה עובדת?

1. חשיבה מהסוף להתחלה

במקום להתחיל בטכנולוגיה:

• מתחילים מהביזנס והבעיה של הלקוח
• מגדירים מראש מהו מוצר איכותי
• מגדירים קריטריוני קבלה (Acceptance Criteria) מוקדם

הבדיקות נגזרות מהבנה זו – עוד לפני כתיבת קוד

2. פיתוח בחתיכות קטנות (Slices)

• פיתוח של פיצ’רים קטנים (MVP / MVF)
• שחרור מהיר לפרודקשן
• קבלת פידבק מהיר מהלקוח

יוצר לולאת שיפור מתמשכת

3. שינוי תפיסת הבדיקות

הפירמידה הקלאסית משתנה:

בעבר:

• רוב הבדיקות בסוף (End-to-End)

כיום:

• Unit Tests
• Component Tests
• Integration / API Tests
• מעט מאוד בדיקות End-to-End

בדיקות מתבצעות מוקדם ובשכבות נמוכות

4. המפתחים בודקים את עצמם

• המפתחים אחראים גם לאיכות
• בודקים תוך כדי פיתוח
• מתקנים מיד בעיות

זה לא “לתת לחתול לשמור על השמנת” כי:

• סוג הבדיקות שונה
• יש מבנה בדיקות היררכי
• יש בקרה נוספת (ראה בהמשך)

תפקיד חדש: Test Architect

במערכות מורכבות:

• המפתחים לא יכולים לראות את כל התמונה

לכן נוצר תפקיד: Test Architect

תפקידו:

• ראייה מערכתית רחבה
• הגדרת אסטרטגיית בדיקות
• טיפול בתלויות מורכבות
• הגדרת דרישות בדיקה למפתחים

מה קורה לבודקים?

בודקים ידניים:

• לא נעלמים
• מתמקדים במקרים שבהם אין יעילות באוטומציה (למשל מיגרציות)

בודקי אוטומציה:

• תפקידם משתנה משמעותית

תפיסה מרכזית: בדיקות אוטומטיות = קוד לכל דבר

לכן:

• נכתבות ע"י מפתחים
• נמצאות באותו קוד בסיס (repository)
• עומדות באותם סטנדרטים

יתרונות השינוי

השינוי הוביל ל:

• שיפור משמעותי במהירות הפיתוח
• שמירה ואף שיפור האיכות
• פחות “waste” (בזבוז זמן על תיקונים מאוחרים)
• פידבק מהיר מהלקוח
• אחריות מלאה של מפתחים על התוצר
• תהליכי CI/CD מתקדמים יותר

לקבוצת הוואצאפ של קהילת הבודקים: https://bit.ly/TestIL_Whatsapp

קישור לפרופיל לינקדאין של דקר: https://www.linkedin.com/in/dakar-shalom-7b6a575/ 

קישור לפרופיל לינקדאין של יעל: https://www.linkedin.com/in/yael-goldeberg-katz/ 

אם גם אתם מעוניינים להשתתף בפודקאסטים, אנא צרו עימנו קשר במייל: [email protected]

קישור לערוץ הפודקאסט שלנו