Posts tagged ‘סקראם מסטר’

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

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

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

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

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

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

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

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

image

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

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

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

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

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

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

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

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

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

החסרונות של סקראם ע”פ Uncle Bob

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

ולאחרונה, בקבוצת הדיון של סקראם ביאהו (Scrum development) נסוב דיון בשאלה הנ”ל, בדיון הזה הציג מישהו את השאלה הזאת ולא למרבה הפלא, ענה לו לא אחר מאשר Robert.C.Martin הידוע גם בכינויו Uncle Bob. אני רוצה בפוסט זה ובתרגום חופשי, לתאר לכם את תשובתו של “הדוד בוב”:

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

1. חוסר בטכניקות טכניות. סקראם מצויין במתן הכוונה בכל הנוגע לניהול הפרויקט אבל אינו מסייע לתהליך הפיתוח עצמו, בכל הטמעה מוצלחת של סקראם ישנה השאלה של טכניקות משיטות אחרות כגון XP, השיטות שיש לצרף לשיטה הן כנראה: TDD, CI, Pair programming, Acceptance testing ו- Refactoring

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

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

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

5. סקראם לא מספק מספיק הכוונה לגבי מבנה ה-Backlog. למדנו במשך השנים שהבקלוג הוא רשימה היררכית של דרישות המורכב מ-Epics, themes, stories, גם למדנו דרכים טובות להעריך אותם באופן סטטיסטי, למדנו גם איך לשבור אותם.

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

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

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

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

איך זה מרגיש ?

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

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

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

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

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

אז איך זה מרגיש לעבוד בסקראם ?

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

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

להיות מוסמך או לא להיות מוסמך ?

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

image ככל שהזמן עובר, יותר ויותר אנשים מבקרים בצורות שונות את הרעיון של הסמכות שונות.
באופן אישי, אני חושב שיש תועלת בהסמכות כאלה ואחרות (רופאים, עורכי דין וכו’), אבל אופי ההסמכות הללו בד”כ מכיל בתוכו תנאים מקדימים רבים (כמו קבלת תואר אקדמאי), בעולם ההסמכות שלנו (Scrum) התנאי לקבלת הסמכה הוא מעבר קורס של יומיים ומבחן ל-CSM, מילוי טפסים שמוכיחים ניסיון ל-CSP, ועמידה בפני ועדה והוכחת ניסיון ל-CST.

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

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

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

אלמנטים של סקראם….רטרוספקטיבה

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

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

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

תפיסת ה-“בחינה והתאמה” מיושמת בסקראם באמצעותה של ישיבה שמתבצעת בסוף כל ספרינט ונקראת רטרוספקטיבת הספרינט (Sprint retrospective).

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

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

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

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

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

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

אלמנטים של סקראם…מה זה DONE ?

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

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

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

בואו נתבונן רגע בהגדרת DONE:

  • הקוד גמור
  • בדיקות גמורות
  • הפיצ’ר אושר ע”י מנהל המוצר.

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

  • הקוד גמור
  • נכתבו Unit tests והם רצים בהצלחה.
  • נכתבו Integration tests והם רצים בהצלחה.
  • הבדיקות התווספו לתשתית האוטומציה.
  • הפיצ’ר תועד (לפי הצורך).

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

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

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

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

נ.ב. – התוספת של התמונות לפוסטים מפריעה? מוסיפה? לא משנה? – אנא תגובתכם.

זהו – אני סיימתי – …I am DONE

 

*מקור התמונה : http://www.flickr.com/photos/hawaii-mcgraths/2701705139/lightbox/

סקראם מסטר – טכנולוג או טכנופוב ?

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

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

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

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

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

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

יש עוד שתי נקודות שעולות לי בהקשר הזה:

  • כאשר שוקלים איזה “סוג” של לסקראם מסטר רוצים, יש לשקול את המחיר של ההתעסקות הטכנית, כאשר סקראם מסטר עסוק בפן הטכני של הפרויקט הוא מזניח, ולו במעט, את הפן ההתנהגותי של הצוות.
  • כאשר לסקראם מסטר ידע טכני, בנוסף לדילמות הרגילות שיש לו, נוספות לו דילמות חדשות בפן הטכני, למשל (דוגמא שלי מהחיים), הסקראם מסטר רואה שהצוות עושה החלטה טכנית גרועה (לדעתו), האם הוא מתערב לצוות בהחלטה ?
    נקודה למחשבה: אם נחזור רגע לערכים האג’ילים נמצא בראש הרשימה את המשפט הבא:
    Individuals and interactions over processes and tools.
    מה זה אומר לכם לגבי הנושא הזה?