Kanban מול Scrum

 IT כגישה לניהול פיתוח אג’ילי בארגוני

IT  מאת: חנן אלכסנדר, יועץ אג’ייל, מנהל תחום

stickies

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

מי מכם שלא שמע על Kanban כגישה אג’ילית לניהול פיתוח, מוזמן להמשיך לקרוא…

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

לכל הדעות מטרות ראויות.

אחת השאלות המשמעותיות ביותר כשמתחילים בשינוי מהסוג המדובר, מיד אחרי הבנת הכאבים של הארגון, היא – איך מתחילים? האם ב Big Bang או בהדרגה? האם Scrum, Kanban או שילוב שלהם? האם להתחיל מפרויקט ספציפי או לפי יחידות ארגוניות?

הפעם אתמקד בבחירת המתודולוגיה

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

אבל על Scrum בטח קראתם לא מעט ולא צריך לשכנע אתכם שזה שווה את המאמץ.

אז הנה כמה שאלות למתקדמים:
איך עושים Scrum בארגון שמשתמש בשירותיהן האדיבים של חברות מיקור חוץ? למשל, שירותים מנוהלים המתומחרים ב Fix Price? צוותים שלמים שמנוהלים חיצונית בשיטות תמחור שונות?

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

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

אז מה עושים?

זה הזמן להגיד כמה מילים על Kanban בלי לסבך יותר מדי.

3 עקרונות פשוטים להבנה שאחד מהם ממש קשה ליישום (הבנתם נכון, השניים האחרים ממש אינטואיטיביים!):

  1. הציגו את העבודה שלכם באופן ויזואלי ומפורש.
  2. עזרו לעבודה לזרום (Flow).
  3. הגבילו את כמות העבודה בתהליך (כדי לעזור לעבודה לזרום).

דוגמה ללוח “מהחיים”:

Real Kanban Board

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

אבל (ידעתם שזה יבוא בסוף נכון?), להגביל את כמות העבודה בתהליך (WIP – Work in progress) זה כבר סרט אחר לחלוטין. זה אומר שבנקודות מסוימות אי אפשר להתחיל עבודה לפני שמתפנה מקום בהמשך השרשרת. זה ממש קשה להגיד שאנחנו לא יכולים לעשות משהו עכשיו. ובכלל, מסתבר שיש לנו נטייה לעשות יותר מדי דברים בבת אחת או לפחות יותר ממה שאופטימלי עבורנו.

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

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

הייתכן? נמשיך לעשות את אותו הדבר וככה בקלות נהיה אג’יליים? אתם ודאי שואלים איפה חותמים…

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

ואל תשכחו את ה WIP Limit…

אז איך עושים את זה?

  1. מבינים מה השלבים המשמעותיים בעבודה שלנו ומייצרים עמודה בלוח לכל אחד מהם.דוגמה נפוצה: חדש, תעדוף ראשוני, אפיון, פיתוח, בדיקות, ייצור.
  2. עוברים על כל הדברים שעושים ומשבצים אותם כפריטים תחת העמודה המתאימה.
  3. מסתכלים על הלוח ומגלים הרבה מאוד בעיות דוגמת אלו שפירטתי קודם.
  4. מתחילים לעבוד עם הלוח ולחשוב מה צריך לעשות כדי לסיים דברים במקום איך לוודא שכולם עסוקים (זה מה שאנחנו רגילים לעשות כמנהלים). באופן מפתיע, זה שכולם עסוקים לא תמיד עוזר לקדם דברים.
  5. מפחיתים בהדרגה את כמות המשימות המתבצעות בשלבים השונים. בעיקר בשלבים בהם יש לנו נטייה לצבור עוד ועוד משימות ולא לסיים כאלו שכבר התחלנו (Limit WIP). זה לא קל בכלל!

יש עוד, אבל אני רוצה לעצור פה כדי לסכם את התובנות המרכזיות:

  1. אם תעבדו נכון תייצרו: מטרה משותפת לכל השותפים הפרויקט, זרימה משופרת של העבודה בין הגורמים השונים בתהליך, קיצור Time To Market, הסתכלות מקצה לקצה ועוד, וזאת בלי להידרש למהפכות גדולות (בטח בהתחלה).
  2. להיות אג’ילי לא בהכרח אומר שצריכים לעבוד ב Scrum (אם כי זה בטוח יעזור).
  3. כדאי לשקול Kanban במקרים בהם קשה לייצר צוות הטרוגני מסיבות אלו או אחרות.
  4. כדי להתחיל עם Kanban לא צריך לשנות כלום בשיטת העבודה הקיימת, אבל כדאי להתכונן להצפה של דברים שיזיזו אתכם מאזור הנוחות שאולי הייתם בו קודם…

Start typing and press Enter to search