Absolútne zosúladenie účelu a dôvery je niečo čo vytvára veľkosť.

Jeff Sutherland

Scrum vo svojom základe predpisuje iba niekoľko základných artefaktov:

• produktový backlog,
• burndown graf
• a backlog sprintu.

Pre fungujúci produktový vývoj sú však potrebné aj ďalšie, ktoré pomôžu tímu sústrediť sa na hlavné ciele produktu.

V tejto kapitole uvádzame postupy a artefakty, ktoré prakticky aplikujeme počas agilného vývoja produktov, resp. v implementácii projektov. Niektoré z nich sú viac vhodné pre B2B produkty. Inšpirovali sme sa aj praktikami, ktoré nevznikli v agilnom svete, ale výrazne podporujú agilný vývoj.

Rámec agilného budovania produktu

V ScrumDesku sa venujeme budovaniu produktov od roku 2007. Počas tohto obdobia sme mali možnosť tvoriť nielen naše produkty a pomáhať klientom s budovaním ich vlastných produktov. Išlo o produkty určené pre segmenty B2C aj B2B.

Počas tohto obdobia sme spoznali rôzne hodnotné techniky, ktoré výrazne urýchlili vývoj produktu a zároveň umožnili ho budovať konzistentne, iteratívne a inkrementálne so zameraním sa na potreby a priority klienta.

Rámec agilného budovania produktu

Časti agilného rámca budovania produktu

• Spoznať – spoznanie prostredia klienta, jeho potrieb, práce, stakeholderov a používateľov produktu.

1. Value Proposition Canvas
2. Mapa zákazníkov
3. Matica predstaviteľov

• Stať sa – identifikácia postupov a procesov, ktoré produkt má pomôcť zjendodušiť, realizovať.

1. Customer Journey
2. Persona

• Prežiť – vytvorenie obchodného modelu, vízie produktu a stručného popisu (elevator statement) produktu. Dlhodobé smerovanie produktu.

1. Business Model Canvas
2. Lean Canvas
3. Elevator Statement

• Naplánovať – vytvorenie prvotného produktového backlogu vlastností, epikov a user stories. Príprava MVP, prvých verzií a iterácií.

1. Produktový backlog

• Vytvoriť
  • Realizácia vlastností v náväzných iteráciách, sprintoch. Priebežné zlepšovanie procesu vývoja a vlastností produktu. Nasadenie do prevádzky a spätná väzba klientov a používateľov.

Vytvárame produkt agilne

Softvérové produkty tvoríme mnohokrát ako domy. No dá sa to aj inak a lepšie. Story je v Scrume základným prvkom popisujúcim požiadavky. Je to jednoduchý a zrozumiteľný popis o tom kto, čo a prečo danú vlastnosť potrebuje.

Ako ale popísať komplexný systém v takejto jednoduchej forme? Práve táto otázka je často kladená pri prechode na agilný vývoj.

Stavba

Ako staviate dom? Najprv základy, potom prízemie, prvé spochodie, ďalšie poschodia no a nakoniec strecha? Výsledok, teda dom, je odovzdaný ako celok. Až potom ho zákazník začne používať.

Softvérové produkty budujeme často podobne. Po vrstvách. Najprv datábaza. Potom (celý) dátový model, ktorým presne zmapujeme požiadavky klienta. Potom pridáme vrstvu s obchodným modelom. Potom vrstvu webových služieb no a nakoniec užívateľské rozhranie.

Výsledok je, rovnako ako dom, použiteľný až na konci. Dôsledkom je, že vznikajú tímy orientované podľa odbornosti. Tímy databázových špecialistov, web dizajnérov, vývojárov služieb a podobne.

Vertikálne?

Softvér sa však dá vytvoriť aj vertikálne. Skúsme vytvoriť iba jednu vlastnosť. Implementujme iba časť databázy popisujúcej danú vlastnosť, potom časť obchodnej logiky, pridajme metódy do webovej služby a sprístupnime užívateľské rozhranie. Vytvorme funkčný blok. Všetko iba pre jednu vlastnosť. Tú dodajme klientovi. Zákazník ju hneď môže začať používať a poskytnúť nám spätnú väzbu.

Až potom pokračujme ďalšou vlastnosťou. Akokeby náš dom bol zostavený z väčších komponent, napr. izieb, ktoré k sebe už iba primontujeme.

Inkrementálne a iteratívne

Takýto inkrementálny vývoj sa dá ešte zlepšiť iteratívnym vývojom. Iteratívny vývoj zdokonalí detaily. Farba na stenách bude v prvej verzii iba biela. Až potom sa rozhodneme pre detaily a pridáme ich. Podobne ako pracuje maliar. Najprv obrys, potom farby, tiene až nakoniec.

Ako nato v softvérovom vývoji? Najprv vytvorte jednoduchý formulár pre zber údajov. No aj s databázovou časťou a webovou službou. Funkčné zadávanie údajov, nielen jednu vrstvu aplikácie. A používateľ môže zadávať údaje bez ohľadu na krásu formulára.

Potom pridajte kontroly. Prispôsobte poradie prvkov lepšej editácii. Zmeňte vzhľad, aby oslovil klienta.

No v tomto momente je to pre klienta už možno zbytočné. Klient totiž potreboval upraviť, zadať, údaje. A to dostal už dávno. Spýtajte sa ho teda ešte predtým, či to skutočne potrebuje.

User story

Vždy keď píšete novú story na kartičku, vždy si všimnite či na kartičke nie je napísaný technický termín (databáza, webservice, business model a pod.). Ak áno,potom je táto story podozrivá. Pretože pravdepodobne popisuje horizontálnu stavbu domu. Klienta nezaujíma, že ste pridali tabuľku do databázy, ale nemôže ju použiť. Aká je teda hodnota takto implementovanej vlastnosti?

0

Zamyslite sa teda už na začiatku, pri písaní kartičiek, na výsledok, ktorý je použiteľný. Prinesie vám veľmi skorú spätnú väzbu ešte v čase, keď kód je ešte v hlavách tímu. V čase keď sa dá jednoducho opraviť.