Plánovanie

Sú situácie, kedy (snaha o) detailné plánovanie v rámci softvérového vývoja má zmysel. Nenaplánovať si napríklad kroky pre migráciu, ich logickú nadväznosť, teda nemať plán pre takúto činnosť, nie je vôbec dobrý nápad.

Úlohy, v rámci softvérových projektov možno rozdeliť do dvoch skupín:

• tie ktoré si viem predstaviť (že bude treba urobiť) - imagined tasks - čím viac skúsenosti máš, tým lepšie si vieš "predstavovať"
• tie ktoré objavím počas realizácie - discovered tasks - v komplikovaných alebo komplexných systémoch si môžeš predstavovať koľko chceš, nedáš to na 100%. Hlavne, vždy Ťa tlačí čas. Nemôžeš sa pripravovať, plánovať, donekonečna.

Je omnoho menej stresujúce, ak viem, že migrácia, ktorá má prebehnúť v stanovenom časovom rámci, postupuje podľa plánu, a keď aj objavím (discover) počas jazdy novú úlohu, tak sa mi sa lepšie dáva do kontrastu s niečím fixovaným (mojím migračným plánom).

Myslieť si však, že v úvodnej fáze projektu (v rámci PRINCE2 iniciačná fáza) superhrdina projektový manažér spolu s tímom zorchestrujú dokonalú WBS-ku je z mojich skúseností nemožné. Takáto WBS-ka automaticky trpí tým, že do nej je pridaná vata, keby sa náhodou niečo nestíhalo, alebo sme na nejaké úlohy zabudli (cost of delay v priamom prenose).

Identifikácia klúčových úloh

Ako večný optimistia, si samozrejme na začiatku projektu myslím, že sa všetko podarí. Ale CEO nezabudne položiť obľúbenú otázku: A kedy to bude?

Používam tieto aktivity, aby som sa dostal k roadmape, ktorá reprezentuje špecifický druh plánu:
1) identifikovať základné okruhy funkcionalít (epics)
2) identifikovať role (aj robotov), ktoré s budúcim softvérovým riešením budú interagovať
3) rozbiť na základné okruhy funkcionality do user stories
4) identifikovať integračné závislosti

Postup v týchto aktivitách nie je výsostne chronologický. Človek preskakuje z jednej aktivity na inú, dopĺňa a modifikuje jednotlivé artefakty (epics, user stories, roles, integrations).

Eposy sú niekedy výsledkom syntézy. Reflektujúc cieľ projektu, už realizačnému tímu začnú preblikovať možné spôsoby riešenia. Potrebujeme manažment objednávok, potrebujeme vystavené faktúry automaticky zaúčtovať, ...  Eposy majú za úlohu dať do spoločných mantinelov konkrétne funkcionality definované pomocou user stories. Niekedy dostaneme epos rovno na stôl. Zadávateľ (zvyčajne CEO) príbehne rovno s návrhom na riešenie (potrebujem aplikáciu na manažovanie dodávateľov), čo je samo o sebe epos. Netreba však hneď skočiť na analýzu a rozbitie na user stories, kým sa kriticky nepozriem na to, prečo. Ono, väčšina CEO má samozrejme pádne a zmysluplné dôvody, ktoré nechcem principiálne spochybňovať. Ale CEO v snahe byť super efektívny, nechcú zdržovať detailami, a dôvodmi. Tie sú však perfektným referenčným bodom počas celého snaženia identifikácie spôsobu riešenia. Približuje nás to, čo sme navrhli, k odstráneniu problému, ktorý má CEO?

Takmer žiaden systém (aplikácia) neexistuje vo vákuu, je závislý na informáciach (dátach) z iných systémov, alebo má informácie iným systémom poskytovať, takže treba jednoduchým spôsobom (diagram s krabičkami a šípkami) zdokumentovať očakávané dátové toky. Obdĺžnik - predstavuje izolovanú aplikáciu, a šípky - predstavujú dátový tok/výmenu.

Prioritizácia

Ak už som v štádiu, že môj zoznam user stories, identifikovaných rolí a predpokladaných integrácii, je ako tak stabilizovaný, môžem pristúpiť k dvom aktivitám:
1) identifikácia kľúčových funkcionalít (čo)
úprimne si odpovedať, či je fakt nevyhnutné tú ktorú user story implementovať, aby celé riešenie zafungovalo. Ja zvyknem používať prioritizovanie pomocou číslovania (1 - musí byť, 5 - nice to have), v praxi sa často používa aj MoSCoW - Must, Should, Could, Would. Ak sa prichytíš, že nejaká funkcionalita je mixom Must/*, tak sa nebráň rozbiť user story tak, že obsahuje iba nevyhnutne minimum (Must) a ostatné (Should/Could/Would) sa dostane do samostatnej story s nižšou prioritou.
2) časové zarámcovanie (kedy)
Ak zoberiem všetky Must funkcionality, tak viem, čo nevyhnutne musím urobiť, aby riešenie začalo prinášať hodnotu. Ak si počul skratku MVP, minimum viable product, tak sumár Must funkcionalít je práve jeho stelesnením.

Odhadovanie

O odhadovaní (čo je predispozícia pre plánovanie) softvérových projektov bol napísaný nespočet kníh, blogov a alchymistických príručiek. Ja sa držím dvoch prístupov, ich kombinácie:

• "expertný" odhad
• time box

Nechcem byť úplne vo vzduchoprázdne, a ani nahrubo nemať šajn, koľko niečo môže trvať. Je lepšie mať aspoň niečo ako nič, a tak si môžem expertný odhad stanoviť: jedna user story bude trvať programátorovi dva dni (prvý deň kým ju pochopí, premyslí, druhý kým ju dotiahne). Ak si chceš preštudovať ako k odhadovaniu pristupuje agilný svet, tak neváhaj a daj do google výrazy ako: story points, t-shirt size, velocity, planning poker...

Moja rada vyššie je v rámci prvých nesmelých pokusov o odhad "len" hypotéza. Psst, odhad je vždy len hypotéza. Ak si v informačnej nevýhode, respektívne nemáš chuť robiť rozborku toho, ako dlho by sa mal implementovať jednoduchý formulár v REACTe, je vo všeobecnosti lepšie použiť timebox.

"Expertný" odhad urobí vývojar (dodávateľ), ty definuješ mantinel: čo mi viete realizovať za timebox (napríklad prvú iteráciu, či už bude 2 týždňová, alebo dlhšia)?

Ak niekomu nastavíš mantinel, začne aplikovať prioritizáciu, a zároveň táto dynamika podporuje hľadanie alternatív (áno, aj workaroundov), resp. človek získava spätnú väzbu v zmysle, že " toto nie je možné urobiť" (v danom čase).

Ak idem do Tesca kúpiť rožok, tak viem, čo za tých 10 centov dostanem.
Jasné, že softvérové riešenia, nie sú rohlíky, ale ak sa softvérová firma špecializuje (robí napríklad výhradne PrestaShop eshopy), tak sa ich proces výroby eshopového riešenia a manažment potrieb zákazníka začína približovať výrobe rohlíka. Preto generické softvérové domy majú v mojej optike nevýhodu voči tým, ktoré sa špecializujú. Špecialisti sa vedia zaviazať k tomu, že očakávaný výsledok dodajú aj v kratšom čase, keďže je to ich denný chleba. Ja potom ako zákazník zase nemôžem slepo žiadať od nich cenu referovať na time&material. Oni mi nepredávajú len svoj čas, oni mi predávajú aj skúsenosti, ktoré rokmi nadobudli.

Ako platiaci zákazník, ktorý obstaráva riešenie dodávateľsky, je mi v princípe jedno ako si dodávateľ vypočíta náklady (na scope). Mňa zaujíma viac hodnota, prínos, ktorá mi bude dodaná. Ak si začnem hovoriť, že peniaze, ktoré som nalial do riešenia sa mi prestali zhodnocovať, je to začiatok konca vzťahu s dodávateľom, ak nepríde k zmene. To je memento k tomu, že riešenia (dodávky) majú slúžiť, nie byť slepo realizované.

Roadmapa

To k čomu sa ja snažím dopracovať teda nie je dokonalý plán na dni. Snažím sa dopracovať k roadmape, ktorej časová granularita je maximálne v týždňoch, zvyčajne v mesiacoch, na ktorej sú zachytené eposy (s logickou následnosťou).

Roadmapa nie je vytesaná do kameňa, práveže ju potrebujem aktualizovať reflektujúc to, čo sa už udialo. Agilný prístup je práve o tom, že reflektujem, to čo sa udialo a na základe toho mením smerovanie, priority.