Vývoj softwaru je svým způsobem umění a existuje mnoho různých cest, jak k němu přistupovat. Pro pochopení konceptu Design Sprintu si nyní představíme dvě z hlavních – waterfall a agile.

Metodika Waterfall je model vývoje softwaru, který postupuje lineárně a sekvenčně od jedné fáze projektu k další. Každá fáze (analýza, návrh, implementace, testování, nasazení, správa) musí být kompletně dokončena předtím, než se přejde k další. Tento model spoléhá na přesné a důkladné plánování a pevně dané specifikace na začátku projektu – to je ovšem v prostředí vývoje moderního software takřka nemožné.

Model také ze své podstaty ztěžuje adaptaci na změny požadavků během vývoje. Zákazník je obvykle zapojen především na začátku při schvalování specifikací a poté až na konci při předávání hotového produktu. Pokud se ale během vývoje změní cíle či představy zákazníka, je velmi obtížné a nákladné dodané řešení upravit, což vede ke zpožděním a vyšším nákladům.

Agile je na druhou stranu flexibilní a iterativní přístup k vývoji softwaru, který se zaměřuje na průběžný vývoj a pravidelné dodávky funkcionalit. Projekt je v něm rozdělen do krátkých iterací a na konci každé iterace je zákazníkovi prezentována fungující část produktu. Tento přístup umožňuje týmu rychle reagovat na změny požadavků, které mohou vzniknout v průběhu vývoje, a okamžitě získávat zpětnou vazbu od zákazníka.

V metodice Agile je zákazník více zapojený do procesu vývoje a má větší kontrolu nad výsledným produktem. Díky pravidelným prezentacím a úzké spolupráci s týmem může zákazník průběžně ovlivňovat směr vývoje a zajistit, že konečný produkt lépe odpovídá jeho potřebám a očekáváním.

Vzhledem k našim zkušenostem používáme na všech projektech metodiku Agile.

Feature-Driven Development (FDD) se zaměřuje na průběžné dodávání funkčních částí, zvaných features. Jejím cílem je rychle poskytovat hmatatelné výsledky a na jejich základu zlepšovat produkt v krátkých, opakovaných cyklech. Test-driven development (TDD) pak klade důraz na psaní testů ještě před implementací kódu, čímž by v teorii měla pomocí vývojářům s pochopením požadavků, usnadněním údržby a zmenšením refaktoringu.

Běžně se pak používají v kombinaci s detailní analýzou požadavků jako základ vývoje. Jejich výsledkem bývají obsáhlé dokumentace, která velmi rychle zestárnou a často nepokryjí klíčové části systému – čistě z toho důvodu, že je pro lidi těžké vnímat a sepsat tak velké množství informací, jaké si žádá komplexní IT systém.

Byť jdou výše zmíněné přístupy správným směrem, chybí jim jeden klíčový prvek – vizualizace. Při prototypování obrazovek se totiž zákazník nad systém začne zamýšlet jinou cestou, než při sepisování požadavků, a často přijde na další souvislosti. I pro analytiky je proces prototypování užitečný – sledujeme, jak zákazník nad řešením přemýšlí, a můžeme ho při návrzích na základě našich zkušeností usměrňovat.

Díky zapojení zákazníka do návrhu výsledného navržení systému se předchází předělávání již hotových řešení a vytvořené specifikace zůstává déle aktuální. Validování a grafické navrhování myšlenek přináší nové koncepty a ladí očekávání obou stran.

Správně definovaný požadavek by měl být stručný a přesný, aby byl srozumitelný a efektivně zpracovatelný při pohledu na celý backlog. Definujme si strukturu požadavku. Jeho název by měl být krátký a výstižný, například „Vytvoření a správa faktur“ nebo „Správa kampaní a nabídek“. Neměl by obsahovat postavy ani hlubší popis.

Více do detailu se dostaneme v samotném popisu požadavku. Ten by měl začínat definicí uživatelského příběhu (kdo, co, proč?): Jako <persona>, chci <udělat něco> tak, aby <přidaná hodnota>.

Např. Jako zákazník e-shopu chci mít možnost uložit si oblíbené produkty, aby se mi při další návštěvě snáze vybíralo.

Také může být v případě potřeby přidán stručný popis, který požadavek více rozebere. Špatně definované požadavky nedodržují výše popsanou strukturu nebo zahrnují dlouhé a nepřehledné popisy.

Správně definované požadavky

• Vytvoření a správa faktur
  Jako účetní chci mít možnost vytvářet a spravovat faktury, aby byl účetní proces efektivnější.
• Správa kampaní a nabídek
  Jako marketér chci spravovat kampaně a nabídky, abych mohl snadno aktualizovat marketingové materiály.
• Přidání platebních metod
  Jako zákazník chci mít možnost přidat více platebních metod, aby moje platby byly flexibilnější.

Špatně definovaný požadavek

• Vytvoření a správa faktur
  Vytvořit komplexní systém pro správu faktur pro malé a střední podniky, který by zahrnoval automatické generování faktur, jejich odesílání zákazníkům a sledování platby
  Komentář: Tento požadavek je příliš komplexní a míchá více funkcí do jednoho požadavku. Také nedodržuje strukturu požadavků.
• Zlepšení uživatelského rozhraní
  Uživatelské rozhraní by mělo být přehlednější
  Komentář: Nadpis a popis jsou příliš vágní, bez konkrétního uživatelského příběhu a specifikace

Hlavní přínos Design Sprintu spočívá v rychlejší a přesnější cestě od identifikace problému k navržení řešení. Díky detailnímu zadání a včasné identifikaci možných komplikací se výrazně snižují náklady na vývoj a pozdější úpravy produktu.

Mezi praktické výstupy patří:

• Prototypy obrazovek systému
  Každý Design Sprint vyústí v interaktivní návrhy obrazovek, které zahrnují vše od menu, přes tlačítka a tabulky, až po detaily záznamů. Tyto prototypy jsou již upravené na základě zpětné vazby a diskuse se zákazníkem a poskytují pevný základ pro další rozvoj a iterace projektu. 
• Soupis nových poznatků a rizik
  Během Sprintu přijdeme na možná rizika, které by se jinak objevila až v průběhu vývoje. Všechna zjištěná rizika, která ovlivňují komplexitu dodání projektu (jako jsou požadavky uživatelů, omezení integrací nebo technické specifikace) sepíšeme do jednoho dokumentu. Jejich včasné rozpoznání umožní zavést preventivní opatření dříve, než by se mohla stát pro projekt kritickými.
• IVA Diagram
  Klíčový výstup IVA analýzy, který zobrazuje oblasti přínosu a dopadu, způsoby naplnění požadavků a identifikovaná rizika. Poskytuje vizuální přehled o klíčových aspektech projektu a je nástrojem pro účelné rozhodování a řízení projektu. Týmy pomocí něj mohou lépe pochopit potenciální výzvy a příležitosti.
• Indikativní nabídka projektu
  Poskytuje nezávazný cenový odhad projektu, který je vytvořen na základě Design Sprintu. 
• Rozpad projektu na dílčí části
  Základní rozpad projektu pro přípravu backlogu, a to do úrovně Features, seřazen podle priority a rozdělen do navrhovaných iterací dodání.

• Všichni zúčastnění mají na dobu Design Sprintu vyhrazený čas tak, aby se mohli zúčastnit osobně a následně se připravili na další setkání
• Experti zákazníka mají připravené podklady od uživatelů (například procesní mapy nebo přístupy do systémů pro demonstrace)
• Vybraní uživatelé zákazníka mají vyhrazený čas na pomoc s otázkami expertů, pokud na ně nedokážou nalézt odpověď členové týmu Design Sprintu
• Vybraní uživatelé mimo tým mají vyhrazený čas v posledním dnu, kdy budou testovat prototyp
• Všem členům týmu byly nasdíleny komunikační kanály a nástroje, které budou během Sprintu používány (např. Teams nebo FigJam)

Pro efektivní průběh Design Sprintu je doporučena přítomnost následujících osob:

Workshopy IVA analýzy

• Product Owner – Nastavuje a upřesňuje dlouhodobou vizi projektu a jeho výsledku, dohlíží na průběh Sprintu a přípravu ze strany zákazníka, upřesňuje podmínky pro schválení designu dílčích částí
• Sponzor – Reprezentuje finanční zájmy zákazníka a zodpovídá za správnou prioritizaci dílčích částí z pohledu finanční návratnosti.
• Manažeři s odpovědností za funkční oblasti, které bude systém pokrývat – Upřesňují stávající komplikace, strategická rozhodnutí a detail procesů, které jsou předmětem implementace

Iterace prototypování vybraných částí projektu

• Zákazník
• Specialista se znalostí konkrétních procesů – Reprezentuje typického koncového uživatele, zná jeho každodenní práci a problémy a dokáže odpovědět na otázky dodavatele spojené s jeho činností. Pokud je třeba, může se těchto expertů zúčastnit více.
• Technický specialista – Reprezentuje IT oddělení a dokáže odpovědět na technické otázky dodavatele, jako využití integrací nebo přihlašování.
• Klíčoví uživatelé – Přítomní až na poslední iteraci, vyzkouší si prototypy a poskytnou zpětnou vazbu
• Dodavatel
  • Business analytik – Pomáhá pokládat návodné otázky, formulovat hlavní tezi a vytvářet strukturu v podobě funkčních oblastí, dopadů, rizik a způsobů řešení.
  • Moderátor diskuse – Kontroluje diskusi pro udržení efektivního postupu, pomáhá řešit konfliktní názory a ujišťuje se, že tým postupuje. Má na starosti zápis, myšlenkové mapy a definování úkolů.
  • UX designer – Přispívá do diskuse znalostmi o designu, připravuje návrhy GUI a prototypy.
  • Architekt řešení – Navrhuje konkrétní technická řešení a ujišťuje se, že návrhy týmu dodržují realistický standard proveditelnosti.

Nikoliv. Během sprintu se soustředíme na identifikaci hlavních funkcí, které bude potřeba implementovat, a snažíme se získat celkový přehled o rozsahu potřebné práce. Detailní příprava a cenové odhady jsou zaměřeny primárně na první vývojový sprint. Čím více času a zdrojů věnujeme na počáteční fázi plánování a analýzu, tím přesnější a spolehlivější bude náš odhad nákladů na celý projekt. Nicméně, přesné a závazné číslo bude možné určit až s postupujícím vývojem a díky dalším iteracím.

Stanovit přesnou cenu na začátku projektu je problematické z několika důvodů, zejména kvůli proměnlivosti obchodního zadání v průběhu vývoje. V dynamickém prostředí softwarového vývoje se požadavky na projekt často vyvíjejí a mění v reakci na tržní podmínky, zpětnou vazbu uživatelů, nebo nové technologické možnosti. Tento neustálý vývoj požadavků znamená, že původní plány a odhady se mohou rychle stát neaktuálními.

Při použití metodiky jako Design Sprint se snažíme identifikovat hlavní funkce a získat přehled o potřebné práci, ale podrobná specifikace a celkové náklady se mohou během projektu značně lišit. Přesnější odhady lze obvykle získat po provedení několika iteračních cyklů, kde každý sprint přináší lepší pochopení celkového rozsahu a složitosti projektu.

Z tohoto důvodu je důležité přistupovat k odhadu nákladů flexibilně a očekávat, že finální cena projektu se může od původních předpokladů lišit. Proto se doporučuje stanovovat ceny postupně, s každým dalším sprintem, což umožňuje přizpůsobit rozpočet aktuálním potřebám a realitě projektu.

IVA analýza

1. Formulace a validace hlavní teze/cíle projektu
2. Identifikace pozitivních a negativních vlivů na naplnění cíle
3. Rozdělení projektu na skupiny business hodnot/dopadů
4. Zhodnocení priority každé části 
5. Prioritizace a přiřazení do fází projektu
6. Návrh cílů minimum viable product (MVP)
7. Výběr částí vhodných pro prototypování – těch, které mají chybějící, nejasné nebo rozporuplné informace

Prototypování

• První iterace prototypů
  • Společná část
    • Představení členů týmu
    • Výběr až tří nejdůležitějších oblastí, které je vhodné prototypovat pro nalezení ideálního řešení
    • Tvoření základních návrhů a diskuse
  • Individuální práce řešitelů
    • Rozeslání zápisů a dalších kroků
    • Příprava prototypu dodavatelem na základě náčrtů
    • Příprava dalších otázek vyplývajících z přípravy prototypů
• Další iterace prototypů
  • Společná část
    • Prezentace připravených prototypů
    • Zpětná vazba na prototypy
    • Odpovědi na dotazy spojené s prototypy
    • Nové náčrty na základě zpětné vazby
    • Výběr nových částí aplikace, znovu podle důležitosti
    • Základní náčrty a diskuse
  • Individuální práce řešitelů
    • Stejné jako první den
• Poslední iterace prototypů
  • Společná část
    • Stejné jako předchozí dny
    • Přidají se další uživatelé pro testování prototypů (s detailní dokumentací)
    • Posbírá se zpětná vazba od uživatelů
    • Již se nepokračuje dalšími návrhy změn, ale proběhne finální kontrola celého řešení
    • Konečné vyjádření členů týmu a brainstorming rizik na základě navrhnutého řešení
  • Individuální práce řešitelů
    • Poslední úpravy prototypů
    • Celkové shrnutí klíčových
      • Částí aplikace a prototypů
      • Poznatků a zjištění
      • Nalezených rizik