התשמע קולי?

Agile Practitioners IL, כללי

September 23, 2012

זה רשמי.
ב-29 וב-30 לינואר יתקיים בשנה השניה כנס ה-Agile Practitioners בכפר המכביה. כמו שנה שעברה גם הפעם בכנס יופיעו מרצים בינלאומיים לצד מרצים מהקהילה האג׳ילית המקומית.
נושא הכנס השנה הוא ״אג׳ייל מעבר לצוות״. אנחנו רגילים לדבר להציג ולהתעסק בצוות, בעבודתו, בממשקים שלו, מנוהל או לא מנוהל, עם בודקים או בלי ועוד ועוד…לא הפעם.

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

הנושאים יכללו דברים כגון:

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

ועכשיו לחלק החשוב:

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

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

CFP-APIL13_128

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

הבטחות לשנה החדשה

Uncategorized

September 13, 2012

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

ו….

  • אני מבטיח שלפחות בהבטחה אחת אני לא אעמוד (אולי זאת האחת….)

שנה טובה לכולם!
אלעד.

Shannah Tovah 2012

שיפור מתמיד…

Uncategorized

September 12, 2012

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

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

אז הנה. עדכנתי.

תודה רבה לך רועי !!!

איזה כיף שיש קוראים כמוך.
שנה טובה.

כמה זמן זה מפה לקהיר?

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

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

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

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

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

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

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

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

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

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

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

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

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

בואו נדבר על… צוותי פיצ׳רים

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

אבל מה זה כן?

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

אז מה הבעיה? למה לא כולם עושים את זה?

הנה כמה סיבות שאני שומע:
  • בצוות כזה אין חלוקה שווה של העומס בין המפתחים – הגיוני, הרי יש פיצ׳רים שדורשים יותר חלק אפליקטיבי ויש כאלה שדורשים יותר פיתוח תשתיתי, יש כאלה שדורישם יותר בדיקות וכאלה שזקוקים בעיקר לקונפיגרציה. אבל מתוך הנחה שרוב הפיצר׳ים דורשים התייחסות בכל החלקים, מישהו מוכן בבקשה לקום ולהסביר לי איך הבעיה הזאת נפתרת כשהאנשים המעורבים יושבים בצוותים שונים? להיפך עבודה בצורה כזו תציף את הבעיה של חוסר איזון בין ההתמחויות ולא תחביא אותה בתוך מבנה ארגוני מסובך.
  • אנשי תוכנה לא יודעים לבדוק כמו שצריך – בואו לא נכנס לוויכוח אם זה נכון או לא ונשאל האם זה בכלל רלוונטי, אם למשל מומחה הבדיקות שלנו מגדיר את הבדיקות שצריכות להתבצע והמתכנת מוציא אותן לפועל, או אם מומחה הבדיקות כותב את הרמה העליונה של האוטומציה (ATDD) והתוכניתן כותב את ה-fixtures.
  • איש ה-QA לא יכול לכתוב קוד – באמת? הפעם דווקא בא לי להתווכח, יש לא מעט אנשי בדיקות שכן יודעים, או שלא יודעים ורוצים ללמוד, אני לא מציע לכם לתת לאיש בדיקות לגעת ללא עזרה באיזורים רגישים בקוד, בדיוק כמו שלא הייתי מציע לכם לאפשר את זה למי שרק סיים אוניברסיטה, אבל בהחלט אפשר להיעזר גם באזני בדיקות בכדי לכתוב קוד במידה והם מעוניינים בכך. גם אם איש הבדיקות לא רוצה לכתוב קוד ישנן עוד משימות שיש לבצע, כתיבת מסמכים, ייצוג הצוות בישיבות, התקנות, אדמיניסטרציה ועוד.
  • תוכניתן A הוא מומחה בשפה מסוימת – אז מה? תוכניתנים לא מחליפים שפות? לא לומדים דברים חדשים? מישהו שיודע שפת C לא יכול לעזור קצת עם ג׳אווה או עם #C? אני גם חושב שזה אפילו כדאי, ראוי ואפילו חובה להרחיב אופקים וללמוד דברים חדשים.
ישנן עוד לא מעט סיבות ״לא לעבוד בצוותי פיצ׳ר״, ואתם מוזמנים להוסיף כאלה בתגובות.
לפני שאני מסיים את הפוסט הזה (והולך לישון – כבר 2 בלילה!!!) אני רוצה לתת סיבה אחת למה כן כדאי, יש הרבה אבל אני רוצה להתמקד באחת:
אין צורך באינטגרציה
בתור מי שמפתח תוכנה כבר לא מעט שנים אחת הבעיות הכי כואבות שאני מכיר היא אינטגרציה, השלב המקולל הזה שאני מתחיל אותו כשגם אני וגם האדם שמולי בטוחים שסיימנו את העבודה ורק נשארו שעה שעתיים לחבר את החלקים, אותו שלב מקולל שדורש ששנינו נהיה פנויים, אותו שלב מקולל שבו מגלים ששום דבר לא באמת עובד, אותו שלב מקולל שבו ממש כשהיגענו לקטע קריטי הוא צריך ללכת לישיבת צוות או משהו דומה… בצוותי פיצ׳ר זה לא קיים! בצוות כזה כל האינטגרציה מתבצעת בתוך אותה יחידה קטנה שנקראת צוות. אותו צוות שיכול להרשות לעצמו לבצע כל הזמן אינטגרציה. איזה כיף זה.
אשמח לשמוע מה לכם יש להגיד בנושא.
מקור התמונה : http://www.flickr.com/photos/35168673@N03/5796777205/in/photostream/

להגיע לפסגה

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

אני בהחלט חושב שהנקודה שיובל העלה בהחלט שווה התייחסות.

להטמעת סקראם יש לטעמי שלושה שלבים עיקריים:

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

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

אם עשיתם רק את שלב הלימוד…

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

אם המשכתם לשלב ההטמעה…

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

אבל אם אתם בשלב הניסויים…

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

המלצתי היא:

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

 

מקור התמונות:
 http://www.flickr.com/photos/jinglesthepirate/2885330439/
http://www.flickr.com/photos/tuchodi/4901707346/

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

ההתחלה

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/