Timeboxing

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

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

טכניקה זו מהווה חלק אינטגרלי במתודולוגיות פיתוח זריז כמו Scrum ו־ Kanban.

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

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

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

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

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

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

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

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

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

### אימוץ Timeboxing בפיתוח תכנה
פרויקטים מוצלחים רבים של פיתוח תוכנה משתמשים ב-Timeboxing, אולם מדובר בעיקר בפרויקטים קטנים יחסית. אימוץ Timeboxing יותר משילש את פרודוקטיביות המפתחים בחברת DuPont בשנות ה-80. במקרים מסוימים, פיתוחים הושלמו במלואם תוך פרק הזמן שהוערך במקור שיידרש רק להכנת המפרט לפיתוח.

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

Timeboxing אומצה על ידי כמה מתודולוגיות פיתוח תוכנה בולטות:
* שיטה לפיתוח מערכות דינמיות (DSDM)
* בפיתוח תוכנה רזה (Lean), pull scheduling עם Kanban מספק ניהול זמן קצר טווח. כאשר מפתחים מערכת גדולה ומורכבת, שבה נדרש תכנון לטווח ארוך, השימוש ב Timeboxing נעשה בשכבה גבוהה יותר.
* פיתוח תוכנה מהיר ליישומים (RAD) כולל פיתוח איטרטיבי ויצירת אב טיפוס של תוכנה. על פי סטיב מקונל, Timebox ה־hא "השיטה המומלצת" עבור RAD ואורך של Timebox טיפוסי צריך להיות 60–120 ימים.
* Scrum הושפע מרעיונות של Timeboxing ופיתוח איטרטיבי. יחידות זמן המכונות ספרינטים מהוות את יחידת הפיתוח הבסיסית. אורך טיפוסי לספרינט הוא פחות מ-30 יום. פגישות תכנון ספרינט, רטרוספקטיב של ספרינט וביקורת ספרינט מנוהלות ב־Timeboxing.
* במתודולוגיות Extreme Programming, תכנון הפיתוח נעשה בדרך כלל באיטרציות מוגבלות בזמן, באורך של 1–3 שבועות. נהוג לעשות הערכה מחדש של User Stories ממתינים לפני כל איטרציה.
פיתוח תוכנה זריז דוגל במעבר מפיתוח שמונע על ידי תוכנית (Plan) לפיתוח שמונע על ידי ערך (Value). בשיטה זו איכות התוצרים הנדרשת וזמן הפיתוח קשיחים, אך מותרת גמישות בהיקף התכולה של הפרויקט. אספקת החלקים החשובים ביותר של התכולה בשלב מוקדם מובילה להחזר ההשקעה (ROI) מוקדם יותר בהשוואה לפיתוח במודל מפל המים (Waterfall).

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

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

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

### קשרים עם שיטות אחרות
Timeboxing משמש כאבן בניין בשיטות אחרות לניהול זמן אישי:
* טכניקת פומודורו מבוססת על תיבות זמן של 25 דקות של ריכוז ממוקד המופרדות על ידי הפסקות לצורך התאוששות.
* אנדרו האנט מגדיר את ה־Timeboxing בתור ה-'T' שלו ב־SMART (ראשי תיבות של סט קריטריונים לקביעה וניהול של יעדים). 

## ראו גם
* מתודולוגיות לפיתוח תוכנה

## קישורים חיצוניים
* Design Sprint - תהליך תחום בזמן בעל חמישה שלבים המשמש בחשיבה עיצובית לגבי מוצר, שירות או תכונה חדשה.
* The Mythical Man-Month - ספר מאת פרד ברוקס העוסק בהנדסת תכנה וניהול פרויקטים.

## הערות שוליים

קטגוריה:מתודולוגיות לפיתוח תוכנה
2024 02