SprintMethod
agilní metodika vycházející ze Scrumu

Řízení vývoje a výroby software nemusí bolet. SprintMethod je agilní metodika, která nabízí k vysoké produktivitě, kvalitě a flexibilitě ještě možnost dělat dobře marketing a prodej produktu. SprintMethod jsem vytvářel tak, aby byl jednoduchý, použitelný i pro jednotlivce, dvojice, stejně tak jako pro korporace a vývojáře hardware. Přečtení tohoto materiálu by vám mělo stačit k implementaci metodiky. Pokud si chcete být jistí, nabízím vám pomoc při zaškolení a zavedení SprintMethod a Scrumu.

Jiří Knesl
Autor SprintMethod
www.knesl.com

Co je SprintMethod?

SprintMethod je metodika řízení výroby a vývoje převážně software (ale i hardware). Je zaměřená na několik ústředních benefitů.

Základním principem je určitý návrat k historii Scrumu. SprintMethod vychází ze stejných teoretických základů, ale prošel reinterpretací těchto poznatků. Výsledkem je metodika, která si bere z vědeckých poznatků profesorů Takeuchiho a Nonaky (věděckých původců Scrumu) trochu jiné závěry. Následkem toho se hodí pro trochu jiné situace.

Co je agilní hnutí?

Agilní hnutí je celkovým podhoubím, ze kterého vlastně vyrostlo všechno, co dnes nazýváme agilním (tedy i agilní metodiky, jako je Scrum, tak i agilní techniky, jako Test Driven Development). Stojí za ním některá esa světového IT. Diskutovali spolu, zkoušeli různé postupy z jiných oborů a mnohdy se jim podařilo zjistit, že některé principy jsou výborně aplikovatelné i ve vývoji software. Návrhové vzory pochází z architektury a postupů architekta Christophera Alexandera. Scrum pochází z vývoje nových automobilů, fotoaparátů a tiskáren. Iterativní vývoj z Demingova cyklu. Test Driven Development z doporučovaných postupů pro programování na děrných štítcích.

Dnes se dá za agilní považovat vše, co odpovídá hodnotám v agilním manifestu.

Víc než všechno, je nutné vnímat agile prostřednictvím hodnot. Co je a není považováno za správné a důležité. Jak máme dodávat hodnotu zákazníkovi?

Agilní podniková kultura odpovídá nejlépe kultuře přátelských experimentů.

Co jsou agilní metodiky?

Obrázek hierarchie různých Agile termínů. Nahoře je hnutí, z kterého vychází metodika, to je konkrétní realizace a poslední je agilní technika, ta závisí na hnutí i metodice

Agilní metodiky jsou samotným vtělením agilních principů. Obvykle vznikají kombinací agilních hodnot a štíhlého řízení výroby (např. metodiky Scrum, nebo Spiral model), případně extrémním využitím agilních technik (Extrémní programování), byť i zde najdeme paralely se štíhlým řízením (konkrétně s Toyota Production System a Total Quality Management).

Proč není jedna nejlepší metodika? Protože každá metodika je optimalizovaná na trochu jinou situaci, tým, či produkt. Zároveň s tím přináší každá metodika jiný benefit. Jakou metodiku máte zvolit? Prohlédněte si tabulku se srovnáním jednotlivých metodik.

Agilní metodika je konkrétní postup uspořádání vývoje a výroby. Je standardizovaným postupem, který určuje, jak vypadají úkoly, jak se zadávají, kam se píšou a v jakém formátu. Jaké jsou schůze a kdo je moderuje a co je cílem. Jednotlivé metodiky také určují práva a povinnosti jednotlivých členů týmu i jejich manažerů.

Co je agilní procesní řízení?

V agilních metodikách probíhá vývoj v kontrolovaném prostředí, které je řízené procesy. Agilní metodiky určitě nejsou žádnou formou anarchie. Velký rozdíl mezi běžně procesně řízenou firmou a agilní firmou najdeme ve dvou základních podmínkách.

Nejčastěji proces vypadá jen jako souhrn bodů. Například:

Release nové verze

Každý krok, který neprojde, restartuje proces.

  1. Spustit všechny testy a ujistit se, že projdou
  2. Otagovat knihovny
  3. Do konfiguračního souboru napsat aktuální verze tagů knihoven
  4. Otagovat produkt
  5. Spustit deployment knihoven a produktu příkazem cap deploy
  6. Spustit testy na staging serveru
  7. Přehodit na produkci
  8. Proklikat web

Ten, kdo chce dělat release, si okopíruje seznam bodů a postupně si odškrtává kroky tak, jak je dokončuje.

V okamžiku, kdy procesy přestanou vyhovovat, musí být možné je ihned změnit.

Co jsou agilní techniky?

Agilní techniky jsou konkrétní výrobní postupy, které jsou běžně používány při vývoji software v agilních týmech. Nejsou používány pouze v nich a řadu z nich již budete určitě znát.

Párové programování

Při párovém programování sedí dva vývojáři u jednoho stroje. Pouze jeden z nich v jednu chvíli píše kód. Jeho cílem je dokončit co nejrychleji úkol při stanovené kvalitativní úrovni. Úkolem druhého je dohlížet na správnou architekturu, radit a dávat tipy, jak vylepšit kód.

Vývojáři se pravidelně prohazují. Buď po úkolu, nebo po uplynutí určitého času. V případě, že tým dělá Test Driven Development, je v pořádku dělat i tzv. ping-pong párové programování. Vývojář napíše kód, který projde testy a napíše test pro druhého vývojáře. U počítače se v tu chvíli vystřídají. Druhý napíše kód, který projde novým testem a napíše zase test. Takto se střídají.

Jedním z pravidel pro párové programování je nasazení do páru obdobně zkušených vývojářů. Junior se seniorem už nejsou ve vztahu páru, ale ve vztahu mentor-žák. V tomto případě se nejedná o pravé párové programování.

Jsou zdokumentované benefity mluvící pro párové programování. Konkrétně: méně chyb (díky průběžnému code review), kód je kratší, tým řeší problémy rychleji, lidé se učí mnohem rychleji, každému kousku systému rozumí více lidí, lidé si víc užívají svou práci, vzrůstá kooperace mezi lidmi a lidé se lépe učí pracovat pohromadě.

Automatizované testování

Pravděpodobně nejznámější agilní technika je automatizované testování. V radikální formě se prosazují přístupy nazvané Behaviour Driven Development a Test Driven Development.

Principem automatizovaného testování je vedle tvorby programu ještě tvorba dalšího programu, který kontroluje, že vyvíjený produkt funguje podle specifikace. Pomocí automatizovaých testů je možné testovat celou řadu různých funkcionalit.

Unit testing

Testuje jednu konkrétní malou jednotku funkcionality. Může testovat jednu třídu (je to nejčastější), ale není to podmínkou.

Integrační testování

Testuje, že jednotlivé jednotky systému interagují správně. Testují se především parametry a počty volání metod, ale i pořadí volání.

Funkční testování

Testuje, že velké kusy systému dovedou korektně pracovat. Takový test například přímo pracuje s databázovými daty, upravuje je apod. Tyto testy jsou velmi vhodné pro ověření toho, zda celek dobře funguje. Nevýhodou je, že tyto testy bývají proti unit testům pomalejší a nejsou tak návodné při lokalizaci chyby.

Akceptační testování

Akceptační testy pracují s konceptem hodnoty pro zákazníka. Při akceptačním testování se ověřuje, zda daný kód umožní systém použít uživateli k účelu, který plánuje.

Zátěžové testování a ostatní

Netestuje se pouze funkcionalita. Je možné testovat chování systému pod zátěží. Při vysoké konkurenci. Při velkých objemech dat. Stejně tak je možné testovat bezpečnost aplikace. Testovat lze přístupnost a použitelnost. Všechny tyto metody mají určitou vhodnou situaci, kdy je správné používat tento kód

Tato témata jsou mimo záběr tohoto dokumentu a prosím čtenáře, aby si další způsoby testování nejen nastudoval, ale používal je i v praxi.

Prototypování

Termín prototyp má celou řadu variant. Zde budu pracovat s variantou, která se často označuje jako "wireframe". V podstatě se jedná o modely jednotlivých obrazovek, zobrazených informací, interakcí.

Prototype driven development vede ke snížení času nezbytného pro pochopení, uživatelský test i samotnou implementaci.

Spike Solution

V situaci, kdy se dostane vývojový tým do situace, ve které není zcela jasné, jak bude daná věc naprogramovatelná, jaké se vyskytnou problémy, je vhodné použít tzv. spike.

Spike solution, spočívá v tom, že se vezme zadání a naprogramuje se nejrychlejší možné řešení, klidně zprasené, neúplné. Hlavní je psát kód tak, aby programátor kódem prošel všemi místy, která jsou považována za problematická. Následkem spike solution je pochopení domény problému.

Po vytvoření spike se tento zahodí a začne se programovat znovu, ale už čistě. Vývojář zná problémy a pravděpodobně je začal už řešit, k problému tedy už přistupuje tak, že problematické místo pro něj není nové a může se vyvarovat řady chyb.

Která agilní metodika je pro mě nejvhodnější

Každá metodika má různý hlavní benefit (nebo i více benefitů). Zároveň jsou různé metodiky různě rozpracované.

Já zde srovnám pouze ty metodiky, o které jsem se hlouběji zajímal, vyzkoušel z nich praktikovat vše nebo části.

Tabulka 1: Rozdělení hlavního benefitu, kladů metodiky, záporů metodiky a pro co je metodika vhodná ve sloupcích a jednotlivé metodiky v řádcích
  Ústřední benefit Klady Zápory Vhodné pro
Scrum Maximální spolehlivost časových odhadů Nejrozpracovanější teorie; Zvládá i zákazníka na pracovišti; Nejpoužívanější - nejjednodušší implementace; fixní délka sprintů usnaďnuje analýzy, vyvíjení abstrakce a dává klidnější pracovní řád Fixní sprinty nejsou vhodné pro týmy, které se o funkcích, které musí ven, dozví těsně před nutným začátkem práce. Nevhodné pro 1-2 členné startupy. Nevhodné pro vývoj hardware Týmy > 2 lidí vyvíjející dlouhodobě pro zákazníka, nebo vyvíjející svůj produkt.
SprintMethod Jednoduchost, napojení na marketing Vhodné pro vývojáře hardware, tam, kde není možné dostat zákazníka na pracoviště, pro jednotlivce, malé týmy, startupy, školní projekty, pro výzkumné projekty, tam, kde není možné odhadnout čas, protože je stráven výrazný čas analýzami Více modulů znamená, že ikdyž někdo implementuje SprintMethod, neovládá ho ještě celý. Pro všechny, komu se z  nějakého důvodu nehodí Scrum. SprintMethod je záměrně vytvářen jako doplňková metodika.
Extrémní programování Nejvyšší možná kvalita Využití agilních technik do maxima. Maximální rychlost učení se. Spolehlivá metodika. Nespolehlivé odhady toho, kdy bude práce hotová. Tam, kde každá chyba hodně bolí (jaderné elektrárny, kardiostimulátory apod.)
Lean Software Development (nesprávně nazývaný Kanban) Nejflexibilnější Možnost rychle zareagovat na změnu. Přehledný kanban board. Velmi minimalistická forma řízení. Naprosto neprodejné pro zákaznické zakázky. Téměř nemožné dělat časové odhady. Pro vlastní produktový vývoj.
Getting Real Napojení na marketing, jednoduchost Rozpracovaná strategie obsahující i tipy pro hledání lidí, marketingu, výběr vlastností k implementaci atd. Nejméně literatury k tématu (pouze knihy od 37signals). Pro malé týmy vyvíjející svůj produkt v malém týmu 1 vývojáře, 1 UX/grafika a 1 kodéro-manažera
Scrumban Metodika jen pro přechod od Scrumu k Lean Software Developmentu, není samostatnou metodikou. Jedná se o ne výrobní strategii, ale change management strategiiDočasně pro ty, kdo přechází od Scrumu k Lean Software Developmentu

Mám-li to shrnout. Pokud vyvíjíte kritický software, použijte Extrémní programování. Pokud děláte dlouhodobý produktový vývoj nebo od vás zákazník kupuje vývoj dlouhodobým placením obdobného množství práce, jděte do Scrumu. Jinak se pro vás hodí SprintMethod (který v sobě zahrnuje výhody Lean Software Developmentu, Getting Real a částečně i Scrumu).

Jak se naučit konkrétní agilní metodiku?

Správná implementace agilní metodiky má tři varianty: