Posts tagged ‘ספרינט’

ספרינט ייצוב.

בואו ננסה להגדיר מהו ספרינט ייצוב – ספרינט(ים) שמתבצע(ים) לאחר שהסתיים המימוש של התכולה לגירסא הנכחית. בספרינט כזה לא מתווספת פונקציונאליות חדשה למוצר, אלא מתעסקים ב”ייצוב” הפונקציונאליות הקיימת, הכוונה בייצוב היא פעילויות כגון תיקון באגים, ביצוע בדיקות נוספות, שיפורים לקוד שנכתב כגון Refactoring או תוספת של כיסוי אוטומטי ע”י בדיקות אוטומטיות , שיפורים אחרונים של ה-Installer ועוד מיני סתימת חורים.

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

בקורסים שאני עורך, אני בד”כ מעלה את השאלה הבאה לדיון קבוצתי:

מה יותר חשוב – יותר פיצ’רים או הגדרת DONE רחבה יותר ?
כמובן שאין תשובה חד משמעית לשאלה הזאת אבל הדיון בד”כ מעלה את העובדה ש”קיצוץ” בהגדרת ה-Done שלכם מוביל באופן מיידי ל:
– צורך בסגירת הפערים הללו = צורך בספרינטים של ייצוב.
– הורדת רמת השקיפות עקב חוסר ידיעה ומדידה של כמה זמן לוקח ייצוב.
– פגיעה ברמת האמון בין ה-PO לבין הצוות עקב אי יכולת לכמת את המאמץ שחסר.

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

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

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

 

* מקור התמונה : http://www.flickr.com/photos/jonasb/364606089/

הישיבה היומית – לעמוד זה לא מספיק

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

  • שיתוף הצוות בהתחייבויות אישיות
  • עדכון סטאטוס
  • זיהוי בעיות
  • חיזוק הצוות.

Daily meeting

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

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

  • איחורים – ללא ספק בעיה קשה, אך אם זאת נפוצה. למה שאנשים מאחרים ?
    • תרבות ארגונית של איחורים – במקרה כזה אני ממליץ לנסות לגרום לצוות להרגיש שונה מהארגון, מיוחד, טוב יותר, וע”י כך לעודד התנתקות מהערכים ה”בעייתיים” של הארגון.
    • אנשים מאחרים כי הם עסוקים – לפעמים אנשים מאחרים פשוט כי יש להם כל כך הרבה משימות במקביל שהם מאבדים את הצפון, מעבר לעמדה הברורה שלי על ריבוי משימות (אני נגד!), אני חושב שאולי צריך לבדוק, אולי השעההמקום של הישיבה לא מתאימים להם וכדאי לשנות אותם.
    • אנשים מאחרים כי “לא אכפת להם” – אני לא יודע מה אתכם, אבל בד”כ כשאני רואה אנשים “שלא אכפת להם” ישנה סיבה טובה לכך, אולי מסיבה אחרת הישיבה לא תורמת להם כלום, ואז יש לטפל בסיבה האמיתית.
  • דיווחים – לעיתים לישיבה היומית יש את הדפוס הבא: כל חבר צוות בתורו מדווח לסקראם מסטר ולא לצוות, מובן שחברי הצוות מרגישים מיותרים במצב כזה. מצב זה בד”כ שכיח בצוותים חדשים, ועל הסקראם מסטר לוודא שהישיבה איננה מיועדת לו אלא לצוות, שיטות לעשות את זה הן למשל להרכין ראש, לעמוד עם הגב אל הצוות, ואפילו מידי פעם “בטעות” לא להגיע או לאחר מאוד לישיבה.
  • הישיבה לא מתחילה מעצמה – בדיקה מעניינת היא לבחון מה קורה כשהישיבה מתחילה? האם מישהו צריך להנחות אותה? האם זה הסקראם מסטר? אם כן אז מדובר באינדיקציה שהצוות למעשה עדיין לא עצמאי מספיק, תפקידו של הסקראם מסטר הוא לעודד את הצוות לעצמאות והישיבה היומית היא אמצעי טוב לכך, למשל לעזור לצוות להחליט איך מתנהלת הישיבה, רעיונות כגון, מדבר ראשון מי שהגיע אחרון, או מדברים עם כיוון השעון, מתחילים ממי שיש לו את הנעליים הכי יפות… כל מיני דרכים לגרום לצוות להסתדר ללא מנהיג מקדמות את העצמאות שלו.
  • פסטיבל מספרי סיפורים – בעיה שכיחה בישיבות היא שאנשים מתחילים לדבר… ולא מפסיקים, יש לדאוג שהצוות יתמקד בפרטים החשובים, וע”י כך ישמור על הישיבה קצרה ומועילה, דיווח כגון : “אתמול התחלתי לעבוד על X אבל אז בא חיים והראה לי את הטלפון החדש לו, חבל לכם על הזמן, אח”כ המשכתי והיה לי בעיות עם הרשת אז התעכבתי עוד קצת וגם היה לי מסובך המודול הזה אז ניגשתי ליוסי שעזר לי איזה שעתיים, היום אני מתכוון להמשיך עם מודול X אבל נראה כי אני צריך ללכת מוקדם כי הבן שלי חולה, נראה לי נדבק מהשכנה שלנו, מעצבנת כזאת, אתמול התארחה אצלנו והביאה את הקטנה שלה עם 40 מעלות חום….” איננו מועיל ותורם לתחושה של בזבוז זמן. בעיה כזאת עלולה להצביע על ירידה באנרגיה של הצוות, ותורם רבות לתחושת שעמום בישיבה.
  • פנטומימה – ההפך מסיפורים, דיווחים קצרים מידי, לקונים, ושאינם מספקים שום מידע רלוונטי למשל : “אתמול תיקנתי באג, היום אני אתקן באג, שום דבר לא מפריע לי”. דיווח כזה אינו מספק שום ערך ועדיף שלא יאמר בכלל.
  • איך כן לדווח ? – יש לשמור על סגנון דיווח קצר ואינפורמטיבי, משהו כמו: “היום תיקנתי באג במודול X, הייתה שם גלישת זיכרון במערך, הפכתי אותו לווקטור, עכשיו זה עובד, אני הולך להתחיל לעבוד על פיתוח פיצ’ר Z במודול Y, בעקרון שום דבר לא מפריע לי, אבל אם משיהו מכיר טוב את מודול Y אני אשמח לעבור איתו 10 דקות”.
  • פתרון בעיות – יש להיזהר שהישיבה לא תהפוך לפורום פתרון בעיות, בישיבה הבעיות שעלולות להפריע לצוות לעמוד בהתחייבויות אמורות לעלות אך לא להיות מטופלות, פתרון הבעיות נעשה אחרי הישיבה, ואחד התפקידים של הסקראם מסטר הוא לדאוג לכך. המשפט “דברו על זה אח”כ” הוא משפט נפוץ בישיבות יומיות של צוותים מתחילים.
  • אין בעיות – בעיה נוספת שנתקלתי בה היא שלאף אחד אין בעיות (או לפחות הן לא נאמרות בישיבה היומית), זאת בעיה שבד”כ מצביעה על בעיה עמוקה הרבה יותר, דרך טובה להבין את מקור הבעיות היא הרטרוספקטיבה. דוגמאות לבעיות כאלה הן:
    • המקרה הכי קל אולי הוא כאשר חברי הצוות מיואשים מלהעלות בעיות עקב העובדה שבעיות שנאמרו לא נפתרות בכל מקרה. הפתרון כאן הוא פשוט יחסית – להתחיל להסיר מכשולים של הצוות ולתת לו כלים לפתרון הבעיות.
    • חברי הצוות אינם מרגישים בטוחים מספיק בתוך הצוות ומפחדים להעלות בעיות מחשש שזה יוריד מההערכה אליהם. כאן הפתרון הוא קצת יותר קשה ויש לעזור לצוות לבטוח אחד בשני ע”י בניית סביבה תומכת.
    • מקרה שלישי הוא שהצוות כל כך טוב שהבעיות כולן מטופלות ונידונות מייד כשהן קורות ואין צורך לדון בהן כלל (למרות שאני וגם אחרים ששאלתי לא נתקלו בצוות כזה מעולם).

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

טוב. ישיבה נעימה :)

אלמנטים של סקראם והפעם…. שקיפות

מה שקיפות עכשיו ? זה אלמנט ? אז באופן פורמאלי לא, אבל אם תשאלו אותי (ואם אתם קוראים כנראה שאלתם) אז שקיפות זה יתרון אדיר של סקראם.
מה הכוונה שקיפות ? הכוונה היא שניתן בכל רגע נתון ובמאמץ מינימאלי להבין את מצב הפרויקט, מצב הספרינט, מצב ה-release וכו’ – איך ? זה כבר סיפור אחר. פשוט, אבל אחר. כדי להמחיש שקיפות אני אשתמש ביותר תמונות ממילים – את התמונות אני צילמתי מחדרים של צוותי סקראם.

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


דוגמא לגרף ספרינט (אמיתי לחלוטין)

מצב הפרויקטrelease משתקף באותה צורה פחות או יותר (מי אמר פשטות ?), ויש שנוהגים לתחזק את ה-backlog על הקיר באמצעות ניירות, פתקים וגרף מצויר בטושים, ויש שנוהגים לנהל את לנהל את הדרישות ואת הפרויקט (שם אחר ל-backlog) באמצעות מיני כלים שונים וביניהם excel.
האקסל הוא כלי פשוט שנותן בקלות לתחזק את רשימת הדרישות ואת גרף ה-Burndown של הפרויקט, ואף ניתן למצוא באינטרנט תבניות שונות לכך (הוספתי לקישורים).
השקיפות באה לידי ביטוי ע”י כך שמעבר לכך שהמידע הוא פשוט להבנה ואינו דורש יכולות של הבנת תרשימים מורכבים, הוא גם חשוף לכל ומתעדכן בזמן אמת.

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

מצב ראשון: ספרינט 2, התקדמות כצפוי, נראה שנסיים אחרי 7 ספרינטים:
clip_image004

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

עוד המחשה לשקיפות היא שפירוט המשימות ברמת הספרינט הוא זמין ונראה לכל עקב כך שמתוחזק על גבי לוחקירטבלת אקסל. (בניגוד לאחרות התמונה הזאת לא שלי…)

ישנם עוד מססר אלמנטים שמקובל לשקף בשיטות דומות.
זהו. שקיפות. יתרון גדול של סקראם!

אלמנטים של סקראם והפעם… Sprint.

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

  • קל להיות גמישים ולשנות את תכולת המוצר כאשר מחזור הפיתוח הוא קצר, פשוט בגלל שבסוף כל מחזור המוצר אמור להימצא במצב שהוא פוטנציאלית מוכן למשלוח.
  • כאשר מפתחים בצורה קלאסית, בד”כ ניתן לראות תוצאות ולקבל ביקורת כל מספר חודשים, כאשר מחזור הפיתוח הוא קצר, ניתן לראות תוצאות מהר מאוד וע”י כך להגדיל את תחושת ההישגיות של הצוות.
  • כאשר מפתחים במחזורים קצרים ניתן לראות מהר מאוד כי הפרויקט אינו מתקדם בצורה הרצויה, ניתן לראות את הבעיות מיד ואין צורך לחכות לשלב מתקדם בפרויקט כגון נקודת ציון (Milestone) או שלב הבדיקות (Verification).
  • כאשר מפתחים במחזורים קצרים, באופן אוטומטי הגישה של הצוות משתנה והמוכנות הפסיכולוגית לשינוי עולה.
  • אז מה זה למעשה ספרינט של סקראם ומה הוא כולל ?
    ספרינט הוא מחזור פיתוח באורך של בן שבועיים לארבעה (ככל שהצוות מיומן יותר כך ניתן לקצר את אורך הספרינט), הוא מתחיל בישיבה שנקראת Sprint planning (עוד יהיה פוסט) שבה מחליטים ביחד, הצוות והאחראי על המוצר (Product owner) על איזה פריטים מתוך ה-product backlog הצוות מתחייב לפתח עד סוף הספרינט, בנוסף מגדירים ביחד מה המשמעות של פריט מוכן, ומחליטים על מטרה לספרינט (Sprint goal), אחרי הישיבה הצוות ניגש לעבודה.
    במשך הספרינט הצוות מקבל שלושה דברים: סמכות מלאה, תמיכה ושקט תעשייתי:

  • סמכות מלאה לקבלת החלטיות טכניות שקשורות לביצוע המשימות
  • תמיכה בפיתרון בעיות שהצוות נתקל בהן ואין בכוחו לפותרן – למשל השלמת ידע בתחום מסוים, חוסר בחומרה ספציפית וכדומה.
  • שקט תעשייתי משמעותו שהצוות למעשה “מוגן” מהתערבויות חיצוניות במהלך הספרינט, התערבויות משמעותן שינוי המשימות שהצוות התחייב עליהן, שינוי המשאבים או מצב כ”א של הצוות. עליי לציין שישנם מצבים שבהם הצוות מסכים מראש בתחילת הספרינט לרמה מסוימת של הפרעות.
  • בכל יום במהלך הספרינט מתכנס הצוות לישיבה שאורכה לא עולה על 15 דקות (בד”כ פחות) ובה כל אחד מחברי הצוות מעדכן את הצוות בשלוש שאלות : מה עשיתי מהישיבה הקודמת עד הנכחית? מה אעשה מעכשיו עד השיבה הבאה? האם משהו מפריע לי לביצוע המשימות? על הישיבה היומית (daily standup meeting) עוד נדון בהרחבה בפוסט משלה. בנוסף במהלך כל יום בספרינט מקובל שמעדכנים את גרף “שריפת העבודה” Burndown chart, גרף זה למעשה מייצג את התקדמות הצוות בצורה פשוטה לעדכון, ויזואלית וקלה להבנה.
    בסוף הספרינט הצוות מציג את ההתקדמות ואת העמידה בהתחייבויות בישיבת ה-sprint review, כמו כן הצוות מקיים ישיבת רטרוספקטיבה (sprint retrospective) שבה הצוות בוחן את הספרינט האחרון ואת הנקודות לשימור ולשיפור, שאחריה למעשה מתחיל ספרינט חדש.

ישנם נושאים נוספים שנוגעים למעשה לספרינט ולמהותו, אך בשלב זה שבו אנו עדיין דנים בבסיס של הדברים ארצה להתייחס רק לאלמנט אחד חשוב, כתבתי שהצוות מקבל שקט תעשייתי ושלא משנים לו את המשימות, הרכב הצוות וכו’, אך מה לעשות, אנחנו מדברים על חברות כלכליות וישנם מקרים יוצאי דופן בהם למשל מה שהצוות עושה במהלך הספרינט הופך ללא רלוונטי עקב שינוי דרמטי במבנה הפרויקט או מצב שבו חייבים אנשים מהצוות ע”מ להציל פרויקט אחר וכו’, במצב כזה ניתן להפסיק את הספרינט באמצע, מצב כזה מכונה הפסקת ספרינט אנורמאלית (Abnormal sprint termination) אך יש לקחת בחשבון שכאשר מבוצע מהלך שכזה אז כל העבודה שנעשתה במהלך הספרינט
“נזרקת לפח”, התנאי הזה קיים ע”מ לגרום לביטול ספרינט להיות דבר נדיר ולגרום לגורמים שמחליטים על ביטול ספרינט לחשוב מספר פעמים ושקול את האפשרות של בכל זאת להמתין לסיום הספרינט שהרי מדובר לכל היותר בארבעה שבועות ובד”כ פחות.

שאלות ?