על פיתוח אג'ייל וחזרה בתשובה

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

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

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

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

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

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

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

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

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

______
¹ זה לא בדיוק בדיוק פיתוח אג'ייל והמטרה שלו, אבל מספיק קרוב לצורך המשל