Posts in Agile – אג’יל

סקראם אוף סקראמס? שלא יעבדו עליכם

ההתחלה

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

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

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

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

התחיל ספרינט ראשון:

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

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

אחרי שעברנו לפיצ’ר טימס

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

הדילמה

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

image רשת בטחון?

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

  שורה תחתונה

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

מקור התמונות :
* אמזון
* http://www.flickr.com/photos/kj-an/2299557485/

בואו נדבר על…. הספרינט

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

מצד שני…

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

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

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

איך עושים את זה? (הפיסקה הבאה לא מומלצת למנהלים בעלי לב חלש)

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

עצור רגע… בכל זאת בסקראם אמורים להשתפר ולהגביר את הקצב עם הזמן לא?

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

*מקור התמונות:
http://www.flickr.com/photos/gareth1953/5992046962/
http://www.flickr.com/photos/hiddenloop/2043964184/

נא לחלק לשתיים לפחות (גם אם לא חייבים)

יש רגעים כאלה שנדלקת המנורה מעל הראש ואתה אומר לעצמך ״איך לא חשבתי על זה קודם?״ בשבוע שעבר היה לי אחד כזה…

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

  • הפיצ׳ר בלי התייחסות לדהל״פ : בתור לקוח אני רוצה לקבל חיווי על אירועים שקורים במערכת.
  • הפיצ’ר עם דהל״פ : בתור לקוח אני רוצה לקבל חיווי על X אירועים שקורים במערכת ב-T זמן (לדוגמא בשניה).

מדוע זה עובד?

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

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

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

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

בואו נדבר על… פיתוח מונחה בדיקות קבלה (ATDD)

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

אז עכשיו תגידו: כמה גרסאות שונות יש לכם לאותה דרישה?

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

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

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

אז מה עושים?

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

שימור של ידע

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

מתי מגדירים את המסמך?

בד״כ כלל את הפירוט של הדוגמאות מגדירים כחלק מתהליך הגדרת הפיצ׳ר, בסקראם הזמן המתאים לכך היא ישיבת טיפוח הבקלוג (grooming).

דוגמא

בשביל להמחיש איך זה נראה וכמה זה פשוט לקריאה וידידותי למשתמש אני מצרף דוגמא אמיתית של תיאור פיצ׳ר בשיטה הזו. הדוגמא הזו היא עם Cucumber שהוא נכון להיום הכלי החביב עליי. קבלו דוגמא מתוך פרוייקט אמיתי שמצאתי ב-GitHub, הפרויקט נקרא Dispora וזהו פרויקט קוד פתוח של רשת חברתית, הפיצ’ר שמתואר בדוגמא הזאת הוא…. בעצם תקראו ותראו אם אתם מבינים לבד :) ליחצו על התמונה לראות אותה בגודל המקורי… והקריא

כלים:

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

*מקור התמונה : http://www.flickr.com/photos/newtown_grafitti/5427334245/sizes/z/in/photostream/

בואו נדבר על… הצעות מחיר

Agile - אג'יל

May 29, 2012

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

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

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

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

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

בשביל לפתח תחילתו של פתרון אנחנו צריכים 3 אנשי פיתוח לשבוע + איש מוצר = 4 שבועות אדם. לא מעט. 
אבל כמה יעלה בשיטה הרגילה? בואו נחשב:
אנליזה של הדרישות – 1 שבוע.
הערכות מאמצים – 3 ימים x מספר הצוותים המעורבים. נגיד 5 צוותים – 3 שבועות.
ואו. יצא אותו הדבר! ברור, שהחישוב שלי לא מדויק, אבל גם ברור שהעלויות הן די דומות.

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

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

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

* מקור התמונה: http://www.flickr.com/photos/7438870@N04/1446756751/

בואו נדבר על… רטרוספקטיבות

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

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

לפני שאני צולל אני רוצה לחלוק אתכם את ה- Retrospective prime directive שניסח  Norm Kerth:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand

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

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

ישנן הרבה מאוד דרכים לקיים רטרוספקטיבה אבל לכולן פחות או יותר מבנה משותף:

  1. פתיחה
  2. איסוף נתונים
  3. יצירת רעיונות
  4. קביעת משימות לביצוע.

פתיחה

הפתיחה כשמה כן היא, תפקידה לעזור לצוות להיכנס לאווירה המתאימה ולהתמקד.היא לא אמורה לקחת יותר ממספר דקות בודדות. בד״כ בשלב זה בין השאר סוקרים את המשימות שנקבעו ברטרוספקטיבה הקודמת (ראו בהמשך). פעילות אפשרית לשלב זה היא check-in

איסוף מידע

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

יצירת רעיונות

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

קביעת משימות לביצוע

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

טיפים לביצוע יעיל של רטרוספקטיבה:

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

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

*מקור התמונות :
http://www.flickr.com/photos/linkey/2752696822/
http://www.flickr.com/photos/chodhound/4489875318/sizes/z/in/photostream/

ספרינט ריוויו אמיתי

show and tell

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

מספר טיפים נוספים לספרינט ריוויו אמיתי:

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

מעבדות לחירות עאלק!

 

פסח בפתח, זמן מצוין לדבר על יציאה מעבדות לחירות.

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

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

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

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

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

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

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

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

חג שמח.

זה לא עבודת צוות כש…

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

Team Spirit starring Superman

זה לא עבודת צוות כשמרגישים שזה לא עבודת צוות.

אני לא יודע

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

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

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

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

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

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

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