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

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

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

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


נכתב ע"י רונית סנה
IntelliManage

שאלות ותגובות למיתוס זה ניתן להעלות כאן