Stavy v procese, stĺpce na Kanban tabuli

Článok je prebraný z http://scrum.sk/index.php/stavy-a-stlpce-na-kanban-tabuli/

Kanban tabuľa

Kanban tabuľa je skvelou pomôckou agilného tímu. Vizualizácia stavu úloh umožňuje tímu sa efektívne samoorganizovať a zároveň budovať dôveru v tíme aj mimo neho.

Každý stĺpec tabule označuje stav. A práve počet stĺpcov, teda stavov, je jednou z prvých otázok scrum mastrov počas prípravy tímu.

Odpoveď závisí od spôsobu akým ste sa rozhodli zavádzať Agile. Ste otvorení väčším zmenám? Alebo radšej opatrne a postupne?

Veľká zmena – maximalizácia minima

Pred niekoľkými mesiacmi sme začínali transformáciu v tíme, ktorý vytvára komplexný informačný systém už niekoľko rokov. V skutočnosti to boli štyri tímy so zložitejším procesom vývoja a teda aj s viacerými stavmi.

Ešte pred začatím transformácie sa však tím rozhodol maximálne zjednodušiť workflow tak, aby sa nemuseli vývojári zamýšľať kedy dať kartu do akého stavu. Pre svoju Kanban tabuľu preto zaviedli iba tri stavy.

Kanban simple workflow proces

Výhody sa ukázali okamžite:

  • Jednoznačný stav. Úlohu je nutné spraviť, alebo sa na nej pracuje, alebo je hotová.
  • Veľa kariet. Aj keď to znelo ako zvýšenie byrokracie, v skutočnosti sa ukázalo, že toto rozhodnutie viedlo tím k lepšej príprave počas plánovania. Požiadavky sú rozdelené na viaceré úlohy, ktoré jasnejšie popisujú prístup k riešeniu požiadavky.
  • Lepšie odhady – každá karta má svoj jednoznačný odhad. Je jasné, koľko sa na kartu plánuje a koľko času ešte zostáva. V predchádzajúcom workflow mal tím špeciálny stav označujúci čakanie. A práve v takomto stave karty ‘viseli’ , no tím nesledoval ich trvanie.
  • Organizácia tímu – každá  karta má svojho riešiteľa. Tak je možné lepšie rozdeliť úlohy medzi členov tímu.
  • Adresnosť problému – v prípade problému pri riešení úlohy je možné ľahko identifikovať, ktoré úlohy majú problém a zviditeľniť ich.

Pomalá zmena

Iný tím sa rozhodol, že zavedenie troch stavov nie je možné vzhľadom k ďalším firemným procesom, no identifikovali, že zjednodušenie je nutné. Otázne bolo ako zmeniť proces čo najmenej a zároveň najefektívnejšie.

Jedným z agilných princípov je pozorovanie a adaptácia. Preto sme v tíme začali s vizualizáciou aktuálneho workflow. Od momentu vzniku požiadavky až po dodanie výsledku používateľom. Táto technika sa volá Value Stream Mapping. Obrázok ilustruje príklad výrobnej fabriky.

Value Stream Mapping

Ďalším krokom bolo meranie trvania spracovania úloh v jednotlivých stavoch a pri presunoch medzi nimi. Keďže hlavným cieľom transformácie bolo skrátiť čas dodávky používateľom, zamerali sme na najdlhšie časti, ktoré stálo zato optimalizovať. Optimalizácia však neznamenala, že sa meranie skončilo. Každá lokálna optimalizácia má dopady na celkový proces, a preto je nutné pokračovať v meraní a ďalšej optimalizácii. Je to v podstate neustály proces.

Vizualizácia a meranie zároveň pomohli identifkovať stavy, v ktorých sa úlohy dlho ‘neohriali’. Úlohy boli cez nich iba presúvané. Tieto stavy boli z workflow odstránené čo zjednodušilo aj samotný proces.

Čo sa pýtať pri vytváraní Kanban tabule?

  • Prečo potrebujeme daný stav?
  • Kto potrebuje daný stav?
  • Ako dlho zostáva úloha v danom stave?
  • Má stav zmysel aj v prípade, že úloha nie je vývojová, ale napr.  napísanie dokumentu?
  • Potrebujete stav merať a vykazovať? Pre koho a prečo? Má to súvis s biznis hodnotou?
  • Čo je zbytočné?
  • Neexistujú iné workflow pre rôzne činnosti vývojového tímu? Napr. riešenie podpory, spracovanie kritických požiadaviek, požiadavky na súčinnosť.

Pr_duktívne plánovanie

Článok je prebraný z http://scrum.sk/index.php/produktivne_planovanie/

Počas niekoľkých posledných mesiacov sa mi naskytla príležitosť zúčastniť sa viacerých plánovacích stretnutí tímov s rôznou dobou nasadenia agile. Od úplných začiatočníkov až po starých harcovníkov, ktorí agile aplikujú už viac ako päť rokov.

Zaujalo ma na nich to, že:

  1. Efektivita plánovania nezávisí od trvania aplikácie agile.
  2. Tímy bez feedbacku upadajú do stereotypov a iba aplikujú procesy.
  3. Tímy sa zamerajú na zjednodušenie práce (rozumej lenivejú) a úplne zabúdajú na dôvôdy prečo sa plánuje.
  4. Výsledkom nie je plán, ktorému všetci rozumejú.
  5. Plán nie je plánom tímu, ale plánom jednotlivcov.
  6. Nesprávne pochopenie kedy a ako aplikovať story pointy a kedy hodiny.
  7. Nepochopenie, prečo vlastne odhadovať čas.
  8. Sprinty napriek plánovaniu aj tak nie sú ukončené načas a tím napriek tomu necíti zodpovednosť.

 

Možno predpokladáte, že tieto chyby mali tímy, ktoré začínali. No nebolo to tak. Tieto chyby sa objavili v skúsených tímoch. Vedené certifikovanými scrum mastrami.

 

A výsledok? Frustrácie manažmentu z nejasného termínu dodania, čo vedie k neustálym zmenám priorít. To prirodzene frustruje zákazníka aj tím. Navyše to prispieva k nemožnosti plánovania, práve kvôli častým zmenám. A začarovaný kruh je na svete. Plánovanie je frustrácia, ktorá bolí a preto ho chceme mať z krku. Preboha, veď za tie 4 hodiny sa dá toho tak veľa stihnúť naprogramovať.

Pravda starých otcov

Jeden z mojich prvých manažérov ma učil pravidlo brúsenia sekery. Jednoducho povedané, nedá sa len stínať stromy. To aj drevorubač sa musí zastaviť, vybrať si ten správny smer, vybrať stromy a nabrúsiť sekeru. Až potom rúbať stromy tak, aby vládal aj na ďalší deň. Ako je to v IT? (Lepší?) Vývojár chce vyvíjať. Všetko ostatné je balast. Sekera sa brúsi iba ojedinele.

No to brúsenie sekery má niečo v sebe…

Pravda starých agilistov

Agilné princípy ukazujú ako z tejto frustrácie von. Začať treba Agilným Manifestom, ktoré dáva do popredia funkčný softvér. Vytvorený v spolupráci tímu, zákazníka tak, aby bol pripravený na zmeny.

Účelom plánovania je robiť plánovanie, nie vytvárať plány.

Teda:

  • spoznať čo ideme dokončiť počas sprintu,
  • chceme začať s čistým stolom, začať novú iteráciu,
  • stanoviť si tímový záväzok k tomu, čo vieme dokončiť a koľko vieme dokončiť,
  • vytvoriť priestor pre spokojnosť. Spokojnosť tímu, klientov aj manažmentu.

Agenda

Často odpozorovanou chybou je úplne chýbajúca agenda stretnutia. Nepripravenosť z pohľadu organizácie času, postupu, priestorov a potrebného materiálu. Tím jednoducho prišiel na plánovanie a nechal sa unášať. V takýchto prípadoch začujete najčastejšie otázku ”Kedy vlastne máme obed?”. Áno, najčastejšie je práve táto prvou otázkou.

Čo je teda potrebné na plánovanie? Tu je niekoľko postrehov.

Čas

Predpokladajte  trvanie asi 2-4 hodiny podľa pripravenosti backlogu. Je to dlho? Radšej si sadnúť na dve hodiny a dohodnúť než potom zmätene hľadať spôsob riešenia niekoľko dní…

Pripravenosť

Dobrý scrum master pripraví miestnosť. Projektor, laptop, funkčné pripojenie k elektronickej tabuli. Telefón(y), web kamery ak je to potrebné.  Viditeľný časový rámec jednotlivých aktivít. Stopky alebo hodiny merajúce čas. A samozrejme pozve ľudí aj poslaním udalosti do kalendára. Dostatočne vopred. Najmenej 2 týždne vopred.

Dobrý produktový vlastník príde na plánovanie s pripravenými požiadavkami, ich prioritami. S odhadnutou biznis hodnotou, rizikom a MoSCoW. S akceptačnými kritériami. Vo forme, ktorú tím považuje za stav pripravený (definition of ready).

Dobré tímy už vedia čo v sprint backlogu je. Už si ho vopred každý preštudoval, napísal si pripomienky, resp. otázky a vie čo musí spraviť pre dokončenie požiadaviek. Má predpripravené konkrétne úlohy.

P1030082

V takomto prípade dokončí 10 ľudí plánovanie sprintu do 2 hodín určite. Postrehli ste ale tú disciplínu v príprave?

Kartičky

Budete potrebovať kartičky, kartičky, kartičky. A ešte raz kartičky. Zabudnite na notebooky. Plánovanie má byť tímovou prácou (manifesto).

S kartami sa ľahko manipuluje, ľahko sa prioritzuje, delí, vytvára nový obsah. Backlog sa jednoducho dá rozdeliť medzi viacero ľudí, zparalelniť prácu. Plánovanie tak bude intenzívne, efektívne a produktívne. Až keď skončíte plánovanie, až potom zadajte všetky karty do nástroja. Ak to urobíte všetci z tímu, tak zadať niekoľko desiatok kariet vám nezaberie viac ako pol hodinu.

P1050046

Aké je to s jedným laptopom a projektorom? Prduktívne. Všetci sedia okolo stola so založenými rukami a v tom lepšom prípade pozerajú na stenu. V bežnom prípade sa hrajú s telefónom pod stolom. Preto prduktívne.

Hmm, notebook

Ok, maximálne jeden, ak váš backlog je v elektronickom nástroji. Aby ste sa vedeli prehrabať v referenciách a ďalších potrebných informáciách. No prineste sprint backlog aj na kartičkách. Malá komplikácia, ktorá zvyšuje produktivitu.

Definícia Hotovo

Prineste si aj vašu definíciu Hotovo. Aby vám pomohla ako šablóna pri písaní úloh. Možno budete potrebovať viacero definícií. Pre user stories alebo chyby.

DoD

Rýchlosť a história

Aby ste sa vyhli zbytočnému deleniu požiadaviek na úlohy, do sprintu má produktový vlastník zaradiť iba toľko stories, koľko tím stihol dokončiť v predchádzajúcich sprintoch. Koľko story pointov bolo realné dokončených.

velocity

Kapacita

Zrátajte kapacitu tímu. Koľko dní budú členovia tímu v práci. Koľko hodín denne sa vedia venovať backlogu. Každú úlohu potom odhadnite v hodinách a nakoniec skontrolujte, či ich stihnete dokončiť.

Aby ste si vedeli overiť, či náhodou ste si nenaplánovali príliš veľa práce na sprint, ktorú nemáte možnosť stihnúť.

Kapacita

A výsledok plánovania?

Výsledkom dobrého plánovania sú:

  • prioritizované user stories,
  • dohodnuté akceptačné kritériá,
  • identifikované riziká,
  • rozdelené user stories na implementačné úlohy podľa definície hotovo a podľa charakteru požiadaviek,
  • odhadnutý čas imlementácie úloh,
  • overená možnosť dokončenia sprint backlogu podľa kapacity tímu a podľa dostupnosti jednotlivých členov tímu,
  • pocit, že vieme takýto sprint dokončiť.

Pocit je často pravdivejší než akákoľvek matematika….

Veľa úspechov pri plánovaní ďalších sprintov, ktoré sa vám podarí dokončiť.

Novembrový meetup v Bratislave

V novembri máme ďalší meetup v Bratislave.

Termín: 26.11.2012, 18:00

Miesto: Hotel MaxInn, Pri Suchom mlyne 7, Bratislava

Témou bude agilita v enterprise, korporáciách a firmách s dlhodobo zabehnutým biznisom. Jednoducho o agilite tam, kde je si ju ťažké čo i len predstaviť.

Máte chuť zdiešať vaše skúsenosti? Privítame vašu prezentáciu. Okrem prezentácii bude priestor aj na diskusiu.

Program

  • Príspevky:
    • Eva Kišoňová, Siemens – Ako nezničiť agilný prístup vo veľkých projektoch a veľkej firme
    • Pavol Eliáš, Descartes – Skúsenosti s agilnými metodológiami v prostredí distribuovaných tímov
    • Dušan Kocúrek, ScrumDesk s.r.o. – Agilita nástrojom, nie cieľom
  • Témy pre Open space diskusiu
    • Vizia PMO a projektových manažérov v rámci agilných projektov vo veľkej firme

Vyhrajte vstup na Agile Prague

SDlogorobime_it-logo

ScrumDesk s.r.o. v spolupráci s robime.it a organizátormi konferencie Agile Prague ponúkajú nielen členom Agile@Slovakia  vstup zdarma na konferenciu Agile Prague v hodnote 5.000 CZK!

Čo potrebujete spraviť aby ste tento vstup získali?  Stačí zodpovedať pár jednoduchých otázok o Agile na stránkach robime.it.

Zúčastniť sa súťaže na stránkach robime.it!

logo_apc-250x70

Prečo ísť do Prahy 3.-4. septembra 2012:

  • pretože je to Praha :),
  • pretože stretnete viac ako 100 ďalších ľudí, ktorí aplikujú Agile alebo sa snažia dozvedieť viac,
  • pretože budú predstavené prípadové štúdie z Barclays, CA, IBM, Kerio, Seznam.cz,
  • po každej prednáške bude rečník dostupný v open space zóne. Preberte svoje problémy s expertmi.

Viete kto prezentuje?

a ďalších 24 rečníkov. Mimochodom, poznáte rečníkov na fotografiách? Stretnete ich na konferenciách nielen v Prahe.

Tak a teraz klikni na linku a pokús sa vyhrať!

Projektový manažér == Scrum Master?

V posledných dňoch mám čoraz väčší dojem, že niektoré veci musíme ako komunita dôraznejšie ozrejmovať,  vysvetľovať a trvať na správnom použití.

V tomto príspevku sa chcem viac zamerať na význam roly Scrum Master. Prečo? Pretože počas posledného týždňa som našiel päť článkov (jeden dokonca publikovaný na nemenovanej unverzite), ktoré nesprávne vysvetľujú kto je Scrum Master, čo má robiť a ako to má robiť.

Dôvodom je možno slovenčina, do ktorej sa tento pojem Scrum Master veľmi ťažko prekladá. Majster Scrumu? Hmm, v profesionálnom prostredí to znie zvláštne. Ja osobne tento pojem práve preto takto neprekladám. No významovo je tento preklad vynikajúci.

Projektový manažér (v terminológii Scrum-u „ScrumMaster“)

Chcel by som sa venovať asi najväčšiemu nepochopeniu, ktoré som objavil.

Nie, nesprávne. Toto sú dve roly, ktoré majú za úlohu riešiť iné aspekty. Áno, často je to ten istý človek. No tento človek má na vešiaku dva kabáty. Raz môže byt projektovým manažérom, inokedy scrum mastrom. Dokonca z praxe poznám mnohých projektových manažérov, ktorý sa radšej stali Scrum Mastrom.

Prečo? Pretože  Projektový manažer <> Scrum Master.

Pretože projektový manažér sa má zaoberať časom, rozpočtom, zdrojmi a kvalitou. To sú atribúty akéhokoľvek projektu. A projektový manažér ich má držať pokope tak, aby výsledok projektu bol dodaný načas, v rozpočte s danou kvalitou, vyvinutý vybraným tímom.

Projektový manažér je na svete kvôli PROJEKTU.

No Scrum Master sa týmto primárne vôbec nemá zaoberať. Scrum Master sa zaoberá:

  • Vyrovnávaním cesty, po ktorej kráča tím.
  • Snaží sa skoro rozpoznať prekážky, snaží sa ich odstrániť aj za pomoci organizácie.
  • Snaží sa tímu pomôcť, aby bol efektívnym.
  • Robí denne prácu, ktorá by iných blokovala.
  • Prináša a udržuje viditeľnosť stavu projektu tým, že komunikuje s tímom a inými tímami
  • Synchronizuje tím s inými tímami
  • Pripravuje a moderuje (pozor, nevedie!) porady a diskusie.
  • Komunikuje s organizáciou – produktovým aj projektovým manažérom.
  • Zaoberá sa procesom vývoja.
  • Koučuje (vyučuje) agilné techniky v tíme. Také aké práve tímu pomôžu. Musí mať prehľad o tejto problematike a mal by vždy vedieť trochu o tom viac ako členovia tímu.

Scrum Master je na svete kvôli TÍMU.

Máte na tento zoznam ako projektový manažér v dnešnej dobe čas?

Základná smernica retrospektívy

Skúste prečítať túto vetu nahlas všetkými členmi tímu na začiatku vašej retrospektívy…

Bez ohľadu na to, čo zistíme,

chápeme a pevne veríme,
že každý robí tú najlepšiu prácu akú môže,

vzhľadom na to, čo pozná,
podľa svojich schopností a zručností,

podľa  situácie, ľudí a zdrojov,
ktoré sú k dispozícii.

Agile Open Space Meetup v Bratislave

Na poslednom meetupe minulý rok v Bratislave sa nám podarilo (v podstate) spraviť malú konferenciu aj vďaka piatim prezentujúcim a množstvu Vás, ktorí sa prišli pozrieť.

Keďže nám ostalo iba málo času na rozhovory, radi by sme Vás pozvali na prvý Agile Open Space. Cieľom bude viac poskytnúť priestor diskusii o témach, ktoré Vás zaujímajú. Témy sa dohodnú priamo na mieste.

Kedy: 3. apríla 2012, 18:00

Kde: Kafe Nervosa, Zámocka 30, Bratislava, Mapa

Vstup zdarma

Aké sú pravidlá open space?

  1. Správny človek je ten kto príde.
  2. Čokoľvek  sa stane je správne.
  3. Správny čas je keď sa to začne.
  4. Keď je koniec tak je koniec.
  5. Ak sa ocitnete v situácii, že sa prestanete učiť alebo prispievať, jednoducho všetkých pozdravte, použite svoje dve nohy a choďte robiť niečo užitočné.

Na záver urobíme krátky prehľad o diskutovaných témach, problémoch a  záveroch.

Navrhované témy:

  • Ako agilný prístup premietnuť do zmluvy o dielo? Dá sa to?
  • TDD, scrum, agilne kontrakty
  • Agile requirements

Chcem Vás poprosiť o krátku registráciu, aby sme vedeli prispôsobiť priestor počtu účastníkov.

Agilný projekt = Tehly a piesok

Produkty sú pri klasickom projektovom riadení pripravené na začiatku veľmi podrobne. Projektový manažér plánuje projekt od začiatku tak, aby v ňom boli všetky úlohy, často až do najmenších detailov. A aj vrátane “bezpečnostnej vaty 10-15%”. Robí to v dobrej viere, že projekt je naplánovaný, odhadnuteľný a realizovateľný. Detailné plánovanie sa však v praxi zrúti ako domček z kariet v momente keď sa požiadavky zmenia. A to znamená “čoskoro a vždy“.

Agilný projekt má samozrejme tie isté úskalia. No agilita dovoľuje flexibilitu rozsahu požiadaviek, čo by produktový vlastník mal využiť. Využiť aj tým, že backlog bude obsahovať vlastnosti rôznej náročnosti (veľkosti).

Prediktívny aj agilný plán majú tie isté východiská, no agilný projekt je  realizovaný odlišným spôsobom:

  • Agilný projekt má síce dohodnuté dátumy dodania, no obsah dodávky je možné zmeniť. V tradičnom projekte sú väčšinou pevne dohodnuté dátumy, rozsah a často aj rozpočet. To znemožňuje pružne reagovať na zmeny.
  • Plán vždy obsahuje veľké požiadavky, tzv. eposy (v anglickej literatúre sa používa slovo epics). Produktového vlastníka zaujímajú práve eposy vytvárané na základe vízie produktu. Príklad: Správa zákazníkov, Správa produktov, Prehľady.
  • Plán obsahuje niekoľko malých, no konkrétnych požiadaviek, ktoré sa majú dokončiť v jednej alebo dvoch nasledujúcich iteráciách. Nie pre celý plán, len pre niekoľko iterácií! Tieto menšie požiadavky, stories, vznikajú iteratívnym a/alebo inkrementálnym rozdelením eposu. Príklad: Pridanie nového zákazníka, Pridanie kontroly údajov do formulára, Mesačný výkaz účtu

Agilný plán by mal obsahovať  “tehly aj piesok”. Eposy (tehly), ktoré tvoria základ aplikácie a stories (piesok), ktoré tvoria detaily.

Produktový vlastník tak má čas pripravovať eposy dopredu, zatiaľ čo tím má čas konkrétne požiadavky (stories) implementovať a dodávať.

Toto je základ dobrého agilného projektového plánu. Ako ale určíme, ktoré eposy potrebujeme skonkretizovať na stories a kedy?

Tvoríme produkt agilne

Softvérové produkty tvoríme mnohokrát ako domy. No dá sa to aj inak a lepšie.

Článok bol publikovaný na Zajtra.sk

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.

Increment vs iterative

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.

Záver

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ť.