Workshop
Analýzy a sběr požadavků v agilním prostředí
Analýzy a sběr požadavků v agilním prostředí
Mnoho firem, které se snaží o agilní vývoj produktů či projektů, se zaměřuje jen na IT vývojové týmy a moc neřeší samotné vstupy do vývoje plynoucí, jejich relevanci, množství a hodnotu, jejich zpracování, ověřování a také následné schvalování a měření. Vlastní vývoj je totiž jen malou součástkou celého toku tvorby hodnoty napříč firmou, typicky třeba jen 20% času a pracnosti, tudíž výrazné zlepšení vývoje pomůže celku jen velmi málo (v řádech jednotek procent). Přesto stále vyvíjíme velký tlak na doručování v IT týmech a divíme se, že kýžený efekt nepřichází. Příčiny jsou totiž jinde – na vstupu.
Proto je nutné současně s efektivitou a transparentností vývoje řešit i oblasti mimo IT vývoj (rádoby Scrum týmy), které se týkají hlavně produktových rolí na pomezí byznysu a IT (product owner - PO, produktový manažer, analytici všeho druhu, UX, architekti, projektoví manažeři):
-
Efektivní sběr potřeb (pozor, ne požadavků!)
-
Popis potřeb a cílů, které jimi chceme dosáhnout (dalece se liší od popisu, jak udělat novou funkci v produktu)
-
Jak efektivně přeložit tyto potřeby do požadavků (spolu s realizačním týmem, ne zamrazit řešení za něj),
-
Experimenty a ověřování nápadů na realizaci (hypotéz, které se domníváme, že mohou pomoci byznysu)
-
Průběžné demonstrace řešení a zapojení byznysu
-
Měření, zda byly naše hypotézy správné
Tyto změny jsou nezbytnou součástí agilní tvorby hodnoty napříč vaší firmou (produktem), proto se v tomto workshopu zaměříme na dvě oblasti, které se v agilním prostředí provádí výrazně jinak a mají významný dopad:
1. Sběr požadavků a jejich forma
2. Analýzy a jejich provádění
1. Agilní sběr požadavků se od toho tradičního výrazně liší v následujících aspektech:
-
Řešíme potřeby a byznys cíle místo konkrétních požadavků na nejrůznější (nikdy nepoužité) funkce produktu,
-
Provádí se průběžně a tedy výrazně častěji než 1x do roka,
-
Ptáme se, co bychom měli udělat z pohledu byznysu (ne jakou chtějí uživatelé funkci),
-
Ověřujeme návrhy formou experimentů a ty neověřené vyřazuje,
-
Pravidelně demonstrujeme verze a měříme přínos,
-
Zapojuje obě strany (byznys a IT) do diskuze a spolu návrhu.
2. Tradiční analýzy se od těch v rámci agilního týmu výrazně liší v následujících aspektech:
-
Děláme je v několika fázích: úvodní hrubá wide & shallow (pro identifikaci přibližného dopadu a prvotní prioritizaci), pozdější detailnější narrow & deep (pro přesnější rozpad a odhady před vlastní implementací).
-
Je to týmová spolupráce včetně vývojářů a testerů, ne dílo jednoho člověka (analytik) či dvou lidí (analytik, architekt, který danou práci pak navíc nedělá).
-
Hojně využíváme prototypy, mockupy, testy a good enough modely.
-
Jedná se o Just-In-Time aktivitu vykonanou co nejblíž vlastní realizaci, abychom předešli plýtvání kapacitami, když danou věc nakonec nebudeme dělat nebo se mezitím změní (velmi častý případ).
-
Vše vzniká interaktivní (workshopovou) formou místo neefektivního sekvenčního předávání dokumentů (zdlouhavé reakce, interpretační domněnky).
V rámci workshopu si nejen teoreticky představíme a vysvětlíme tyto rozdíly, ale hlavně se o nich budeme bavit, modelovat příklady z vašeho prostředí a generovat možné kroky, které můžete uplatnit u vás.
Workshop je vhodný pro:
-
product owner - PO,
-
produktový manažer,
-
analytici všeho druhu (byznys analytik, systémový analytik),
-
UX role,
-
architekti,
-
(seniorní) vývojáři více zapojení do analýz a odhadů
-
PMO a projektoví manažeři
-
portfolio manažeři
-
střední management i vedení firem
