Úvod do metodologie vývoje softwaru
Pokud se již nějaký ten rok pohybujeme v IT, programujeme, vytváříme UX design nebo jinou činnost spjatou s vývojem softwaru, zcela určitě jsme se setkali s projektem, se kterým byl vážný problém. Ať už se jednalo o vlastní projekt malých rozměrů nebo třeba i nějaký větší. Typickými problémy se kterými jste se mohli setkat jsou:
projekt se nestihne dodělat včas
projekt je dražší, než jste čekali
projekt se vůbec nedokončí a tzv. ztroskotá
Problémy mnohdy vznikají z toho důvodu, že zákazník téměř nikdy nemá rozmyšlené co přesně chce (alespoň ne ze začátku). Má pouze představu.
Motivace
Představme si problém projektu na úplně triviálním příkladu.
Zákazník po nás bude chtít e-shop s možností platby pouze hotově. Při nasazení e-shopu si náš zákazník uvědomí, že by chtěl lehce párovat platby pomocí externího účetního softwaru. Jelikož jsme nepočítali s tím, že platba bude muset ještě komunikovat s externími systémy, vývoj se nám výrazně zkomplikoval a prodloužil. Kdybychom tento požadavek dostali hned na začátku, nemuseli bychom předělávat část projektu.
V praxi jsou samozřejmě takové problémy výrazně komplikovanější, tento příklad byl pouze ukázkový.
Takový projekt je často znázorněn kresleným příběhem stavění houpačky:
Metodologie vs Metodika
Z takových problému, který jsme si uvedli výše, vznikla disciplína zabývající se metodami/problémy vývoje rozsáhlých softwarových systémů. Této disciplíně se říká metodologie.
Ve vývoji softwaru představuje metodika sadu doporučených praktik a postupů pokrývající celý životní cyklus tvorby softwaru (od návrhu až k provozu).
Metodika a metodologie je v angličtině „methodology“, oba pojmy mají však jiný význam. Z tohoto důvodu se v češtině mnohdy tyto pojmy zaměňují.
Code and fix
Pro lepší pochopení si ukážeme příklad nejzákladnější metodiky. Jedna z nejzákladnějších metodik, kterou používáme při programování malé aplikace, je Code and fix. Metodika má 3 základní body:
Implementace
Oprava chyb
Rozšíření (další implementace)
Asi je jasné, že má tato metodika nějaké nevýhody. Na větších projektech totiž selhává. U takovéto metodiky je mnohdy výsledek projektu nejasný. Metodika typu "Code and fix" by nám tedy v praxi nevystačila. Jak jsme si už řekli, klient mnohdy ani neví co chce a tyto informace musí často získat projektový manažer od klienta.
Firmy obvykle investují do IT jen kolem 6 % jejich obratu.
Statistiky
Musíme si uvědomit, že softwarový vývoj je poněkud „mladá“ disciplína na rozdíl od elektrotechniky, které se lidstvo věnuje téměř od počátku existence. Softwarovému vývoji se věnujeme pouze od roku 1960 (a to informační systémy nebyly zcela tak komplexní jako dnes).
Z tohoto důvodu je pouze 60 % úspěšně dokončených projektů. Úspěšně dokončeným projektem rozumíme, že nepřesáhl předem domluvený rozpočet a termín dokončení (tzv. deadline).
Při tzv. tradičních metodik je úspěšnost pouze 40 %. Tradiční metodika je popsána dále v článku.
Protože mají zákazníci často nerealistická očekávání, průměrně projekt přesáhne rozpočet o 45 %, čas o 7 % a doručí jen 44 % přidané hodnoty. Tyto problémy jsou způsobeny nejčastěji tímto:
téměř polovina vývojářů plně nechápou/nevidí přidanou hodnotu v softwaru většina projekt manažerů nevěří v úspěch projektu příliš velký projekt (projekty s rozpočtem kolem $10 mil. mají pouze 10 % úspěšnost).
Řešení rizik při vývoji softwaru
Aby se projekt stal úspěšným, měli bychom:
Pochopit problém, který zákazník řeší. Zákazník přesně ani neví, co chce. Programátor zase nechápe/nerozumí to co přesně potřebuje. Mnohdy se stává, že zákazník zvolí nevhodné řešení, protože tomu pořádně nerozumí. Je na nás, abychom se kromě programování podíleli i na zapojování softwaru do business problematiky a pochopili tak tzv. use case softwaru.
softwaru. Popsat problém „jednou“ větou.
Jasně si definovat přidanou hodnotu softwaru.
Aktivně se věnovat vývojovým metodikám, abychom mohli zvolit tu nejlepší metodiku pro náš projekt.
Projektový trojimperativ (trojúhelník)
Kvalita projektu záleží na rozsahu ( scope ), rozpočtu ( price ) a termínu dodání ( delivery ).
Vraťme se k příkladu s e-shopem, který jsme si uvedli na začátku. Změna požadavků zákazníka vedl ke změně rozsahu (klient požadoval vlastnost, s kterou jsme nepočítali). Abychom zachovali kvalitu nových vlastností, které nám ještě zbývají naimplementovat, musíme zvýšit rozpočet a oddálit termín dodání.
Uveďme si ještě jeden příklad. Typicky platí, že projekt s menším rozpočtem, má delší dobu implementace. Je to logické, menší rozpočet mnohdy znamená menší tým lidí, co můžou na projektu aktivně pracovat. Samozřejmě můžeme do jisté míry zkrátit dobu dodání, ale s větším rozpočtem (větším týmem). Od určitého počtu členů týmu se produktivita však začne zase snižovat. Zaměstnanci si totiž začnou překážet a mohou způsobit spíše víc problémů než užitku).
Když tedy změníme jeden parametr (např. rozsah), minimálně jeden další parametr je ovlivněn. To nám znázorňuje model projektový trojimperativ:
Už je tedy asi jasné, že projektový trojúhelník má fixní a variabilní složky. Fixní složka je ta, která se po celou dobu projektu nemění. Variabilní se mění v průběhu životního cyklu vývoje softwaru. Typicky tyto kombinace fixních a variabilních složek rozdělujeme na dva typy metodik:
tradiční metodika
agilní metodika
Tradiční metodika
V tradičních metodikách platí, že je fixní rozsah. Analýza se udělá typicky hned ze začátku a když s ní klient souhlasí, „podepíše ji krví“. Projekty používající tuto metodiku trpí nižší kvalitou. Jeden z důvodů nižší kvality je fakt, že vývoj většího softwaru trvá minimálně 6 měsíců a za tu dobu se toho může ledacos změnit. Například si klient u konkurence všimne, že jejich POS (Point of sale) obsahují i samoobslužné kasy, ale my klientovi pouze vyvíjíme POS, které jsou určeny pouze pro zaměstnance (prodavačky).
POS je anglická zkratka, která v překladu znamená pokladní místo
Tento příklad zase berte s nadhledem
Tuto metodiku můžeme vyjádřit tímto schématem:
Agilní metodika
U agilních metodik je fixní rozpočet a termín dodání. Rozsah je variabilní. Oproti tradičních metodik mají projekty typicky vyšší kvalitu, jelikož se projekt adaptuje vnějším faktorům. Konkurence přidá samoobslužný POS a nám nedělá problém se přizpůsobit a vytvořit je taky (rozsah projektu je variabilní).
Tato metodika lze znázornit zase tímto schématem:
Agilní metodika, stejně jako tradiční, má taky řadu svých nevýhod. Agilní metodiky mají tendenci být více chaotické, kvůli měnícímu se rozsahu. Dále mají tyto metodiky tendenci víc zapojovat klienta. Ne vždy má však klient čas řešit analýzy.
Závěr
Je mnoho faktorů ovlivňující výběr správné metodiky. Je důležité pochopit, že se jedná pouze o souhrn doporučení. Mnoho firem si různé metodiky upravují podle sebe, aby lépe vyhověla jejich případům užití.
V následujících lekcích si ukážeme nejznámější a nepoužívanější metodiky.
V další lekci, Metodiky RAD a DSDM, se podíváme na metodiky RAD a DSDM, které spolu tak trochu souvisí.
