Agile is Rigor Mortis as sagteware se staatsgodsdiens

Dit was nie ongewoon in die sagteware-ingenieurswêreld om proklamasies van die dood van Agile te hoor van mense met 'n gevestigde belang in die metodologie nie, wat beweer dat tensy ons groter geloof toon, dit verlore sal gaan, en in gevalle waar dit misluk, dit is bloot nie behoorlik geïmplementeer nie - wat herinner aan ander aansprake na die "geen ware Skot"-dwaling soos "regte kommunisme is nog nooit beproef nie."

Ten spyte van sy teenwoordigheid in sagteware-katastrofes wat wissel van geregtigheidsmiskrame tot lugvaartsagteware-rampe, is die realiteit dat Agile 'n posisie beklee het as ietwat van 'n professionele godsdiens van sagteware-ingenieurswese.

Hierdie situasie het die afgelope maande ingrypend verander. Sedert ek 6 maande gelede aan navorsing gewerk het wat gewys het dat Agile-sagtewareprojekte 'n 268% hoër mislukkingsyfer gehad het, het 'n oorvloed navorsing uitgekom wat hierdie werk bevestig.

Soos kommunisme of geloofsgenesing, sal die fantasieë van grootsheid dat universeel goeie, maar onrealistiese oplossings al ons probleme kan oplos, altyd by sommige mense 'n beroep doen, nieteenstaande die bewyse - maar wat nou fundamenteel verander het, is dat daar ingeligte toestemming bestaan of om Agile te volg of iets anders doen. '

(Geen twyfel nie, die internasionale nuus wat verband hou met die CrowdStrike-verval-sagteware-opdatering het beslis gehelp om die punte wat ek probeer maak het, tuis te bring.)

Nieteenstaande die weersinwekkende mate wat sommige in die Agile-gemeenskap probeer het om my stil te maak om oor Agile te praat, is dit belangrik om grootmoedig te wees in oorwinning, so ek sal nie probeer om die argumente hier te heroorweeg nie - in plaas daarvan, voel ek dit is die moeite werd om onlangse ontwikkelings en die pad vorentoe, 6 maande verder.

Google se DORA-navorsing skakel rats aan

JL Partners, wat ek aangestel het om die Agile-mislukkingskoersnavorsing uit te voer, het die afgelope paar maande 'n fenomenale gehad. Anders as baie ander wat navorsing doen met beperkte aanspreeklikheid, toets hulle gereeld hul modelle deur verkiesings te voorspel. Toe dit by die Britse verkiesings kom, het hulle gevind dat hulle een van die mees akkurate voorspellings lewer. Dinge is selfs meer merkwaardig wanneer dit kom by die Amerikaanse verkiesing soos Politico berig :

… JL Partners kan heel moontlik onder die akkuraatste wees in hul finale voorverkiesingsvoorspellings. Die firma se finale model was net een van twee om 'n Trump-oorwinning te voorspel en dit het ook geprojekteer dat hy die Kieskollege 287-251 sou wen - die hoogste geprojekteerde Trump-wenmarge van enige meningspeiler. Dit was ook een van baie min meningspeilers wat voorspel het dat Trump die gewilde stem sou wen.

Daarbenewens het navorsing van RAND Corporation wat aanvanklik vir die Amerikaanse departement van verdediging gedoen is, bevind dat KI-ontwikkeling en rats nie goed meng nie . Verder rapporteer Synodus ('n wêreldwye tegnologieverskaffer wat voorsien (Fortune 500-maatskappye soos BOC Aviation, KPMG en Unilever) dat deur weg te beweeg van Agile , vind hulle dat hulle projekte 2-3 keer vinniger lewer en rapporteer dat 'n toonaangewende lugredery 63 bespaar. % van hul ontwikkelingskoste.

Dit is ten spyte van die feit dat spoed en koste tradisioneel maatstawwe is wat met Agile en LEAN geassosieer word, terwyl die Impact Engineering-benadering op Impak as 'n primêre maatstaf fokus.

Ten slotte, soos Colm Campbell in die artikel " P-Hacking with Dinosaurs " geskryf het, is die aansprake wat deur die "Agile Mafia" in reaksie op die Agile-mislukkingskoersstudie voorgehou is, omvattend weerlê, wat slegs patetiese persoonlike aanvalle oorlaat.

Maar miskien kom een van die mees verrassende areas van ondersteunende navorsing van Google se DORA-span. DORA self vind sy wortels in die DevOps-beweging, wat self 'n wese van Agile is. Hul jaarlikse State of DevOps-verslag vir 2024 het geen besonder wydverspreide dekking vanjaar gekry nie, gegewe die lugtyd wat na Agile-navorsing gegaan het, maar dit is interessant om te sien dat hulle ook hul rug op Agile draai.

Nou moet ek daarop let dat ek krities was oor die DORA-span se metodologie (sedert ek van plan verander het oor Agile, DevOps, ens.) aangesien die primêre maatstawwe wat hulle gebruik om dinge te meet, gefokus is op spoed van aflewering ( wat ons weet is nie nie wat gebruikers wil hê nie ), maar die feit dat hulle dit sien, selfs met hul benadering, dui op iets dieper hier aan die gang.

Op bladsy 64 van die State of DevOps Report 2024 beweer hulle:

'Die Agile-manifes pleit vir "werkende sagteware bo omvattende dokumentasie". Ons vind egter steeds dat kwaliteit dokumentasie 'n sleutelkomponent van werkende sagteware is.'

Verder, op bladsy 82, blyk dit dat hulle hul rug op DevOps self draai:

'Ons is verbind tot die grondbeginsels wat nog altyd deel van die DevOps-beweging was: kultuur, samewerking, outomatisering, leer en die gebruik van tegnologie om besigheidsdoelwitte te bereik. Ons gemeenskap en navorsing trek voordeel uit die perspektiewe van uiteenlopende rolle, insluitend mense wat dalk nie met die "DevOps"-etiket assosieer nie. Jy moet verwag om die term "DevOps" uit die kollig te sien beweeg.'

Ek het steeds probleme met hul navorsingsmetodologie; die eindpunte wat gebruik word om sukses te meet, is gefokus op spoed, en verder, hulle pleit voort vir transformasionele leierskap ten spyte van die sielkundige navorsing op hierdie gebied wat sulke benaderings bevraagteken.

Op 'n menslike vlak lyk dit merkwaardig kru om so sterk te fokus op 'n poging om organisasies en mense te transformeer sonder hul ingeligte toestemming, terwyl dit ook nie besef hoe daar dikwels geen beter bron van leer as ons eie foute is nie (in die mate waarin ons die ingeligte het) toestemming om dit te maak), 'n belangrike kritiek wat ek het op werk soos The Pheonix Project en The Unicorn Project .

Dit is egter merkwaardig om toenemende bevestiging vir Impact Engineering teen tradisionele Agile- en DevOps-statistieke te sien.

Skrum-, TDD- en ontwerppatrone

Toe The Register 'n paar maande gelede met my 'n onderhoud gevoer het in die artikel " Studieondersteuner: Katastrofale neem Agile oorbeklemtoon nuwe kenmerke " , het ek geen geheim gemaak van die drie faktore waarmee ek probleme gehad het in moderne benaderings tot Agile, DevOps en digitale transformasie nie:

1. Agile-benaderings wat vereistes afkeur, ten spyte van rampe, insluitend die Poskantoor-skandaal en Boeing 737 Max 8-ongelukke .

   
   

2. Implementerings van DevOps wat die spoed van die lewering van nuwe kenmerke en herstel van probleme prioritiseer in plaas daarvan om probleme in die eerste plek te voorkom - ten spyte van navorsing wat toon dat die publieke rang die nuutste kenmerke so vinnig as moontlik kry asdie minste belangrike ding vir hulle wanneer hulle rekenaarstelsels gebruik, met datasekuriteit, data-akkuraatheid en geen ernstige foute wat die belangrikste faktore is nie.

   
   

3. Pogings tot organisasietransformasie van onder na bo sonder om ingeligte toestemming te verkry, wat die belangrikheid daarvan verwaarloos om mense toe te laat om te leer uit hul eie foute wat hulle die ingeligte toestemming het om te maak – met sulke programme wat verkoop word as seker-vuur suksesse wat oorweldigend eindig in stresvolle ellende en mislukking.

   
   

Soos ek begin om sagteware-rampe en moordenaar rekenaars na te vors (soos berig in Forbes terug in April ), was dit die drie faktore waarmee ek toenemende morele uitdagings begin ondervind het. Ek het geen werklike probleem gehad met verskillende sagteware-ontwikkelingsbenaderings of projekbestuurstegnieke nie, aangesien ek nie dieselfde skakel gesien het na die rampgevallestudies wat ek ondersoek het nie. Ek het nie die behoefte gevoel om my persoonlike sienings as ingenieur ten opsigte van hierdie ander sake uit te spreek nie.

Nietemin is dit interessant om te sien dat die ontploffingsradius verder as hierdie aanvanklike drie gebiede uitgebrei het na ander benaderings wat deur die Agile Manifesto-mede-outeurs soos Scrum, Test-Driven Development (TDD), Object-Oriented Programming (OOP) en Ontwerp voorgestaan word. Patrone (sien bv. Soumen Sarkar se LinkedIn-plasing op Ontwerppatrone ).

Ek het min om by te voeg op hierdie gebied. Ek wonder egter of die Agile mede-outeurs nie so hard geveg het teen sy dood as 'n godsdiens as die sagteware-ingenieursgemeenskap meer vriendelik teenoor hul ander idees sou wees nie. Die vraag is nou ter sprake, aangesien Agile se godsdienstige status rigor mortis is en alles lyk op die spel: OOP, ontwerppatrone, TDD, ens.

Op pad na bewustheid van verliesaversie

Aangesien 'n relatief aansienlike deel van die afgelope paar maande bestee is aan voorbladnuus van verskeie tegnologiepublikasies wat oor Agile praat en baie wyd onder die gemeenskap bespreek is, sou dit miskien nie verbasend wees om 'n paar bisarre ontmoetings te hê nie. Vir die grootste deel was dit egter buitengewoon aangename ontmoetings van mense wat in die openbaar na my gekom het en lukraak in gesprek oor Agile betrokke raak.

Daar was egter een ontmoeting wat 'n skerp indruk op my gelaat het. 'n Paar weke gelede was ek na die Britse parlement om beleidmakers toe te spreek oor verskeie tegnologieskandale waaraan ek besig was om te ondersoek. Ek was nog nooit self 'n groot aanhanger daarvan om mag te beklee nie, en ek het dit nog altyd raaiselagtig gevind dat daar in die privaat kroeë in die Parlement tekens moet wees wat individue daaraan herinner om nie hul mag te misbruik wanneer hulle besope is nie.

Maar toe ek hierdie toespraak gehou het, was ek nie net goed geklee en meer presenteerbaar as gewoonlik nie, maar ek was ook voor 'n simpatieke gehoor, geflankeer deur 'n Parlementslid en 'n vriend wat toevallig 'n King's Counsel is ('n senior prokureur wat toegegee is) daardie onderskeid deur die monarg vir uitsonderlike voorspraak).

Sodra ek my toespraak gehou het en 'n aantal vrae beantwoord het, was daar iemand in die gehoor wat 'n besoeker was wat oor Agile begin praat het (die praatjie was nie oor Agile nie). In teenstelling met my driedelige pak, was hy geklee in 'n ketchup-bevlekte hemp en (sonder om op besonderhede in te gaan) was nie presenteerbaar of polities verbind nie. Hy het begin "Kan ek jou terugvoer gee?"

Toe hy oor Agile begin praat, het ek met hom oogkontak gemaak, en hy het afgekyk en opgehou praat, amper asof hy besef het dat hy nie meer aanlyn is nie en eintlik iemand met sy woorde in die gesig staar. Voordat ek kon reageer, het 'n HUB-vriend tussenbeide getree om die punt vir my aan te spreek.

Op daardie oomblik het ek besef ek hou nie van krag in 'n mate wat ek tot dusver nog nie besef het nie.

Ongelukkig het dit vir hierdie individu gelyk asof hy reeds 'n slagoffer was van diegene wat versekerde transformasie-oplossings verkoop het, wat klaarblyklik tot probleme in sy eie lewe gelei het. Waarom word hierdie transformasiemetodologieë in hierdie omstandighede steeds voorgestaan?

Meer in die breë, hoekom kan Agile nie in die regte wêreld werk nie? Met kommunisme kan ons ten minste die mislukking aan gierigheid toeskryf, so wat is die sielkunde van Agile mislukking? Die antwoord kom in my oë neer op 'n sielkundige faktor bekend as verliesafkeer . Op algemene aanvraag het ek onlangs 'n voordrukvraestel oor die Impact Engineering-werk geskryf en dit het gefokus op die rol wat verliesaversiebewustheid kan speel om projeksukses te versag.

Die koerant, "So is ek Dr. Frankenstein? Of was jy die hele tyd 'n monster?”: Versagtende sagtewareprojekmislukking met verlies-aversie-bewuste ontwikkelingsmetodologieë , sluit soos volg af:

Gevallestudies het getoon dat sagteware-rampe kan sneeubal in rampe wanneer probleme nie aangespreek word nie en eerder bedek word. Sielkundige faktore, 'n sleutel is verliesafkeer, kan organisasies aanspoor om hierdie pad te gaan ten spyte van die rampspoedige gevolge.

Tog het sagtewaremetodologieë histories hierdie sielkundige faktor verontagsaam, in plaas daarvan om te aanvaar dat mense probleme so gou moontlik sal wil aanspreek. Vorige navorsing van verskillende metodologieë het bevind die sielkundige veiligheid om kwessies te opper en te bespreek, is die sleutel tot verbeterde sagteware-lewering. Dit is egter ongetwyfeld optimisties om te glo dat sulke betekenisvolle kulturele en sielkundige verandering in alle organisasies bereik kan word. Soos ons vind, selfs tussen die Verenigde Koninkryk en die VSA, bly sielkundige veiligheid die grootste verskil in ingenieurspraktyk tussen die twee lande.

In hierdie vraestel fokus ons op 'n ander pad vorentoe. In plaas daarvan om 'n kulturele verandering te probeer bewerkstellig wat hoogstens uitdagend is, fokus ons eerder op 'n meer pragmatiese benadering: beperk die snellers van verliesaversie van meet af aan deur robuuste vereistes en mik dan na sielkundige veiligheid waar dit nodig is. In ons navorsing was die enigste faktor wat ons gevind het wat die sukseskoers van 'n projek meer sou verhoog as sielkundige veiligheid, om van die begin af duidelike vereistes te hê.

Teen ons hipotese blyk dit dat die resultate dat bloot duidelike vereistes het, selfs wanneer dit laat in ontwikkeling verander of nie in lyn is met die werklike wêreld nie, 'n beduidende rol in sagtewareprojeksukses speel. Dit dui daarop dat om 'n hek voor die aanvang van 'n projek te hê om probleme te bespreek en aan te spreek, wanneer verliesaversie op sy laagste is, die grootste verbetering in sukseskoerse moontlik maak.

Die liedjie Dr. Frankenstein deur RedHook bevat die refrein: “So is ek Dr. Frankenstein? Of was jy die hele tyd ’n monster?” Vir katastrofiese sagtewareprojekte voer hierdie artikel aan dat sagtewareprojekte rampe word wanneer mense nie daarin slaag om tegniese probleme op kleiner skaal aan te spreek nie. Bestaande sagteware-ingenieursmetodologieë slaag nie daarin om aan te spreek dat mense nie masjiene is nie en sielkundige faktore belemmer die vermoë om probleme aan te spreek. Nadat hierdie anachronisme in bestaande metodologieë geïdentifiseer is, bied hierdie artikel aan hoe ons daarvolgens kan optree deur vereistes te gebruik voor die aanvang van 'n projek om die geleentheid te bied om probleme aan te spreek wanneer verliesaversie op sy laagste is.