יום רביעי, 5 בספטמבר 2012

קאנבאן (Kanban) - תהליך שמתנהל מעצמו

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

שייך לסדרה: אג'ייל - מתודולוגיות פיתוח רזות


"מדוע אנו זקוקים ל*עוד* מתודולוגיה? עדיין לא השתלטנו על סקראם!"
ובכן, קאנבאן היא (בערך) סקראם פשוט יותר וקצת אחר. ראיתי הרבה קשיים ועיוותים באימוץ של סקראם [א]. אימוץ סקראם מלווה לעיתים קרובות ב"רעידת אדמה ארגונית" בה האנשים המתאימים לתפקיד אחד - נדרשים מעתה לתפקיד חדש:
  • סקראם מאסטרס הם לא "מנהלים", כי אם "מאמנים".
  • הצוות, שהיה רגיל לקבל הנחיות מדויקות, נדרש להיות עצמאי ו"לנהל את עצמו".
  • מנהלי הקבוצות שידם הייתה בכל, נדרשים "לנהל אנשים" ולהתרחק מטכנולוגיה או הגדרות המוצר.

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


מקורות
המילה קאנבאן היא מילה יפנית שמשמעה ״כרטיס חזותי״. היא משמשת בטויוטה (החברה שהמציאה את האג׳ייל[ב]) לתאר תהליך ניהול המלאי מופלא שקורה מעצמו. את התהליך של טויוטה כותבים בעזרת k קטנה (kanban) בעוד את תהליך התוכנה שמבוסס עליו כותבים בעזרת K גדולה (Kanban).

תהליך ניהול המלאי שהיה מקובל במערב נראה בערך כך:
  1. החברה מגדירה ומאיישת תפקיד בשם ״מנהלי מלאי״.
  2. כשהמלאי מגיע לרמה הנמוכה ("מלאי מינימום") מנהל המלאי מבצע הזמנה על מנת למלא את המלאי לרמה הגבוהה (מה שנקרא בטעות "מלאי אופטימום"[ג]). 
  3. "מלאי האופטימום" היא תחזית סטטיסטית, של מנהלי המלאי, על הביקוש העתידי לחלק. 
  4. מנהלי המלאי הם בעלי הבנה קטנה בייצור. ה"חלקים" ומבחינתם אלו יכולים להיות מנועי בואינג 747 או עגבניות. Same Same. 
  5. חלק גדול מהעבודה של מנהלי המלאי מושקע בזיהוי הפריטים והזמנת החלק הנכון. לכל חלק יהיה שם, מספר קטלוגי פנימי, מספר קטלוגי יצרן, פרטים לזיהוי היצרן, תמונות שיסייעו (למנהלי המלאי - האנשים במפעל כבר יודעים) לזהות את החלקים וכו'. אופרציה שלמה. הזמנות מלאי לרוב נעשות באצוות (batch) על מנת "לקבל מחיר טוב יותר ולחסוך כסף במחלקת המלאי".
הגישה המערבית לייעול התהליך היה רכישת תוכנה יקרה עם מיליון אפשרויות (ניהול מלאי הוא עסק מסובך) שתסייע למנהלי המלאי לעבוד מהר יותר ("Send an order by one-click").
גישת ה LEAN, שצמחה מיפן, הייתה לשלוח את כל מנהלי המלאי להיות עובדי ייצור - ולבטל כמעט כליל את תפקיד ניהול המלאי.


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

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

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

קאנבאן. מקור:  http://mylesbraithwaite.com/journal/2011/03/new-starbucks-coffee-cup-design/ 

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

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


ישיבות סטטוס
יצא לי לעבוד בצוות של 11 מתכנתים. המנהל היה "כוכב עולה" והצליח לנהל צוות כ"כ גדול.
ישיבות הצוות השבועיות (בעצם - ישיבות הסטטוס) נראו אבסורדיות: ישבנו כולנו במשך שעה, בעוד המנהל עבר איש-איש ושאל אותו כיצד הוא התקדם בפרטים של המשימות שלו. הספקת כבר לכתוב את זה? מה עם הבאג ההוא?
לאף אחד אחר בצוות לא היה אכפת - אלו היו משימות אישיות. המנהל היה עסוק במשך שעה ב 11 שיחות של חמש דקות שעניינו אותו, ולנו היו 5 דקות שיחה ו-50 דקות של המתנה משעממת.


קאנבאן Kanban בתוכנה
על פניה, קאנבאן היא מתודולוגיה מאוד פשוטה: היא מגדירה 4 חוקים שיש למלא:
  • גרמו לתהליך להיות נראה (visible) ע"י פרסום גלוי של מידע-מפתח[ד].
  • הגבילו את מספר הפריטים שבעבודה (Work In Progress = WIP)
  • הגדירו מדדי הצלחה ופרסמו אותם.
  • שפרו, באופן עקבי, את התהליך.
המוטיבציה לאימוץ קאנבאן במקור הייתה דיי פשוטה: ״אנו ארגון Support או Operations, אין לנו מוצר שניתן להציג כל ספרינט - אך אנחנו עדיין רוצים לעשות אג׳ייל. איך עושים את זה?״

התשובה הפשוטה (והלא-קלה) היא זו: מבטלים את הספרינטים. עושים את הכל כרגיל רק בלי ספרינטים. לא צריך Sprint Planning - כי העבודה נקבעת ע"י הלקוחות שפותחים קייסים.

אם ראיתם פעם את רשימת המטלות של ארגון סאפורט (כלומר Product Backlog), אתם בוודאי יודעים שיכולים להיות עשרות קייסים בטיפולו של כל צוות. אי-ניהול ה Sprint Backlog יכול ליצור מצב לא יעיל בו אנשי-הצוות במקביל על הכל (חוק התיכנותיקה: "ל Context Switch תמיד יש מחיר"). באירגון סאפורט קשה מאוד "להתחיל קייס ולסיים" - מכיוון שיש תלויות חיצוניות.
לשם כך מגדירים בקאנבאן מגבלה בשם Work In Progress. המגבלה מחייבת את הצוות, מצד אחד, לא לעבוד במקביל על יותר ממספר פריטים (כל צוות קובע עם הזמן את ה WIP שלו). מצד שני היא מחייבת את הצוות "לסיים" נושאים ויהי-מה, אחרת כל ה slots של ה WIP יתמלאו - והצוות לא יוכל להמשיך לעבוד.

ההנחה קאנבאן היא שעצם פרסום המדדים - יגרום לאנשים צורך לשמור עליהם ולשפר אותם תמידית.
כפי שציינתי, קאנבאן במקור השאירה חללים בהגדרה (בניגוד לסקראם - מתודולוגיה מפורטת למדי) שעל המיישם להשלים.
בפועל, עקרונות האג׳ייל (למשל "eliminate waste") הם אלו שמנחים וממלאים את החללים שלא הוגדרו במתודולוגית הקאנבאן. נראה שרוב האנשים שעושים קאנבאן, לומדים את רוח האג׳ייל מספרי סקראם: יש הרבה ספרים כאלו והם עוסקים בנושאים אלו באריכות. 

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

למרות שקאנבאן נתפרה לצוות ללא Deliverables - גם צוותי פיתוח יכולים לעשות קאנבאן והיטב. באופן אישי אני מעדיף  לעשות "קאנבאן עם ספרינטים". לקחת את קאנבאן כפי שהוא, ללא תפקידים מיוחדים (Scrum Master) או טקסים (Stand-Up Sit-Down meeting ואחרים), אבל עדיין עם תצוגת התקדמות יזומה בצורת ספרינט רביו: "מה עשינו בשבועיים-שלושה האחרונים".

שיהיה בהצלחה!


---

[א] בפוסט בשם מה בעצם חשוב בסקראם, תיארתי כיצד התמקדות בחלק קטן מהעקרונות של סקראם יכולה להביא לתוצאות יפות מאוד, מבלי לחוות את ״רעידת האדמה האירגונית״ שנובעת משינוי מבנה התפקידים באירגון (סקראם מאסטר - שהוא ״מאמן״, ומנהל אנשים - שלא אמור להשפיע יותר על הגדרת המוצר)

[ב] תוכלו לקרוא על כך בקיצור תולדות הסקראם.

[ג] רכישה של חלקים שיושבים במחסן במשך זמן ללא שימוש = מינוס בבנק וריביות. הרבה רכיבים כאלו זה בהחלט לא "אופטימום".

[ד] ברוח ה Waterfall האהוב, הצעד הראשון של ארגונים רבים במימוש Scrum או Kanban הוא השגת תוכנה (יקרה) שתעזור לנהל את התהליך בצורה Efficient (= מהירה לכאורה). ניהול הסטטוס של הצוות בתוך תוכנה, כך שצריך לגשת למחשב וללחוץ כמה קליקים על מנת לראות נתון כלשהו, היא הדרך ליצור חוסר-נראות. האאא הרגלים רעים...



5 תגובות:

  1. מעניין מאוד. מה שמעניין זה שעקרונות ניהוליים ועקרונות ארכיטקטוניים אים רחוקים זה מזה (בהקשר למודל ה- Pull vs Push שהדגמת). בסופו של דבר מדובר בניהול תהליך.

    אני רוצה להתכעב דווקא על הערה [ד] שלך. מסקרן אותי לדעת למה אתה חושב שתהליך כזה מקטין נראות. האם לדעתך מדובר ב- Overkill (לדוגמא לעומת לוח פיסי של BLI's) או שהגישה פגומה מיסודה?

    השבמחק
    תשובות
    1. היי ויטלי,

      תודה על התגובה.

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

      לגבי הערה [ד] - המסקנה שלי נובעת מניסיון בפועל. כשהתחילו אצלנו לממש SCRUM, בניגוד לעצת היועצים, רכשו מערכת מתוחכמת לניהול פרוייקטים ועבדו בה. פעמים רבות עלו שאלות בישיבות "בעצם איפה אנחנו עם X" או "מה קורה בכלל עם Y - עושים אותו או לו?" - שאלות שמעידות עד חוסר בקיאות. התקורה של להיות ליד מחשב + להשקיע כמה שניות בכדי להתחבר למערכת - פשוט מנעה מרוב האנשים בפרוייקט להישאר מעודכנים. אני מדבר על חברי הצוות ואנשים חיצוניים לצוות כאחד. אני מודה שגם אני לא מרבה להתחבר ולהתעדכן.

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

      אין לי מושג מה זה BLI.

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

      הייתי אומר שזה Push ולא Pull.

      מחק
    3. BLI זה Back-Log item.
      מה שעושים אצלנו זה מסך מחשב שמוצג במסדרון אשר מציג לכל המעוניין את כל ה- Task'ים שלנו. (בהתחלה היה לוח ואז השתדרגנו).
      כנראה שהתועלת הגדולה ביותר מפגישות ה- SCRUM היא דווקא שיתוף מידע אבל מסוג מאוד מסויים כגון:

      1. א: "אני עובד על באג x y z"
      ב: "יו! זה נשמע דומה לבאג שאני עובד עליו גם! אולי מדובר באותה הבעיה בעצם?"
      2. א: "אני מנסה לעשות x y z"
      ב: "ואללה, ניסית את A או דיברת אם B, הוא עשה מהשהו דומה לפני שבוע..."

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

      מחק
  2. נהיה יותר ויותר קשה להוכיח שאני לא רובוט :-)

    השבמחק