Posts tagged ‘sprint’

ספרינט בקלוג – Smells

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

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

בפוסט הזה אני הולך לדבר על ריחות של ספרינט בקלוג – Sprint backlog smells .

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

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

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

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

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

חד גוני – בהנחה שהספרינט בקלוג נמצא על הקיר (או על מסך פלזמה גדול), אם כולו מורכב מפתקים בצבע אחד, קשה באמת להבין איך הוא מתקדם, איזה פריטים נמצאים בעבודה ומה ההתקדמות של כל אחת מהמשימות. לספרינט בקלוג חד גוני יכולות להיות שתי סיבות עיקריות:
1. הספרינט מורכב רק ממשימה אחת מתוך בקלוג המוצר (Product backlog).
2. הספרינט מורכב ממספר משימות מתוך בקלוג המוצר (Product backlog) אבל אתם משתמשים באותו סוג של פתק לכל המשימות.
בכל אחד מהמקרים אפשר להריח בעיה: במקרה הראשון ישנה בעיה שהפריטים ב-Product backlog כנראה גדולים מידי, במקרה השני ישנה בעיה לקרוא את הבקלוג מבלי לצלול לפרטים, שאת רוב האנשים לא מעניינים.
יש סייג אחד לסעיף הזה, אם הבקלוג הוא טבלה שמחולקת לשורות שכל שורה מייצגת פריט מתוך ה-Product backlog, אז הוא יכול להיות חד גוני.

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

פתקים “ברוורס” – אם רואים לעיתים קרובות מידי פתקים עושים “פניית פרסה” וחוזרים מעמודת “Done” לעמודת “In work”, זה עלול להעיד אולי על בעיתיות בהשלמת המשימות, ואולי על בעיה בהגדרת המשימות עצמן.

יותר מידי פריטים במקביל – אם רואים שיש יותר מידי פריטים מטופלים במקביל זה בד”כ מעיד על בעיה, זה יכול להיות שמשימות תקועות, יכול להיות שאנשים עובדים על מספר משימות במקביל, וזה יכול להעיד על בעיית ריכוזיות.

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

שאלות ?