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

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

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

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

לא לתעד בכללimage

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

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

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

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

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

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

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

 

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

Comments are closed.