תכנון ספרינטים: שיטות Agile מובילות

יסודות התכנון

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

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

שלב ההכנה

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

• Definition of Ready (DoR) מגדיר מתי user story מוכן להיכנס לספרינט. לכל סטורי צריכים להיות קריטריוני קבלה ברורים, הערכת מורכבות ותלויות ידועות במשימות אחרות. כשלא מקפידים על DoR, התכנון הופך לבלגן, והצוות עסוק בלברר מה בכלל מבקשים ממנו במקום לתכנן את הביצוע.
• Backlog refinement צריך להתקיים באופן קבוע ולא רק ממש לפני תכנון הספרינט. מקובל להקדיש לו 10% מזמן הספרינט. צוותים יכולים לקיים מפגשי refinement קצרים כמה פעמים בשבוע ולהבשיל בהדרגה את הסטוריז של הספרינטים הבאים.
• ניתוח Velocity מראה לצוות כמה הוא באמת מסוגל לספק. הממוצע של 3-5 הספרינטים האחרונים הוא רק חלק מהתמונה, וצריך להביא בחשבון גם את מה שעלול להאט את הספרינט הקרוב: חופשות מתוכננות, חגים, חוב טכני שהצטבר ותלויות חיצוניות.

מפגשי תכנון

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

1. הצוות, יחד עם ה-Product Owner, קובע את יעד הספרינט שמחבר בין כל ה-user stories שנבחרו. היעד צריך להיות ספציפי ומדיד ולהיות בעל משמעות לכל המשתתפים. יעד חלש: "שיפור חוויית המשתמש." יעד טוב: "משתמשים יוכלו להירשם דרך מדיה חברתית בלחיצה אחת."
2. צוות הפיתוח מפרק את הסטוריז שנבחרו למשימות ומעריך כל אחת בשעות. בשלב הזה צצות מורכבות ותלויות שלא רואים ברמת הסטורי. אף משימה לא אמורה לקחת יותר מ-8 שעות, ומשימה שחורגת מזה מפרקים לתת-משימות.

תפקידים ואחריות

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

• ה-Scrum Master מנחה את התהליך, שומר על ה-timeboxes ועוזר לצוות להגיע להחלטות. הוא לא כופה פתרונות אלא שואל את השאלות הנכונות ודואג שהדיון יישאר ענייני.
• ה-Product Owner אחראי על תיעדוף ה-backlog ועל ההחלטה אילו תכונות מפתחים קודם. עליו להיות מסוגל להסביר את הערך העסקי של כל סטורי ולענות על שאלות צוות הפיתוח בפירוט שמספיק כדי להעריך את העבודה.
• צוות הפיתוח מתחייב לספק את התוצאות. ההתחייבות הזו צריכה לבוא מהצוות עצמו. כשהיא מוכתבת מבחוץ, משהו הולך לאיבוד: התחייבות שהצוות נתן בעצמו מניעה אותו הרבה יותר ויוצרת תחושת אחריות חזקה בהרבה מיעד שנכפה עליו.

טעויות נפוצות

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

ניטור תהליך

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

מדדים לניתוח:

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

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

התאמת התכנון

• צוותים מרוחקים צריכים תכנון ספרינט מותאם. צריך כלים מתאימים לעבודה משותפת, וצריך לדאוג באופן פעיל שכל המשתתפים מרחוק יקבלו הזדמנות שווה לדבר. בצוותים מבוזרים כמה מפגשים קצרים במקום פגישה ארוכה אחת מביאים שוב ושוב יותר מעורבות ותוצאות טובות יותר.
• תוכניות גדולות עם כמה צוותים דורשות תיאום ברמת התוכנית. Scrum of Scrums או SAFe (Scaled Agile Framework) נותנים מבנה מוכן לתיאום תכנון הספרינט בין צוותים שיש ביניהם תלויות משותפות.
• פרויקטי תחזוקה, שבהם חלק גדול מזמן הספרינט הולך לתמיכה ולתיקון באגים, צריכים לשריין במפורש קיבולת לעבודה לא מתוכננת. מקובל להקצות 30-50% מקיבולת הספרינט לתמיכה ולהשאיר את השאר לפיתוח תכונות חדשות. כשמתייחסים לתמיכה כעומס צדדי שמחוץ לתוכנית, מועדי המסירה מתפספסים.

מאמרים קשורים:

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

לסקירה מעשית של לוחות Kanban וניהול ויזואלי של זרימת עבודה, קראו מהו לוח Kanban? מדריך לניהול ויזואלי של זרימת עבודה.

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

מסקנה

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