זה לא היה נדיר בעולם הנדסת התוכנה לשמוע הכרזות על מותו של אג'ייל מאנשים בעלי אינטרס במתודולוגיה, בטענה שאם לא נגלה אמונה גדולה יותר, היא תלך לאיבוד, ובמקרים שבהם היא נכשלת, פשוט - מזכיר טענות אחרות בעקבות הכשל "אין סקוטי אמיתי" כמו "קומוניזם אמיתי מעולם לא נוסה". לא יושם כראוי למרות החל מעיוות דין ועד אסונות תוכנה תעופה, המציאות היא ש-Agile מחזיקה בעמדה כדת מקצועית של הנדסת תוכנה. נוכחותה בקטסטרופות תוכנה, מצב זה השתנה באופן עמוק במהלך החודשים האחרונים. מאז שעבדתי על לפני 6 חודשים שהראה שלפרויקטי תוכנה Agile היה שיעור , יצא שפע של מחקרים המאששים את העבודה הזו. מחקר כשל גבוה ב-268% כמו קומוניזם או ריפוי באמונה, פנטזיות ההוד שפתרונות אוניברסליים טובים, אך לא מציאותיים יכולים לפתור את כל הבעיות שלנו, תמיד ימשכו חלק על אף העדויות - אבל מה שהשתנה כעת באופן מהותי הוא שקיימת הסכמה מדעת אם ללכת לפי Agile או לעשות משהו אחר. ' (ללא ספק, החדשות הבינלאומיות הקשורות בהחלט עזרו להדגיש את הנקודות שניסיתי להעלות). לעדכון התוכנה המשוכלל של CrowdStrike למרות המידה הדוחה שחלק בקהילת האג'ייל ניסו להשתיק אותי מלדבר על אג'ייל, חשוב להיות נדיב בניצחון אז אני לא אנסה להדגיש את הטיעונים כאן - במקום זאת, אני מרגיש שכדאי לדון בהתפתחויות האחרונות הדרך קדימה, 6 חודשים אחרי. מחקר DORA של גוגל מפעיל את זריזות ל-JL Partners, שהזמנתי לערוך את מחקר שיעור הכישלון של Agile, היו חודשים האחרונים פנומנליים. בניגוד לרבים אחרים שעורכים מחקר עם אחריות מוגבלת, הם בודקים באופן קבוע את המודלים שלהם על ידי חיזוי בחירות. כשזה הגיע לבחירות בבריטניה, הם מצאו את עצמם מייצרים . הדברים מדהימים אפילו יותר כשמדובר בבחירות בארה"ב : בין התחזיות המדויקות ביותר כפי שפוליטיקו מדווחת ... ייתכן ש-JL Partners יהיו בין המדויקים ביותר בתחזיותיהם הסופיות לפני הבחירות. המודל הסופי של החברה היה רק אחד משניים שחיזו ניצחון של טראמפ, והוא גם חזה אותו לזכייה במכללת הבחירות 287-251 - מרווח הזכייה הגבוה ביותר של טראמפ מכל סוקר. זה גם היה אחד הבודדים ביותר שחזו שטראמפ יזכה בהצבעה העממית. בנוסף, מחקר של RAND Corporation שנערך בתחילה עבור משרד ההגנה האמריקני מצא . יתר על כן, Synodus (ספקית טכנולוגיה עולמית המספקת (חברות Fortune 500 כמו BOC Aviation, KPMG ויוניליוור) מדווחת כי , הם מגלים שהם מספקים פרויקטים פי 2-3 מהר יותר ומדווחים שחברת תעופה מובילה חסכה 63 % מעלות הפיתוח שלהם. שפיתוח בינה מלאכותית וזריז לא משתלבים היטב על ידי התרחקות מאג'ייל זאת למרות העובדה שמהירות ועלות הם באופן מסורתי מדדים הקשורים ל-Agile ו-LEAN, בעוד שגישת ההנדסה של ההשפעה מתמקדת בהשפעה כמדד ראשוני. לבסוף, כפי שכתב קולם קמפבל במאמר " ", הטענות שהעלתה "המאפיה הזריזה" בתגובה למחקר שיעור הכישלון של Agile הופרכו באופן מקיף, והותירו רק התקפות אישיות פתטיות. P-Hacking with Dinosaurs עם זאת, אולי אחד התחומים המפתיעים ביותר של תמיכה במחקר מגיע מצוות DORA של גוגל. DORA עצמה מוצאת את שורשיה בתנועת DevOps, שהיא בעצמה יצור של Agile. דו"ח מצב ה-DevOps השנתי שלהם לשנת 2024 לא זכה לסיקור נרחב במיוחד השנה בהתחשב בזמן השידור שעבר למחקר Agile, אבל מעניין לראות שהם מפנים עורף גם ל-Agile. כעת, עלי לציין (מאז ששיניתי את דעתי לגבי Agile, DevOps וכו') מכיוון שהמדדים העיקריים שבהם הם משתמשים למדידת דברים מתמקדים במהירות האספקה ( ), אבל העובדה שהם רואים את זה אפילו באמצעות הגישה שלהם מצביעה על משהו עמוק יותר שקורה כאן. שהייתי ביקורתית כלפי המתודולוגיה של צוות DORA שאנחנו יודעים שהיא לא לא מה שהמשתמשים רוצים בעמוד 64 בדוח מצב DevOps 2024, הם טוענים: "המניפסט של Agile תומך ב"תוכנה עובדת על פני תיעוד מקיף". עם זאת, אנו ממשיכים לגלות שתיעוד איכותי הוא מרכיב מרכזי בתוכנה עובדת.' יתר על כן, בעמוד 82, נראה שהם מפנים עורף ל-DevOps עצמו: "אנו מחויבים לעקרונות היסוד שתמיד היו חלק מתנועת DevOps: תרבות, שיתוף פעולה, אוטומציה, למידה ושימוש בטכנולוגיה להשגת יעדים עסקיים. הקהילה והמחקר שלנו נהנים מנקודות המבט של תפקידים מגוונים, כולל אנשים שאולי לא קשורים לתווית "DevOps". אתה צריך לצפות לראות את המונח "DevOps" זז מאור הזרקורים'. עדיין יש לי בעיות עם מתודולוגיית המחקר שלהם; נקודות הקצה המשמשות למדידת הצלחה מתמקדות במהירות, ויתרה מכך, הן ממשיכות לתמוך במנהיגות טרנספורמטיבית למרות המטיל ספק בגישות כאלה. המחקר הפסיכולוגי בתחום זה ברמה האנושית, זה נראה גס להפליא להתמקד כל כך הרבה בניסיון לשנות ארגונים ואנשים ללא הסכמתם מדעת, תוך חוסר הבנה כיצד לעתים קרובות אין מקור טוב יותר ללמידה מאשר הטעויות שלנו (במידה שיש לנו את הידע המושכל). הסכמה ליצור אותם), ביקורת מרכזית שיש לי על עבודה כמו ו- . The Pheonix Project The Unicorn Project עם זאת, בכל זאת מדהים לראות אישור הולך וגובר עבור Impact Engineering מול מדדי Agile ו-DevOps המסורתיים. Scrum, TDD ודפוסי עיצוב כאשר The Register ראיין אותי לפני מספר חודשים במאמר , לא הסתרתי את שלושת הגורמים שהיו לי איתם בעיות בגישות מודרניות ל-Agile, DevOps וטרנספורמציה דיגיטלית: " " תומכת מחקר: קטסטרופלית לוקחת על Agile, מדגישה יתר על המידה תכונות חדשות גישות של Agile שמבטלות את הדרישות, למרות . אסונות כולל שערוריית הדואר והתרסקות בואינג 737 Max 8 הטמעות של DevOps אשר נותנות עדיפות למהירות אספקת תכונות חדשות והתאוששות מבעיות, לעומת מניעת בעיות מלכתחילה - למרות מחקר שמראה כי הדירוג הציבורי מקבל את הפיצ'רים העדכניים במהירות האפשרית כדבר עבורם בעת שימוש במערכות מחשב, עם אבטחת מידע, דיוק נתונים וללא באגים רציניים שהם הגורמים החשובים ביותר. הפחות חשוב ניסיונות לשינוי ארגוני מלמטה למעלה מבלי לקבל הסכמה מדעת, הזניחת החשיבות של לאפשר לאנשים ללמוד מהטעויות שלהם יש להם הסכמה מדעת לעשות - כאשר תוכניות כאלה נמכרות כהצלחות בטוחות מסתיימות ברובן המוחלט באומללות ובכישלונות מלחיצים. כשהתחלתי לחקור אסונות תוכנה ומחשבים קטלניים (כפי שדווח ), אלה היו שלושת הגורמים שאיתם התחילו לי אתגרים מוסריים הולכים וגדלים. לא הייתה לי בעיה אמיתית עם גישות שונות לפיתוח תוכנה או טכניקות ניהול פרויקטים מכיוון שלא ראיתי את אותו הקישור למקרי המקרה של אסונות שחקרתי. לא הרגשתי צורך להביע את דעתי האישית כמהנדס ביחס לעניינים האחרים הללו. בפורבס באפריל עם זאת, מעניין לראות את רדיוס הפיצוץ התרחב מעבר לשלושת התחומים הראשוניים הללו לגישות אחרות בהן דגלו מחברי המניפסט Agile כגון Scrum, Test-Driven Development (TDD), תכנות מונחה עצמים (OOP) ועיצוב דפוסים (למשל, ראה את הפוסט בלינקדאין של Soumen Sarkar ב- ). Design Patterns אין לי מה להוסיף בתחום הזה. עם זאת, אני תוהה אם שותפי ה-Agile לא נלחמו כל כך קשה נגד מותה כדת אם קהילת הנדסת התוכנה הייתה טובה יותר לרעיונות האחרים שלהם. השאלה מתעוררת כעת בהתחשב במעמד הדתי של אג'ייל הוא ונראה שהכל מובן מאליו: OOP, דפוסי עיצוב, TDD וכו'. קפדני לקראת סלידה מהפסד מכיוון שביליתי חלק ניכר יחסית מהחודשים האחרונים בחדשות בעמוד הראשון של פרסומים טכנולוגיים שונים שמדברים על Agile ונדונו באופן נרחב בקהילה באופן כללי, זה אולי לא יהיה מפתיע שיהיו כמה מפגשים מוזרים. על פי רוב, הם היו מפגשים נעימים ביותר של אנשים שהגיעו אליי בפומבי והשתתפו באקראי בדיון על Agile. עם זאת, היה מפגש אחד שהותיר בי רושם עז. לפני כמה שבועות הלכתי לפרלמנט הבריטי כדי לפנות לקובעי מדיניות בשערוריות טכנולוגיות שונות שעליהן עבדתי לחקור. אף פעם לא הייתי מעריץ גדול של להחזיק בשלטון בעצמי, ותמיד מצאתי את זה מוזר שבברים הפרטיים בפרלמנט, חייבים להיות שלטים שמזכירים לאנשים לא לנצל את כוחם לרעה כשהם שיכורים. עם זאת, כשנשאתי את ההרצאה הזו, לא רק שהייתי לבוש היטב ויצוגי מהרגיל, אלא גם עמדתי מול קהל אוהד, ולצדו חבר פרלמנט וחבר שהוא במקרה יועץ המלך (עורך דין בכיר קיבל ההבחנה הזו של המונרך להסברה יוצאת דופן). ברגע שנשאתי את ההרצאה שלי ועניתי על מספר שאלות, היה מישהו בקהל שהיה אורח שהתחיל לדבר על Agile (השיחה לא הייתה על Agile). בניגוד לחליפת השלושה שלי, הוא היה לבוש בחולצה מוכתמת בקטשופ ו(בלי להיכנס לפרטים) לא היה ייצוגי ולא קשור פוליטית. הוא התחיל "אפשר לתת לך משוב?" כשהוא התחיל לדבר על אג'ייל, יצרתי איתו קשר עין בחשדנות, והוא השפיל את מבטו והפסיק לדבר, כמעט כאילו הוא הבין שהוא כבר לא מחובר ולמעשה עומד מול מישהו עם המילים שלו. לפני שהספקתי להגיב, חבר מנכ"ל התערב כדי להתייחס לנקודה עבורי. באותו רגע, הבנתי שאני לא אוהב כוח במידה שלא הבנתי עד כה. לרוע המזל, עבור הפרט הזה, נראה שהוא כבר היה קורבן של אלה שמוכרים פתרונות טרנספורמציה בטוחים שהובילו כנראה לקשיים בחייו שלו. בנסיבות אלה מדוע מתודולוגיות הטרנספורמציה הללו עדיין דוגלות? באופן רחב יותר, מדוע Agile לא מסוגלת לפעול בעולם האמיתי? עם קומוניזם, לפחות אנחנו יכולים לייחס את הכישלון לחמדנות, אז מהי הפסיכולוגיה של כישלון זריז? התשובה, בעיניי, מסתכמת בגורם פסיכולוגי המכונה . לפי דרישה פופולרית, לאחרונה כתבתי מאמר טרום-דפוס על עבודת הנדסת ההשפעה והוא התמקד בתפקיד שמודעות לסלידה מהפסד יכולה למלא בהפחתת הצלחת הפרויקט. סלידה מאובדן העיתון, , מסתיים כדלקמן: "אז אני ד"ר פרנקנשטיין? או שהיית מפלצת כל הזמן?": ממתן כישלון בפרויקט תוכנה באמצעות מתודולוגיות פיתוח מודעת לאובדן מחקרי מקרים הראו שאסונות תוכנה עלולים להגיע לקטסטרופות כאשר בעיות אינן מטופלות ובמקום זאת מכוסות. גורמים פסיכולוגיים, שהמפתח הוא סלידה מהפסד, יכולים לתמרץ ארגונים ללכת בדרך זו למרות ההשלכות הרות אסון. עם זאת, מתודולוגיות תוכנה התעלמו באופן היסטורי מהגורם הפסיכולוגי הזה, במקום זאת בהנחה שבני אדם ירצו לטפל בבעיות בהקדם האפשרי. מחקרים קודמים של מתודולוגיות שונות מצאו שהבטיחות הפסיכולוגית להעלות ולדון בנושאים היא המפתח לאספקת תוכנה משופרת. עם זאת, אין ספק שאופטימי להאמין שניתן להשיג שינוי תרבותי ופסיכולוגי כה משמעותי בכל הארגונים. כפי שאנו מוצאים, אפילו בין בריטניה לארה"ב, בטיחות פסיכולוגית נותרה ההבדל הגדול ביותר בפרקטיקה ההנדסית בין שתי המדינות. במאמר זה, אנו מתמקדים בדרך אחרת קדימה. במקום לנסות להשיג שינוי תרבותי שהוא במקרה הטוב מאתגר, במקום זאת אנו מתמקדים בגישה פרגמטית יותר: מגבילים את הגורמים לרתיעה מאובדן מלכתחילה באמצעות דרישות חזקות ולאחר מכן שואפים לבטיחות פסיכולוגית היכן שהיא נחוצה. במחקר שלנו, הגורם היחיד שמצאנו שיעלה את שיעור ההצלחה של פרויקט יותר מאשר בטיחות פסיכולוגית היה דרישות ברורות מלכתחילה. בניגוד להשערה שלנו, נראה כי לתוצאות שרק בעלות דרישות ברורות, גם כשהן משתנות מאוחר בפיתוח או אינן מתואמות עם העולם האמיתי, יש תפקיד משמעותי בהצלחת פרויקט התוכנה. זה מצביע על כך שיש שער לפני תחילת פרויקט לדיון ולטפל בבעיות, כאשר רתיעה מהפסד היא בשיאה, מאפשרת את השיפור הגדול ביותר באחוזי ההצלחה. השיר Dr. Frankenstein של RedHook מכיל את הפזמון: "אז אני ד"ר פרנקנשטיין? או שהיית מפלצת כל הזמן?" עבור פרויקטי תוכנה קטסטרופליים, מאמר זה טוען שפרויקטי תוכנה הופכים לאסונות כאשר בני אדם אינם מצליחים לטפל בבעיות טכניות בקנה מידה קטן יותר. מתודולוגיות הנדסת תוכנה קיימות אינן מצליחות לטפל בכך שבני אדם אינם מכונות וגורמים פסיכולוגיים פוגעים ביכולת לטפל בבעיות. לאחר שזיהינו את האנכרוניזם הזה במתודולוגיות קיימות, מאמר זה מציג כיצד אנו יכולים לפעול לפיו על ידי שימוש בדרישות לפני תחילת פרויקט כדי לספק את ההזדמנות לטפל בבעיות כאשר סלידה מאובדן היא בשפל.
