Posts tagged ‘Agile’

מה לגבי הלקוחות?

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

אולי זה אבוד ואין שום סיכוי אמיתי למשפט האידילי וחסר האחיזה במציאות customer collaboration over contract negotiation, אולי זה בכלל רק עניין ישראלי ובעולם זה שונה? המון שאלות יש לי…

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

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

Image Detailהסעיפים הם אלה:

– יש לאפשר ללקוח בכל עת לשנות את התכולה של הפרויקט ע״י החלפה של תכולה בתכולה חדשה שדורשת את אותה כמות מאמץ וללא עלות נוספת.

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

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

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

אני אשמח לשמוע רעיונות שיש לכם בנושא.

שנה טובה.

לא בשביל כסף

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

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

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

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

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

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

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

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

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

שלא תבינו לא נכון – אני לא מתנגד להתקשרות עסקית על בסיס של מחויבות הדדית ותגמול ע”פ הצלחה (Win-Win) אבל אל תפלו בפח.

 

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

הבהרה מס’ 2: לא כל יועץ אג’ילי מתאים לכל חברה יש עניין של “כימיה”  – אם לא הצליח לכם עם יועץ מסוים זה לא אומר שהוא “מתחזה” למומחה..

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

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

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

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

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

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

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

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

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

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

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

עמוד נח.

מכתבים למערכת

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

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

הוא כתב:

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

אני עניתי

הי ישראל ישראלי.

שאלות קשות יש לך :)

אני אנסה להביע את דעתי.

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

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

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

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

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

אלעד.

הוא ענה:

הי אלעד,

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

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

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

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

תודה,
ישראל ישראלי

גם אני, ואני מאמין שגם “ישראל”, נשמח לשמוע את חוות דעתכם בנושא.

פגישה ראשונה – Agile practitioners IL

איזה יופי טופי!
זה קרה, המפגש הראשון שהתקיים אתמול במשרדי NICE ברעננה בשעה 17:30 בנוכחות של כ-40 אנשים. תודה רבה לאוהד ו-NICE על הארגון המופתי.

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

APIL1

מבחינתי היה מאוד מוצלח בגלל מספר דברים ואני אפרט:

באו 40 אנשים – לדעתי זה מספר מדהים, אני אמרתי לחברי לארגון הקהילה הזאת, אילן וליאור, שאם יגיעו 20 זה הצלחה אדירה למפגש ראשון, מניסיוני מקבוצות דומות 20 למפגש ראשון זו התחלה מצויינת, אז 40 ?! מעולה!

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

גיוון – היו אנשים ממגוון תפקידים: מפתחים, Product owners, Scrum masters בודקים, יועצים, בקיצר קשת רחבה ומגוונת של אנשים שמאפשרת, כפי שראינו, לייצר דיון פורה ומעניין.

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

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

APIL2

נ.ב. – מזל טוב לרועי מקונטרה שזכה בספר של יורגן אפלו.

מטריקות בע”מ

לפני כשבוע השתתפתי בקורס של יורגן אפלו בנושא ניהול ומנהלים בסביבה אג’ילית. שם הקורס הוא זהה לשם הספר שהוא כתב Management 3.0.

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

 photo

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

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

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

במסגרת הנושא יורגן הציג טבלה ובה שבע עמודות שמייצגות את הישויות שהארגון מייצר משהו עבורן, וכמו כן 7 פרספקטיבות של המשהו הזה, דברים כגון: זמן, כלים, ערך פונקציונליות ועוד, יורגן ביקש שנמצא KPI’s שונים בשביל למדוד את הדברים הללו.
לדוגמא: מדד לשימוש בכלים מהפרספקטיבה של האינדיבידואל יכול להיות “WTH(What the hell) Per minute” – למי שלא מבין, למדוד כמה פעמים בדקה אומר “מה לעזעזל?” מי שמשתמש בכלי מסוים.

photo

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

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

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

You get what you measure

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

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

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

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

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

זה קורה: Agile Practitioners IL

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

ביום שלישי ה-5 ביולי יתקיים המפגש הראשון של Agile Practitioners IL, מה זה אתם שואלים?

image

Agile Practitioners IL – זוהי קבוצה של אנשים (User group) שמתעניינים מתעסקים באג’יל ורוצים לשתף וללמוד אחד מהשני.

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

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

במפגש הראשון מתוכננים שני חלקים עיקריים:
החלק הראשון: הרצאה של עבדכם הנאמן על החשיבות של Feedback, שם ההרצאה הוא "Feedback – The secret ingredient of success"
החלק השני יוקדש לדיון פתוח על מטרות הקבוצה, ושאר מאפיינים שלה, דברים כגון: איזה תכנים אנחנו רוצים שיהיו בה, באיזה פורמט, באיזה שעות יהיו המפגשים וכו’.

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

אני מקווה שזו התחלה של הקמת קהילה אג’ילית ישראלית אמיתית. בהצלחה לכולנו.

זה גדול מידי.

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. הצד המעשי של איך מחלקים פיצ’ר.

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