Először is nézzük meg, mi is a szoftverspecifikáció és mit kell tartalmazzon. A szoftverspecifikáció az összes olyan szükséges információ gyűjteménye, amely a megfelelő szoftver kivitelezését biztosítja. Több dokumentumból áll.

A szoftverkövetelmények leírják a projekt hátterét, üzleti céljait és korlátait. Ezt általában az ügyfél hozza létre, esetleg a szoftvertanácsadóval vagy UX tanácsadóval együtt.

Képzeld el a házépítés folyamatát! Először leírod az elképzeléseidet, hány szobát és milyen jellemzőket szeretnél. Ezek a célok. A telek sajátosságai és az építési törvények a korlátaid.

A tervezési dokumentum olyan műszaki dokumentum, amely pontos megoldást nyújt a követelményekben leírt célokra. Ez magában foglalja az adatok tervezését, az architektúra tervezését, drótvázakat és prototípusokat.

Gondolj erre úgy, mint a tényleges ház terveire: alaprajzok, építési tervek, statikai tervek, metszetek, anyagok, villamos- és gépészeti tervek, és így tovább.

A tesztdokumentáció szintén része a specifikációnak. Ez a dokumentum leírja, hogyan, hol és mikor kell a szoftvert tesztelni, beleértve a teszteseteket és a kapcsolódó kockázatokat.

Ezek lehetnek a házadnak a minőségi előírásai és az ellenőrző dokumentumok, amelyek biztosítják a ház megfelelő működését jelenleg és a belátható jövőben.

Végül, de nem utolsósorban a felhasználói dokumentáció. Ezek a fejlesztés után íródnak, de a specifikációk részének is tekinthetők. A felhasználói dokumentáció egyszerűen leírja, hogyan kell használni a szoftvert.

De mi agilisek vagyunk, nem írunk specifikációt!

A vízesés és a V-modellek esetében egy szoftver minőségi és időben történő szállításának biztosítása érdekében ki kellett dolgozni a szoftverspecifikációt a legutolsó részletig. De a szoftver minden specifikációelemének részletezése sok időt vesz igénybe és költséges.

Ugyanakkor irreális, mert a felhasználók ritkán képesek részletezni minden olyan funkcionalitást, amelyet a végtermékben szeretnének látni, így a projekt hatásköre (scope) számtalanszor változik.

De mi van, ha agilis módszertant használunk projektjeink során? Sokan úgy gondolják, hogy az agilis csapatok specifikáció nélkül dolgoznak. Ez nem teljesen igaz. Egy agilis projektnek szintén szerkezetre van szüksége, hogy a csapat ne hozzon kritikus döntéseket támogatás nélkül. Ezt a struktúrát az ú.n. felhasználói történetek (user story) adják, melyek a rendszer egy vagy több jellemzőjének természetes nyelvű leírásai a végfelhasználó szemszögéből.

Az agilis módszer azon elv köré épül, hogy a projekt hatásköre változhat és változnia kell a projekt során. Minden felhasználói történetet a projekt elején egy backlogba helyezünk, de nem részletezzük őket. Ehelyett ezek majd a fejlesztési folyamat során körvonalazódnak pontosabban.

Az agilis folyamat

Az agilis csapatok rövid (1 vagy 2 hetes) iterációval dolgoznak, ú.n. sprintekkel. Minden egyes sprint elején kis számú felhasználói történetet választanak ki a backlogból (általában azokat, amelyek a legtöbb üzleti értéket jelentik), és részletezik ezeket.

A hagyományos módszerekkel ellentétben a részletek kidolgozásának felelősségét az ügyfél (a product owner vagy terméktulajdonos által) és a fejlesztőcsapat osztja meg. Ahhoz, hogy ez működni tudjon, fontos hogy minden résztvevő azonos megértést és empátiát tanúsítson a végfelhasználóval szemben. Ennek a közös megértésnek köszönhetően a terméktulajdonos a magas szintű követelményekre és az üzleti célokra koncentrálhat, minden fejlesztési részletetet a fejlesztőcsapatra hagyva.

A sprintekre felosztott fejlesztés egyik előnye, hogy a sprint végén az ügyfél egy ténylegesen működő szoftverre adhat visszajelzést, nemcsak egy specifikációra. Ezáltal korán kiderül, hogy a termék megfelel-e az ügyfél várakozásainak, anélkül, hogy várni kellene (akár hónapokat is), ameddig a teljes szoftverfejlesztés lezárul. Ha ebben a pontban az ügyfél megváltoztatja a kéréseket, akkor új felhasználói történeteket vezetnek be a backlogba és ezeket betervezik egy következő sprintbe.

Az agilis módszer rugalmassága lehetővé teszi a projekt hatáskörének a megváltoztatását a fejlesztés során, a hagyományos módszerekkel ellentétben, ahol mindez csak a fejlesztés végén történhet, gyakran több hónapos munka lenullázásával vagy megismétlésével. Ez természetesen magas költségekkel, a határidők elmulasztásával és nem utolsósorban a motiváció csökkenésével jár minden érintett számára.

Hogy csináljuk mi mindezt?

Lássuk, mi hogyan dolgozunk a Furthernél. Kétféle ügyfelünk van. Azok, akiknek már megvannak a szoftverkövetelményei, és azok, akiknek csak egy rövid projektvázlata van, vagy csak egy ötletük. Általában egyik sincs a végfelhasználó szemszögéből leírva.

Tehát az első dolog, amit csinálunk, az az, hogy leülünk az ügyfél terméktulajdonosával, és létrehozzuk az összes olyan felhasználói történetet, amellyel találkozhatunk. Ezután kategorizáljuk őket „kötelező" és „jó, ha van" osztályokba. Ezen backlog alapján csapatunk nagyjából felbecsülheti a költségeket és a határidőket.

Egy extra dolog, amit néha a projekt elindítása előtt elvégzünk, hogy létrehozunk egy pár drótvázat az összetettebb interfészekhez. Ez ellentmondásos az agilis gyakorlatokkal, mert a fejlesztés előtt részletes specifikációt hozunk létre, de úgy tapasztaltuk, hogy segít csapatunknak a jobb becslések elkészítésében.

Egy érdekes dolog, amit bevezettünk, hogy nálunk gyakran átfedés van a tervezési sprintek és a fejlesztési sprintek között. Egy tervezési sprinttel kezdünk, amelyben elkészítjük a kiválasztott felhasználói történetekre vonatkozó tényleges specifikációkat (tervdokumentumok, tesztesetek, kockázati mátrixok és drótvázak vagy prototípusok).

A sprint végén bemutatjuk ezeket az ügyfélnek, és jóváhagyás után elindítjuk a fejlesztési sprintet, vagyis a kód megírását. Ezzel párhuzamosan már elkezdjük a következő fázis tervezési sprintjét. Mivel a fejlesztők már rendelkeznek a tervezőcsapat által kidolgozott dokumentációval, ez a módszer lényegesen felgyorsítja a dolgokat, ha megfelelő erőforrásokkal rendelkezünk.

Cikkünk végére értünk. Mindig kíváncsiak vagyunk arra, hogyan dolgoznak mások, ezért ha meg szeretnéd ezt osztani velünk, vagy elképzelésed van arról, hogyan javíthatnánk a munkafolyamatunkon, akkor lépj kapcsolatba velünk.