קנבן – הדרך לניהול רזה בסביבת פיתוח תוכנה

מהו ניהול רזה בעולם פיתוח התוכנה? ( הינה גישה המתאימה לארגוניLean Software Development / Lean ITניהול רזה בעולם פיתוח התוכנה )

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

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

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

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

( תוך כדי מינוף ההוןKaizen( בארגון ומקנה שיטות ניהול ועבודה החותרות לשיפור מתמיד )Flowהעבודה ) האנושי – אותם אנשים הקרובים לשטח ויודעים איפה הבזבוזים המשמעותיים. אנשים אלה יכולים להביא

רעיונות ברי ביצוע שאפשר לנסות לממש כדי לשפר את ביצועי הארגון.

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

(Theory of Constraints(. שיטות שיפור בעולם הייצור והשירות )למשל תורת האילוצים Flowמודל הזרימה ) ( מרגע הופעת דרישה או צורך עד למימוש הערך הנדרש. על ידיCycle Timeמדברות על קיצור זמן הסבב )

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

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

חשיבות תהליכי משוב מהיר בעולם התוכנה הקורא העירני יתהה למה כאלה הם פני הדברים. הלא אי אפשר להשוות את מחיר האחסנה של קוד או

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

(. בעולם זה אנחנו מקבלים הרבהKnowledge Workמערכות המידע שייכת לתחום "עבודת הידע" ) ( כדי לודא שהחלטותינו נכונות. דוגמאות לאיFeedbackהחלטות בתנאי אי ודאות וזקוקים למנגנוני משוב )

ודאות – האם בחרנו את הדרישה הנכונה להתמקד בה כדי לספק ערך מקסימלי ללקוח? האם האפיון שלנו באמת עונה לצורך? האם הקוד עונה לאפיון? האם המערכת עובדת כמו שצריך אחרי שהוספנו את

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

( Kanban Methodמודל זרימה ושיטת הקנבן ) ( ומנסה לייצר עבודה ממוקדת בה אנחנוEarly Feedbackמודל הזרימה מדגיש את הצורך במשוב מהיר )

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

הערך שציפה לו(. התמקדות זאת מתבצעת ע"י המחשת העבודה בצורה המדגישה את הזרימה במערכת(Visualize the Work בדרך כלל על ידי לוחות – )Kanbanהמראים את מצב הזרימה הנוכחי. בלוחות אלה

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

Kanban Board

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

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

Cumulative Flow Diagram

אחרי שנתחיל לנהל את העבודה במודל הזרימה נבצע הגבלה של כמות העבודה המתבצעת במקביל (. הצעדים שתוארו בפסקה האחרונה הם בעצם הצעדים הראשוניםLimited Work in Processבתהליך )

( – שיטה לניהול שינוי והשתפרות בצורה אבולוציונית מונחית. Kanban Methodב"שיטת הקנבן" )

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

( שאנחנו מחילים עלConstraints אנחנו משתמשים ב"מגבלות" )Kanbanמהעשייה היומיומית? בשיטת ה- (Improve Collaboratively using Modelsעצמנו בכוונה כדי לדרבן תהליך השתפרות המערב את האנשים )

( הינה מגבלהLimited Work in Processולכוון אותו לכיוונים הרצויים. למשל הגבלת העבודה במקביל ) כזאת. כמובן שאם נגיע לארגון קיים יהיה קשה מאוד לקום מחר בבוקר ולעבוד על עשירית מכמות

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

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

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

Improvementהדרגתי, נשתפר וגם נגביר את שילוב האנשים בשטח. השיטה שתוארה כאן נקראת גם Kata (Rother)לאורך הדרך נשתמש במודלים לשיפור הרלוונטיים לסוג המחסום שמולנו. מודלים לדוגמה .

או מיפוי השונות והתמודדות עם נקודות קיצון. Theory of Constraints Five Focusing Stepsיכולים להיות

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

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

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

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

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

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

אבולוציה – הדרך להשתפר בסביבות מורכבות למה בעצם אי אפשר להגדיר מראש מה צורת העבודה הנכונה ופשוט לעבור אליה בלי תהליך של ניסוי

(.Complex Systemsוכוונון המתואר כאן? הסיבה העיקרית היא שרובנו עובדים בסביבות מורכבות ) בסביבות אלו יש יחסי גומלין מורכבים בין הגורמים המעורבים ואי אפשר לדעת מה הפתרון האידאלי

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

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

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

והתמקדות משמש אותנו הןEarly Feedbackאל מול "כוונת המשורר". כדאי לשים לב שאותו מודל של לפיתוח התוכנה והן לפיתוח התהליך! התובנה שרוב הסביבות המעניינות אותנו הן מורכבות מסביר את

להתמודד בצורה מוצלחת יותר עם המציאות של שינוי ארגוניLean ו-Agileההצלחה הרבה של גישות כגון ופיתוח תוכנה מאשר שיטות "סטטיות" יותר המניחות אפשרות לתכנן פתרון מוצלח מראש ואז לצאת

ולבצע אותו.

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

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

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

(.Lead Time)הפחתה של הזמן מבקשה ראשונית ועד למימוש הערך לקוחות/משתמשים/נותני חסות עסקיים ידווחו על חווית שימוש משופרת ורמת שביעות רצון

.גבוהה יותר

= בה. יובל מגיע מעולםKanban המתמקד ומוביל את תחום הAgileSparksיובל ירט – יועץ בכיר בחברת Kanban. הוא ממובילי תנועת ה-IT שנה בתחומי פיתוח תוכנה ו-17ניהול הפיתוח, עם נסיון של מעל

. יובל כותב בלוג בנושאי פיתוחAccredited Kanban Trainer ו-Lean Systems Society Fellowהעולמית, ”. Holy Land Kanban ופרסם לאחרונה ספר מאמרים בשם “www.yuvalyeret.comתוכנה ואג'יל בכתובת

AgileSparksעוזרת לחברות לשפר את יכולות ניהול הפרויקטים שלהן ע"י אימוץ שיטות

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

www.agilesparks.com

כדי ללמוד עוד על קנבן ותחום ניהול הפרויקטים, הצטרפו לאחד מקורסי הקנבן הקרובים -http://www.agilesparks.com/Training/KanbanForManagersLeaders