4 כללים למדידת פשטות של תוכנה

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

אחת ההגדרות שאני אוהב היא של בחור בשם J.B. Rainsberger, הגדרה של ״מבנה פשוט של תוכנה״.

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


ע״פ ריינסברגר (עוד), ישנם ארבעה אלמנטים (עם סדר עדיפויות ברור) המובילים לתוכנה פשוטה:

1. כל הבדיקות עוברות. 
2. צמצום כפילויות קוד. 
3. הקוד מתאר כוונה (clarity). 
4. צמצום  מספר האלמנטים בקוד למינימום האפשרי  אלמנטים שאינם משרתים את מטרות 1-3.

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


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

הנה דוגמה של קוד "ללא כפילויות" שהפריע לי והפכתי לכפול:

אני מסכים, זה לא קוד "מושלם", וספריית templating הייתה יכולה להפוך אותו ליפה יותר, אך זו דוגמה אמיתית מהחיים.

הנה הקוד לאחר השינוי:

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


קוד המתאר כוונה
אם מזקקים את הכלל של "כתיבת קוד המתאר כוונה", לרוב עיקר העבודה היא מסביב לשמות: שמות של פונקציות או משתנים, או שמות חדשים הנוספים ע"י פעולות "extract method" או "introduce variable".

ישנן 4 "דרגות" של שם:

1. שם סתמי
2. שם נכון
3. שם מדויק
4. שם בעל משמעות ("meaningful").

עצלנות ולחץ גורמים לנו להיצמד לתחתית הסקאלה (1,2), בעוד הקפדה ומקצועיות דוחפים אותנו לראש הסקאלה (3,4).

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

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

צמצום אלמנטים שאינם משרתים את מטרות 1-3. 

למי שנתקל ברעיונות אג'יליים - אני מניח שעקרון זה הוא מובן מאליו: Eliminate Waste. עדכון המטרה בעיקרון זה היא להימנע ממרכיבים בקוד שלא משרתים את הפונקציונליות, לא מונעים קוד-כפול ולא מסבירים את התנהגות המערכת, כל מיני "הכנות למזגן"[ג].

מי שעובד ב (Test Driven Development (TDD נהנה באופן מובנה מעקרון 1 ("כל הבדיקות עוברות") ועקרון 4 ("צמצום אלמנטים לא-חיוניים"). זו הדרך המהירה ליצירת קוד פשוט, שגם יישאר פשוט לאורך זמן.

מכאן נותרו רק 2 פעולות לשים לב אליהן:

צמצום כפילויות קוד [ב] ו כתיבת קוד המתאר כוונה / קוד ברור. המשיכו לעשות את אלו בצורה תמידית - והמבנה של הקוד שלכם, או ה "design" של הקוד שלכם - יהיה פשוט. זו הדרך היעילה ביותר שאני מכיר.

זה אולי נשמע קצת פשוט מדי: אולי ציפיתם לשימוש במחשבון של Cyclomatic complexity וטכניקות של ספירת Weighted Micro Function Points (ממש כמו ספירת קלוריות). 

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


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

----

[א] יש המשתמשים במילה Design על מנת לתאר מצב של תוכנה חיה, ולא רק את התוכניות. לדוגמה: "Refactoring: Improving the Design of Existing Code". אם הרעיון הזה ברור לכם - הרגישו חופשיים להשתמש במילה design ולא ב structure.

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

[ג] המטאפורה הזו מטעה! מזגן הוא דבר מוכר שאנו יודעים לצפות לו ולבנות לו הכנה טובה. רוב ה"הכנות למזגן" בתוכנה הם ניחושים בעלטה אודות משהו לא-ידוע. בהתאמה: מנסיוני, רובן מתגלות כלא-יעילות או חסרות שימוש.

המתכנת הרציונלי

״מה שמייחד איש מקצוע אמיתי הוא ההתבססות על ידיעות - לא על ניחושים״. האם אתם מסכימים עם האמירה הזו?

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

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

לא סביר שכל האנושות, בכל רגע, תפעיל חשיבה עובדתית. ...זה לא אנושי, כנראה.

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


הטיות אנושיות

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

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

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

לא רק שמאים חשופים להטיה - כל בני האדם חשופים.

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

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

הטיות אנושיות מוכרות מוכרות אחרות כוללות "מציאת תבנית" (pattern) לא קיימת בנתונים אקראיים - וייחוס חשיבות לקשר[א], השפעה מתכונה אנושית אחת (למשל: יופי חיצוני) על הערכת תכונה אחרת לא קשורה (למשל: טוב לב, חכמה) - מה שנקרא אפקט ההילה, ועוד.

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

העגל רוצה לינוק
כבני אדם, אנו בנויים על מנת לינוק מידע. יש לנו נטייה ברורה להעדיף דברים שאנו רוצים לשמוע על פני דברים שלא.
כשאנחנו מחפשים אחר מידע, אנו מחפשים בצורה מגמתית שסביר יותר שתוביל אותנו להיכן שאנו רוצים להגיע. מצאתי את עצמי, לא פעם, מבצע בגוגל שאילתות כגון "SomeTechnology> good performance>" או "'why use TechA". כמובן, שמצאתי תוצאות שהשביעו את רצוני והמשכתי עמן הלאה: מצגת, שכנוע, החלטה.

כשעשיתי את התרגיל וחיפשתי את השאילתות ההפוכות: "SomeTechnology> poor performance>" או "techA problems" - מצאתי, לעתים קרובות, תוצאות מספקות שהיו יכולות לשרת אותי אם הייתי רוצה לטעון את ההפיך הגמור.

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

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

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

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

מאמץ להשתמש ב"שפה גבוהה ומתוחכמת" או להיצמד לשמות גדולים (גוגל, אפל, וכו') - יכולים גם הם להיות סימני אזהרה ברורים למידע לא רציני[ב].

הטיית השטן

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

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

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


מילת סיכום

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


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


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

---

[א] תרגיל מעניין הוא השמעת קטעים מוזיקליים לאחור - מה שהופך אותם לרצף דיי אקראי, ומציאת "מסרים סמויים" ברצף. ב http://jeffmilner.com/backmasking/ תוכלו למצוא כמה דוגמאות. לא סביר שתוכלו להבין משהו מהקטעים שמושמעים לאחור, אך לאחר שתקראו טקסט ההסבר (לדוגמה: "James Brown is dead") - יהיה קשה לכם להתכחש לכך שזה בדיוק מה שנאמר שם. לאחר שהורגלו ברעיון ("זיהינו את התבנית") - קשה לנו לחזור בנו ולהתעלם ממנה.

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

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

קאנבאן (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 (= מהירה לכאורה). ניהול הסטטוס של הצוות בתוך תוכנה, כך שצריך לגשת למחשב וללחוץ כמה קליקים על מנת לראות נתון כלשהו, היא הדרך ליצור חוסר-נראות. האאא הרגלים רעים...