Blog | Při plánování nového projektu nezapomeňte na Requirements a Architecture

Při plánování nového projektu nezapomeňte na Requirements a Architecture

Ve Scrumu, když chystáte nový projekt, je vhodné udělat analýzu. Být agilní nerovná se sednout k počítači a začít bušit. Ta analýza se dělá, ale trochu jinak, než je běžné ve vodopádovém modelu.

Cíl analýzy ve vodopádovém modelu je odlišný: „Odpovědět všechny otázky předtím, než bude napsána byť jediná řádka kódu.“

Cíl analýzy v agilní metodice je spíš: „Vymezit businessový i technologický rámec, základní parametry, přibližný termín, rozpočet, funkcionality a moduly, nutnosti pro import a export dat a nutnost komunikovat s jinými systémy a dodržet nějaké existující normy.“

Rozsah takový analýzy je mnohem menší. U projektu na jeden člověkorok je u vodopádových modelů běžné, že analýza může trvat i několik měsíců. U agilních projektů je u projektu na člověkorok dobré vložit cca 10 člověkodní.

Scrum nemá žádnou konkrétní techniku pro založení nového projektu. Protože ale za mnou firmy chodí, že chtěji nasadit Scrum, častěji v situaci, kdy:

  • startují nový projekt (interní nebo pro zákazníka)
  • přepisují existující projekt do nové verze

Vzniká pro ně potřeba, jak odvrátit několik potenciálních rizik, které by z nedostatečné anaýzy mohly vzniknout. Najednou chtějí flexibilitu agilní metodiky a zároveň se nechtějí dostat do stavu, kdy budou muset velkou část aplikace zahodit nebo obastlit, protože na něco nepomysleli. Navíc vzniká poptávka po analýze, která bude velká „tak akorát“ a nebude v ní nic, co by se dělalo zbytečně.

Já na školeních Scrumu předávám zjednodušený systém od Scotta W. Amblera. Tento postup se nazývá Agilní modelování a víc informací k němu získáte na oficiálním webu.

Já předávám tento systém ještě zjednodušený, kde se klade důraz na 2 činnosti.

  • Requirements Envisioning
  • Architecture Envisioning

To jsou dva dokumenty, které vznikají (souběžně s tím, že Requirements začne vznikat o trochu dřív).

Requirements obsahuje vymezení projektu, co to je, pro koho, jaké jsou základní moduly, user stories a jaké business values jsou přinášeny.

Architecture analyzuje, jaké budou použity technologie, např. prog.jazyk, aplikační server, databáze, cache, zálohování, generování PDF. Jak se bude reagovat na pomalost (a jaká je výkonnostní charakteristika), jak se bude systém testovat atd.

Poté, co jsou tyto dokumenty vytvořeny, vznikne milník Minimálního tržního produktu (někdy ho nazývám jako 0. release – jde o minimalistický produkt, který přináší jen ty nejnezbytnější business values pro zákazníka) a tým iteruje až do dosažení tohoto stavu.

Tyto dokumenty jsou prevencí potencionálních rizik a výhodou je:

  • je zjevný termín i čas, byť v agile je toto vždy jen přibližné (můžete měnit zadání → mění se scope)
  • je zjevné, co se bude dělat a architektura se tomu přizpůsobuje
  • lidé si rozumí, protože ví, k čemu směřují
  • produkt před minimálním tržním produktem obvykle není releasován a není moc potřeb měnit zadání, tato analýza zvyšuje produktivitu lidí, protože se mají o co opřít
  • nestane se, že by se nasadila nevhodná technologie a pak se musel kus systému zahodit a psát znovu

Poté, co po mě studenti opakovaně chtěli vzorový dokument, jsem připravil jeden, na kterém nejsem vázán žádným NDA ani obchodními vztahy. Tento dokument budou studenti, které potřebují nějak analyzovat nový vývojový produkt, dostávat na školení Scrumu k dispozici.

Agile

Předejte zkušenosti i dalším a sdílejte tento článek!



Jiří Knesl
Business & IT konzultant

Jiří Knesl poprvé začal programovat v roce 1993. Od té doby, díky skvělým učitelům a později zákazníkům, měl možnost neustále růst v oboru vývoje webových aplikací a informačních systémů. v roce 2002 se přidal zájem o ekonomii a v roce 2006 o organizaci práce. Vším tím se konstantně profesně zabývá jak ve svém podnikání, tak i u zákazníků. Za posledních 5 let vydal na tato témata přes 400 článků.

Prohlédněte si moje reference

Mám zkušenosti z rozsáhlých projektů pro korporace, velké podniky, střední i malé firmy, ale i pro startupy v cloudu. Zvyšoval jsem jejich know-how, pomáhal nastavovat jejich organizační strukturu, byl lektorem a mentorem v náročných situacích. Podívejte se, jak vidí můj přínos samotní klienti.

Sledujte mé postřehy na sociálních sítích