Cargo Cult Software Engineering

a Dél-tengerek Van egy rakomány kultusz az emberek. A háború alatt sok jó anyagot tartalmazó repülőgépet láttak, és azt akarják, hogy most is ugyanez történjen. Ezért elrendezték, hogy kifutópályákat készítsenek, hogy tüzet rakjanak a kifutópályák oldalára, hogy egy fából készült kunyhót készítsenek az embernek, ahol ülhet, két fadarabbal a fején a fejhallgatók számára, és bambuszrudakkal, amelyek antennaként állnak ki—ő a vezérlő—és várják, hogy a repülőgépek leszálljanak. Mindent jól csinálnak. A forma tökéletes. Pontosan úgy néz ki, mint korábban. De nem működik. Repülőgépek nem szállnak le. Tehát ezeket a dolgokat rakománykultusz tudománynak hívom, mert követik a tudományos kutatás minden látszólagos előírását és formáját, de hiányzik valami lényeges, mert a repülőgépek nem szállnak le.
-Richard Feynman

hasznosnak találom két különböző szervezeti fejlesztési stílus kontrasztját: a “folyamatorientált” és az “elkötelezettség-orientált” fejlesztést. A folyamatorientált fejlesztés ügyes tervezéssel, gondosan meghatározott folyamatok felhasználásával, a rendelkezésre álló idő hatékony felhasználásával és a szoftverfejlesztés legjobb gyakorlatainak ügyes alkalmazásával éri el hatékonyságát. Ez a fejlesztési stílus sikeres, mert az azt használó szervezet folyamatosan javul. Még akkor is, ha korai kísérletei hatástalanok, a folyamat folyamatos figyelme azt jelenti, hogy minden egymást követő kísérlet jobban fog működni, mint az előző kísérlet.

az elkötelezettség-orientált fejlesztésnek számos neve van, beleértve a “hős-orientált fejlesztést” és az “egyéni felhatalmazást”.”Az elkötelezettség-orientált szervezeteket az jellemzi, hogy a lehető legjobb embereket veszik fel, teljes elkötelezettséget kérnek tőlük projektjeik iránt, szinte teljes autonómiával ruházzák fel őket, szélsőséges mértékben motiválják őket, majd látják, hogy heti 60, 80 vagy 100 órát dolgoznak, amíg a projekt befejeződik. Az elkötelezettség-orientált fejlődés hatalmas motivációs képességéből származik-a tanulmány után a tanulmány megállapította, hogy az egyéni motiváció messze a legnagyobb mértékben járul hozzá a termelékenységhez. A fejlesztők önkéntes, személyes elkötelezettséget vállalnak a projektjeik iránt, és gyakran rendkívüli erőfeszítéseket tesznek annak érdekében, hogy projektjeik sikeresek legyenek.

szervezeti imposztorok

tudásalapú használat esetén bármelyik fejlesztési stílus gazdaságosan és gyorsan képes kiváló minőségű szoftvereket előállítani. De mindkét fejlesztési stílusnak vannak olyan kóros megjelenései, amelyek közel sem működnek olyan jól, és ezt nehéz megkülönböztetni az eredeti cikkektől.

a process-imposter szervezet gyakorlatát a folyamat iránti szolgai odaadásra alapozza. Ezek a szervezetek olyan folyamatorientált szervezeteket vizsgálnak, mint a NASA Software Engineering Laboratory és az IBM korábbi szövetségi rendszerek részlege. Megfigyelik, hogy ezek a szervezetek sok dokumentumot generálnak, és gyakran tartanak találkozókat. Arra a következtetésre jutnak, hogy ha azonos számú dokumentumot állítanak össze, és hasonló számú ülést tartanak, akkor hasonlóan sikeresek lesznek. Ha több dokumentációt készítenek és több értekezletet tartanak, akkor még sikeresebbek lesznek! De nem értik, hogy a dokumentáció és a találkozók nem felelősek a sikerért; ezek néhány specifikus hatékony folyamat mellékhatásai. Ezeket a szervezeteket bürokratikusnak nevezzük, mert a szoftverfolyamatok formáját az anyag fölé helyezik. A folyamattal való visszaélés demotiváló, ami károsítja a termelékenységet. És nem túl élvezetes nekik dolgozni.

a commitment-imposter szervezet elsősorban az emberek motiválására összpontosít, hogy hosszú órákat dolgozzanak. Ezek a szervezetek olyan sikeres vállalatokat vizsgálnak, mint a Microsoft; figyelje meg, hogy nagyon kevés dokumentációt generálnak; részvényopciókat kínálnak alkalmazottaiknak; aztán megkövetelik tőlük, hogy a Túlórák hegyeit dolgozzák. Arra a következtetésre jutnak, hogy ha ők is minimalizálják a dokumentációt, részvényopciókat kínálnak, és kiterjedt túlórát igényelnek, akkor sikeresek lesznek. Minél kevesebb dokumentáció és minél több túlóra, annál jobb! De ezek a szervezetek hiányolják azt a tényt, hogy a Microsoft és más sikeres elkötelezettségorientált vállalatok nem igényelnek túlórát. Olyan embereket vesznek fel, akik szeretnek szoftvereket készíteni. Ők csapat ezek az emberek más emberek, akik szeretnek létrehozni szoftver ugyanúgy, mint ők. Bőséges szervezeti támogatást és jutalmat nyújtanak a szoftverek létrehozásához. Aztán elengedik őket. A természetes eredmény az, hogy a szoftverfejlesztők és a vezetők úgy döntenek, hogy hosszú órákat dolgoznak önként. Az impozáns szervezetek összekeverik a hatást (hosszú órák) az okkal (magas motiváció). Azért hívjuk az imposztor szervezeteket, mert a kemény munkát hangsúlyozzák, nem pedig az okosságot, és általában kaotikusak és hatástalanok. Nekik sem túl élvezetes dolgozni.

Cargo Cult Software Engineering

első pillantásra úgy tűnik, hogy ez a kétféle csaló szervezet pontosan ellentétes. Az egyik hihetetlenül bürokratikus, a másik hihetetlenül kaotikus. De az egyik legfontosabb hasonlóság valójában fontosabb, mint a felületes különbségek. Egyik sem nagyon hatékony, és ennek oka az, hogy egyik sem érti, mi teszi a projektjeit sikeressé vagy kudarcba. Mennek keresztül a mozgások néz ki, mint a hatékony szervezetek, amelyek stilisztikailag hasonló. De anélkül, hogy valóban megértenék, miért működnek a gyakorlatok, lényegében csak bambuszdarabokat ragasztanak a fülükbe, és remélik, hogy projektjeik biztonságosan landolnak. Sok projektjük végül összeomlik, mert ezek csak a cargo cult szoftverfejlesztés két különböző fajtája, hasonlóan ahhoz, hogy nem értik, mi teszi a szoftverprojekteket működésbe.

a Cargo cult szoftverfejlesztés könnyen azonosítható. A Cargo cult szoftvermérnökei azzal indokolják gyakorlatukat ,hogy “a múltban mindig így csináltuk” vagy “vállalati szabványaink megkövetelik tőlünk, hogy ezt így tegyük”—még akkor is, ha ezeknek a módszereknek nincs értelme. Nem hajlandók elismerni a folyamatorientált vagy elkötelezettség-orientált fejlesztésben rejlő kompromisszumokat. Mindkettőnek vannak erősségei és gyengeségei. A cargo cult szoftvermérnökei, ha hatékonyabb, új gyakorlatokat mutatnak be, inkább az ismerős, kényelmes és-nem feltétlenül-hatékony munkamódszerekkel rendelkező faházakban maradnak. “Ugyanazt csinálni újra és újra, és különböző eredményeket várni az őrület jele” – tartja a régi mondás. Ez a rakománykultusz szoftverfejlesztésének jele is.

az igazi vita

ebben a magazinban és sok más kiadványban azzal töltjük az időnket, hogy azon vitatkozunk, hogy a folyamat jó-e, vagy az egyéni felhatalmazás (más szóval az elkötelezettség-orientált fejlesztés) jobb. Ez egy hamis dichotómia. A folyamat jó, csakúgy, mint az egyéni felhatalmazás. A kettő létezhet egymás mellett. A folyamatorientált szervezetek rendkívüli elkötelezettséget kérhetnek bizonyos projektek iránt. Az elkötelezettség-orientált szervezetek ügyesen használhatják a szoftverfejlesztési gyakorlatokat.

a két megközelítés közötti különbség valójában a stílus és a személyiség különbségéből fakad. Különböző stílusokon dolgoztam, és különböző dolgokat szerettem az egyes stílusokban. Egyes fejlesztők szívesen dolgoznak módszeresen egy 8-5 ütemterv szerint, ami gyakoribb a folyamatorientált vállalatoknál. Más fejlesztők élvezik a fókuszt és az izgalmat, ami azzal jár, hogy egy projekthez 24 6-os elkötelezettséget vállalnak. Az elkötelezettség-orientált projektek átlagosan izgalmasabbak, de egy folyamat-orientált projekt ugyanolyan izgalmas lehet, ha jól meghatározott és inspiráló küldetéssel rendelkezik. Úgy tűnik, hogy a folyamatorientált szervezetek ritkábban degenerálódnak pathalogikus megjelenéseikbe, mint az elkötelezettség-orientált szervezetek, de bármelyik stílus jól működhet, ha ügyesen megtervezik és végrehajtják.

az a tény, hogy mind a folyamatorientált, mind az elkötelezettség-orientált projektek kóros megjelenéssel rendelkeznek, elrontotta a vitát. Néhány, az egyes stílusokban végrehajtott projekt sikeres, mások kudarcot vallanak. Ez lehetővé teszi, hogy a folyamat szószólója rámutatjon a folyamat sikerére és az elkötelezettség kudarcaira, és azt állítja, hogy a folyamat a siker kulcsa. Ez lehetővé teszi az elkötelezettség szószólója számára, hogy ugyanezt tegye.

az a kérdés, amely az út mentén esett, miközben a folyamat vs.elkötelezettség vitáját folytattuk, annyira nyilvánvaló, hogy mint Edgar Allen Poe szegélyezett levele, egyszerűen annyira nyilvánvaló volt, hogy figyelmen kívül hagytuk. Nem a folyamat vs. elkötelezettség, hanem a kompetencia vs. inkompetencia. Az igazi különbség nem az, hogy melyik stílust választják, hanem az, hogy milyen oktatást, képzést és megértést hoznak a projektbe. Ahelyett, hogy a folyamat vs. elkötelezettség, meg kell keresni a módját, hogy növelje az átlagos szintű fejlesztő és menedzser kompetencia. Ez javítja a siker esélyeit, függetlenül attól, hogy melyik fejlesztési stílust választjuk.