Posts in הרגלי עבודה אג’ילים

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

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

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

לפני שאני צולל אני רוצה לחלוק אתכם את ה- 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/

יש לנו הרבה מה ללמוד מפקידות קבלה

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

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

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

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

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

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

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

מעניין למה?

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

הגודל כן קובע

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

עמוד נח.

צוותי פיצ’ר – Feature teams

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

component_teamרוב הארגונים שאני פוגש עדיין עובדים במבנה צוותים שמבוסס על מודול או קומפוננט. המונח המקצועי הוא Component team.
כלומר, במצב שבו יש מספר קומפוננטות במערכת, למשל: GUI, BL, SERVER, INFRA אז כל צוות הוא מומחה בקומפוננט מסוים. קלאסי.

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

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

נתחיל מדף חלק – יום 0 של הפרויקט.
יש לנו רשימת פיצ’רים לגירסה הקרובה, חמישה במספר. הפיצ’רים הללו לא דורשים רמת מאמץ זהה מכל הצוותים, יש פיצ’רים שדורשים יותר עבודה ב-Gui ויש כאלה שיותר עבודה ב- Server וכו’. הנה דוגמא: הטבלה מציגה עבור כל פיצ’ר את התפלגות המאמץ באחוזים לפי מודול.

מספר פיצ’ר A B C D
1 20 30 50 0
2 40 20 0 40
3 0 80 20 0
4 50 0 50 0
5 20 0 70 10

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

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

מה האפשרות שרוב הארגונים לא שוקלים (אולי כי הם לא מכירים אותה) לשנות את המבנה של הצוותים כך שלא יהיה מאורגן לפי מודולים אלא לפי איזורים פונקציונאליים, או כפי שקוראים למבנה הזה בשפה המקצועית: צוותי פיצ’ר -  Feature teams.

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

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

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

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

זה גדול מידי.

imageאתם עובדים בסקראם. ספרינטים של שבועיים. הצוותים בנויים נכון (Feature teams). יש לכם בקלוג. בבקלוג של דרישה של לקוח, ואפילו בפורמט של סיפור לקוח (User story). כבוד!

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


תזכורת: סיפור לקוח הוא מהזוית של הלקוח ומשמעותו – משהו שאפשר ממש להדגים ללקוח)


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

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


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

1. בתור אדמיניסטרטור אני רוצה אפשרות לשלוח הודעה למסך של כל המשתמשים במערכת
2. בתור אדמיניסטרטור אני רוצה אפשרות לשלוח הודעה למסך של משתמשים במערכת אשר שייכים למחלקה מסוימת.
3. בתור אדמיניסטרטור אני רוצה אפשרות לשלוח הודעה למסך של משתמשים במערכת בעלי תפקיד מסוים
…..

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


דוגמא 2 – עיבוד תמלילים: בתור משתמש אני רוצה להיות מסוגל לשמור את הקובץ שלי במיקום ובשם ע”פ בחירתי.

1. בתור משתמש אני רוצה לקבל הודעה כששם הקובץ שבחרתי לא חוקי
2. בתור משתמש אני רוצה לקבל הודעה כשאין מספיק מקום אחסון בדיסק.
3. בתור משתמש אני רוצה לקבל הודעה כשאין לי הרשאות שמירה.
4. בתור משתמש אני רוצה לשמור את הקובץ למקום מוגדר מראש
5. בתור משתמש אני רוצה לבחור את המיקום של הקובץ
6. בתור משתמש אני רוצה לבחור את שמו של הקובץ

שברנו את הסיפור שוב ע”י שימוש בשתי טכניקות: הראשונה היא למצבי שגיאה (1-3) זה בעיקר שימוישי לסיפורים מורכבים מאוד. הטכניקה השניה היא ע”י התחלה מפיצ’ר עם מגבלות קשות (מה שנקרא Hard coded) והסרתן של המגבלות אחת אחרי השניה.

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

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

שיטת הקבנוס

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

פיתוח תשתיות תוכנה – INFRA
פיתוח Backend
פיתוח Business logic
פיתוח Frontend
פיתוח UI
בדיקות.

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

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

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

kabanosדוגמא להמחשה:
אם יש לי דרישה לניהול מאגר לקוחות, ניתן
לחלק אותה למשל ל-3 דרישות קטנות יותר: 
1. הוספת לקוח 
2. עדכון פרטי לקוח
3. מחיקת לקוח.

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

טוב, חסרים שני חלקים לפאזל הזה:
1. הסבר מקיף יותר על Feature teams.
2. הצד המעשי של איך מחלקים פיצ’ר.

בפוסטים הבאים….

סיפורי לקוח – User stories

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

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

1. יושבים אנשי השיווק עם אנשי ה-System ומנסים להבין איך יעבוד הדו”ח היומי, איזה שדות יהיו בו, איזה פעולות צריך המשתמש לבצע
2. את התובנות שלהם, הם הופכים למשהו שהפיתוח “יבינו” שהרי הנחת יסוד היא שהפיתוח לא מבין כלום חוץ מפיתוח.
3. את המשהו שהמפתחים מבינים, המפתחים הופכים לקוד, שבסופו של דבר הופך לפונקציונליות במוצר.
4. כשהפיתוח הסתיים מראים לאנשי המוצר את התוצאות, והם בד”כ טוענים שלא בדיוק לזה הם התכוונו…
5. הפיתוח מבצע מקצה שיפורים.
6. מראים שוב לאנשי המוצר. הפעם זה טוב.
7. כשיוצאת גרסה, אנשי המוצר מציגים ללקוח את המוצר בגרסתו החדשה עם הפונקציונליות שביקש. הוא אומר שזה לא בדיוק מה שהתכוון. חוזרים לסעיף 2 עד שמישהו מתייאש, או שעבר כל כך הרבה זמן שהפיצ’ר כבר לא רלוונטי יותר.

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

<As a <user type> I want to <do/get somthing> so that <reason
בתור <סוג לקוח> אני רוצה ש<משהו יקרה> על מנת ש<סיבה>

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

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

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

באגים יש?

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

image

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

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

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

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

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

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

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

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

Software Craftsmanship – מפגש 7

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

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

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

במרכז המפגש היו שני נושאים:
– שפות דינאמיות מול שפות סטטיות.
– DSL’s.

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

ההרצאה השניה היתה בנושא DSL והעברה ע”י דרור הלפר מ-Better place.
דרור הסביר בקצרה מה זה DSL והציג את הסוגים השונים הקיימים.
בהמשך הוא נתן דוגמא יוצאת מין הכלל לדעתי ל-DSL: הנה היא לפניכם:
The next release candidate would contain features X, Y & Z and no more than five high priority Bugs and no show stoppers

22032011455

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

 

 

החלק השלישי היה כרגיל עבודה מעשית: התבקשנו לממש DSL למערכת של חוקים עבור עגלת קניות, החוקים הם בסגנון הנחות ומבצעים שונים:
– 1+1 למוצר מסוים.
– קניתה מוצר X קבל מוצר Y ב-15% הנחה.
– ללקוח VIP מגיע הנחה מסוימת קבועה.
– וכו’

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

מצפה בקוצר רוח למפגש הבא.