כיצד ייתכן?!

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

כיצד ייתכן שהמחשב הראשון של אפל כלל רק "לוח אם": הייתם צריכים לקנות בנפרד מקלדת ולהרכיב בעצמכם מארז??

האם זה הגיוני? אתם יכולים לדמיין זאת?

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

כיצד ייתכן, אם כן, שהאייפוד הראשון תמך רק ב MacOS עם חיבור Firewire?
ושהוא היה כ"כ לא אמין עד שכ 20% המכשירים התקלקלו בטווח שימוש סביר?

כיצד ייתכן שרק ב iOS 4 (אמצע 2010) האייפון קיבל תיקיות לארגון האפליקציות? האם אתם מדמיינים אתכם מפתחים מערכת הפעלה ללא תיקיות?

“If Apple can launch a smartphone without Find or Cut-and-Paste, what can you cut out of your product requirements?” – Sramana Mitra

כך נראה Youtube בשנת 2005. לא, זו לא תקלה – כך באמת הוא נראה.
מקור: http://www.telegraph.co.uk/technology/6125914/How-20-popular-websites-looked-when-they-launched.html

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

כיצד ייתכן שרק בסוף 2010 Gmail שחררה את הפ'יצר הבא: Context Sensitive Help. עד אותו רגע ה Help תמיד נפתח בדף הראשי, ללא קשר. האם אתם מדמיינים את עצמכם משחררים תיעוד של מוצר שלא מקושר לתוכן?

העיצוב של וויקיפדיה בשנת 2001.
מקור: http://www.telegraph.co.uk/technology/6125914/How-20-popular-websites-looked-when-they-launched.html

אפרופו תיקיות, Gmail אפשרה לארגן הודעות מייל בתיקיות רק ב 2009, שנתיים אחרי ששוחררה לקהל הרחב. אני מופתע כי אני עבדתי על כמה מוצרים שלא הסכמנו לשחרר לפני שהיו תיקיות, תוויות ועוד כמה התחכמויות שהסתבכו וביטלנו ברגע האחרון. כיצד ייתכן שגוגל הצליחה עם Gmail ללא תכונה שאצל כ"כ הרבה מנהלי מוצר / פיתוח יהיה ב "Must-Must Have"?

כיצד ייתכן שהארכיטקטורה של גרופון הייתה דף בבלוג WordPress ציבורי, עם Widget של ThePoint שכולל מקטע AppleScript ששולח קופונים ב PDF? איזה מתכנת היה מוכן לשחרר דבר שכזה? שלא לדבר על איזה ארכיטקט היה מאשר את זה…

כך נראה טוויטר בשנת 2006. האם הייתם משחררים אתר שנראה כך?
מקור: http://www.telegraph.co.uk/technology/6125914/How-20-popular-websites-looked-when-they-launched.html

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

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

מנכ"ל דרופבוס מדבר על הקמת החברה.
מקור (שווה קריאה): http://www.slideshare.net/gueste94e4c/dropbox-startup-lessons-learned-3836587?from=ss_embed

The lesson of the MVP is that any additional work beyond what was required to start learning is waste, no matter how important it might have seemed at the time.

הקרב בתעשיית התוכנה: Development vs. Marketing

הקרב בין מחלקת השיווק ([1]Marketing) למחלקת הפיתוח מתנהל כבר שנים, במשך דורות, אבות ובנים. אלה רוצים \"עוד פיצ\'רים ומהר\" אלו רוצים \"איכות, דיוק ושיטתיות\" (ע\"פ המפתחים. אנשי שיווק יספרו את הסיפור קצת אחרת). נקודת ההכרעה אינה נראית באופק.

האם זה קרב מחוייב המציאות? האם לא ברור שהפעם \"אנחנו\" צודקים?

שאלה: כאשר בא אליך איש מוצר ורוצה עוד פיצ\'רים על חשבון איכות, מה אתה אומר לו?

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

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

Best Practices: פיתוח כנגד שיווק

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

DRY – אל תחזור על עצמך
Bake Quality In – איכות צריכה להיות בכל שלב בתהליך
Abstraction / Loose Coupling – צמצם תלויות בקוד כך ששינוי באזור אחד לא יזעזע אזורים אחרים.
Naming / Clean Code – קוד \"ספרותי\" שמתאר את עצמו.
וכו\'

אנשי השיווק העתיקו מאיתנו, המפתחים, את הרעיון של Best Practices ויצרו רשימה משלהם. הנה כמה הרלוונטיים לדיון:

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

Feature Superiority
הרבה יותר קל למכור מוצר שיש לו רשימה גדולה יותר של פ\'יצרים. ללקוח זו מרגישה קנייה בטוחה יותר ומי שמוכר אותה נתפס מנוסה יותר. ב SAP שמעתי את האמרה הבאה (שנכונה גם לחברות אחרות): \"The Suite Always Wins\". כלומר ל SAP לא חייב להיות מוצר לניהול משאבי אנוש הכי טוב או כלי לניהול פרוייקטים הכי טוב, אך כשהיא מוכרת חבילה שמחליפה 10 מוצרים שונים ויותר – יש לה ייתרון אדיר. עקרון זה נכון כאשר מדובר במוצרים נפרדים תחת אותה קורת גג (\"One Stop Shop\") ואפילו קצת יותר כאשר מדובר במוצרים שמדברים אחד עם השני (\"Suite\").

ייתכן והרצון להגיע ל Feature Superiority דוחף לבקש עוד פ\'יצרים על חשבון סגירת ושיפור הקיימים. למי שמכיר את תאוריית האוקיינוס הכחול[3] (או בכלל את פורטר) – זו נראית לעיתים קרובה טעות נפוצה של אנשי שיווק ולא Best Practice, אך נראה שאנשי שיווק לא מעטים פספסו את השיעור הזה ב MBA שלהם. אציין שאנשים נבונים שעבדתי איתם עשו, למיטב הבנתי, את הטעות הזו. נראה שתחת לחץ ותחרות (אנשי מכירות שמכפישים את שמכם בחברה כי הפסידו עסקה בגלל המחסור בפ\'יצר X) – קל מאוד להגיע לשם. באופן אירוני, מתחרה שלו יש עדיפות במספר הפ\'יצרים ואולי הגיע לשם בעקבות לחץ, עלול לגרור את החברה שלכם לריצה אחר רשימת פ\'יצרים במקום להתבונן על התמונה השלמה.

Check-box Feature
לעיתים קרובות, תהליך מכירה של תוכנה ארגונית עובד כך: הלקוח שולח RFP – Request For Proposal לכמה ספקי תוכנה שנשמע שיש להם תוכנה שמתאימה לצורכיו. ה-RFP הוא מסמך עם רשימה ארוכה של דרישות \"יש\"/\"אין\" שעל הספק למלא. מי שעומד בדרישת הסף עובר לשלב הבא בו משוחחים על הפתרון, עושים פיילוט וממשיכים למכירה. אם חסר לכם ברשימת הדרישות פ\'יצר שמוגדר כקריטי – יסננו אתכם עוד בשלב ה RFP, לעיתים ללא הבנה מה אתם במקום לאותה הבעיה, ללא ודאות שזה באמת מה שנחוץ וכו\'. על מנת לעבור את התהליך יש לסמן כמה שיותר סימני V.
זה תהליך דומה מאוד לשילחת קורות חיים. מתכנת עם 10 שנות ניסיון ב Web יציין ידע ב JQuery, Comet, Ajax ו Cross-Browser DOM אבל אולי ידלג על HTML ו CSS. הוא עלול לגלות שאשת כח-האדם שעושה Pattern-matching על קורות החיים שלו פשוט מסננת אותו \"אין לו מספיק ידע\" כי \"צריך ידע ב CSS\" או CSS3 או XHTML (מול HTML – הבדל סמנטי) וכו\'.
מה הפתרון? על מנת לעבור את הסינון הזה אותו מתכנת יכתוב אינסוף מושגים הקשורים לווב, שחלקם אולי לא כ\"כ נכונים על מנת להגיע למראיין המקצועי (כלומר – טכנולוגי) הראשון שיוכל להתרשם באמת מכישוריו.

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

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

פי\'צר כזה מסומן כ Check-box Feature – תחמושת חשובה שאיש השיווק רוצה לספק לאנשי המכירות שלו. הם יוכלו לטעון \"בטח – גם לנו יש Mobile Cloud EAI Service Integration 2.0 ואולי יוכלו לעבור איזה Demo של כמה דקות. אבל הפ\'יצר עצמו לא באמת צריך לעבוד על מנת למכור או אפילו ליצור לקוח מרוצה – חבל לבזבז עליו זמן פיתוח.
מה עדיף? לחנך את הלקוחות/שוק (והגרורות שלהם) שזה פ\'יצר מיותר (קשה מאוד) או לבקש מהמפתחים פ\'יצר חלקי ונבוב בהשקעה מינימלית (יחסית קל)? האופצייה השנייה ישימה יותר ועובדת טוב יותר (לצערנו, המפתחים).

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

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

אנחנו בפיתוח מעדיפים לדייק בפרטים ולא \"לנפח\". אנו נעדיף לקרוא לאובייקט \"SnmpMessage\" ולא \"SystemWellBeingReport\" (קצת מוגזם – לא?). אנו נעדיף \"XmlParser\" ולא \"Cross-SystemTranslator\". לכן כשאנחנו רואים את החומר השיווק של המוצר שפיתחנו, בעוד אנו יודעים מה הוא באמת עושה, אנו עלולים להיות מופתעים. \"הם חיים בעננים\" אנו מספרים על אנשי השיווק, \"רואים סרטים בעננים\", מוסיפים. קרוב לודאי שהסבר כמו \"הלקוחות שמחים לקנות את הסיפור, זה נותן להם אמון שאנחנו מבינים אותם ויודעים על מה אנחנו מדברים\" רק מעצים את תחושת הניכור.

סיכום
טעות נפוצה היא לחשוב ש\"המוצר מוכר את עצמו\" או ש\"מספיק מוצר טוב\". אמנם יש מעט מוצרים שנמכרים ללא שיווק (למשל מנוע החיפוש של גוגל) ולמשתמש ישירות, אך את רוב המוצרים עדיין מוכרים בעזרת אנשי מכירות, שיווק וחומר פרסומי ועל המוצר למלא חלק במערכה. הלקוחות שלנו אינם תמיד מבקשים את מה שהם צריכים [4], השוק לעיתים קרובות \"טיפש\" (או \"לא רציונלי\") וזו הטייה שחשוב להבין להתמודד איתה על מנת להצליח בעסקים. לא מעט סטראט-אפים נופלים על הטעות הזו. אם לא שמתם לב – ברוב חברות ההייטק, לפיתוח מוקצים כ 10-15% מהתקציב ולשיווק – כ 40-60% מהתקציב. לא סתם.

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

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

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

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

תודה לניר דרמר על ההערות המועילות על הפוסט.

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

[2] או שלא. יש פה סיכון מסוים. אנחנו בפיתוח נוטים לזכור היטב את המקרים שבהם זה לא עבד – אבל הרבה פעמים זה עובד יפה. בכל זאת זהו Best Practice ולא Flawless practice.

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

[4] ב XP נוהגים לומר: תן ללקוח מה שהוא צריך, לא מה שהוא מבקש.

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

[6] מדידה של איכות תוכנה הוא דבר מורכב ובעייתי, במיוחד מכיוון שאין מדדים מוסכמים ל\"מהי איכות\". לכן לכל מחקר או נתון על איכות תוכנה יש להתייחס בזהירות.

קיצור תולדות ה 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 אך עדיין מאוד רלוונטי.

איכות תוכנה – ארגז כלים (3)

המשך ל פוסט 2: איכות תוכנה – ארגז כלים

מחפשים כיצד לשפר את איכות התוכנה ומחפשים אחר ה Best Practices בתעשייה?

בטבלה למטה ריכזתי את הטכניקות העיקריות שעברו את מבחן ההוכחה בתעשייה. ציינתי גם התייחסות כמה אתם יכולים לצפות לשיפור באיכות הפנימית (IQ – Internal Quality) או החיצונית (EQ – External Quality). אנשים לדוגמה מופתעים ש Unit Tests לא תופס הרבה באגים – אבל זו עובדה מוכרת. לעומת זאת טכניקות כמו Code Inspection ו TDD פחות מוכרות ברחבי התעשייה – אבל מניסיוני הן אפקטיביות ביותר. שימו לב שהטכניקות הקלות יותר להטמעה הן אלו שנפוצות בקרב האירגונים – זה דבר טבעי.

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

בתחתית הטבלה ציינתי עוד כמה נקודות חשובות.

טכניקה	השפעה על איכות חיצונית EQ	השפעה על איכות פנימית IQ	כמות השקעה	קושי הטמעה	הערות
תהליכים – לרוב קורים לפני או בזמן הפיתוח. לא מסכנים את הקוד. יעילים בצורה מפתיעה.
CI	לא רלוונטי	בינונית	נמוכה	נמוך	הרצת בדיקה ואינטגרציה בצורה אוטומטית מיד אחרי כל שינוי קוד ולא בסוף גרסת הפיתוח. נקודת פתיחה טובה ובסיס לבדיקות רגרסיה.
Bug Tracking	גבוהה	נמוכה	נמוכה (לארגון)	נמוך	מעקב יסודי אחר כמות הבאגים וקצב הפתיחה / סגירה.עם המדידה באים הלחצים והרעיונות לשיפור. הכרחי!
Requirements Inspection & verification	גבוהה	עקיפה בלבד	בינונית	בינוני	לעתים קרובות לא נעשה או נעשה בצורה חפיפה. הכוונה להשקעה יסודית בבחינת ואימות הדרישות.
Formal Design Inspection	נמוכה	גבוהה	בינונית	גבוה	לעתים קרובות לא נעשה או נעשה בצורה חפיפה. בחינת אלטרנטיבות אמיתיות וסיבות על כל שינוי מהותי במערכת שנבע אפילו מתיקן באג – לא אותם מסמכים שמתארים את המובן מאליו מתובל ב interfaces וקוד!
Formal Code Inspection	גבוהה	גבוהה	בינונית	בינוני עד גבוה	קריאה אינטנסיבית של קוד ללא מחשב + דיון. זהו לא ה freestyle Code Review שעושים לעתים בארגונים.
Peer Review	נמוכה	בינונית	נמוכה	נמוך עד בינוני	ישיבה עם מתכנת או ראש צוות עד רבע שעה לפני check-in
בדיקות רגרסיה – מגבירים את הביטחון והיכולת לבצע refactoring בבטחה. כיסוי גבוה נדרש להשגת האפקט.
Unit-Tests	נמוכה	בינונית	גבוהה	גבוה	לכל class בקוד – בדיקה. נכתב ע\"י המפתח. קשה מאוד להטמעה בקוד שנכתב ללא unit tests
Integration / Component Tests	בינונית	נמוכה	בינונית	בינוני	בדיקה ל flow בקוד שכולל מספר classes. נכתב ע\"י המפתח.
Acceptance Tests	בינונית	זניחה	בינונית	בינוני עד גבוה	בדיקת black box למערכת עצמה, הזרקה של input ובדיקת התוצאות. נבדק לעתים קרובות ע\"י \"צוות אינטגרציה\"
GUI Tests	בינונית	זניחה	גבוהה	בינוני	בדיקת ה UI ע\"י כלים שמדמים browser (כמו Selenium). בדיקות קשות לתחזוקה אך הדרך האוטומטית לבדיקת GUI.
TDD	זניחה	גבוהה	בינונית	בינוני	טכניקה משופרת לכתיבת unit-test, משפר את המודולריות בקוד, יעילות כתיבת הבדיקות וכתיבת בדיקות יציבות יותר. כיף חיים!
אחרים
Risk-Based Testing	גבוהה	זניחה	גבוהה	נמוך	צוות QA שעובד בצורה נבונה ומתמקד בבדיקת הפונקציות החשובות והמורכבות של המערכת
Testing Tools	נמוכה	זניחה	בינונית	נמוך	השקעה בכלי עזר שיעזרו למפתחים ו QA לבדוק מהר יותר וטוב יותר. מאפשר למפתחים לבדוק יותר ולהתעייף פחות.
Stress Test	נמוכה	זניחה	בינונית	גבוה	העמדת המערכת בעומס גבוה לראות מה נשבר ראשון. לרוב מגלה מספר מצומצם של בעיות, אך בעיות שהיו קורים אצל לקוחות.
Alpha / Beta Test	בינונית	זניחה	נמוכה	גבוה (מחוץ לפיתוח)	להגיע ללקוח מהר עם מוצר לא גמור ולבדוק את המוצר אצלו ובעזרתו. מסייע לאימות Requirements שיכול להיות קריטי להצלחת המוצר!
Static Code Analysis	בינונית	נמוכה	נמוכה	נמוך	כלים אוטומטים שמנתחים את הקוד למצוא בעיות. PMD, Find bugs ו CheckStyle הם המפורסמים בג\'אווה, כאשר יש כלים כמו Sonar או פלאג-אינים כמו QA Plug שמרכזים את כולם ביחד.

להוסיף (חשוב!): Eat your own dogfood

עוד כמה הערות:

Formal code / design / requirement inspection – כמו שניסיתי לציין בטבלה יש הרבה ארגונים שעושים חלק מזה, אבל בצורה לא יסודית ולא יעילה. ראיתי המון מסמכי designs בחיים שחבל שנכתבו. הרבה ישיבות design או requirements review שהיו ריקות מתוכן כי לאלו שאמורים לעשות את הביקורת לא היה ידע מספק \"לעשות את העבודה\". לסיכום: קל ליפול בטכניקות הללו לביצוע בינוני בלי לשים לב.

בדיקות רגרסיה
הסוגים השונים של הבדיקות הן לא כ\"כ אלטרנטיבות אחת לשנייה, אלא יותר משלימות. רגרסיה טובה כוללת הרבה unit-tests, מספר לא מבוטל של integration ו acceptance tests ומעט GUI Tests (פרמידת הבדיקות). פוסט טוב שמסביר קצת יותר ניתן למצוא כאן.

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

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

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

בהצלחה!