"זה נראה כמו סיפור הצלחה"

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

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

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

נושאים טכנולוגים (במיוחד חדשים) הם הרבה פחות מוכרים ואינטואטיביים: למשל Big Data. אם הייתי מספר לכם שיש לי אפליקציה שולחנית עם המון נתונים (אולי איזה 10GB!!) ואני רוצה להיכנס לעולם ה Big Data – ייתכן וזה היה נשמע יותר הגיוני. "למה לא?" הייתם עונים "זה תחום חם היום." – "פשוט מגניב!".

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

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

קרוב לוודאי שזה נשמע מצחיק (השתדלתי), אבל התיאור אינו שונה כ"כ ממאמצי אימוץ שונים שנתקלתי בהם: SCRUM, Object-Oriented ו test-automation – ואלו הן רק כמה דוגמאות ("to name the few").

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

הדגשים העיקריים מניסיוני הם אלו:

התמקדו בתוצאות – והזהרו מהתמקדות ב"חזות המקצוען"
ב SCRUM צוותים ממהרים להציג לוחות Burn-down Charts ולעשות Stand up meeting.
אם אח"כ, בישיבת ה Retrospective, רק ה Scrum Master מדבר ומחלק ציונים לכל האחרים – כנראה שמשהו התפספס (סיפור אמיתי). אם יש לכם שני ספרינטים של Design ואז שני ספרינטים של "מימוש" ואולי עוד ספירנט "בדיקות ו Stabilization" – כנראה שמשהו התפספס (המשך של אותו הסיפור).

פעם ראיתי ראש צוות שלמד Object-Oriented באמצע הקריירה (הוא בא מ Kernel C). הוא יצר מחלקה "פונקציות", מחלקה "קבועים" ומחלקה "משתנים" (והמשיך לפתח פרוצדורלית, כמובן). "הבנתי את הסיפור" הוא הכריז. "נחמד, קצת עושה סדר – אבל אני לא מבין למה עשו מ OO כזה רעש…"

אנו רוצים "להראות" כמו המקצועניים ו"להרגיש" כמו המקצוענים – ומהר, אבל בעצם יותר חשוב שנראה שיפור מדיד (ע"פ מדדים אובייקטיבים) ולבסוף נגיע לתוצאות טובות יותר מאשר השיטה הישנה. האם לחלק את הפונקציה ל class נפרד משפר את הקוד? אם לא – חשוב לשפר סגנון או לזנוח את ה OO. עדיף Waterfall מוצלח (אם יש דבר כזה…) על SCRUM רע ועדיף תכנות פרוצדורלי מסודר על פני תכנות OO מגוחך.

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

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

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

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

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

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

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

הניחו לצורך בהצלחה סובייקטיבית להתמלא ולחלוף – ושמרו כוחותיכם להצלחה האובייקטיבית הנדרשת הבאה.

קיצור תולדות ה SCRUM, חלק 2 – עקרונות ה LEAN

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

לא משנה באיזו מתודולוגיה אג'ילית תבחרו לעבוד ובאיזו תעשייה, שווה להכיר את המקור – הרי הוא ה (TPS (Toyota Production System של חברת טויוטה. להלן כמה מהערונות העיקריים של ה TPS שאומצו ע"י תנועת ה LEAN. קרוב לוודאי שכמה מהמושגים שאציין ישמעו לכם מוכרים.

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

Kaizen – "שיפור מתמיד"
העקרון לפיו אין לקפוא לרגע השמרים – יש לשפר כל הזמן. מי שמכיר ארגונים יודע שאין סוף לשיפורים האפשריים. אפילו אם הגענו לקצה האופטימיזציה האפשרית, הסביבה העסקית והטכנולוגית משתנה כל הזמן ויוצרת הזדמנויות שיפור נוספות. אנו עושים Retrospective בסיום כל ספרינט ב SCRUM על מנת להמשיך ולהשתפר כל הזמן [1]. השיפור איננו תלוי ביזמה מיוחדת של העובדים – הוא נדרש ומצופה כל הזמן. אנו מקצים זמן מיוחד על מנת לעצור הכל, להתבונן על ביצועינו – ולשפר.

אחד ההבטים שמתקדים בהם ב TPS הוא מציאת ה waste וביטולו. זאת בניגוד לגישת ה Waterfall בה מנסים לקחת תהליך קיים – ולמקסם (maximum) אותו. על פניו, זו נשמעת דקדקנות גרידא – אך ההבדל בצורת החשיבה מוביל לתוצאות שונות לגמרי.

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

5Y, בעצם 5xWhy – "לפתור בעיות מהשורש"
עוד עקרון חשוב הוא תחקור מעמיק על מנת לפתור בעיות מהשורש. ע"פ עיקרון ה 5Y, בכל פעם שנתקלים בבעיה יש לעצור ולשאול את השאלה "למה?" חמש פעמים – ורק אז לגשת לביצוע הפיתרון.

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

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

Stop the Line" – Jidoka"
עקרון מחמיר זה אומר שברגע שיש תקלה (לדוגמא זיהוי חלק לא תקין בפס הייצור) יש לעצור מיד את הקו, לתחקר במקום את הסיבה (זה יהיה נאמר 2Y, לא 5Y), לתקן ורק אז להמשיך ולהפעיל את פס הייצור. היכולת של תחקור ותיקון מהירים היא קריטית להצלחה – ובאחריותם של העובדים (לא סביר להשבית את הקו עד שהמנהל יהיה זמין).

בהקשר זה אני רוצה להציג עקרון מרכזי נוסף של ה TPS (שקשור גם ל 5Y): תיקון בעיות מהשורש והמנעות מהוספת תלאי / שכבה מרפדת.

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

אם נפעל ע"פ עקרונות ה LEAN נעבור ממצב 1 (השמאלי) למצב 2 (במרכז) – בו יש פחות Waste. אולם במצב זה בעיה שעד עתה הייתה מוסתרת – מוענת מאיתנו להמשיך.

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

הנה כמה דוגמאות:

בעיה: אנו מאחרים ב Deliveries. פתרון Waterfall: להכפיל כל הערכת זמנים פי 2, ראש הקבוצה יכפיל את ההערכות פי 1.5 ומנהל הפיתוח יוסיף עוד שבועיים משלו "בצד".
- פתרון אגי'לי: שיפור תהליך הערכה כך שיהיה ניתן להסתמך עליו או יצירת חוזה "גמיש" עם הלקוחות, בו מתחייבים על חלק מהתכולות, וחלק אחר נתון להספק משתנה של גוף הפיתוח.
- הערה: ע"פ ה LEAN כל Buffer הוא Waste, ויש לצמצם buffers למינימום האפשרי.
בעיה: אין תקשורת טובה בין קבוצת הפיתוח לקבוצת ה QA. פתרון Waterfall: נוסיף מסמכים שישמשו כתקשורת (!Waste – סביר להניח שרוב העבודה על מסמכים אלו תהיה בזבוז זמן. ייתכן ותעלה הטענה "על שיפור צריך לשלם" – אך זו טעות לוגית, מכיוון שבמקרה זה סביר שנשלם יותר משנדרש).
- פתרון אג'ילי: למצוא דרכים לשפר את התקשורת בצורה לא בזבזנית: להושיב את הקבוצות קרוב אחת לשנייה, לצרף את ה QA למפגשי סנכרון יעילים עם קבוצת הפיתוח וכו'.
בעיה: עובד מסוים לא מבצע עבודתו כראוי. פתרון Waterfall: שמישהו אחר יעשה זאת במקומו. או אולי – נוסיף מישהו בכיר שיפקח על כל צעד שלו.
- פתרון אג'ילי: לחנוך ולסייע לאותו אדם לבצע את העבודה שלו כראוי ולהגיע לעצמאות.
בעיה: שינוי קוד רוחבי במערכת פספס קומפוננטה מסוימת. פתרון Waterfall: להוסיף לכל מסמך Design פרק עם כל הקומפוננטות או ביצוע ישיבות עדכון בה ישתתף נציג מכל קומפוננטה לכל שינוי במערכת.
- פתרון אג'ילי: לייצר רישום: מי רלוונטי לאיזו קומפוננטה, ולאמן את כל אנשים בפיתוח להשתמש בה בתבונה. זה יכול להיות תהליך ארוך וקשה יותר ליישום – אך בסיומו יהיה מעט מאוד Waste.

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

Kanban ("ארגזים מסומנים")
עקרון חשוב נוסף ב TPS הוא החתירה ל "Flow". מצב בו התהליך מתקתק בצורה טבעית, קלה וכמעט בלתי מורגשת אך בכל זאת – יעילה להפליא. חידוש משמעותי בפילוסופיה האג'ילית הוא שימוש עקרי במשיכה "Pull" כנגד דחיפה [2]"Push" המקובלת בניהול המסורתי.

בתעשייה המסורתית, היו מייצרם בקצב בו המכונות יכולות לעבוד – במקום בקצב בו נדרשת התוצר. בתעשיית התוכנה הקבלה אפשרית היא פיתוח 100 פי'צרים במוצר חדש (כי זה מוצר מבטיח וחשוב להצליח בו) מקום לפתח רק 20 פיצ'רים שידועים שנדרשים. הקצב נקבע ע"פ יכולת הייצור ולא ע"פ הביקוש.

הרעיון של Kanban הוא ליצור רצף (Flow) של משיכות. טויוטה אינה מזמינה כל חודש מהספקים שלה כמות קבועה של חומר גלם וחלקים. היא איננה יודעת כמה מכוניות מדגם זה או אחר הלקוחות באמת יזמינו. במקום זאת, כשיש הזמנה לרכב – רק אז נשלחת בקשה למחלקת ההרכבה (השלב האחרון בשרשרת ייצור הרכב), זו שולחת את הדרישות שלה למחלקות הייצור השונות ואלו מזמינות את החלקים מהספק.
כיצד מזמינים 18 ברגים להרכבת דלת? כמובן שזה יהיה בזבוז. טויוטה מחזיקה מלאי מינימאלי. במחלקת הדלתות יש 10 ארגזים של ברגים. כל פעם שארגז מתרוקן שמים אותו בערמה של ארגזים ריקים. על הארגז רשום בצד אחד "ברגים מסוג 123" ומצד שני "מחלקת דלתות – צוות יושימושי". הארגז יישלח (ביחד עם ארגזים אחרים ריקים) לספק – אשר ימלא אותו בברגים ע"פ הכיתוב: "ברגים 123". הארגז יחזור מלא בחלק החסר לשולח – במקרה שלנו הצוות של יושימושי במחלקת הדלתות.

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

Amplify Learning / Amplify Feedback
עוד עקרון חשוב, שהוא אולי המוכר ביותר במתודולוגית SCRUM, הוא העקרון של קיצור מחזורי ה feedback על מנת להגביר את הלמידה.

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

וכו'

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

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

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

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

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

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

[1] Retrospective גם מתמפה לעקרון ב TPS שנקרא Hansei – התבוננות עצמית.

[2] לאחר שיצא לי לחוות את Agile ועקרון ה Flow, כל פעם שאני שומע את הפועל "נדחוף" (פיצ'ר/תוצר/יזמה) נאמר – אני בודק האם מדובר בתוספת שלא באמת נחוצה ע"פ בחינה אובייקטיבית.

קיצור תולדות ה SCRUM, חלק 1

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

לא מעטים יספרו על גוגל – חברה שכמוה לא הייתה מעולם: ״איזו חברה מאפשרת לעובדים לעסוק יום בשבוע במה שמתחשק להם??". ויש גם את SCRUM, XP וכל תנועת ה Agile: מי שמע על דבר דומה בתעשייה המסורתית?

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

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

מי שעוד מתמודד עם הבנת SCRUM – מוזמן לבדוק את התרגום העברי לספרון המצויין: "סקראם מהשוחות" (שוחה – קדמת שדה הקרב)

במשך השנים תעשיית התוכנה חיפשה רבות, אך כמעט ולא מצאה כלים שמסייעים משמעותית לפריון (Productivity) : לא OO, לא IDEs, לא שפות תכנות חדישות, לא שיתוף קוד ולא SOA. אולי אפילו ההפך [1].

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

SCRUM (ואג'ייל בכלל) לא רק מסייע לפריון, אלא לרוב גם עוזר ליצור מוצר שמשביע את דרישות הלקוח בצורה טובה יותר ואף מסייע להטמעת איכות גבוהה יותר [2].

בואו ונחזור אל ההיסטוריה, מאין הגיע ה SCRUM/AGILE/LEAN וכיצד הוא נוצר…

מפעל המכוניות של משפחת טויודה

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

בשנת 1937 הקים טויודה חברה לייצור מכוניות – תחום מבטיח שצמח במהרה. אולם באותה תקופה ביפן לא היו מקובלות הלוואות, מכירה באשראי או השקעות חיצוניות (כגון Venture Capital). זו הייתה מגבלה חמורה ליכולת של העסק לצמוח במהירות. רק לאחר שסיים את ייצור batch של רכבים יכול היה למכור אותם ברווח קטן ולהתחיל ב batch גדול מעט יותר. מהירות הכנת ה batch (מה שנקרא Lead Time) וכמות המזומנים הזמינה בכיס בכל רגע נתון, הפכו להיות הגורם המרכזי ביכולת החברה לצמוח. טויודה התמקד במשימה: פיתוח הדרכים היעילות ביותר לקיצור ה Lead Time והגדלת ההון הנזיל.

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

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

בקיצור – פס הייצור המודרני.

יעילות נוסח המהפכה התעשייתית / Waterfall

יעילות עור-ועצמות

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

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

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

התהליך היה קשה וארוך ,אך אלו היו יפנים – שסבלנות עבורם הוא מקור לגאווה.

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

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

תרומה משמעותית נוספת הייתה של פרופ' אדוארד דמינג, חוקר אמריקאי שהציג גישה חדשה לאיכות: "איכות אינו שלב בתהליך, איכות צריכה להיות שזורה בתהליך – לכל אורכו" (מה שנקרא TQM – Total Quality Management). בעוד שבארה"ב לא התייחסו אליו ברצינות, ביפן גילו עניין עצום בתורתו, אימצו אותה והוא קיבל מעמד של גורו-על.

התוצאות לא איחרו לבוא והיו ניכרות. טיויטה בראה יעילות ואיכות שלא נראו עד כה בתעשיית הרכב.

יעילות נוסח טויוטה / Agile / Lean

מפגש התרבויות

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

לעזרת היפנים, במקרה, הגיע משבר האנרגיה של 1973 – כאשר מדינות ערב עצרו את אספקת הנפט למערב כתגובה לתמיכתן בישראל במלחמת יום הכיפורים. מחירי הנפט האמירו בצורה חדה (המחיר עלה פי 4 תוך זמן קצר. בחישוב מנורמל להיום: מ 15$ ל 60$ לחבית). התלות של המערב בנפט הייתה טוטאלית: עסקים הפסיקו לעבוד (לא יכלו לייצר ברווח), הכלכלה קרסה ולחלופות זולות ומיידיות לאנרגיה היה ביקוש רב. הצרכנים האמריקאים החלו לחפש רכבים הצורכים מעט דלק וכך שיחק מזלן של היצרניות היפניות: הן הצליחו לחדור בצורה משמעותית לשוק האמריקאי. משבר האנרגיה הסתיים ב 1974 כאשר מצד אחד ארה"ב דרשה מישראל לסגת מסיני (לא, נראה שזו לא הייתה יזמה ישראלית. חומרי הלימוד של משרד החינוך בהסטוריה הם קצת מגמתיים) ומצד שני בריטניה הציגה בפומבי תוכנית אופרטיבית לפלוש למדינות ערב ולקחת את הנפט בכוח.
אותה שנה הספיקה לטויוטה להגיע למספיק לקוחות אמריקאים בכדי שיגלו שני דברים:

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

עוד ועוד לקחות רכשו את "המכוניות שאינן מתקלקלות" וחברות הרכב נלחצו וניסו להבין "איך היפנים עושים את זה?" [5].
ב1980 פורמה כתבה ברשת NBC שעוררה הדים בשם "?If Japan Can, Why can't we".

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

אימוץ השיטות של טויוטה בעולם המערבי
השם שנתנו האמריקאים לשיטה היפנית הוא Lean Manufacturing ולרעיון של ניהול מלאי – (Just In Time (JIT. שם אמריקאי ומדריכים אמריקאים עזרו רבות לקבל בחום את השיטה. אימוץ השיטה התחיל אמנם מתעשיית הרכב אולם התפשט לתעשיות אחרות רבות. כיום רוב תעשיית הייצור, אך גם חלק גדול ממגזר השירותים, הבנייה, רשתות קמעוניות ואפילו משרדי ראיית חשבון והמוסדות האקדמים אימצו את עקרונות ה Lean. הייתרון התחרותי הינו כ"כ חד-משמעי, כך שבתעשייה בה קם שחקן שאימץ את השיטה בהצלחה – נאלצו שאר המתחרות לאמץ אותה גם כן על מנת לשרוד[6]. אם תבקרו, למשל, בסניף של דומינוס פיצה ותצפו בעובדים בפעולה – תוכלו לזהות רבים מהעקרונות שאציין בהמשך. אם תשאלו את העובדים האם הם עובדים "Lean" קרוב לוודאי שתענו: "מה?? … לא. סתם. ככה אנחנו עובדים פה".

בתעשיית התוכנה, היו כמה נסיונות ליישם מתודולוגיות פיתוח המבוססות על עקרונות ה Lean כבר באמצע שנות ה-90. תשומת הלב המשמעותית הגיעה לדעתי עם הופעת ה Extreme Programming אותה הציג קנת בק – מתודולוגיה קיצונית אך מעוררת מחשבה.
עולם התוכנה נתן שם משלו לסגנון ה LEAN ושמו: Agile. עבודה רבה נעשתה ע"י מרי וטום פופנדיק אשר חזרו למקורות ועזרו לתרגם את רעיונות ה LEAN לעולם התוכנה בצורה מקיפה [7]. בשנת 2001 התכנסו כמה מראשי המתודולוגיות השונות לחתום על מסמך הסכמות המשותף לכל המתודולוגיות – הרי הוא ה Agile Manifesto.

נראה שרק שבאמצע שנות האלפיים ה Agile "חצה את התהום" – והגיע למיינסטרים. כיום חברות רבות, כגון Microsoft, Yahoo, Google, SAP, IBM, Salesforce ועוד אימצו בחלקים כאלו או אחרים את SCRUM ובהצלחה.

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

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

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

[1] מה שנקרא "There is no Silver bullet".

[2] ישנם דיווחים על הצלחה של SCRUM בחברות שונות, גדולות וקטנות – אך עדיין מוקדם לדעת בוודאות מה גודל ההצלחה. מנסיון אישי, קשה לי לחשוב על שינוי משמעותי בתעשייה בעשור האחרון שמשתווה ל Agile. למשל, TDD הוא נהדר – אבל הוכח כבר שאינו מתאים לכל אחד = אינו scalable ברמת התעשייה. SCRUM הצליח אצל אנשים שאהבו אותו יותר ופחות, ארגונים קטנים וגדולים, פרוייקטי פיתוח ותחזוקה. כמובן שיש ש SCRUM לפעמים הצליח פחות ולפעמים יותר.

[3] כמובן שהשפל הגדול היה האטה משמעותית במגמה, אך זה רק היה עיכוב – והיא המשיכה והתעצמה.

[4] מספר משיכות המכחול לכתיבת "טויוטה" הוא שמונה. מספר מזל בתרבות היפנית, שאינה נקייה מאלמנטים מיסטיים.

[5] כיום לטויוטה (ולמותג היקרה שלה – לקסוס) יש רק ייתרון קל באיכות ע"פ המתחרות האחרות (ע"פ סקרי J.D Power אשר בונים בסיס נתונים על תקלות ברכב של עשרות אלפי לקוחות). בשנות ה-80 פער האיכות היה משמעותי ביותר, אך נראה שהפער הצטמצם בכך שכל חברות הרכב בעולם אימצו את שיטת ה Lean.

[6] דוגמא טובה היא DELL שהצליחה לייצר מחשבים מהר, טוב וזול מהמתחרות ושברה את השוק. HP אימצה את שיטות ה Lean גם כן, התאוששה, סגרה פערים ואפילו התקדמה קצת מעבר.

[7] הספר הבולט והמומלץ ביותר הוא כנראה Lean Software Development שיצא ב 2003 אך עדיין מאוד רלוונטי.