A specifikációt azért szeretik a klasszikus menedzsment világban, mert elvileg minden egyes nüansznyi lépést és tennivalót előre leírunk benne. Szépen hierarchiába szedjük a tartalmat, és ezek után joggal azt gondoljuk róla, hogy ha egy fejlesztő megkapja, akkor nincs más dolga, mint lépésről lépésre végigmenni a specifikáción, és varázslat, kiesik belőle a csodálatos, hibátlan késztermék.
Ez gyártó közegben akár még igaz is lehet. Tudásalapú gazdaságban, szoftverfejlesztési közegben már semmiképp sem. Hiába a világautomata specifikáció, a szoftverfejlesztésben folyamatosan sok a bizonytalanság. Bármilyen fejlesztés folyamatában olyan új információk kerülnek rendszeresen a birtokunkba, melyek akár alapjaiban boríthatják az eredeti specifikációt.
A szoftverfejlesztés világában mind a technológiák, mind a nyelvek elképesztő sebességgel változnak és fejlődnek. Ugyanez a volatilitás igaz az üzleti igényekre is. Egy jól kigondolt működés vagy modell, két három hónap után, értelmét, vagy értékét veszítheti.
Ezért van az, hogy a specifikáció írás magában hordozza a felesleges munka veszélyét. Specifikáció vezérelt együttműködésben egyetlen érintett fél sem lelkesedik, hogy átvezessék egy vastag dokumentáción azokat az információkat és változásokat, amik óhatatlanul bekövetkeznek egy szoftverfejlesztési projekt időskálájában. Így mindenki ennek elkerülésében érdekelt, ami egészen biztos, hogy nem a szoros, közös érdekeken nyugvó kooperáció irányába hat.
Akkor hát mikor érdemes specifikációt írni? Kis projektnél lehet kis specifikációt írni, ami kielégíti a kis igényeket.
De mit érdemes csinálni akkor a specifikáció helyett?
Kapcsolódó blogcikkünk lesz az Agile öt szintű tervezése, de most a válasszunk a Backlog.
Definíció
A Backlog mindig jól definiált fejlesztési egységekből áll, amik egymáshoz képest mindig priorizálva vannak.
A Backlog magas prioritású elemei folyamatosan finomító tervezési feladatokon mennek keresztül, míg a későbbi elemek nincsenek részletesen kifejtve mindaddig, amíg üzleti döntés nem születik arról, hogy ő lesz a következő, amit majd ki kell tenni a piacra.
Backlogot érdemes csinálni specifikáció helyet
A Backlog egy olyan speciális állatfaj, ami rendelkezik néhány fontos és egyedi tulajdonsággal. Ezek kötött jellemzők. Cserébe elképesztő mennyiségű rugalmasságot enged, szemben egy klasszikus specifikációval, ahol mind a két fél érdeke a rugalmatlan végrehajtás. Tipikus specifikáció vezérelt párbeszéd:
– “Én pontosan megterveztem!”
– “Én meg nem vagyok hajlandó semmi mást kifizetni!”
– “Ez soha nem volt része!”
-”Szerintem meg alapértelmezett, és teljesen egyértelmű, hogy bele kell érteni!”
A Backlog megengedő rugalmassága tehermentesíti a megrendelőt és a szolgáltató felet attól, hogy egymás torkán próbáljanak meg lenyomni különböző, ellentmondó érdekeket.
Hogyan éri el ezt a rugalmasságot?
A Backlognak a legkisebb értelmezhető egysége az úgynevezett User Story. A User Story is követ néhány alapvető műfaji szabályt (erről majd szintén egy későbbi bejegyzésben), és ha ezeket a műfaji szabályokat betartva írjuk meg a User Story-kat, akkor a Backlog képes lesz arra, hogy olyan szinten kösse össze a fejlesztést és az üzletet, mint ahogy más dokumentáció soha.
A User Story a végfelhasználók szemével ír le valamilyen funkciót, és e szerint fogják a fejlesztők becsülhető, jól definiált feladatokra szétbontani.
Amíg a User Story az a legkisebb üzletileg értelmezhető egység, ami úgy fejti ki a szoftver működését, hogy az még mindenki számára értelmezhető, addig a fejlesztői subtaskok már nem tartoznak ide.
A User Story-k mögé megírt fejlesztői subtaskok összessége gyakorlatilag lefedi egy kiváló specifikációval szemben megfogalmazott igényeinket. Sőt még annál sokkal messzebb megy, mert általános megkötéseket és minőségbiztosítási elemeket is tartalmaz User Story-nként, szemben a specifikációval, ahol ezeket nagyon nehéz betartani és követni.
Gyakorlatilag onnantól kezdve, hogy van néhány User Story, a fejlesztők el tudnak kezdeni dolgozni. Különösen, ha a User Story-kat valamilyen szempont szerint már priorizáltuk.
A fontosság és a prioritás mindig megállapítható két item között. Megértem azt, minden fontos, és mindent meg kell csinálni, de mindig vannak fontosabbak, és vannak olyanok, amiket előbb kell megcsinálni, mint minden mást.
Tehát a Backlog legfontosabb ismertetőjele, hogy priorizált User Story-kból áll.
Elismerem azt is, hogy nem minden körülmények között érdemes User Story-t írni. Vannak pl. nettó technikai feladatok, amelyeket nem lehet egy végfelhasználói folyamathoz hozzákötni. Külön Backlog itemként fogjuk őket definiálni, és priorizálni.
A Backlog priorizálását nem érinti, hogy épp egy User Story-ról, vagy egyéb backlog itemről van szó. A lényeg, hogy minden érintett minden körülmények között tisztában legyen azzal, épp min kell dolgozni, mi lesz a következő feladat, és mi az, amit még nem szabad elkezdeni.
Erre csak a Backlog képes, ha betartjuk a szabályait.
Mit ad nekünk a Backlog?
A Backlog prioritásainak betartásának egyik ajándéka, hogy a fejlesztők nem fognak meglepetéseket okozni a menedzsmentnek. Mindig tudni fogja a menedzsment,hogy mit csinálnak, miért csinálják, és a fejlesztők sem fognak eltévedni.
Itt ismét fel kell hívjam a figyelmet: a Backlog feltöltése nem önkényes tevékenység. Az Agile öt szintű tervezésének minden egyes elemét szigorúan be kell tartani, különben káoszba zuhannak a törekvéseink.
Ha készen vannak a Backlog itemjeink, és azokat valamilyen szempontrendszer szerint priorizáltam, akkor már csak annyi a dolgunk, hogy a fejlesztők a subtaskokat a prioritásoknak megfelelően sorrendben írják meg… és teljesítsék.
A subtaskok becsléseit mindig a szerződés szerinti elszámolási mértékegységben kell megadni!
A Jós
A folyamatos priorizálás mellett biztosítani kell azt is, hogy a becsléseink kellően jól előre vetíthetőek legyenek. Ellentmondásos igénynek tűnik, hiszen nem tudjuk minden egyes Backlog item, minden egyes lépését előre letervezni. A legtöbbje valójában még ki sincs igazán fejtve.
Mégis, jogos igény, hogy valamilyen becsléssel elő tudjunk hozakodni.
A válasz, a Backlog relatív becsülhetőségének a trükkjében rejlik.
A Backlog abban is rengeteget segít, hogy extrapolálni tudjuk a még meg nem tervezett itemek várható teljesítési idejét és erőforrás szükségletét is.
Némi rutinnal olyan backlog itemeket tudunk írni, amelyek komplexitása egymáshoz viszonyítva megállapítható. Egy önkényesen kiválasztott, alapnak tekintett Backlog itemhez képest az összes többit meg tudom ítélni, hogy kb. akkorák, kétszer akkorák, feleakkorák stb.
Nem egy lézerpontos becslés, de ez nem is cél. A cél az, hogy a Backlog itemek olcsó és nagyon gyors vizsgálatával, pillanatokon belül kiderüljön ha valamilyen cél egyértelműen meg tud lenni, vagy már messziről látszik, hogy baj lesz.
A két nyilvánvaló eseten kívüli állapotokat további tervezés során tudjuk pontosítani.
A relatív becslés segítségével a menedzsment anélkül tud tájékozódni a Backlog állapotáról, és a priorizált elemek várható érkezéséről, hogy értelmetlen erőfeszítéseket kellene fektetni olyan tervezésekbe, aminek a jelentős része valószínűleg a kukában fog landolni (változik a üzleti környezet, a technológiai szabályok és előírások, a felhasználói vagy megrendelői igények).
A Backlogot felügyelő és kezelő kollégáknak folyamatosan munkát ad az, hogy iterációról iterációra újra és újra végig kell menni az új információk birtokában a Backlog még hátralevő elemein, ellenőrzik, ha kell, alakítják a prioritásokat, és folyamatosan pontosítják a becsléseket a várható szállítási időpontra, és/vagy erőforrás igényre vonatkoztatva.
Egy jól működő Agilis projektben a tervezésre elköltött idő az elmúlt 10 év mérései és személyes tapasztalataim alapján a 25-45% között mozog.
A Backlog lehetővé teszi:
-
- a módszertan által megkövetelt öt szintű tervezést
- az öt szintnek megfelelő kimeneti elemek előre meghatározott szemlélet szerinti darabolását
- lehetővé teszi (sőt megköveteli) a folyamatos priorizálást
- a folyamatos priorizáláson keresztül a rugalmas és gyors reagálást a piaci és/vagy technológiai környezet változásaira
- a “go” vagy “no go” döntési helyzetek felismerését és objektív indoklását
Az agilis módszertani átállás során a szervezetek egységnyi időre vetített termelő képessége átlagosan 150-300%-kal nőtt. A HVG Akadémia, Agile Recruiter sorozatának módszertani vezetője.