Posts tagged ‘רטרוספקטיבה’

תמיד מאשימים את ה-ש.ג. ובצדק.

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

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

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

כמובן שדוגמת ביה”ס היא לא מושלמת, אבל היא מתאימה.

מידי פעם, מישהו מחליט על שינוי, שינוי תהליך, שינוי בשיטות עבודה, מעבר לסקראם, שינוי לצוותים מנוהלים עצמאית, מעבר ל-TDD, מנסים CI, לנסות Pair programming, וכדומה.
אין לי סטטיסטיקה אבל לפי ניסיוני לפחות בחצי מהמקרים השינוי לא מצליח בטווח הארוך, צוות הסקראם מפסיק לעשות רטרוספקטיבות ודיילי, ראש הצוות בסוף כן אומר לצוות מה ואיך לעשות, כותבים בדיקות אחרי הקוד ולא לפניו, הבילד אדום במשך ימים שלמים ואף שבועות, וכו’.

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

איך שומרים על שינוי, או, איך שומרים עלינו מעצמינו?

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

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

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

עמוד נח.

באגים יש?

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

image

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

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

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

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

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

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

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

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

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

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

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

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

תפיסת ה-“בחינה והתאמה” מיושמת בסקראם באמצעותה של ישיבה שמתבצעת בסוף כל ספרינט ונקראת רטרוספקטיבת הספרינט (Sprint retrospective).

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

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

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

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

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

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