Posts tagged ‘Scrum’

שיטת הקבנוס

כמעט ברור וטריוויאלי שהדרישות שאנו מקבלים לפיתוח הן גדולות מידי בשביל לתכנן ולהוציא לפועל ב”חתיכה אחת”. לכן רוב הארגונים מחלקים את הדרישות ליחידות ביצוע קטנות יותר.
אז 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 אחת התפיסות שקיימות בעולם היא שבשביל להצליח צריך לעבוד קשה, שמי שרוצה להגיע למשהו בחיים, צריך לעבוד הרבה. כלומר – מי שעובד יותר מרוויח יותר. טעות!

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

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

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

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

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

יום העצלנות הבינלאומי

ביום זה כל פועל ופועלת (לפחות בתחום ההיטק) מצווים לחדול מהעיסוק היומיומי השגרתי של כתיבת קודביצוע בדיקותכתיבת מסמכים וכו’

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

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

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

image

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

לסיום דוגמאות לעצלנות קלאסית:
– במקום לבצע חלק ניכר מהבדיקות באופן ידני כל פעם מחדש, לכתוב אוטומציה שמבצעת זאת בשבילכם בזמן שאתם משחקים ברשת באתרים כגון http://www.escapegames24.com/
– במקום לכתוב מסמכים שמתעדים את הקוד ואת הדיזיין, להשתמש בכלים שעושים זאת עבורכם כגון JavaDoc.
– במקום לכתוב כל פעם קוד חדש מאפס, להשתמש בסיפריות שנכתבו כבר ובדוגמאות, ניתן להיעזר באתרים כגון http://stackoverflow.com/

יאללה, לכו לנוח.

באגים יש?

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

image

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

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

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

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

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

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

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

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

עשרת המכות

אֵלּוּ עֶשֶׂר מַכּוֹת שֶׁהֵבִיא הַקָּדוֹשׁ בָּרוּךְ הוּא עַל חברות התוכנה בְּמִצְרַיִם, וְאֵלּוּ הֵן:

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

 

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

 

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

 

image 4. ערוב – לפי חלק מן הפרשנים המודרניים יותר הכוונה למכרסמים או מזיקים שעלולים להרוס את הארץ – מכירים את המכרסמים האלו? אלה שמסרבים ללמוד דברים חדשים? לא מוכנים לשמוע על Unit test או Refactoring, מה שכן הם תמיד ישמחו לכתוב את התשתית החדשה. תעצרו אותם לפני שיהיה מאוחר מידי!

 

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

 

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

 

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

 

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

 

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

 

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

 

חג שמח!!!image

כמה זה מספיק ?

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

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

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

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

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

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

דוגמא לבקלוג עם רמת תכנון לא עקבית – לחצו על התמונה להגדלה:
clip_image004

דוגמא לבקלוג עם רמת תכנון עקבית – לחצו על התמונה להגדלה:
clip_image006

שלא יעבדו עליכם…

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

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

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

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

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

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

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

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

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

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

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

בקיצר, שלא יעבדו עליכם….

את מי כן הייתי מעסיק ?

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

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

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

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

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

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

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

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

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

כלים אג’ילים – יש דבר כזה?

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

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

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

נסקור את הסיבות לשימוש ב”כלים אג’ילים” שאני נתקל בהן:

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

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

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

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

עקרון חשוב ומנחה במניפסט האג’ילי (עקרון 5) הוא:

Build projects around motivated individuals, give the environment and the tools they need, and trust them to get the job done.

עקרון נוסף חשוב (עקרון 11) הוא:

The best architectures, requirements and design emerge from self-organizing teams

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

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

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

לסיום אני רוצה לצטט משפט מתוך ספר של בס וודה וקרייג לרמן:
If you automate a mess, you will get an automated mess.

אני לא הייתי מעסיק את סופרמן

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

מכירים אותו ?

אני די משוכנע שאתם מכירים אותו.

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

imageאני לא הייתי מעסיק אותו.

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

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

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

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

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

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

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