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.

Big Design Up Front (BDUF) je přístup k vývoji softwaru spadající do metodiky Waterfall (viz výše). Vyznačuje se tím, že je návrh softwaru kompletně dokončen a dotažen do detailu před samotným začátkem implementace. Tento přístup je problematický v tom, že staví zejména na předvídání průběhu a výsledků projektu bez využití prototypů, a navíc se těžko adaptuje na jakékoliv pozdější změny požadavků.

Functional Design Document (FDD) představuje obsáhlou dokumentaci požadavků, specifikací a cílů pro celý projekt vývoje softwaru. Poskytuje detailní rozbor toho, jak budou fungovat jednotlivé prvky výsledného řešení. Technical Design Document (TDD) je dokument popisující technické aspekty řešení a jeho jedntlivých částí. Problémem takto obsáhlé dokumentace je fakt, že velmi rychle zestárne a často nepokryje klíčové části systému – čistě z toho důvodu, že je pro lidi těžké již předem vnímat a sepsat tak velké množství informací, jaké si žádá komplexní IT systém. Navíc se jedná o přístup, který bývá zejména u komplexnějších projektů poměrně zdlouhavý.

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émem začne zamýšlet jinou cestou, než při pouhém 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ávají 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ý 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 popíše.

Je nutné, aby požadavky dodržovaly výše popsanou strukturu a nezahrnovaly 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

Pro efektivní průběh jednotlivých iterací prototypování doporučujeme účast následujících osob: 

• Ze strany Společnosti 
  • Specialisté s detailní znalostí procesů: Reprezentují typického koncového uživatele, znají jeho každodenní práci a problémy a dokáží odpovědět na otázky týkající se fungování jednotlivých oblastí.  
  • Klíčoví uživatelé: Účastní se zejména závěrečných iterací, testují vytvořenéprototypy a poskytují zpětnou vazbu.
• Ze strany Dodavatele
  • Business analytik: Pomáhá definovat a strukturovat požadavky, vede diskuze a zajišťuje souhlas prototypů s obchodními cíli projektu.
  • UX designer: Přispívá do diskuse znalostmi o designu, připravuje návrhy GUI a prototypy. 
  • Architekt řešení: Zajišťuje technickou proveditelnost navrhovaných řešení a optimalizuje prototypy z hlediska budoucí implementace.

Jedním z výstupů Design Sprintu je závazná cenová nabídka na realizaci prvního implementačního sprintu. Stanovit ale přesnou cenu za celý projekt je na jeho začátků velmi problematické, a to z několika důvodů.

Jedním z hlavních je proměnlivost zadání v průběhu vývoje. V dynamickém prostředí softwarového vývoje se požadavky na projekt často mění v reakci na trh, 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 stát neaktuálními.

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.