Agile da Rigor Mortis Softwarearen Estatuko Erlijio gisa

Ez da ohikoa izan software-ingeniaritza munduan Agileren heriotzaren aldarrikapenak entzutea metodologian interesa duten pertsonengandik, sinesmen handiagoa erakutsi ezean, galdu egingo dela, eta huts egiten duen kasuetan, besterik gabe, ez da behar bezala inplementatu - "benetako eskoziarrik ez" faltsuaren ondorengo beste aldarrikapen batzuk gogorarazten ditu "benetako komunismoa ez da inoiz probatu" bezalakoa.

Softwarearen hondamendietan presentzia izan arren, justiziaren hutsegiteetatik hasi eta abiazio softwarearen hondamendietaraino, errealitatea da Agile-k software ingeniaritzaren erlijio profesional baten jarrera izan duela.

Egoera hau zeharo aldatu da azken hilabeteotan. Duela 6 hilabete Agile software-proiektuek porrot-tasa % 268 handiagoa zutela erakutsiz ikerketan aritu nintzenetik, ikerketa ugari atera dira lan hau egiaztatzen.

Komunismoa edo fedearen sendatzea bezala, unibertsalki onak baina irrealistak diren irtenbideak gure arazo guztiak konpondu ditzaketen handitasunaren fantasiak beti erakargarriak izango dira batzuentzat ebidentzia gorabehera, baina gaur egun funtsean aldatu dena da Agile jarraitu ala ez jakiteko adostasun informatua dagoela. edo beste zerbait egin. '

(Zalantzarik gabe, CrowdStrike software-eguneratzeari lotutako nazioarteko albisteek, zalantzarik gabe, egiten saiatzen ari nintzen puntuak lortzen lagundu zuten.)

Agile komunitateko batzuk ni Agileri buruz hitz egitean isilarazteko ahalegina egin nahi izan arren, garrantzitsua da garaipenean eskuzabala izatea, beraz, ez ditudala hemen argudioak errepikatzen saiatuko; horren ordez, uste dut merezi duela azken garapenak eta eztabaidatzea. bidea, 6 hilabetera.

Google-ren DORA Ikerketak Agilea aktibatu du

JL Partners-ek, Agile porrot-tasaren ikerketa egiteko enkarguz egin nion, azken hilabeteotan izugarria izan da. Erantzukizun mugatuarekin ikerketak egiten dituzten beste askok ez bezala, aldizka probatzen dituzte beren ereduak hauteskundeak aurreikusiz. Erresuma Batuko hauteskundeei dagokienez, iragarpen zehatzenen artean egin zuten. Gauzak are nabarmenagoak dira AEBetako hauteskundeei dagokienez , Politicok jakinarazi duenez :

… Baliteke JL bazkideak hauteskundeen aurreko azken iragarpenetan zehatzenetakoa izatea. Konpainiaren azken eredua Trumpen garaipena aurreikusten zuten bietako bat besterik ez zen eta Hauteskunde Elkargoak 287-251 irabaztea ere aurreikusi zuen - inkesta-inkesta guztien Trump-en irabazitako alderik handiena. Gainera, inkesta gutxienetako bat izan zen Trumpek herri bozketa irabaziko zuela iragarri zuena.

Gainera, hasiera batean AEBetako Defentsa Sailarentzat egindako RAND Corporation-ek egindako ikerketek aurkitu dute AI garapena eta agilea ez direla ondo nahasten . Gainera, Synodus-ek (hornitzaile global teknologiko hornitzaile bat (Fortune 500 konpainiak BOC Aviation, KPMG eta Unilever bezalakoak) jakinarazi du Agiletik aldenduz , proiektuak 2-3 aldiz azkarrago ematen ari direla eta hegazkin-konpainia lider batek aurreztu duela 63. haien garapen-kostuen %.

Hau da, abiadura eta kostua tradizionalki Agile eta LEAN-ekin lotutako neurketak izan arren, Impact Engineering-en ikuspegia Inpaktua metrika nagusi gisa oinarritzen den bitartean.

Azkenik, Colm Campbell-ek " P-Hacking with Dinosaurs " artikuluan idatzi duen bezala, "Agile Mafia"-k Agile porrot-tasaren azterketari erantzunez egindako aldarrikapenak erabat gezurtatu dira, eraso pertsonal patetikoak soilik utziz.

Hala ere, beharbada ikerketak laguntzeko arlo harrigarrienetako bat Google-ren DORA taldetik dator. DORAk berak DevOps mugimenduan aurkitzen ditu bere sustraiak, bera Agileren izaki bat baita. 2024rako DevOps egoeraren urteko txostenak ez du aurtengo estaldura berezirik jaso Agileren ikerketara joan den aire-denbora ikusita, baina interesgarria da Agileri ere bizkarra ematen ari zaizkiola ikustea.

Orain, kontuan izan behar dut DORA taldearen metodologiarekin kritiko izan naizela (Agile, DevOps, etab.-en inguruan iritzia aldatu nuenetik), gauzak neurtzeko erabiltzen dituzten neurgailu nagusiak entrega-abiaduran oinarritzen direlako ( badakigu ez dela). Ez da erabiltzaileek nahi dutena ), baina hori ikusten ari direla beren ikuspegia erabiliz ere hemen sakonago gertatzen ari dela adierazten du.

DevOps 2024ko egoeraren txostenaren 64. orrialdean, honako hau diote:

'Agile manifestuak "softwarea dokumentazio integralaren gainetik lan egitea" defendatzen du. Hala ere, ikusten jarraitzen dugu kalitatezko dokumentazioa laneko softwarearen funtsezko osagaia dela».

Gainera, 82. orrialdean, DevOps berari bizkarra ematen diotela dirudi:

"Betidanik DevOps mugimenduaren parte izan diren oinarrizko printzipioekin konprometituta gaude: kultura, lankidetza, automatizazioa, ikaskuntza eta teknologia erabiltzea negozio helburuak lortzeko. Gure komunitateak eta ikerketak eginkizun ezberdinen ikuspuntutik etekina ateratzen dute, "DevOps" etiketarekin erlazionatzen ez diren pertsonak barne. "DevOps" terminoa fokuetatik kanpo ikustea espero beharko zenuke.'

Oraindik arazoak ditut haien ikerketa-metodologiarekin; arrakasta neurtzeko erabiltzen diren puntuak abiaduran zentratzen dira, eta, gainera, lidergo eraldatzailearen alde egiten jarraitzen dute arlo honetako ikerketa psikologikoak horrelako planteamenduak zalantzan jartzen dituen arren.

Giza mailan, oso gordina dirudi erakundeak eta pertsonak haien baimen informaturik gabe eraldatzen saiatzean hainbeste bideratzea, eta, era berean, ez baita askotan gure akatsak baino ikaskuntza-iturri hoberik ez dagoen aitortzen (informatua dugun neurrian). horiek egiteko baimena), Pheonix Project eta Unicorn Project bezalako lanei egin diodan funtsezko kritika.

Hala ere, nabarmena da Inpaktu Ingeniaritza Agile eta DevOps metrika tradizionalen aurka gero eta berrespen handiagoa ikustea.

Scrum, TDD eta Diseinu ereduak

The Register-ek duela hilabete batzuk elkarrizketatu ninduenean " Study backer: Catastrophic take on Agile overemphasize new features " artikuluan, ez nituen ezkutatu Agile, DevOps eta eraldaketa digitalaren ikuspegi modernoetan arazoak izan nituen hiru faktoreak:

1. Eskakizunak zaharkitzen dituzten Agile-ren hurbilketak, Post Office eskandalua eta Boeing 737 Max 8 istripuak barne hondamendiak izan arren.

   
   

2. Funtzio berriak emateko eta arazoetatik berreskuratzeko abiadura lehenesten duten DevOps-en inplementazioak, lehenik eta behin, arazoak prebenitzeari baino, ikerketek erakutsi duten arren, publikoak azken funtzioak ahalik eta azkarren eskuratzen ditu sistema informatikoak erabiltzen dituzteneangarrantzitsuena dena . datuen segurtasuna, datuen zehaztasuna eta akats larririk gabe faktore garrantzitsuenak izanik.

   
   

3. Baimen informatua lortu gabe behetik gorako antolakuntza-eraldaketa egiten saiatzen da, jendeari beren akatsetatik ikasteko baimen informatua duten baimena ematearen garrantzia alde batera utzita, programa horiek arrakasta ziur gisa salduz, erabateko miseria eta porrot estresagarrietan amaitzen direlarik.

   
   

Software hondamendiak eta ordenagailu hiltzaileak ikertzen hasi nintzenean ( apirilean Forbes-en jakinarazi zuenez), hauek izan ziren erronka moral gero eta handiagoak izaten hasi nintzen hiru faktoreak. Ez nuen benetako arazorik izan software-garapeneko ikuspegi desberdinekin edo proiektuen kudeaketa-teknikekin, ez nuelako lotura bera ikusten ikertzen ari nintzen hondamendien kasuen azterketekin. Ez nuen ingeniari gisa nire iritzi pertsonalak adierazteko beharrik beste gai hauei buruz.

Dena den, interesgarria da leherketaren erradioa hasierako hiru eremu horietatik haratago zabaldu dela Agile Manifesto-ren egilekideek defendatutako beste ikuspegi batzuetara, hala nola Scrum, Test-Driven Development (TDD), Object-Oriented Programming (OOP) eta Design. Ereduak (adibidez, ikusi Soumen Sarkar-en LinkedIn-eko argitalpena Diseinu-ereduak ).

Alor honetan ezer gutxi daukat gehitzeko. Hala ere, galdetzen diot neure buruari galdetzen diot egile Agileek erlijio gisa haren heriotzaren aurka hain gogor borrokatu ez ote zuten softwarearen ingeniaritza komunitatea euren beste ideiekin atseginagoa izango balitz. Galdera eztabaidagarria da orain, Agileren estatus erlijiosoa rigor mortis dela eta dena prest dagoela dirudi: OOP, diseinu ereduak, TDD, etab.

Galeraren Abertsioaren Sentsibilizaziorantz

Azken hilabeteetako zati handi bat Agileri buruz hitz egiten duten hainbat argitalpen teknologikoen lehen orrialdeko albisteak izaten eta komunitatean orokorrean oso eztabaidatua izan denez, agian ez litzateke harritzekoa topaketa bitxi batzuk izatea. Gehienetan, ordea, jendearen topaketa oso atseginak izan dira nigana etortzen diren eta ausaz Agileri buruzko eztabaidan parte hartzen duten pertsonen arteko topaketa atseginak izan dira.

Hala ere, izan zen topaketa bat inpresio gogorra utzi zidan. Duela aste batzuk, Erresuma Batuko Parlamentura joan nintzen ikertzen ari nintzen teknologia-eskandalu ezberdinen arduradun politikoei zuzentzeko. Inoiz ez naiz izan boterea edukitzea oso zalea, eta beti iruditu zait harrigarria Parlamentuko taberna pribatuetan, mozkortuta daudenean norbanakoei boterea ez abusatzeko gogorarazten dieten kartelak egotea.

Dena den, hitzaldi hau emanez, ohi baino ondo jantzita eta aurkezleagoa ez ezik, entzule jator baten aurrean ere egon nintzen, legebiltzarkide bat eta erregearen aholkularia den lagun bat ondoan (abokatu nagusi batek onartu zuen). monarkak aparteko aldarrikapenagatik egindako bereizketa hori).

Behin nire hitzaldia eman eta hainbat galdera erantzun nituenean, entzuleen artean bisitari bat zegoen norbait Agileri buruz hitz egiten hasi zena (hitzaldia ez zen Agileari buruzkoa izan). Nire hiru piezako trajearen aldean, ketchup zikindutako alkandora batekin jantzita zegoen eta (xehetasunetan sartu gabe) ez zegoen ez aurkezgarria, ez politikoki lotuta. "Eman al dezaket iritziren bat?" hasi zuen.

Agileari buruz hitz egiten hasi zenean, begi-harremana jarri nuen berarekin galdezka, eta behera begiratu zuen eta hitz egiteari utzi zion, ia sarean ez zegoela eta norbaiti aurrez aurre bere hitzekin konturatuko balitz bezala. Erantzun ahal izan baino lehen, zuzendari nagusiaren lagun batek tartea egin zidan puntua jorratzeko.

Momentu horretan, konturatu nintzen boterea ez nuela gustatzen orain arte konturatu ez nintzen neurrian.

Zoritxarrez, gizabanako honentzat, bazirudien jadanik bere bizitzan zailtasunak sor ditzaketen eraldaketa irtenbide seguruak saltzen zituztenen biktima izan zela. Egoera hauetan zergatik defendatzen dira oraindik eraldaketa-metodologia hauek?

Orokorrean, zergatik ezin da Agile mundu errealean funtzionatu? Komunismoarekin, gutxienez porrota gutiziari egotzi diezaiokegu, beraz, zein da Agile porrotaren psikologia? Erantzuna, nire begietan, galerarako aversion izenez ezagutzen den faktore psikologiko batera dator. Jendearen eskariari esker, duela gutxi inprimatze aurreko lan bat idatzi nuen Eraginaren Ingeniaritza lanari buruz eta proiektuaren arrakasta arintzeko egin dezakeen paperaren galeraren aurkako kontzientziari buruz zentratu zen.

Papera, "Beraz, Frankenstein doktorea naiz? Or Were You a Monster the Whole Time?”: Mitigating Software Project Failure With Loss-Aversion-Aware Development Methodologies , honela ondorioztatzen da:

Kasu-azterketek frogatu dute software-hondamendiek elur-bolada bihur dezaketela arazoak konpontzen ez direnean eta estali egiten direnean. Faktore psikologikoek, gakoa den galeraren aurkakotasuna, erakundeak bide horretatik joatera bultza ditzakete ondorio negargarriak izan arren.

Hala ere, software-metodologiek historikoki faktore psikologiko hori baztertu dute, gizakiek arazoei lehenbailehen aurre egin nahi dietela suposatuz. Metodologia ezberdinen aurreko ikerketek aurkitu dute segurtasun psikologikoa gaiak planteatzeko eta eztabaidatzeko funtsezkoa dela softwarearen entrega hobetzeko. Hala ere, zalantzarik gabe, baikorra da erakunde guztietan aldaketa kultural eta psikologiko garrantzitsu hori lor daitekeela uste izatea. Aurkitu dugunez, Erresuma Batuaren eta AEBen artean ere, segurtasun psikologikoak bi herrialdeen arteko ingeniaritza praktikan alde handiena izaten jarraitzen du.

Artikulu honetan, beste bide batean zentratuko gara. Onenean erronka den aldaketa kulturala lortzen saiatu beharrean, ikuspegi pragmatikoago batean jartzen dugu arreta: hasieratik mugatu galera-abertsioaren eragileak baldintza sendoen bidez eta gero segurtasun psikologikoa behar den tokian bilatu. Gure ikerketan, proiektu baten arrakasta-tasa areagotuko lukeen faktore bakarra segurtasun psikologikoa baino gehiago eskakizun argiak izatea izan zen hasieratik.

Gure hipotesiaren aurka, eskakizun argiak edukitzea besterik ez duten emaitzek, garapenean berandu aldatzen direnean edo mundu errealarekin bat ez datozenean ere, software proiektuen arrakastan zeresan handia dute. Horrek iradokitzen du proiektu bat hasi baino lehen ate bat izateak arazoei buruz eztabaidatzeko eta konpontzeko, galeraren aurkako abertsioa baxuenean dagoenean, arrakasta-tasen hobekuntza handiena ahalbidetzen duela.

RedHook-en Dr. Frankenstein abestiak estribilloa dauka: “Beraz, Frankenstein doktorea naiz? Edo munstro bat izan zinen denbora guztian?" Software-proiektu hondamendietarako, dokumentu honek dio software-proiektuak hondamendi bihurtzen direla gizakiek eskala txikiagoko arazo teknikoei aurre egiten ez diotenean. Dauden software-ingeniaritza-metodologiek ez dute lortzen gizakiak makinak ez direla eta faktore psikologikoek arazoei aurre egiteko gaitasuna oztopatzen dute. Lehendik dauden metodologietan anakronismo hori identifikatu ondoren, lan honek proiektu bat hasi aurretik eskakizunak erabiliz nola jarduteko modua aurkezten du, galera-abertsioa baxuenean dagoenean arazoak konpontzeko aukera eskaintzeko.