Idestova 25 éve (negyedszázada!) dolgozok a szoftveriparban, ráadásul sok különböző munkahelyen megfordultam. Bár igaz, egy tekintetben azért „egysíkú” a tapasztalatom – külföldi tulajdonú cégeknél dolgoztam, jobbára külföldi megrendelésre: az Egyesült Államokba, Németországba, Franciaországba illetve az Egyesült Királyságba. Mondhatjuk, hogy tapasztalataim a „második vonal” (az első természetesen Kalifornia állam, még csak nem is az Egyesült Államok, hanem kifejezetten annak legnyugatibb állama) módszereit, munkastílusát tükrözik.
Ez idő alatt jó pár technológiai „váltást” megéltem. Ebben a posztban most technológiák közül a számomra leginkább furcsára, a szoftvermetodológiákra fogok koncentrálni.
Az meg mi?
Mi is tulajdonképpen a szoftvermetodológia, vagy ha úgy tetszik módszertan? Tulajdonképpen a szoftverek készítésének, karbantartásának egy követendő módszere. Mint módszer, megfogalmaz
- javaslatokat
- szerepköröket
- szabályokat
- eszközöket
- folyamatokat
mindezt abból a célból, hogy a szoftverek a lehető legjobb minőségűek legyenek. Készüljenek el időben, lehetőleg ne tartalmazzanak (sok) hibát, és nagyjából azt a feladatot oldják meg, amit eredetileg szántak nekik. A számítógépek szélesebb körű üzleti elterjedését követően eléggé hamar kiderült, hogy nem egyszerű feladat szoftvert készíteni. A szoftverkrízis sok pénzt és erőfeszítést égetett el. Abból a célból, hogy a hasonló fiaskóknak elejét vegyék, a szoftverkészítést elkezdték részben irányítási, részben mérnöki szemmel nézni, és megszülettek az első módszertanok.
Módszertanok
Ahhoz, hogy bemutassam a ívet, ami a módszertanok egymást követő megjelenése és elterjedése megjelenít, pár szót kell ejtenem azokról, amelyeket közelebbről is ismerek.
Waterfall
A „vízesés” modell a szoftverfejlesztést egymást követő, jól elhatárolt lépésekben képzeli el. Nagyjában-egészében a követelmények -> tervezés -> kivitelezés (programozás) -> ellenőrzés -> telepítés -> karbantartás folyamatot követve. Látható, hogy a módszertan fő vezérelve a „gondolkodj, mielőtt cselekszel” alaptétel.
V-modell
Nagyon hasonló a vízeséshez, a különböző tervezési fázisok párba vannak állítva a nekik megfelelő ellenőrzési fázisokkal, de ez a módszer is megtartja az „előbb tervezz aztán végezz” elvét.
Rational unified process
Úgynevezett iteratív modell, azaz a kulcslépések sorozatát, meghatározott sorrendben ismétli, mindig finomítva a szoftvertermék képességeit, és készültségi fokát. Ebben a modellben is megfigyelhető a követelmények -> tervezés -> kivitelezés -> ellenőrzés egymásra épülése, időbeni egymásutánisága.
A maga módján mindegyik módszertan teljes, és logikus alkotás. És a maga módján mindegyik azt állítja, hogy az általa lefektetett szabályokat követve elérhető az áhított cél. Csakhogy – természetesen – ezek a módszertanok azért valamennyire különböznek egymásól, tehát nem lehet mindegyikük a megfelelő módszertan. Van viszont a módszertanok egy olyan csoportja, amely jelentősen eltér az eddig bemutatottaktól.
Agilis módszertanok (Scrum, Agile, SAFe, stb.)
Szintén iteratív módszertanok, de … amit itt tervezésnek (planning) hívnak, annak nincs köze a korábban megismert tervezéshez. Amit itt reviewként ismerünk, nem azonos a többi módszertan ellenőrzési lépésével. Talán az agilis módszertanok mondanak a legkevesebbet arról, milyen lépésekben képzelik a szoftverfejlesztést – inkább az úgynevezett rituálékra koncentrálnak, és a fejlesztő csapatok autonómiáját hangsúlyozzák.
A tervezés nagyjából azt jelenti, hogy a csapat előtt álló közepesen hosszú időszakban (egy iteráció, néha sprint) mely feladatokkal fognak foglalkozni. A napi standup vagy scrum 15 percében az aznapi vállalás a téma. A review és retrospektív rituálé azt elemzi, hogyan sikerült elérni az iteráció céljait, mit lehetett tanulni a sikerekből és a kudarcokból.
Ami megvan benne
A kis lépésekben haladó kivitelezésnek és ellenőrzésnek kétségkívül megvan az az előnye, hogy gyors, sűrű visszajelzést ad arról, hogy mely „tulajdonsága” az illető terméknek milyen készültségi fokon áll. Ezt, természetesen mindazok, akik megelégednek a működő szoftverrel, kedvezőnek tartják.
Nagyjában-egészében tervezhetővé, költségeket illetően kontrollálhatóvá teszi a szoftver készítését. A csapatok jellemzően aránylag jól meg tudják ítélni, hogy a következő 2-3 hétben (a sprint tipikus hossza) mennyi kis feladatot tudnak elvégezni, így aztán rövid távra aránylag jól lehet tervezni.
Ezen felül az agilis módszertanok divatosak, senkit nem fognak csak ezért kirúgni mert alkalmazza őket – ennélfogva tehát, a menedzsment szintjén, biztonságos választás bármelyikük.
Ami hiányzik belőle
Látható, hogy nincs jelen a többi módszertan megszokott, tervezés -> végrehajtás lépéspárja, legalábbis nem olyan értelemben, mint azoknál. A tervezés itt „mikroszinten” zajlik, minden feladathoz (work item) külön-külön. Nehéz megérteni, hogyan lesz az ily módon, feladatonként külön „megtervezett” szoftverből egységes alapelvek szerint létrehozott egész.
Tulajdonképpen talán ez nem is lehetséges, tapasztalataim szerint az agilis módszertanok inkább szoftverek továbbfejlesztésénél, apró lépésekben történő bővítésénél kapnak szerepet – nagy léptékű „zöldmezős” fejlesztéseknél, ahol az architektúrát „nulláról” kell kialakítani, nem. Kis lépésekkel, ugyebár, nem lehet átjutni a szakadékon. Hiányzik tehát a nagy léptékű tervezés lehetősége.
Van egy zavarba ejtő másik jelenség: a napi (lényegében) számonkérés, a scrum vagy „standup” néven ismert 15 perces rituálé, amiben az ember elmondja mivel fog foglalkozni. Nagyon kevés olyan emberrel találkoztam, akik élvezték volna ezeket a rövid beszámolókat. Sokan – én is – úgy vélik, hogy ennek az értekezletnek egyfajta ellenőrzés, a csapattagok feletti kontroll gyakorlása a célja, és nem (mint gyakran elhangzik) annak kiderítése szükség van-e valakinek segítségre. És tényleg: ha valaki elakad, nem működik valami, vagy nem talál meg egy kulcsfontosságú információt, akkor előbb-utóbb segítséget kér, aligha várja meg vele a másnap reggelt … Ellenben a reggeli beszámoltatás kitűnő alapját képezheti a egy alapos teljesítményvizsgálatnak. Az hogy erre naponta sor kerül, úgy is értelmezhető, hogy a csapattagokról nem képzelhető el a nagyobb léptékű tervek önálló kivitelezése. Hiányzik tehát a képességekbe vetett bizalom.
A kis lépésekben, nagyívű tervezés nélkül végzett munka nem lesz koherens szerkezetű. Működni fog, de csak azért, mert a módszertan sűrű ellenőrzést épít be a folyamatba. A minőségre azonban ez nem fog garanciát jelenteni, csak a működőképességre. Saját tapasztalat az olyan szoftver, amely működik – de csak éppenhogy. Ha bárhol módosítani kell rajta, csak nagy nehézségek árán tehető meg, ugyanis az egész rendszernek nincs nagy, mindent átható szervező elve. Ahhoz ugyebár architektúra tervezés kellett volna, de annak nincs három hét alatt felmutatható eredménye, ennélfogva agilis módszertannal nem végezhető el a feladat. Hiányzik tehát a koherens architektúra megvalósításának lehetősége.
Ahonnan az agilis módszertan hiányzik
Napjaink legsikeresebb szoftverei nem is léteznek önállóan. Szabadon felhasználható, lényegében ingyenes szoftverkönyvtárak, vagy modulok. Ezeket létező problémák megoldására lelkes amatőrök fejlesztik. Ők csak abban az értelemben amatőrök, hogy nem pénzért csinálják, egyébként természetesen vérbeli profik. Az OpenSSH könyvtárat lényegében mindenki (tényleg mindenki) használja, de pár lelkes amatőr írta csak meg – igaz azóta céget alapítottak, ahol konzultációs segítséget nyújtanak. A cats könyvtárat tucatnyi közreműködő alkotta meg, szinte minden Scala nyelven írt projektben használják. Az Apache projektnek számtalan eleme van – használóinak száma milliós nagyságrendű. Ezek mind-mind ingyenes, és a legnagyobb részt magánkezdeményezésből megszületett alkotások.
No, és mit nem csinálnak a földrajzilag szétszórt, amatőr, nem alkalmazottként alkotó programozók, miközben létrehozzák ezeket? Bingó, standup-ot például biztosan nem. Semmiféle módszertant nem követnek – saját legjobb értékítéletükön kívül. Nem adnak semmiféle becslést arra, hogy egy adott funkcionalitás mikor lesz készen. Nem próbálják meghatározni, hogy melyik feladat mennyire komplex. Ugyanakkor teljesen biztos, hogy terveznek, mielőtt végrehajtanak – de ez minden.
És mégis, messze megbízhatóbb, nagyobb hatású és jobb minőségű szoftvert csinálnak, mint a legtöbb cég.
Záró gondolatok
Nekem a fentiekből úgy tűnik, hogy a szoftverminőség talán nem a módszertanon múlik, hanem az egyéni motiváción. Ha megvan a jó akarása, akkor a végeredmény – ha az idő engedi – jó lesz. A különböző módszertanok talán hozzájárultak ahhoz, hogy a szoftveripar kiszámíthatóbban hozzon eredményeket, de ahhoz nem, hogy a motiváció javításával járuljanak hozzá a jobb minőség eléréséhez. Paradox módon napjaink szoftverei ott a legjobbak, ahol a módszertanokat a legkevésbé követik vagy alkalmazzák: a beépített szabad szoftverkönyvtárak esetében.
Talán egyszer majd a cégek is megtanulják, hogyan lehet olyan környezetet csinálni, amelyben lehetséges az ilyen minőségű termék előállítása. Egy valamiben biztos vagyok: standup nem fog hozzá kelleni.