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

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

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

הצטרפו אליי לקורס סקראם ב- 3-4/6/12 לחצו על הקישור לפרטים נוספים

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

הצטרפו אליי לקורס סקראם ב- 3-4/6/12 לחצו על הקישור לפרטים נוספים

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

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

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

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

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

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

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

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

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

חג שמח.

הצטרפו אליי לקורס סקראם ב- 3-4/6/12 לחצו על הקישור לפרטים נוספים

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

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

הצטרפו אליי לקורס סקראם ב- 3-4/6/12 לחצו על הקישור לפרטים נוספים

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

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

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

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

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

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

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

הצטרפו אליי לקורס סקראם ב- 3-4/6/12 לחצו על הקישור לפרטים נוספים

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

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

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

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

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

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

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

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

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

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

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

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

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

למה? ככה!

הצטרפו אליי לקורס סקראם ב- 3-4/6/12 לחצו על הקישור לפרטים נוספים

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

טוב נו, הוא לא באמת מדבר על ניהול פרויקטים, אבל זה מתאים טורבו.

הצטרפו אליי לקורס סקראם ב- 3-4/6/12 לחצו על הקישור לפרטים נוספים

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

לפעמים זה מענין רק בשביל הרכילות ולפעמים זה מענין כדי ללמוד ודעת מה להיזהר ומה כדאי לנסות. המפגש הקרוב של קבוצתינו היקרה Agile Practitioners IL  שיתקיים ביום ראשון הקרוב ה-4 למרץ 2012 יוקדש כולו לנושא הזה בדיוק, אחד אחרי השני יחלקו איתנו נציגים של חברת LivePerson שגם מארחים את המפגש, נציגים של חברת WebCollage ונציגים של חברת SAP את המשמעות של המלה אג׳יל עבורם.

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

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

הצטרפו אליי לקורס סקראם ב- 3-4/6/12 לחצו על הקישור לפרטים נוספים

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

איך עושים את זה?

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

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

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

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

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

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

תחילה נשאל מי הם ה״שחקנים״ שיכולים לעזור להגיע ליעד העסקי הזה:
1. לקוחות שכבר קונים בחנות – לקוחות קיימים.
2. מנהל החנות 
3. אנשים שמתדלקים בתחנת הדלק
4. אנשים שעוברים באיזור התחנה.
5. אנשים שגרים באיזור התחנה.

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

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

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

לסיכום

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

הצטרפו אליי לקורס סקראם ב- 3-4/6/12 לחצו על הקישור לפרטים נוספים

ואו! איזה כנס זה היה: מדהים, כיף ומעניין.

אז למי שלא היה על כדור הארץ (או לפחות בלינקדאין או בטוויטר) בחודשים האחרונים כדאי שאספר: בימים שני ושלישי ה-30/31 לינואר שנת 2012 התקיים בפעם הראשונה כנס שענה לשם:

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

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

אז מה היה? או מה אני עשיתי בכנס?

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

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

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

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

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

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

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

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

לסיום – מיני רטרוספקטיבה אישית:

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

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

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

נתראה ב -Agile Practitioners 2013 ….

הצטרפו אליי לקורס סקראם ב- 3-4/6/12 לחצו על הקישור לפרטים נוספים