כבר בהגדרה הבסיסית ביותר של קצב (rhythm) נוכל לזהות מאפיינים חזקים מאד אשר נדרשים
בתהליך הפיתוח - "הקצב הוא המאחד את הקבוצה, ובעזרתו ניתן לעשות פעולות
בסיסיות ומורכבות ביחד תוך כדי זמן קבוע ואחיד" (ויקיפדיה).
הצורך – את הצורך ניתן לפרט ממספר נקודות מבט:
מנקודת מבט המנהל – יכולת עמידת הצוות בקצב פיתוח תוצרים קבוע, תאפשר לו להתחייב עבור
תכולות עתידיות ברמת וודאות גבוהה. הורדת רמת הסיכון בצד האופרטיבי (פיתוח) תאפשר
לו להשקיע יותר בצד האסטרטגי (ניהולי, ארגוני) של החברה.
מנקודת מבט הצוות – קצב פיתוח תוצרים קבוע, יאפשר הגדרת היעדים ברמת הצוות (להבדיל
מהרמה האישית), יגרום לגיבוש הצוות ולמיקוד נכון בתוצר המבוקש.
הגעה ליעדים אלו תגרום
לעלייה בסיפוק ולהגברת המוטיבציה בקרב אנשי הצוות.
מנקודת מבט הלקוחות – עמידה בהתחייבויות החברה תראה על יציבות וחוסן, ותאפשר הרחבת שיתוף
הפעולה בהתחיבויות עתידיות.
הכלים - קיימים כיום בשוק מספר כלים אשר מספקים מענה לצורך זה. במאמר זה
אתאר 3 מהמובילים שבהם.
Drum Buffer Rope (DBR) – הוצגה לראשונה ע"י
דר' אלי גולדרט ז"ל כחלק מתאוריית האילוצים TOC.
(ניתן לקרוא מאמר קודם שלי כאן אשר מסביר את המושגים הבסיסיים בנושא).
בבסיס הרעיון עומד ה Drummer – זה אשר מכתיב את הקצב של הצוות. בתורת האילוצים ה Drummer יהיה האילוץ אשר ע"פ
גולדרט קיים בכל מערכת והוא זה אשר קובע את הקצב עבור המערכת כולה (כגון המכונה
האיטית בתהליך ייצור, ההולך האיטי בשיירה, וכיו"ב).
בכדי לשמור על קצב קבוע
(אפקטיבי) יש "להכפיף את המערכת לאילוץ", במקרה זה המשמעות מתורגמת לשתי
פעולות עיקריות - מניעת "הרעבה" starvation )ממומש ע"י ה Buffer), ותזמון ה"מנה" הבאה (ממומש
ע"י Rope)
כיצד בא הדבר לידי ביטוי
בתהליך הפיתוח ?
ניקח לדוגמא צוות של 4
מפתחים אשר מפתחים מוצר מבוסס תשתית DB.
בצוות 3 אנשי אפליקציה, ואיש DBA אחד אשר עבור הדוגמא מהווה את האילוץ במערכת.
(כלומר קצב ההתקדמות של התוצר תלוי בקצב ההתקדמות של איש ה DBA).
כל "הרעבה" של ה DBA (כלומר זמן שבו לא מחכה לו עבודה לביצוע) יגרום
להאטה של המערכת כולה, ולכן נגדיר לו Buffer של מספר עבודות אשר מחכות לו בכל זמן נתון. בצורה
זו כאשר יסיים משימה אחת, יוכל למשוך ללא שהיות את המשימה הבאה.
ה Rope מאפשר לנו להיערך ולהכין את משימות ה Buffer הבאות ולהעבירן בתזמון
הנכון. כלומר, בעוד שה DBA נמצא בעשייה, יש לנו זמן לתכנן, לתעדף ולנתח את חבילת התוכן
הבאה (בגודל ה Buffer)
ולתזמן אותה בנקודה בה ה Buffer מתרוקן (כל תזמון מוקדם יותר ייצור עומס לא יעיל על האילוץ)
אז היכן נמצא הרווח?
במספר אזורים –
1. ההתמקדות בזיהוי
האילוץ ומניעת "הרעבה" שלו יתנו לנו את התוצר המרבי שנוכל להפיק בתהליך
נתון
2. שימוש
ב"חבל" יאפשר לנו זמן לבצע תכנון ותעדוף איכותיים יותר, ומדויקים יותר
בשל קרבתם הרבה לשלב הביצוע.
Agile – גם מתודולוגיית ה-Agile מתבססת על קצב ה"ייצור" של הצוות כמפתח
להצלחת התהליך לאורך זמן. הדבר בא לידי ביטוי במונח הנקרא "Team velocity", והכוונה היא ל"תפוקה" שצוות
האג'ייל מסוגל לייצר ביחידת זמן של ספרינט. לאחר שנזהה מדד זה (בדר"כ לאחר
ספרינט אחד או שניים), נוכל להגדירו כחבילת העבודה עבור הצוות שעליו לסיים במהלך
הספרינט (בדומה ל Buffer ב DBR ). מן הצד השני נוכל לתכנן ולתזמן את החבילה הבאה שעליה יעבוד הצוות(בדומה
ל Rope ב DBR ).
הרחבה על נושא
מתודולוגיית האג'ייל ניתן למצוא כאן.
Kanban – פעילות ב"קצב הנכון" היא במוקד
מתודולוגיית ה-קנבאן.
הדבר בא לידי ביטוי בשניי
אלמנטים עיקריים –
1. Pull Vs Push – כל שלב בתהליך מושך (pull) את המשימה הבאה כאשר מסיים את הנוכחית,
ולמעשה קובע את קצב העבודה.
2. WIP (Work In Progress) - כאמור קצב
ה"ייצור" נקבע ע"פ האילוץ במערכת. כחלק מהכפפת המערכת לאילוץ, אם
נשקיע יותר משאבים בעזרה לאילוץ (מאשר בייצור מוגבר בתחנות שאינן האילוץ) כך נקבל
קצב ייצור קבוע, והגבוה ביותר שניתן להפיק מהמערכת.
הרחבה על נושא
מתודולוגיית ה kanban ניתן למצוא כאן.
שורת סיכום
בחתירה ליעד של קצב קבוע
בתהליך הפיתוח אין מפסידים רק מנצחים. (win-win situation).
אם קיים קושי, הוא ימצא
במרבית המקרים, ביכולת להניע ולהטמיע שינוי מסוג זה, בתוך חברות המתנהלות ע"ב
מודלים שהושרשו בחברה במשך שנים.
בהצלחה !
*אם יש לכם תהיות והתלבטויות הקשורות לייעוץ והכוונה בנושא –
יוגב טל, PMP
בחזרה לעמוד הבית - מרעננים
את הפיתוח
אין תגובות:
הוסף רשומת תגובה