Dokumentáció az agilis módszertanban

Meg lehet szabadulni a dokumentálástól az agilis működéssel?

Valljuk be őszintén, senki sem szeret dokumentálni, a legtöbben felesleges időpocsékolásnak tartják. Az általános közvélekedés szerint sosincs rá kellő idő, általában nincs hozzá megfelelő módszertan és támogató eszköz. Emellett maga a feladat is unalmas és az így elkészült kétes minőségű dokumentációt úgysem olvassa senki.

Éppen ezért, amikor az agilis módszertanok kezdtek elterjedni, a dokumentáció száműzése volt az egyik legerősebb hívószó, ami segített meggyőzni a változásokkal szemben a legvégsőkig kitartó dolgozókat is arról, hogy érdemes belevágni, hiszen egy sokkal szebb, dokumentációmentes jövő köszönt majd rájuk.

Mindez pedig olyan jól sikerült, hogy mind a mai napig rendszeresen hallani azt a meggyőződést egy-egy „agilisan” működő szervezetben dolgozó csapattól, hogy „Mi nem dokumentálunk, hiszen mi agilisak vagyunk!”

Mi az alapja annak az elterjedt felfogásnak, hogy az agilis működés során nincs szükség dokumentálásra?

De vajon honnan ered ez a rendkívül erős tévhit? Miért gondolják azt a legtöbben, akik bármilyen formában találkoztak már az agilis eszmékkel, hogy az agilitásban nem szükséges dokumentáció?

Az agilis manifesztó négy értéke közül az egyik pont így fogalmaz: „Megtanultuk értékelni a működő szoftvert az átfogó dokumentációval szemben”.

Ezt pedig tovább erősíti az az agilis alapelv, amely úgy hangzik, hogy: „A leghatásosabb és leghatékonyabb módszere az információ átadásának a fejlesztési csapaton belül a személyes beszélgetés.”

Ebből a két megállapításból kiindulva, sokan úgy interpretálják az agilis működést, hogy:

• az agilis user story-ban három összetett mondatban meg kell válaszolni azt a három kérdést, hogy „Kinek?”, „Mit?” és „Milyen célból?”,
• összeültetjük az önállóan szállítani képes csapatot egy közös asztalhoz, hogy beszéljék át a részleteket,
• ahol közösen, gyakorlatilag a fejlesztés közben határozzák meg, hogy hogyan nézzen ki, vagy hogyan működjön maga a végtermék,
• végül pedig az így előállt produktumot bemutatják a sprint végén, és ha mindenki elégedett vele, már mehet is éles üzembe.

Tehát a fejlesztések és üzleti igények dokumentálása teljesen felesleges, ha amúgy is szóban adjuk át egymásnak, hogy mi lenne egy szoftverrel kapcsolatosan az elvárt működés. Azt a három bővített mondatot rögzítjük a JIRA-ba és meg is vagyunk, dokumentáció letudva és mindenki boldog, nem pocsékoltunk erőforrásokat a felesleges adminisztrációra és már mehetünk is tovább a következő sprint következő user story-jára.

Mégis szükség van dokumentációkészítésre az agilis alapelvek alapján?

De talán nem is lehetne ennél jobban félreértelmezni az agilis eszméket és alapelveket. Hiszen a fent idézett alapelv mellé általában elfelejtik hozzátenni azt az igen fontos kiegészítést, amit szintén megfogalmaztak az agilis kiáltvány szellemi atyjai, ami így hangzik: „…annak ellenére, hogy a jobb oldalon szereplő tételek is értékkel bírnak, mi többre tartjuk a bal oldalon feltüntetetteket”.

Tehát elismerik az átfogó dokumentáció értékét és hasznát, de a működő szoftvert többre értékelik. Továbbá a dokumentáltság ellenzői általában azokat az alapelveket is szeretik elhallgatni, amelyek úgy hangoznak, hogy:

• „A műszaki kiválóság és a jó terv folyamatos szem előtt tartása fokozza az agilitást.”
• „A legjobb architektúrák, követelmények és rendszertervek az önszerveződő csapatoktól származnak.”

Álljunk csak meg egy pillanatra! A „jó terv (…) fokozza az agilitást”?

Most akkor az önszerveződő agilis csapatoknak is kell követelményeket és rendszerterveket összeállítaniuk?

Nos a válasz erre a kérdésre egy határozott IGEN!

Sőt a tesztesetek, tesztjegyzőkönyvek, vagy adott esetben a szekvencia diagrammok és az architektúra tervek elkészítése is ugyanúgy részét kell, hogy képezze egy agilis fejlesztői csapat életének és mindennapjainak, mint ahogyan egy nem agilis csapat esetében.

Ahhoz, hogy egy adott üzleti funkció a megvalósítás szakaszában már tényleg olyan formát öltsön, mint amilyennek azt látni szeretnénk, ma már elengedhetetlen a megfelelő előkészítés. Gyakran előfordul, hogy egy adott üzleti funkció többféle módon is megvalósítható, akár ugyanabban a rendszerben eltérő megközelítéssel, vagy különböző architektúra elemekkel is.

Egy jól működő csapatnak az az érdeke, hogy ezek közül többet is felmérjen, az egyes opciókat megfelelően kielemezze és ezen ismeretek birtokában hozzon döntést a megvalósítás irányáról. Ez természetesen elképzelhetetlen megfelelő dokumentáltság hiányában. És nem csak azért, hogy a csapat által meghozott döntés és az ahhoz vezető út később is visszakereshető, és átlátható legyen, hanem azért is, hogy a fejlesztés minden szakaszában támogatni tudjuk a változás megfigyelését és a változó körülményekhez történő alkalmazkodást, amelyek a scrum módszertan legfontosabb alappillérei.

A megfelelő dokumentáció hatása a megrendelő és a szállító viszonyára

Ezen a ponton kanyarodjunk vissza egy kicsit ahhoz az alapdefinícióhoz, amiből a dokumentáltság ellenzői olyan határozottan levezették a saját érvrendszerüket: „Megtanultuk értékelni a működő szoftvert az átfogó dokumentációval szemben.”

Vajon mire gondolhattak ennek a megfogalmazásánál az „alapítók”, miért tartották fontosnak, hogy ez bekerüljön az agilis értékek közé?

Véleményem szerint azért, hogy ezzel is kiemeljék a megrendelő és szállító viszonyában azt az alapvető szemléletbeli változást, amit el akartak érni az agilis kiáltvány megfogalmazásával, mégpedig azt, hogy:

• Az üzleti igények meghatározása nem érhet véget akkor, amikor lezárul egy projekt előkészítő fázisa, és megszárad a tinta a felek közötti együttműködési megállapodáson.
• A változás érték és arra nyitottnak kell maradni egészen addig, amíg a végtermék élesítésre nem kerül.
• A projektek ne félbehagyva, összecsapva kerüljenek lezárásra pusztán azért, mert valamire nem gondoltak a felek hónapokkal, évekkel korábban, amikor egymás tenyerébe csaptak, és később már egyik fél sem volt nyitott a változásra.

Mert ez senkinek sem jó, sem a megrendelőnek, aki fizetett valamiért, amit nem úgy és nem arra tud használni, amire és ahogyan szeretne, sem a szállítónak, aki veszít a reputációjából és a motivációjából és egy olyan végterméket kell kiadnia a kezéből, amelyre valójában saját maga sem lehet büszke.

Mindezt azért, mert egyik fél sem volt hajlandó elfogadni, azt, hogy egyetlen állandó dolog van körülöttünk az életben, az pedig nem más, mint a folyamatos változás.

Mik a megfelelő dokumentáció ismérvei az agilis szoftverfejlesztés során?

Az a változás, ami minden esetben csak valamihez képest definiálható! Ez a valami nem más, mint maga a megfelelően és kellő mértékben elkészített dokumentáció. A lényeg ebben az esetben a megfelelőség és a kellő mérték. Ugyanis a fejlesztési dokumentáció elkészítése során az elsődleges szempont, mindig a csapat számára történő felhasználhatóság, a második pedig a csapat transzparens működésének a biztosítása. De mit is jelent ez pontosan?

Vegyünk egy konkrét példát. A hagyományos megközelítés szerint az IT tervezés, majd a fejlesztés megkezdésének előfeltétele a minél részletesebben kidolgozott üzleti specifikáció elkészítése. Minden, ami nem szerepel ebben a dokumentumban, az nem lesz része a projekt scope-jának.

Ez a dokumentum lesz a fejlesztési projekt, alfája és omegája, bármilyen olyan kérdésben, ami a projekt tervezési, vagy megvalósítási szakaszában a későbbiekben felmerül, ehhez nyúlnak majd vissza a felek, és ez alapján fogják majd eldönteni az újra és újra felmerülő kérdést „bugfix vagy change request”.

Az ilyen megközelítés mentén készülő dokumentumok pedig az alábbi hibajegyeket hordozzák magukon:

• Túl terjedelmesek, igyekeznek minden részletre kiterjedni és jellemzően sokkal inkább fókuszálnak a „hogyan”-ra, mint a „mit”-re, a „kinek”-re és a „miért”-re.
• Általában túl sokáig készülnek, túl sok iterációs körön mennek végig és gyakran előfordul, hogy már akkorra okafogyottá és elavulttá válnak, amire véglegesítésre kerülnek.
• Túl sok kötöttséget tartalmaznak, így nem adnak megfelelő teret a kreativitásra a tervezési és a megvalósítási szakaszban. Azaz hiába merülne fel egy jobb, hatékonyabb, modernebb megvalósítási javaslat az IT tervező, vagy a fejlesztő részéről, azok nem kerülnek, vagy nem kerülhetnek megvalósításra, hiszen „nem azt tartalmazza az üzleti igény”.

Ezzel ellentétben az agilis megközelítés szerint, az üzleti igénnyel, azaz a user story-val szemben támasztott minimális elvárás, hogy választ adjon arra a három alapvető kérdésre, hogy „mit”, „kinek” és „milyen célból”.

Ebben az esetben pedig a cél nem a szállító és a megrendelő közötti jogi és strukturális viszony definiálása és körbebástyázása, hanem sokkal inkább egy olyan alapkövetelmény megfogalmazása, amely a végfelhasználóra fókuszál. Nem kell, hogy tökéletes és teljes körű legyen, nem kell, hogy minden lehetséges szcenáriót rögzítsen, bőven elegendő, ha az alapokat leírja, hiszen a többit majd maga az agilis csapat teszi hozzá a tervezések, a refinementek, a fejlesztés és a tesztelés során.

Ez a megközelítés pedig azért nagyszerű, mert az így elkészült dokumentáció nem gátja a kreativitásnak és a folyamatos fejlődésnek, hanem támogatja azt. Nem öncélúan készül, hanem organikusan leköveti egy üzleti igény, egy ötlet megvalósítását annak felmerülésétől egészen a használatba vételig.

Összefoglalás

Meglátásunk szerint tehát az agilis módszertan nem a dokumentáció teljes mellőzését jelenti, hanem annak megfelelő mértékű és célzott elkészítését, amely támogatja a fejlesztési folyamatokat.

Az agilis alapelvek hangsúlyozzák, hogy bár a működő szoftver előbbre való, az átfogó dokumentáció is értéket képvisel és a jól elkészített dokumentáció elősegíti a fejlesztési folyamatok átláthatóságát, támogatja a változások nyomon követését és alkalmazását, és hozzájárul a csapat hatékony munkavégzéséhez.

A nagyvállalati környezetben különösen fontos a dokumentáció, mivel az IT architektúra összetettsége megköveteli a precíz előkészítést és a döntések dokumentálását.