Posts tagged ‘סקראם’

היה הסקראם מסטר של עצמך

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

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

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

עד כאן איך לא.איך כן?

תתחילו בבית (תיקון*: תתחילו בעצמכם במקום העבודה)

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

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

image

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

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

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

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

הגודל כן קובע

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

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

 

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

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

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

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

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

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

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

רוצים ללמוד סקראם?

בתאריך 25-26 לאוקטובר אני פותח בשיתוף עם פסיפיק תוכנה קורס סקראם ציבורי לקהל הרחב.

אני מזמין אתכם לקחת חלק בקורס וללמוד ביחד איתי ועם עוד משתתפים על הדברים הבאים:
– ההיסטוריה של סקראם ואג’יל.
– המניפסט האג’ילי.
logo -  מה זה סקראם?
– איך עובדים בסקראם?
– התפקידים:
     *הצוות
     *הסקראם מסטר
     *מנהל המוצר – Product owner.
– הטקסים והישיבות:
     *תכנון ספרינט
     *הישיבה היומית
     *סיום הספרינט
     *רטרוספקטיבה.
– התוצרים: ספרינט בקלוג, ניהול דרישות תוך שימוש בבקלוג מוצר.
– תהליך הפיתוח בסקראם: שיטת פיתוח אג’יליות.
– תכנון פרויקט בסקראם.
– הערכת מאמצים בעולם אג’ילי.
– עבודת צוות: צוותים מנוהלים עצמאית.
– סקראם בארגוניםמוצרים מרובי צוותים.
– ועוד…

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

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

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

עדיין ניתן לקבל הנחת רישום מוקדם עד ה-10 לאוקטובר. צרו איתי קשר למימוש ההנחה.

פרטים נוספים והרשמה ניתן למצוא בקישור הבא: http://pacificsoft.co.il/course.asp?p=664&s=1210

ממוצע הציון שהתקבל בקורס האחרון שהעברתי הוא : 4.4 מתוך 5.

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

לא בשביל כסף

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

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

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

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

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

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

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

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

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

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

 

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

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

מיפוי מח של סקראם מסטר

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

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

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

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

Scrum master's mindmap

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

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

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

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

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

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

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

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

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

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

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

עמוד נח.

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

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

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

הוא כתב:

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

אני עניתי

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

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

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

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

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

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

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

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

אלעד.

הוא ענה:

הי אלעד,

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

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

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

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

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

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

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

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