מודל עבודה לסידור מערכת ניהול הפיתוח או איך מסדרים את הג’ירה?

בקצרה:

במסגרת הסדרת תהליכי העבודה בפיתוח, אנחנו נדרשים לסדר את מערכת ניהול הפיתוח – כך שתהיה אחידה וברורה, משקפת את התהליכים החדשים ובעיקר מאפשרת גידול משמעותי ביכולות ניהול הפיתוח. אבל מאיפה מתחילים? לשם כך, אני מציעה מודל מדורג בשם AVP: Alignment , Visibility & Predictability. מודל זה מאפשר לא רק ליצור סדר במערכת, אלא לייצר בסיס לכלים לייצור תובנות תומכות החלטה להנלה. מודל זה הוא מדורג, כל שלב מוביל לשלב הבא, וכל שלב קורה מספר פעמים לאורך פרק הזמן בו מייצבים את התהליכים. השלב הראשון, Alignment, מדבר על יישר קו ברמת השדות, לוחות הזמנים והתפקידים. השלב השני מדבר על יצירת Visibility, שקיפות למידע שעתה קיים בפורמט אחוד והשלב השלישי מתאפשר בזכות השניים הראשונים ומאפשר להעלות את ה- predictability של מחלקת הפיתוח, ואת אחוז התאימות בין התכנון לביצוע בפועל.

בהרחבה:

בשלבים ראשונים של הפיתוח, הצוותים עובדים בצורה עצמאית למדי ורצים קדימה. התוצאה מבחינת מערכות המידע היא לרוב שהצוותים עובדים בצורה שונה, גם אם עובדים באותה מערכת לניהול הפיתוח כמו ג’ירה TFS, מאנדיי או כל אחת אחרת: מגדירים אחרת epic-ים, משתמשים בשדות ייחודיים, סטאטוסים עצמאיים וכו’. גם במקומות בהם העבודה נוהלה בצורה אחידה, הרי שבשלב של יצירה והאחדה של תהליכים רחבים, נוצר צורך בשדות חדשים ובהגדרות חדשות שצריך לעשות באופן אחיד ומסודר. ועכשיו השאלה היא איך עושים סדר ואיך מאפשרים לייצר תובנות תומכות החלטה להנהלה על בסיס הסדר הזה?

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

שלב זה מתאר את יצירת ההגדרות הבסיסיות לשפה אחידה בפיתוח ובמערכת המידע:

• הגדרות בסיס – מהו Epic, Story ו-Task.
• הגדרות בעלי תפקיד- מי מכניס ומעדכן את המידע ברמת כל אחד מישויות הבסיס
• ספרינטים – פורמט לשמות הספרינטים, משך הספרינט ותזמון.
• ההיררכיה וסוג הישויות שמשתמשים בהם (issue types בג’ירה), שדות בהם משתמשים (Fields) והסטאטוסים בהם משתמשים (Workflow)
• חישובי עלות – ימים/ story points וחישובי קיבולת של צוות
• תפקידים – מה עושה איש Product Manager לעומת Tech Team Lead? מי פותח Epic-ים ומי מעדכן בהם מידע?

נקודות לשים לב אליהם – איך צוותים שונים מסמנים פעילות FE לעומת BE? איך הצוותים מתייחסים למשימות QA לעומת פיתוח – האם זו משימה אחת שהולכת מהתחלת הפיתוח ועד ל- PRODUCTION, כולל QA? איך מסמנים כמה ימים תוכננה לקחת משימה וכמה ימים לקחה בפועל?

לאחר שנתנו תשובות בסיסיות אלו, אנו יכולים כבר לחשוב על השלב הבא: מה יהיה לנו חשוב למדוד? מה יהיה לנו חשוב שתהיה עליו תמונה מלאה? התשובות לכל אלו יהיו טמונות בשדות נוספים או באקסטרפולציה על שדות קיימים, בין אם אנו יודעים כבר להצביע עליהם או לא.

שלב זה חוזרים אליו כל פעם ופעם מחדש. בכל תהליך חדש שמייצרים ומיישרים, יהיה שלב של יצירת אחידות ברמת השדות. לדוגמא, אם התחלתם לעבוד על תכנון הפיתוח, ואתם מחליטים על יצירת פונקציות המובילות את פיתוח הפיצ’ר, תרצו להוסיף עתה שדות שמייצגים את אותם מובילים.

שלב שני: Visibility – הגדלת השקיפות

עתה, כאשר ההגדרות והשדות ואופן העבודה במערכת ניהול הפיתוח היא אחידה, מתאפשרת הרמה הבאה: שיקוף הפיתוח בצורה אגרגטיבית בעזרת Dashboard-ים ויצירת נראות להנהלה ולבעלי עניין נוספים לגבי סטאטוס פיתוח ונורות אדומות. השימוש האחיד והשפה האחידה היא שמאפשר לייצר תמונה מלאה על כל הארגון.

שלב זה של יצירת נראות ושקיפות היא עבור הלקוחות הפנימיים שלנו. אנו צריכים לזהות את הלקוחות הפנימיים שלנו ולכל לקוח פנימי, מהם הצרכים שלו.

עיקר הלקוחות הפנימיים הם בדר”כ: דרג ראשי צוותים, ראשי קבוצות, מנהלי הפיתוח, אנשי מכירות.

מה מעניין כל דרג לדוגמא:

• ראשי צוותים – האם לכל חבר צוות הוקצו מספיק משימות והמשימות הנכונות? האם יש דברים שנתקעים ואני צריך לשים לב אליהם?
• ראשי הקבוצות ומנהלי הפיתוח – ראייה רוחבית ואיתור נורות אדומות: סטאטוס הספרינט, סטאטוס הפיצ’רים אל מול תאריך היעד, אילו דברים נתקעים כבר זמן רב? רמת האיכות וכמות/דחיפות הבאגים הפתוחים
• אנשי מכירות – מתי תצא גרסא חדשה, יכולת מסוימת או תיקון של באג מסוים.

לא כולם רגילים לעבוד בדשבורדים או יודעים כבר על ההתחלה לשאול את השאלות הנכונות ולכן כדאי להתחיל מדשבורדים כלליים ולהראות תובנות שמאפשרות לבעלי העניין להבין מה הם יכולים להפיק מכך ועל בסיס זה לעורר את צורת החשיבה הזו.

שלב זה קורה באופן איטרטיבי גם הוא: ככל שמתחילים לייצר יותר דשבורדים, עולות שאלות נוספות ועולה מידע נוסף המאפשר העמקה ושיפור שבעקבותיו משפרים את הדשבורדים.

שלב שלישי: Predictability – הגדלת יכולת החיזוי

שלב זה, מבוסס על שני השלבים הקודמים של יצירת האחידות והשיקוף, ומאפשר קפיצת מדרגה ביכולות הפיתוח. עתה, משייצרנו בסיס רחב ואחיד, אפשרנו יצירת Dashboard-ים. בחינה מתמדת של Dashboard-ים אלו מאפשרת לנו לחשוף בעיות בתהליכים ובעיות בהערכות הזמנים הגורמים לבזבוז זמן או למצג שווא של תפוקה צפויה. לדוגמא – צוותים שבאופן קבוע מעבירים באגים מספרינט לספרינט ובפועל לא מתקנים אותם, הערכת חסר מתמדת בצוותים מסוימים וכו’.

סיפור מקרה

אצלנו התחלנו מלהגדיר את הספרינטים כשפה אחידה. עד אז הצוותים פעלו לפי תאריכים ייעודיים לפרויקטים עם משכי ספרינט של בין שבוע לשבועיים. כיום, כל הספרינטים נמשכים שבועיים ומתחילים בימי שני ב-11, על מנת לאפשר לצוותים היושבים בחו”ל לעבוד באותו קו זמן. הספרינטים נקראים בפורמט של חלוקת החודש לשבועיים הראשונים והאחרונים בו: Jan 1, Jan 2, Feb 1, Feb 2 וכו’. היה לנו חשוב לייצר מקצב קבוע של שבועיים, גם על חשבון הדיוק בתאריכים ומצד שני לרשום שם לספרינט המעיד בקירוב על התאריך אליו הוא רלוונטי. (לכן לפעמים ספרינט נקרא Feb 1, אבל יתחיל בסוף ינואר, או שלפעמים יהיה צורך בספרינט השלמה כמו May 3)

מבחינת ההיררכיות ושימוש ב- Issuetypes, הבנו שהשימוש אצלנו בEpic-ים אינו אחיד ויש צוותים אשר משתמשים רק בטאסקים וכאלה שביוזר סטוריס. הבנו כי ראשית יש צורך בלהגדיר מהו epic ורק לאחר מכן נוכל לרדת ולהגדיר היררכיה אחידה נמוכה יותר. יותר מכך, הבנו כי למעשה אנחנו צריכים גם היררכיה מעל Epic בשם Initiative, שתאפשר לנו להביא רעיון עסקי רחב יותר לידי ביטוי במספר אפיקים ביחד.

ברמת תהליך העבודה, הסטאטוסים בהם אנו משתמשים הם הבסיס לפרקטיקת העבודה. התחלנו במעבר בין הצוותים השונים והבנו את צורת העבודה וה- best practices השונים. החלטנו להטמיע סטאטוסים ברורים ואחידים לכולם, אבל גם לאפשר גמישות מסוימת בתור התחלה. כלומר בחרנו רשימה יחסית רחבה של סטאטוסים שרק בהם מותר לעבוד, ישנם סטאטוסי חובה וישנם סטאטוסים שבהם כל צוות יכול לבחור להשתמש בהם . הבנו שאנחנו לא נכנסים לדיון האם יש טאסקים נפרדים לפיתוח ול- QA, או טאסק אחד קצה לקצה אבל כן שיהיה ברור שמשימה היא גמורה, רק כאשר היא מוכנה ל- PRODUCTION באופן מלא.

במקביל התחלנו לעסוק בהבניית תהליכי תכנון ספרינט וביצירת SDLC מובנה. תהליכים אלו, יצרו אצלנו צורך בשדות נוספים של פונקציות אחראיות (מי אחראי קצה לקצה על פיצ’ר מורכב מבחינת הפיתוח, המוצר, וה- QA?) ובשדות נוספים לתיאור GATE-ים של מעבר משלבי הגדרת המוצר (Scoping) לשלבי התכנון הטכני (Tech Design) ושלבי הפיתוח עצמו. תהליכים אלו יצרו אצלנו סבב נוסף של המודל: יישור קו -> שיקוף -> חיזוי.

ברגע שתהליכים אלו התחילו להבשיל, הצורך ביצירת שיקוף (Visibilty) קפץ באופן דרמטי: על מה עובד הפיתוח? איך “הולך” לנו בספרינט הזה? איך אני יודע שהצוות שלי בכיוון הנכון? האם נעמוד בלוחות הזמנים שלנו? מהי רמת האיכות שלנו? דשבורדים אלו מאפשרים לנו להבין גם את התכנון וגם לשקף את המציאות כלפי חוץ. ברגע שה- visibility קופץ, הצורך בטיוב ה- Predictability עולה: המועדים בהם אנו צפויים לדלוור יכולות מסוימות משוקפות כלפי חוץ ולכן הציפייה לעמוד בלוחות הזמנים עולה אף היא. על שלבים אלו בהרחבה בהמשך.

האם גם אתם אנשי אופרציה העוסקים בתהליכי עבודה, מתודולוגיות וכלים בעולמות הפיתוח? אם כן, נשמח שתצטרפו לקבוצת Engineering Operations בוואטסאפ ותעקבו אחרינו בעמוד ה- Linked In שלנו.