Posts tagged ‘תהליך’

כל אחד הוא מיוחד

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

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

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

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

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

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

חבל על הזמן…

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

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

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

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

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

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

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

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

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

לשבור את הקיר

clip_image002[4]

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

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

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

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

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

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

הרצאה בכנס PMI

image

לאחרונה הצגתי בכנס PMI הרצאה שנותנת מבוא לאג’יל (Agile) וסקראם.

אם אתם מוצאים את זה מעניין, אז הנה לינק למצגת.

איך שואלים “למה”?

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

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

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

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

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

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

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

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

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

במקום לשאול: “למה לא הספקת לסיים את המשימה?”
אפשר לשאול: “אילו דברים הפריעו לך לסיים את המשימה?”
וכדומה…

אז הנה לכם כלי פשוט וקל שיכול לעשות שינוי משמעותי.

מכתב פתוח לדוד בוב

בוב היקר,

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

אתייחס כעת לעל אחת מהנקודות שהעלית:

1. חוסר בטכניקות טכניות – אתה צודק, וזה ידוע לרוב שסקראם, בניגוד למשל ל-XP אינו מציין באיזה טכניקות או שיטות יש להשתמש כשמפתחים תוכנה, ולטעמי לא סתם: לו היה סקראם מגדיר באיזה שיטות לעבוד כשמפתחים תוכנה הרי היה גורלו להפוך לא רלוונטי כעבור פרק זמן מסויים, וכידוע לנו, תחום התוכנה הוא דינאמי ומשתנה. כאשר צוותים היום בוחרים לעבוד בסקראם הם בד”כ משתמשים בשיטות כגון CI, Pair programming, TDD וכו’ מכיוון שאלה דברים שנכון להיום אנו יודעים שהם עובדים, אבל מה יהיה עוד 10 שנים, האם עדיין אותן שיטות יהיו רלוונטיות ? אז ממש כמו ה-Agile Manifesto שאתה מהיוזמים שלו, לא צוינו פרטים טכניים בכדי לשמר אותו לאורך זמן, כך גם סקראם, ואני רואה בכך יתרון.

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

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

4. מסכים! מסכים! מסכים! אבל גם זה לא חסרון של סקראם אלא של הארגון שמפיץ אותו, היה נפלא לו היינו נפתרים מה-“Certified” לאלתר.

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

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

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

8. צוותים מרובים או “סקראם בגדול” היא באמת שאלה פתוחה ואני לא חושב שמישהו עדיין מצא אחת גלובאלית להתמודד עם השאלה, לטעמי האישי הרעיונות של Bas Vodde ו-Craig Larman הם טובים, אך גם הם לא מתאימים לכל מקום כמו כפפה ליד, הנושא של פיתוח בסדר גודל גדול הוא נושא כנראה סבוך מידי ואין פתרון אחד (ממש כמו התפיסה האג’ילית – One size does not fit all)

זוהי תשובתי מלאת ההערכה אלייך דוד בוב (Robert C Martin).

אלעד.

ישיבות או לא להיות

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

clip_image002באופן קלאסי ישיבה מתחלקת לשלושה חלקים:

– הכנת השטח.
– איסוף נתונים
– עיבוד הנתונים.

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

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

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

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

שיטה עם ערכים

לא הרבה אנשים מכירים את העובדה שכמו ל”מניפסט האג’ילי” גם לסקראם (Scrum) יש 5 ערכים, הערכים האלו מוזכרים בספר הראשון שנכתב על המתודולוגיה שנקרא “Agile software development with Scrum”, הספר נכתב ע”י מייק בידל וקן שוובר (Mike Beedle & Ken Schwaber) ובו מצאו לנכון הכותבים להקדיש מקום לערכים הבסיסיים שעליהם מבוססת השיטה.

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

clip_image002[4]

כעת אציג בפניכם את חמשת הערכים:

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

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

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

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

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

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

תכנון פרויקטים בסקראם.

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

נתחיל במספר נקודות:

  • אם נחזור רגע להערכת משימות בשיטה אג’ילית, יש שבוחרים (ואני גם ממליץ) להשתמש ביחידות מידה יחסיות שנקראות Story points (ראו הרחבה בפוסט בנושא).
  • אחד המאפיינים הבולטים של שיטות ה-agile השונות וביניהן Scrum הוא איטרציות קבועות בזמן שבסופן הצוות מספק תוכנה עובדת (Done), היתרון העיקרי של איטרציות שכאלה, הוא קיומו של “דופק” קבוע לפרויקט, שמאפשר לנו לקבל תמונה לא רעה בכלל על מצב הפרויקט והתקדמותו, אחד המדדים החשובים שניתן לקבל כאשר עובדים באיטרציות הוא כמה תפוקה הצוות (או הצוותים) מסוגל לספק באיטרציה אחת (במקרה של סקראם ספרינט), נהוג לכנות את המדד הזה בשם Velocity.
  • רשימת הדרישות נמצאת בתוך מסמך שאנו מכנים Product backlog, המסמך מאופיין בכך שבכל רגע נתון, הפריטים בו מסודרים לפי הסדר שבו אנו מבקשים לפתח אותם.

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

אז מה אנחנו רוצים לתכנן ? התכנון מתבצע ברמות שונות:

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

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

אלמנטים של סקראם… מיון רשימת הדרישות (Product backlog) – חלק שני

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

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

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

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

עבור כל פריט מהרשימה, נסמן לכל קריטריון בתא המתאים בטבלה האם הוא טוב יותר (+), טוב פחות (-) או טוב באותה המידה (0). אחרי שסימנו את כל הטבלה נותר רק לסכום עבור כל פריט: כל ‘+’ מעלה בנקודה, כל ‘-‘ מוריד נקודה ו-‘0’ לא משנה ניקוד. למעשה, דירגנו את הפריטים באופן יחסי זה לזה (על סמך פריט הבסיס כמובן).
את השיטה הזאת ניתן לשכלל במספר דרכים שכמובן דורשות מאמץ נוסף כגון:
– להחליט על פריט להשוואה שונה עבור כל אחד מהקריטריונים וכך לקבל תמונה טובה יותר.
– במקום להשתמש ב ‘+’ ו ‘-‘ ניתן להשתמש במספרים 1-5, שלא רק אומרים אם פריט מסוים עונה טוב יותר או פחות על קריטריון אלא גם לציין עד כמה באופן יחסי.
– ניתן להוסיף פקטור לכל אחד מהקריטריונים בכדי לבטא את החשיבות שלו למשל לקריטריון 1 ניתן פקטור של 0.5 ולקריטריון 2 ניתן פקטור של 0.1 ורצוי שסה”כ הפקטורים יהיה 1 (על בסיס של 100%).
– וניתן כמובן לשכלל את המודל בכל צורה שעולה על דעתכם.

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

ניקוד יחסי.
הרעיון הכללי בניקוד יחסי הוא הכללה מספר פרמטרים שעד כה לא לקחנו בחשבון במודלים הקודמים, הפרמטרים הללו הם: עלות ותועלת. אם עד כה הצגתי שיטות שמנסות לדרג את הפריטים ע”פ האיכות הפונקציונאלית שלהם, אציג כעת שיטה שנותנת משקל לעלות והתועלת שכל אחד מהפריטים מביא איתו. לדעתי לא ניתן לומר בצורה חד משמעית אם השילוב של הפרמטרים האלה הוא טוב או רע, וכנראה שזה תלוי בסוג הפרויקט, ובהעדפה אישית, יש שיגידו שהאיכות הפונקציונאלית כבר כוללת בתוכה את התועלת, והתחשבות בעלות היא חשובה, אבל פחות. כפי שציינתי זה גם מאוד תלוי על איך מגדירים את המושג ROIומהן מטרות הפרויקט.
במודל הזה, עבור כל פריט אנחנו ננסה לענות על מספר שאלות, תוך שימוש במספרים 1-9 כתשובות אפשריות. השאלות עליהן אנו מתבקשים לענות הן, אני גם אתן דוגמאות בכדי להמחיש:
– מה היא תועלת יחסית שנקבל אם הפריט ייכלל בתכולה ?
– מה הוא נזק יחסי שיגרם אם הפריט לא ייכלל ?
– מה היא העלות ?- הערכת מאמץ (לא משנה באיזה יחידות)
דוגמאות להמחשה :
– תמיכה ל-iPhone – מצד אחד יש תועלת משמעותית כי זה יכול לחשוף את האפליקציה שלנו לשוק חדש, מצד שני, אם לא נכלול את זה, יגרם נזק אבל הוא לא משמעותי. הערכתנו לפיתוח היק 20 נקודות (Story points).
– תמיכה בחוק הספאם לרשימות תפוצה – אם לא נוסיף תמיכה אז הנזק יהיה משמעותי ונאבד חלק ניכר מהלקוחות, למרות שהוספה שלו לא נותנת לנו שום תועלת ממשית. הערכתנו לפיתוח היא 8 נקודות (Story points).

אחרי שסיימנו למלא את הנתונים, מבצעים את החישובים הבאים :
– ערך = (ייכלל) + (לא ייכלל)
– ערך יחסי = 100 * (ערך סכום (ערך))
– עלות יחסית = עלות סכום (עלות)
– דירוג = 100 * (ערך יחסי עלות יחסית).

התבוננות על שדה הדירוג מדרגת את הפריטים לפי עדיפות מהגבוה לנמוך.

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

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