Az Agile története
Robert C. Martin nemrégiben beszélt a The Changelog podcastben arról, hogy az Agile értelmezése az évek során mennyire eltávolodott annak eredeti megfogalmazásától. Uncle Bob — ahogy sokan Robert C. Martint nevezik — egy nemrégiben megjelent könyve kapcsán beszélt az Agilis szoftverfejlesztés eredetéről és az azóta eltelt évek során kialakult különböző irányzatairól.
A szoftverfejlesztés eredete
Az 1950-es évek során senki sem tudta, hogy hogyan kell programot írni. Egyetemeken nem tanítottak szoftverfejlesztést. Jellemzően mérnöki tudományokban jártas oktatók voltak a téma nagy úttörői. Ők nagyrészt matematikusok, fizikusok voltak akik saját munkájuk során használták fel a számítástudomány vívmányait segédeszközként. Ezek a korai programozók gyorsan kifejlesztettek egy programozási stílust amit akár mai szemmel agilisnek is lehetne nevezni, de persze akkor nem nevezték még így. A stílus jellegzetessége az volt, hogy a munka rövid szakaszokban folyt és a kimenetet előre megírt tesztesetekkel rendszeresen ellenőrizték. Például a Mercury-programban résztvevő programozók úgy kezdték a napot, hogy délelőtt megírták a unit tesztet arra a problémára amit délután megoldottak. Tehát az 1 napból álló fejlesztési ciklus volt jellemző.
Waterfall model
Az 1970-es évek elején kezdtek megjelenni az első végző szoftverfejlesztő évfolyamok az egyetemeken. Ebben az időben Winston W. Royce írta meg a Managing the Development of Large Software Systems tanulmányát a korai szoftver menedzsment folyamatokkal kapcsolatos problémákról. Ebben a kiadványban került ábrázolásra először a Waterfall modell. A vízesésmodellben a munkafázisok egymást követik ahol az egyes szakaszok az előző fázis eredményétől függnek. A mérnöki tervezés bizonyos területeire jellemző ez a megközelítés, ezért a szoftverfejlesztésben inkább a kevésbé iteratív és rugalmatlan megközelítések közé tartozik, mivel a haladás nagyrészt egy irányba (“lefelé”, mint egy vízesésnél) folyik az elgondolás, a kezdeményezés, az elemzés, a tervezés, a felépítés, a tesztelés, a telepítés és a karbantartás szakaszában.
A vízesésmodellt Winston W. Royce tanulmánya kifejezetten úgy mutatja be, hogy miért rossz ötlet ezt alkalmazni, a Royce részletesen megindokolja, hogy ezek a folyamatok miért nem követhetik egymást sorosan. A tanulmányt csak kevesen értelmezték, sokan kiragadták a modellt a környezetéből és próbáltak benne értelmet találni. Így alakult, hogy következő 30 évben a Waterfall lett a szoftverfejlesztés meghatározó modellje.
Agile
Az 1990-es években számos könnyűsúlyú szoftverfejlesztési eljárás született, melyek az uralkodó nehézsúlyú (waterfall alapú) metodológiákkal szemben kínáltak egy kevésbé szabályozott, lazábban tervezett környezetet. A könnyűsúlyú eljárásokban hívők gyakorlatilag visszatértek a korai szoftverfejlesztési folyamatokhoz ahol a résztvevők tesztekkel definiált rövid ciklusidőben gondolkodnak amelyek végén kész verzió születik.
2001 februárjában Robert C. Martin 16 szoftverfejlesztési szakértő társaságában összegyűlt Utah-ban és megfogalmaztak egy kiadványt melynek címe “Kiáltvány az agilis szoftverfejlesztésért”. Néhány szerző megalapította az Agilis Szövetséget (angolul Agile Alliance), egy nonprofit szervezetet, amely segíti a szoftverfejlesztést a kiáltvány értékei és alapelvei szerint.
Robert C. Martin szerint ennek a kiáltványnak az alapelveit szinte azonnal elkezdték átfogalmazni és félreértelmezni egyesek. Sokan megpróbálták a szoftverfejlesztés világán kívül értelmezni a kiáltvány pontjait. Az Agile mozgalmat gyakorlatilag egyik pillanatról a másikra a soft-skillekkel dolgozó management iparág vette irányítása alá. Ez a programozóknak és mérnökök nem tetszett. Az Agile eredetileg hard-skillekre épül, melyek szigorú követelmények segítségével terelik mederbe az Agilis folyamatokat. Ezek az Agile magját adó hard skillek a következők lehetnek:
Olyan eszközök nélkül, melyek objektíven könnyen mérhető eredményeket produkálnak az Agile értelmét veszti. Ezeket az eszközöket az Agile mozgalom nem terjesztette, hanem a softskillekre alapuló metodológiát propagálta. Ez a szoftverfejlesztőknek és a mérnököknek nem tetszett azért 2008-ban megalakult a Craftmanship mozgalom, mely egy próbálkozás volt arra, hogy a technikai oldalát az Agile-nak újra felélessze.
Ma az agilis közösség a következő két csoportra oszlik:
- Az első csoport különböző hard-skillekre épülő technikákkal szeretne Agilisan működni.
- A sokkal nagyobb második soft-skillekkel dolgozó csoport pedig milliónyi címkét hozott létre az Agile mellé raktak. Ezek a címkék arra jók, hogy cégeket és csapatokat meg lehessen különböztetni egymástól. De Mondta Robert C. Martin azt is hozzátette a podcastben, hogy leginkább arra használják őket cégek, hogy agilisnak tűnjenek, holott valójában nem azok.
Mikor nem Agilis egy csapat?
Ha ennyien alkalmazzák magukra az agile jelzőt cégek, akkor adódik a kérdés: Mik a nyilvánvaló jelei annak, ha egy csapat vagy szervezet nem agilis? Robert C. Martin erre a kérdésre a következő világos jeleket sorolta fel:
1. Nem szállít új verziót hetente vagy kéthetente
A szoftverfejlesztő csapatnak sűrűn és pontosan kell szállítania feature halmazt. Ezt azt jelenti, hogy maximum 2 hetente le kell tenni valamit az asztalra ami teljeskörűen tesztelt, a specifikációnak megfelelő és dokumentálva van.
2. Nem kommunikál intenzíven a részvevőkkel
Programozóknak a stakeholderekkel a szoftverfejlesztési szakasz összes fázisában intenzív kommunikációt kell folytatniuk. Minden felmerülő kérdésre rövid úton és lehetőleg gyorsan választ kell találni. A két fél közti kommunikációnak világosnak és nyomon követketőnek kell lennie a későbbi félreértések elkerülése végett.
3. Nem ír teszteket
Akkor birtokol valaki egy szoftvert, ha bármely pillanatban meg tudjuk mondani annak minden funkciójáról, hogy jól működik. Ezt a kérdést csak akkor tudja valaki megválaszolni, ha rendelkezik a követelményeket teljeskörűen lefedő unit teszt halmazzal. A unit tesztek futásuk során igazolják, hogy a szoftver azt csinálja amire tervezték. A unit teszteknek konzisztensnek kell lenniük a követelményekkel, amennyiben a követelmények változnak, úgy a unit teszteket is frissíteni kell. Az a csapat nem agilis amelyik nem ír teszteket, amik a követelményeket állítják szembe az implementációval.
4. Ha elveszti a kontrollt a kódbázis felett
A kódot tisztán kell tartani és ismerni kell. A kontrollt úgy lehet megőrizni, hogy a szoftverfejlesztési folyamat minden döntése dokumentálásra került. Ezekből a dokumentumokból világosan látszik hogy mi volt a követelmény és mely követelményekből származtak egyes design elemek.
A megrendelői oldal
Az Enlight csapatával mi elkötelezett hívei vagyunk a technikai Agile vonalnak. Véleményünk szerint egy cég nem engedheti meg magának, hogy olyan szoftverre bízza bevételének termelését melyet agile értelmezés szerint nem birtokol.
Például Ipar 4.0 környezetben tevékenykedő partnereink nem engedhetnek meg maguknak kiesést abból adódóan, ha valami elromlik a rendszerükben. Ilyen környezetbe mi olyan egyedi szoftvereket fejlesztünk, melyet technikai agile megközelítéssel hoztunk létre. Ennek során mi részletesen dokumentáljuk a szoftver fejlesztési folyamatot és minden egyes követelményt unit teszttel fedünk le.
Nem minden esetben van szüksége a megrendelőnek unit tesztekre. Előfordul az is, hogy a megrendelőink nem kritikus folyamataikat ültetik át az általunk fejlesztett egyedi szoftverre. Ezek olyan szoftver megoldások, melyek ideiglenesen, pilot jelleggel vagy megoldás validációként kerülnek elhelyezésre Ipar 4.0 környezetbe. Költséghatékonyabb és kézenfekvő megoldás ebben az esetben a unit tesztek kihagyása. Ekkor akár fejlesztési idő 50%-át is meg lehet spórolni azáltal, hogy a teszteseteket kihagyjuk a szoftver fejlesztési folyamatból.
Az üzleti döntést, miszerint kell-e unit tesztekkel lefedni a kódbázist az ügyfeleinkre bízzük. Mi az enlight csapattal ettől függetlenül heti fejlesztési ciklusokban gondolkodunk amin belül teljes mértékben dokumentált egyedi szoftvert adunk át ügyfeleinknek.
