Posts tagged ‘Visibility’

עשרת המכות

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

חג שמח!!!image

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ספרינט בקלוג – Smells

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

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

בפוסט הזה אני הולך לדבר על ריחות של ספרינט בקלוג – Sprint backlog smells .

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

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

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

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

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

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

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

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

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

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

חבל על הזמן…

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

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

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

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

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

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

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

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

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

לשבור את הקיר

clip_image002[4]

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

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

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

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

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

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

רוצים לסיים מוקדם – תתחילו באיחור!

האם אי פעם נתקלתם בסיטואציה כזו:

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

clip_image002

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

למה זה כל כך רע?

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

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

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

בואו נחזור לדוגמא מההתחלה אחרי חודש עבודה:

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

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

שיטה עם ערכים

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

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

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

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

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

אחד הגורמים שמשפיעים על הצלחתם של פרויקטים בכלל, ופרויקט תוכנה בפרט הוא ההחזר על ההשקעה (ROI – Return on investment), סקראם (Scrum) מתייחס בכובד ראש לעניין זה ולכן טוען שעל רשימת הדרישות להיות מסודרת בצורה כזו, שבראש הרשימה נמצאים האלמנטים בעלי הערך הגדול ביותר. כמובן שיש יוצאי דופן כגון פריטים שמהווים בסיס לפיתוחם של אחרים, אבל באופן כללי אנו שואפים למזער תלויות. בהינתן שהפריטים ברשימה מסודרים “נכון”, ואנו מפתחים את התוכנה לפי הסדר של הפריטים ב-backlog, אנו למעשה מגדילים משמעותית את הסיכוי להצלחתו של הפרויקט מבחינת ה-ROI.

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

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

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

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

clip_image004מרגש –Exciter – אלה הם מאפיינים של מוצר שהלקוח אפילו לא ידע שהוא רוצה עד שהוא ראה אותם, דוגמא למאפיין כזה הוא למשל שלט שפותח את דלתות המכונית, וכן, בד”כ מאפיינים מסוג זה לא נשארים כאלה לאורך זמן.
חובה–
Mandatory– מאפיינים שבלעדיהם אין זכות קיום למוצר, דוגמא למאפיין כזה היא למשל האפשרות לשמור קבצים במעבד תמלילים.
לינארי – Linear – ניתן לאפיין את הסוג הזה בעזרת המשפט “כל המרבה, הרי זה משובח”, ככל שיש יותר כאלה, כך שביעות הרצון של הלקוח עולה. דוגמא למאפיין כזה היא למשל כמות הזיכרונות במכשיר סלולארי.
מפוקפק – Questionable – כזה שלא מספיק ברור לגביו מה הסיווג.
הפוך – Reverse – כזה שברור שהלקוח לא רוצה.
משהו – Indifferent – משהו שלא משנה ולא במעט את שביעות הרצון של הלקוח.

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

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

עוד מודלים בפוסט הבא.