Kanban – מתעשית הרכב היפנית למתודולוגית פיתוח תוכנה

כבר כמעט משנתיים שלא נגעתי בפוסטים בנושא מתודולוגיות ל-IT. התחושה שלי היא שלפחות Agile ו-Itil שכתבתי עליהם בעבר וגם Lean תופסות לאחרונה נפח באירגונים. מתודולוגיות ה-Agile ו-Lean מתייחסות להיבטים של ניהול פרויקטי פיתוח ומתברר שלא פשוט לממש אותן כמתודולוגיה עצמאית ולכן נוספו אליהן 2 גישות Scrum ו- Kanban.

כמהנדס תעשיה וניהול עצם הזכור מתודולוגית Kanban החזירה אותי לאחור לתקופת הלימודים בטכניון. Kanban נוצרה כמתודולוגיה לניהול שרשרת האספקה ביצור בחברת טויוטה היפנית בכדי לתמוך בשיטת ה-Just In Time שבאה להבטיח קבלת חומרי גלם ברגע הנחוץ, לא לפני ולא אחרי במטרה לא להחזיק מלאים. המילה Kanban היא כמובן ביפנית שמשמעותה "כרטיס". זה היה כנראה לפני עדין בו מיחשבו את רצפת היצור והשתמשו בכלים לסמן דרישה לפריט. הדרישה לפריט נובעת מאירוע של משיכת פריט ב-Kanban הבא של שרשרת היצור. כלומר שיטת Pull, אם ב-Kanban של המוצר המוגמר נרכש פריט וירדה רמת המלאי שנקבעה ב-Kanban מתבצע תהליך של הוראה לייצור מוצר נוסף. בעצם הגבלת גודל ה-Kanban גורמת להקטנת רמות המלאי.

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

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

המפתח לכל שיטת ה-Lean הוא לצמצם בזבוז. בתוכנה, עבודה שהושלמה בחלקה נחשבת לבזבוז. עבודה שהושלמה בחלקה מכונה Work In Progress (WIP). נדרש שתהיה כמות מסויימת של WIP, אבל הנקודה היא לצמצם אותה למינימום האפשרי. כשמצמצמים WIP, התוצאה היא שהעבודה מושלמת במהירות. זה יכול להתקיים רק אם יש כמות קבועה של עובדים וכאשר צמצום מספר הנושאים עליהם עובדים בו זמנית יאפשר להם להשקיע יותר זמן על כמות נושאים קטנה יותר, וכך להשלים אותם במהירות רבה יותר.

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

המיקוד הוא על שטף פעילויות הפיתוח. מיקוד בשטף גורם לשני דברים:

• הראשון – עוזר להשיג השלמה של פעילויות באופן מתמשך.
• השני – עוזר לחשוף בעיות.

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

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

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

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

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

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