Riadenie softvérového projektu zákopovou metódou
Článok z blogchainu: zákopová metóda.
Čo je zákopová metóda?
Zákopová metóda popisuje referenčný spôsob ako riadiť softvérový projekt. Je to kompilát (vykrádačka) rôznych metodík a reálnych skúseností z bojového poľa. Nie je to kompletná teoretická metóda od A po Z ako PRINCE2, a jemu podobné. Zameriava sa primárne na dostatočnú (good enough) dokumentáciu biznisových požiadaviek, monitoring projektu a zdielanie kľúčových informácií o jeho stave.
Cieľom je odstrániť, minimalizovať problémy na komunikácii medzi zadávateľom (stakeholder, používatelia) a realizátorom (vývojar, SW štúdio) tak, aby výsledkom bol funkčný a prospešný softvér (procesy).
Ja som agilista, daj pokoj
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Zdroj: Agile manifesto (https://agilemanifesto.org/)
Vyslovím hypotézu, že zákopová metódá nie je v rozpore s agilným manifestom. Budem vdačný všetkým oponentom, ktorí mi budú dokazovať opak, a budeme diskutovať o potrebe/nepotrebe niektorých artefaktov.
Základný kameň
Gro metódy sa sústredí na identifikáciu, dizajn a dokumentáciu biznisových požiadaviek a ich postupné úspešné doručovanie. Ultimátnym cieľom je, aby spôsob v ktorom sú požiadavky zdokumentované bol jednotný a štruktúrovaný. Všetci účastníci projektu používajú a chápu jednotný zápis, spôsob dokumentácie požiadaviek, na to čo má softvér robiť, vo forme user story. A táto pravda sa náchadza práve na jednom mieste.
User stories sú evidované v štruktúrovanej forme, t.z. nie vo Worde. Pre možnosť jednoduchého adoptovania metódy partizánskym spôsobom ich evidujeme v tabuľke - zdieľateľnom Google Sheet, alebo Microsoft Excel-i. Samozrejme, nič nebráni tomu použiť nástroj na projektový manažment ako JIRA (v kombinácii z Confluence). A rovnako nič nebráni tomu, aby doplňujúca dokumentácia bola vo Wordoch, PDFkach, atp. Mäso požiadaviek je však vo forme user story a de facto následne tvorí aj dokumentáciu samotného softvérového riešenia (aj pre bežných používateľov).
Artefakty
Tak ako každá metodológia, ktorá to myslí vážne (PRINCE2), aj zákopová metóda má artefakty, ktoré plnia svoje špecifické úlohy. Opäť sa vo veľkej miere aplikuje na gro excelovský prístup, evidované sú vo forme tabuliek. Neplatí to samozrejme pre všetky, vždy je dobré si pripomenúť slogan: Jeden obrázok lepší ako tisíc slov. (roadmapa, diagram). Opätovne mi nedá nepripomenúť, že nástrojov na riadenie softvérových projektov, je ako húb po daždi.
Organizácia
- biznis case - "jedna" A4, prečo to robíme, aj čo nerobíme, aké sú ciele, časový rámec projektu, očakávaný rozpočet
- komunikačná matica - zoznam členov projektového tímu, stakeholderov a ostatných dôležitých osôb (funkcia, kontakty) - môžeme si to komplikovať napríklad formou RACI matice, ale maj na pamäti, že mať zoznam kontaktov na jednom mieste, dostupný všetkým relevatným, je dobrý nápad. A čím menej hodností máš na projekte, tým lepšie.
- roadmapa - eposy (prípadne iný kontext) zobrazené na časovej osy s indikáciou mílnikov
Špecifikácia dodávky
- architektúra/deployment - hi level diagramové zobrazenie ako projektom riešený/dotknutý systém (moduly, aplikácie) komunikuje s okolitým svetom (interfaces), resp. vo "vnútri". Špecifikácia toho na čom to bude bežať (HW požiadavky, cloud).
- role - špecifikujú skupiny užívateľov (v prípade komplexnejších projektov/aplikácií zasadené do kontextov)
- eposy - skupiny funkcionalít, ktoré zastrešujú user stories
- user stories - špecifikácia očakavaní (de facto budúca dokumentácia riešenia)
- datamap - definícia dátového modelu, ktorý definuje očakávania/limity, naprieč všetkými user stories
- nefunkčné požiadavky - požiadavky, ktoré priamo nedefinujú funkčnosť, ale ovplyvňujú riešenie (dostupnosť, rýchlosť)
Monitorovanie projektu
- riziká - zoznam rizík, ktoré sa podarilo identifikovať na začiatku, alebo v priebehu projektu
- issue list - zoznam úloh projektu, ktoré môžu skončiť vo výsledku ako user stories, ale vo fáze ich vzniku je efektívnejšie sa snahou o ich okamžitý prepis nesnažiť. Ide o identifikované chyby (bug), nápady (ideas), zmeny (change) a nová požiadavka (new feature)/vylepšenie (improvement)
- follow up - dohľad nad úlohami vyplývajúcich z kontextu riadenia projektu, QADI. (Q) otázky, ktoré majú byť zodpovedané, (A) úlohy, ktoré treba vykonať, (D) rozhodnutia, ktoré treba urobiť, (I) informácie, ktoré treba distribuovať.
- heartbeat - pravidelné kvantitatívne (monitorovanie projektu pohľadom čísiel - počet nových požiadaviek/úloh, priemerný život požiadavky) a kvalitatívne reporty (updaty zo strany projektového tímu)
- akceptácia/testovanie - testovacie scenáre (zadanie, behy, výsledky)
Referencie
- dokumentový koš - akýkoľvek dokument, ktorý sa týka projektu. Keď nemáš wiki (ala confluence), poslúži adresár na zdielanom disku, cloude (office 365, google drive, sharepoint, one drive, dropbox)
- slovníček - v duchu ubiquitous language snaha o špecifikáciu doménových termínov (v kontexte projektu), zjednotenie slovníka
Na pokračovanie
V ďalších príspevkoch bližšie rozoberám jednotlivé artefakty a dám do pozornosti postupy a odporúčania, ktoré majú za cieľ zlepšovať vzájomnú komunikáciu na projekte. Mojím cieľom je ukázať vlastnú kuchyňu, vďaka čomu môžeš ty reflektovať ako to robíš: lepšie/horšie/inak.