Posts in הרגלי עבודה אג’ילים

לולאה אינסופית

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

clip_image002פתיחה

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

איסוף נתונים:

בחרנו בשיטה של Good, Bad, Better, Best וכל אחד מהמנהלים רשם אירועים ודברים על פתקיות דביקות והדביק אותם בקטגוריה הרלוונטית, לאחר שכולם סיימו (למעשה לאחר שתם הזמן לחלק הזה) העלמתי את הקטגוריות המקוריות שביקשתי מהמשתתפים למיין את הפתקים לקבוצות לפי נושא, ולעשות זאת מבלי לדבר בכלל.
זה לקח כ-5 דקות ולבסוף היו לנו 8 קבוצות, הקבוצה הגדולה ביותר באופן משמעותי הייתה הקבוצה שהם הגדירו שקשורה למוטיבציה של חברי הצוותים.

ניתוח הנתונים:

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

תכנון של ניסוי:

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

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

סיכום:

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

מקור התמונה: http://www.flickr.com/photos/livenature/8064660509/

חמש טעויות נפוצות

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

גרומינג רק לספרינט הבא

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

לא לתעד בכללimage

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

להשוות צוותים ע״י שימוש בוולוסיטי

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

תכנון מפורט מידיי

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

אי הקפדה על הגדרת ה-Done

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

 

מקור התמונה : http://www.flickr.com/photos/squidish/410698265/in/set-72157594528501650

אולי תחליטו כבר?

"גם לא להחליט זו החלטה" כך היא אמרה לי, וכמה שהיא צודקת….

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

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

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

אז איך מקבלים החלטה?

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

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

פרוטוקול החלטה (מבית היוצר של הזוג מק’ארתי)

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

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

בר החלטה

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

פרמטרים להחלטה

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

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

מקור התמונות:
http://www.flickr.com/photos/inafrenzy/5787848646/
http://www.flickr.com/photos/sarahreido/3120877348/

הכל זה אישי

לא מזמן ובמסגרת הסדנאות של כנס אג׳ייל פרקישיונרס 2013, זכיתי להעביר ביחד עם Yves Hanoulle סדנא שנקראת Persnal Agility, למעשה הסדנא עוסקת בנושא שנקרא Personal Kanban שבלי לפרט יותר מידי היא טכניקה שמבוססת על קנבן קלאסי אבל מטרתה היא להכניס סדר ושפיות לניהול העצמי של כל אחד ואחת מאיתנו.

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

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

image

אז הנה אני חולק:

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

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

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

אף פעם לא הייתי מאוד מרוצה מצורת ההמחשה של הדחיפות/עדיפות של המשימות והנה השיפור שאני חושב לעשות בלוח הקנבן שלי.

New Personal Kanban כפי שאתם רואים (תקליקו להגדלה) הארכתי בצורה אלכסונית את הטורים To do, in work, on hold ו-today, הצורה הזו מאפשרת לי לראות במבט חטוף משימות שבגלל סיבות שונות ומשונות לא נמצאות במקום שהייתי מצפה שהם יהיו, אם כי הזמן לביצוען הולך ואוזל או אם כי הן נמצאות (לדעתי כמובן) זמן רב מידי על הלוח.

למשל משימה שנמצאת בעמודת ה-to do והייתי מצפה שתהיה כבר לפחות ב- Today תמצא את מקומה בעמודת ה-To do מתחת לעמודת ה-In work.

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

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

אשמח להערות והארות בנושא.

בנוסף אנחנו מציעים קורסים ציבוריים ופרטיים בנושא, פרטים ניתן למצוא באתר שלנו.
http://practical-agile.com

מה ההבדל בין טבח ביתי לשף?

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

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

בוא נתחיל עם אלה שלא:

  • יכולת יוצאת דופן לחוש בטעמים או כמו שהם קוראים לזה ״חך מצוין״
  • כישרון
  • אהבה אמיתית לאוכל.

יש בטח עוד אבל אלה לטעמי הדברים העיקריים שאו שנולדים/גדלים/מחונכים איתם או שלא.

8170834332_9e4da61829[1]בואו נמשיך עם אלה שניתנות לגישור:

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

הבנתם? אז בואו נחזור לקרקע.

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

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

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

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

מקור התמונות:
http://simania.co.il/bookimages/covers0/8957.jpg
http://www.flickr.com/photos/19714819@N00/8170834332

ספרינט ייצוב – תנצב”ה

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

למה אני מתכוון?

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

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

בשביל לשנות תפיסה צריך קודם להבין שיש בעיה.

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

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

בקיצור: זה רע.

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

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

איך?

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

מקור התמונה:http://www.flickr.com/photos/lenore-m/4052125926/

 

כמה זמן זה מפה לקהיר?

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

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

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

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

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

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

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

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

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

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

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

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

*מקור התמונה : http://www.flickr.com/photos/arancidamoeba/3415301321/

בואו נדבר על… צוותי פיצ׳רים

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

אבל מה זה כן?

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

אז מה הבעיה? למה לא כולם עושים את זה?

הנה כמה סיבות שאני שומע:
  • בצוות כזה אין חלוקה שווה של העומס בין המפתחים – הגיוני, הרי יש פיצ׳רים שדורשים יותר חלק אפליקטיבי ויש כאלה שדורשים יותר פיתוח תשתיתי, יש כאלה שדורישם יותר בדיקות וכאלה שזקוקים בעיקר לקונפיגרציה. אבל מתוך הנחה שרוב הפיצר׳ים דורשים התייחסות בכל החלקים, מישהו מוכן בבקשה לקום ולהסביר לי איך הבעיה הזאת נפתרת כשהאנשים המעורבים יושבים בצוותים שונים? להיפך עבודה בצורה כזו תציף את הבעיה של חוסר איזון בין ההתמחויות ולא תחביא אותה בתוך מבנה ארגוני מסובך.
  • אנשי תוכנה לא יודעים לבדוק כמו שצריך – בואו לא נכנס לוויכוח אם זה נכון או לא ונשאל האם זה בכלל רלוונטי, אם למשל מומחה הבדיקות שלנו מגדיר את הבדיקות שצריכות להתבצע והמתכנת מוציא אותן לפועל, או אם מומחה הבדיקות כותב את הרמה העליונה של האוטומציה (ATDD) והתוכניתן כותב את ה-fixtures.
  • איש ה-QA לא יכול לכתוב קוד – באמת? הפעם דווקא בא לי להתווכח, יש לא מעט אנשי בדיקות שכן יודעים, או שלא יודעים ורוצים ללמוד, אני לא מציע לכם לתת לאיש בדיקות לגעת ללא עזרה באיזורים רגישים בקוד, בדיוק כמו שלא הייתי מציע לכם לאפשר את זה למי שרק סיים אוניברסיטה, אבל בהחלט אפשר להיעזר גם באזני בדיקות בכדי לכתוב קוד במידה והם מעוניינים בכך. גם אם איש הבדיקות לא רוצה לכתוב קוד ישנן עוד משימות שיש לבצע, כתיבת מסמכים, ייצוג הצוות בישיבות, התקנות, אדמיניסטרציה ועוד.
  • תוכניתן A הוא מומחה בשפה מסוימת – אז מה? תוכניתנים לא מחליפים שפות? לא לומדים דברים חדשים? מישהו שיודע שפת C לא יכול לעזור קצת עם ג׳אווה או עם #C? אני גם חושב שזה אפילו כדאי, ראוי ואפילו חובה להרחיב אופקים וללמוד דברים חדשים.
ישנן עוד לא מעט סיבות ״לא לעבוד בצוותי פיצ׳ר״, ואתם מוזמנים להוסיף כאלה בתגובות.
לפני שאני מסיים את הפוסט הזה (והולך לישון – כבר 2 בלילה!!!) אני רוצה לתת סיבה אחת למה כן כדאי, יש הרבה אבל אני רוצה להתמקד באחת:
אין צורך באינטגרציה
בתור מי שמפתח תוכנה כבר לא מעט שנים אחת הבעיות הכי כואבות שאני מכיר היא אינטגרציה, השלב המקולל הזה שאני מתחיל אותו כשגם אני וגם האדם שמולי בטוחים שסיימנו את העבודה ורק נשארו שעה שעתיים לחבר את החלקים, אותו שלב מקולל שדורש ששנינו נהיה פנויים, אותו שלב מקולל שבו מגלים ששום דבר לא באמת עובד, אותו שלב מקולל שבו ממש כשהיגענו לקטע קריטי הוא צריך ללכת לישיבת צוות או משהו דומה… בצוותי פיצ׳ר זה לא קיים! בצוות כזה כל האינטגרציה מתבצעת בתוך אותה יחידה קטנה שנקראת צוות. אותו צוות שיכול להרשות לעצמו לבצע כל הזמן אינטגרציה. איזה כיף זה.
אשמח לשמוע מה לכם יש להגיד בנושא.
מקור התמונה : http://www.flickr.com/photos/35168673@N03/5796777205/in/photostream/

להגיע לפסגה

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

אני בהחלט חושב שהנקודה שיובל העלה בהחלט שווה התייחסות.

להטמעת סקראם יש לטעמי שלושה שלבים עיקריים:

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

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

אם עשיתם רק את שלב הלימוד…

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

אם המשכתם לשלב ההטמעה…

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

אבל אם אתם בשלב הניסויים…

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

המלצתי היא:

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

 

מקור התמונות:
 http://www.flickr.com/photos/jinglesthepirate/2885330439/
http://www.flickr.com/photos/tuchodi/4901707346/

בואו נדבר על…. הספרינט

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

מצד שני…

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

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

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

איך עושים את זה? (הפיסקה הבאה לא מומלצת למנהלים בעלי לב חלש)

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

עצור רגע… בכל זאת בסקראם אמורים להשתפר ולהגביר את הקצב עם הזמן לא?

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

*מקור התמונות:
http://www.flickr.com/photos/gareth1953/5992046962/
http://www.flickr.com/photos/hiddenloop/2043964184/