Avagy a terv szükséges, de hibás, ha kőbe véssük azt.
Az előző cikkünkben arról írtunk, hogy a terv semmi, a tervezés minden. Viszont nyilvánvalóan terv nélkül nem lehet projektet kezdeni, hiszen építkezni sem úgy kezdünk, hogy elkezdjük a téglákat egymásra pakolni, és előbb utóbb majd kisül belőle valami… ez egy szoftverfejlesztési projekt esetében sincs máshogy.
Azt, hogy hova szeretnénk eljutni, és milyen módon tesszük azt, igenis fontos végig gondolni és rögzíteni a projekt elején. De nagy különbség van abban, hogy ezt úgy tesszük, hogy hónapokkal (vagy akár évekkel) előre kőbe véssük azt a tervet, vagy arra egy iránymutatásként tekintünk a fejlesztés során.
Persze ahhoz, hogy egy tervre iránymutatásként tekintsünk, és ne egy szerződés olyan mellékleteként, amit mindenképpen teljesíteni kell a projekt során, ahhoz elengedhetetlen a partnerek közötti bizalom, szoros együttműködés, és mindkét fél elhivatottsága az értékteremtés mellett. Mutatom, hogy mi hogyan csináljuk a Nitrowise-ban.
A cikk olvasásához néhány kiegészítő információ
(1) A cikk feladata nem az, hogy bemutassa az egyes technikákat, arról, hogy hogyan történnek az egyes lépések, hanem az általunk követett tervezés, együttműködési folyamatot hivatott bemutatni. Minden itt található részegységnek külön cikket szentelünk a későbbiekben. Kövess minket a LinkedIn-en, vagy Facebook-on és értesülj ezekről elsőkézből.
(2) Ki a cikkben hivatkozott Veled? Mindig az, akire ügyfél oldalról szükség van az adott lépésnél. Nem mindig egy személy, viszont így egyszerűbb volt megfogalmazni. A célokat általában a megrendelő oldali cégvezetőkkel együtt szoktuk kitűzni, majd a tervezés további részében, aki éppen az adott részhez relevánsan tud hozzátenni, legyen az a termékmenedzser, projektmenedzser, vagy akár csak valaki aki témában szakértő és információval tud szolgáltatni.A tervezés lépései
Célkitűzés – Vision
A tervezést azzal kezdjük, hogy Veled (az ügyféllel) együtt kitűzzük a célt, amit mindenképpen meg kívánunk valósítani. Ez a cél lesz az, amire aztán a későbbiek során folyamatosan vissza tudunk csatolni, hogy az éppen felvett feladat a kitűzött célhoz ad-e értéket.
Például az egyik projektünkben
egy olyan szoftver fejlesztése a cél, mellyel a felhasználók informatikai hozzáértés nélkül tudnak e-learning tananyagokat készíteni. Aki tud Word vagy Powerpoint prezentációt készíteni, az ezt a szoftvert is képes lesz használni.
A cél világos, így amikor a következő feladatot kellett volna megvalósítani: „a felhasználók módosíthatnak az alapértelmezett css property-ken”, akkor rá tudtunk világítani, hogy:
biztosan ez az a feladat, ami a kitűzött célhoz hozzáad?
Hiszen az átlagfelhasználók általában azt se tudják, eszik vagy isszák a css-t. Végül közösen arra jutottunk az ügyféllel, hogy ezt a feladatot a backlogba se vesszük fel. Találtunk helyette egy olyan megoldást (tananyag témák bevezetése), amivel az eredeti igényt a projekt kitűött céljának megfelelően valósíthattuk meg.
Persze a kitűzött cél is változhat a projekt folyamán, de fontos, hogy mindig, mint egy világítótorony, mutassa nekünk az utat, hogy merre kell tartanunk. Ha ez nincs, akkor az egész projekt egy vakrepülés.
Teendők listája – Epic list
Ha a célunk világos, akkor el tudjuk kezdeni lebontani nagyobb léptékű feladatokra. Ez gyakorlatilag egy mesterlista arról, hogy mi az, amit mindenképp meg akarunk csinálni. Ezek még csak nagyobb gyűjtők, mint például:
- Felhasználókezelés: a tananyagszerkesztő felület csak bejelentkezést követően érhető el, ezért tudni kell a felhasználókat kezelni.
- Tananyag létrehozás: a rendszeren belül több tananyagot kezelünk, így tudni kell ezeket listázni, keresni, csoportokba rendezni
- Tananyagstruktúrát létrehozni: egy tananyagon belül található fejezetek, leckék és szakaszok. Ezekre kerülhetnek a tartalmak.
- …..
Ha ezeket a teendőket közösen átvettük, akkor már nekünk is lesz egy képünk arról, hogy a tervezett szoftver pontosan mit is csinál. Ezeket Veled együtt priorizáljuk és már ezen a ponton meg tudjuk neked mondani, hogy szerintünk egyes részek mennyire komplexek, milyen összetételű csapat nagyjából mennyi idő alatt tudja ezeket megvalósítani.
Fontos azonban, hogy ez egy olyan becslés (és nem ígéret), ami erősen nagyságrendi, és a későbbi lépésekben egyre jobban pontosításra kerül. Viszont elég sok tapasztalatunk van abban, hogy egy-egy funkcióhalom megvalósítása pár nap, pár hét, vagy pár hónap nagyságrendű. Ennek előnye, hogy már a tervezés ezen szakaszában látszik, hogy mekkora realitása van a projekt tervezett büdzséjének és az elképzelt terveknek. Ezen becslések alapján pedig már te is el tudod dönteni, hogy érdemes-e folytatni a tervezést.
Feladatok – User story
Miután a teendők listájával készen vagyunk, az abban szereplő tételeket le lehet bontani részletes feladatokra. Ezt user story formátumban tesszük. Itt már megjelennek az egyes konkrét feladatok:
A tanulástervezőnek tudnia kell képeket elhelyezni a tananyagban, hogy azt illusztrációkkal színesebbé tegye, ezáltal a tanulókban az adott tanulási egység jobban felidézhetővé válik.
Ahogy látszik, itt sem írunk le minden konkrétumot. Nem határozzuk meg előre például, hogy milyen formátumú képeket kell kezelni, vagy mekkora lehet a maximális feltöltött fájlméret (ezek későbbi lépésben elfogadási kritériumokként jelennek majd meg). Viszont beszélgetünk a feladatról Veled, kialakul egy közös elképzelés, megértjük azt is, hogy az adott feladat elvégzése miért fontos.
Az egyes feladatokat vizuálisan is ábrázoljuk egy story map-en, mely a release tervezést is segíti.
Ha úgy gondoljuk, hogy lefedtük a szoftver elvárt működését, és elvégeztük a becsléseket (minden user story mellé teszünk egy napban megadott nagyságrendi becslést), akkor következik egy ellenőrzés, hogy az előző kör nagyságrendi becsléseivel mennyire stimmel a már lebontott részletesebb terv. Ha jelentős eltérés van akár pozitív – akár negatív irányba az egyes listáknál, akkor azt külön megvitatjuk Veled.
Megvalósítási terv – Iterációk
A tervezés eredményeként a munkát iterációkra – egy-két hetes időszak – bontjuk, ezeket Sprinteknek hívjuk. Ezekben a sprintekben fogja a csapat a meghatározott user storykat működő és tesztelt szoftverré alakítani.
Így nem csak azt fogjuk látni a tervezés végére, hogy mennyibe kerül a szoftver, hanem azt is, hogy várhatóan mikor fogunk végezni.
Ez tényleg ilyen egyszerű?
Sajnos nem. A fenti működés ideális eseteket ír le, azt mondanám, hogy így szeretnénk működni. De általában küzdeni kell azért, hogy ez így megvalósuljon, és ebben nekünk, azaz a szállítónak is nagy felelőssége van. Röviden összeszedtük azokat a problémákat, amik általában elő szoktak fordulni, amikkel általában küzdünk egy ilyen tervezés során.
1. probléma
Általában a tervezés során túl sok tennivalóval szembesülünk, és az ügyfél arra törekszik, hogy a lehető legtöbb feladat megvalósításra kerüljön az egyes iterációkban.
Az előzetes projekt tervezésen egy dedikált Product Owner és Vezető fejlesztő gondoskodik arról, hogy csak olyan vállalást fogadjunk be szállító oldalon, amit megfelelő minőségben (értsd: elfogadási követelményeknek megfelelően, demózhatóan, KÉSZEN) el is tudunk készíteni a megadott kereteknek megfelelően a projekt végére.
A nap végén mindenki jobban jár, ha nem ígérünk olyat, amit nem tartunk reálisan megvalósíthatónak.
2. probléma
Folyamatosan változik a terv, más lesz fontosabb. Valami nem kell, helyette mást kellene tenni, a tervezés egy részén rájövünk, hogy amit az elején mondtunk az mégsem úgy van…
Nálunk ez nem probléma. Ez adja az agilitás savát borsát. Ha változik a környezet és az igények, akkor adaptívan alkalmazkodunk mi is. Ilyen esetekben frissítjük a tervet, a storymap-et, a roadmap-et, és kalkulációt készítünk a megváltozott igényekre. Azért jó, hogy nem többszáz oldalas dokumentációt készítünk, mivel az általunk használt tervek formátuma alkalmas arra, hogy dinamikusan változtassunk rajta.
Ez igaz a tervezésre is, és már a fejlesztésre is. Fontos, hogy mindkét fél úgy tekintsen a tervezés eredményére, mint egy terv, aminek a kivitelezésére törekszünk, de bármikor bekövetkezhet változás, ami indokolttá teszi, hogy mi is módosítsunk a terven.
3. probléma
Alábecsültük egy feladat komplexitását a tervezés során.
Ez már nem szorosan a tervezéshez kapcsolódik, ez a kivitelezés során szokott kiderülni. Szerencsés esetben a sprint indítása előtt a tervezésen, rosszabb esetben a sprint közben jövünk rá, hogy valamit nem vettünk számításba. Hazudnánk, ha azt mondanánk ez velünk nem történik meg. Ez alapvetően az iparág sajátossága és sajnos előfordul.
Viszont több dolgot is teszünk, hogy az ezzel járó negatív érzéseket csökkentsük!
Az egyes sprintek előtt mindig a fejlesztő csapattal frissítjük a becsléseket, és ott a user storykban található feladatra (és elfogadási követelményekre) vállalást teszünk. Erre már nem mint becslés, hanem mint vállalás tekintünk. Azaz ezekért a Nitrowise Labs felelősséget vállal.
Az alul- és túlbecsléseink általában egy projekt során kiegyenlítik egymást, így végül mindkét fél szempontjából teljesül, amivel a projektindítás során számolt.
Zárógondolat
A Nitrowise Labs hitvallása, hogy a kezdetektől fogva nyíltan és őszintén működünk együtt partnereinkkel. Elmondjuk a dolgokat úgy, ahogy vannak, és nem úgy, ahogy hallani akarod. Minden információt megadunk, hogy megalapozott döntéseket hozz termékeddel kapcsolatos költségek, dátumok és terjedelem tekintetében. Ezt mindjárt a projekt elején, valamint végig a megvalósítás során is biztosítjuk neked.
Te ilyen beszállítóval dolgozol együtt szívesen vagy olyannal, aki azt mondja, amit hallani szeretnél? ? Ha az előbbi, akkor keress minket bizalommal a sales@nitrowise.com elérhetőségen, és beszélgessünk az együttműködés lehetőségeiről.
Mindeközben én projekt menedzserből szépen lassan Product Ownerré váltam és a „sikeres” projekt zárás helyett a partnerek elégedettsége, az üzleti érték maximalizálása lett az, ami a mindennapjaimat vezérli.