Timeboxing

מתוך ויקיפדיה, האנציקלופדיה החופשית

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

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

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

Timeboxing בניהול פרויקטים[עריכת קוד מקור | עריכה]

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

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

Timeboxing כאלטרנטיבה לעבודה עם תכולה קבועה[עריכת קוד מקור | עריכה]

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

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

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

ניהול סיכונים עם Timeboxing[עריכת קוד מקור | עריכה]

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

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

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

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

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

אימוץ Timeboxing בפיתוח תכנה[עריכת קוד מקור | עריכה]

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

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

Timeboxing אומצה על ידי כמה מתודולוגיות פיתוח תוכנה בולטות:

  • שיטה לפיתוח מערכות דינמיות (DSDM)
  • בפיתוח תוכנה רזה (Lean), pull scheduling עם Kanban מספק ניהול זמן קצר טווח. כאשר מפתחים מערכת גדולה ומורכבת, שבה נדרש תכנון לטווח ארוך, השימוש ב Timeboxing נעשה בשכבה גבוהה יותר.[7]
  • פיתוח תוכנה מהיר ליישומים (RAD) כולל פיתוח איטרטיבי ויצירת אב טיפוס של תוכנה. על פי סטיב מקונל, Timebox הhא "השיטה המומלצת" עבור RAD ואורך של Timebox טיפוסי צריך להיות 60-120 ימים.[8]
  • Scrum הושפע מרעיונות של Timeboxing ופיתוח איטרטיבי.[9] יחידות זמן המכונות ספרינטים מהוות את יחידת הפיתוח הבסיסית.[10] אורך טיפוסי לספרינט הוא פחות מ-30 יום.[11] פגישות תכנון ספרינט, רטרוספקטיב של ספרינט וביקורת ספרינט מנוהלות ב- Timeboxing.[11]
  • במתודולוגיות Extreme Programming, תכנון הפיתוח נעשה בדרך כלל באיטרציות מוגבלות בזמן, באורך של 1-3 שבועות. נהוג לעשות הערכה מחדש של User Stories ממתינים לפני כל איטרציה.[12]

פיתוח תוכנה זריז דוגל במעבר מפיתוח שמונע על ידי תכנית (Plan) לפיתוח שמונע על ידי ערך (Value). בשיטה זו איכות התוצרים הנדרשת וזמן הפיתוח קשיחים, אך מותרת גמישות בהיקף התכולה של הפרויקט. אספקת החלקים החשובים ביותר של התכולה בשלב מוקדם מובילה להחזר ההשקעה (ROI) מוקדם יותר בהשוואה לפיתוח במודל מפל המים (Waterfall).[13]

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

בניהול זמן אישי[עריכת קוד מקור | עריכה]

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

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

קשרים עם שיטות אחרות[עריכת קוד מקור | עריכה]

Timeboxing משמש כאבן בניין בשיטות אחרות לניהול זמן אישי:

  • טכניקת פומודורו מבוססת על תיבות זמן של 25 דקות של ריכוז ממוקד המופרדות על ידי הפסקות לצורך התאוששות.[16]
  • אנדרו האנט מגדיר את ה- Timeboxing בתור ה-'T' שלו ב- SMART (ראשי תיבות של סט קריטריונים לקביעה וניהול של יעדים). [17]

ראו גם[עריכת קוד מקור | עריכה]

קישורים חיצוניים[עריכת קוד מקור | עריכה]

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

הערות שוליים[עריכת קוד מקור | עריכה]

  1. ^ Timeboxing – why you should use it? | Firmbee, ‏2022-01-17 (באנגלית אמריקאית)
  2. ^ Project Management – Manage Your Projects Successfully, www.projectmanagement.net.au
  3. ^ Kent Beck, Extreme programming eXplained : embrace change, Reading, MA : Addison-Wesley, 2000, ISBN 978-0-201-61641-5
  4. ^ 1 2 3 Jennifer Stapleton, DSDM, dynamic systems development method: the method in practice, Reprint, Harlow: Addison-Wesley, 1998, ISBN 978-0-201-17889-0
  5. ^ Frederick P. (Frederick Phillips) Brooks, The mythical man-month : essays on software engineering, Reading, Mass. : Addison-Wesley Pub. Co., 1975, ISBN 978-0-201-00650-6
  6. ^ 1 2 3 Steve McConnell, Rapid development, Microsoft Press, 2000, ISBN 978-1-55615-900-8
  7. ^ Mary Poppendieck, Tom Poppendieck, Leading lean software development: results are not the point, Upper Saddle River, NJ Munich: Addison-Wesley, 2010, The Addison-Wesley signature series, ISBN 978-0-321-62070-5
  8. ^ Steve McConnell, Rapid development, Microsoft Press, 2000, ISBN 978-1-55615-900-8
  9. ^ James O. Coplien, Gertrud Bjørnvig, Lean Architecture: for Agile Software Development, John Wiley & Sons, 2011-01-06, ISBN 978-0-470-97013-3. (באנגלית)
  10. ^ Mike Cohn, Succeeding with Agile: software development using Scrum, 5. print, Upper Saddle River, NJ Munich: Addison-Wesley, 2011, The Addison-Wesley signature series, ISBN 978-0-321-57936-2
  11. ^ 1 2 Ken Schwaber, Agile Project Management with Scrum, Microsoft Press, 2009-11-30, ISBN 978-0-7356-3790-0. (באנגלית)
  12. ^ Kent Beck, Extreme programming eXplained : embrace change, Reading, MA : Addison-Wesley, 2000, ISBN 978-0-201-61641-5
  13. ^ Dean Leffingwell, Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise, Addison-Wesley Professional, 2010-12-27, ISBN 978-0-321-68540-7. (באנגלית)
  14. ^ The Toggl Team, Time Blocking Guide for Beginners, Toggl Blog, ‏2018-08-21 (באנגלית אמריקאית)
  15. ^ Adam Pash, Gina Trapani, Lifehacker: The Guide to Working Smarter, Faster, and Better, John Wiley & Sons, 2011-06-03, ISBN 978-1-118-13345-3. (באנגלית)
  16. ^ Staffan Nöteberg, Pomodoro Technique illustrated: the easy way to do more in less time, Raleigh, NC: Pragmatic Bookshelf, 2009, Pragmatic life, ISBN 978-1-934356-50-0
  17. ^ Andrew Hunt, Pragmatic thinking and learning, Pragmatic, 2008, ISBN 978-1-934356-05-0
אוחזר מתוך "https://he.wikipedia.org/w/index.php?title=Timeboxing&oldid=38238308"