Lekce 14 - Úvod do vývoje softwaru

V předchozím kvízu, Kvíz - Přístupy k testování, management testování a rizik, jsme si ověřili nabyté zkušenosti z předchozích lekcí.

V dnešním tutoriálu si uvedeme běžné problémy při vývoji softwaru a jejich možné řešení. Podíváme se na metodiku code and fix, řešení rizik při vývoji softwaru a rovněž na projektový trojimperativ. Také se dozvíme, jaký je rozdíl mezi tradiční a agilní metodikou.

Tato lekce je součástí kurzu Metodiky vývoje softwaru.

Pokud se již nějaký ten rok pohybujete v IT, programujete, vytváříte UX design nebo jinou činnost spjatou s vývojem softwaru, zcela jistě jste se už 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, s nimiž jste se mohli setkat, jsou tyto situace:

• Projekt se nestihne dodělat včas.
• Projekt je dražší, než jsme č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 zpočá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 s tím, že platba bude muset ještě komunikovat s externími systémy, nepočítali, 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 podobných problémů 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.

Metodika ve vývoji softwaru naproti tomu představuje sadu doporučených praktik a postupů pokrývajících celý software development life cycle (od návrhu až po provoz).

Metodika i metodologie se anglicky řeknou „methodology“, kvůli čemuž se tyto pojmy v češtině mnohdy chybně zaměňují. Každý z pojmů má však jiný význam.

Code and fix

Pro lepší pochopení si ukážeme jednu z nejzákladnějších metodik, kterou používáme při programování malé aplikace. Jedná se o code and fix. Metodika má tři základní body:

• implementaci,
• opravu chyb,
• rozšíření (další implementaci).

Asi je zřejmé, že tato metodika má určité nevýhody. Na větších projektech selhává, neboť je u ní výsledek projektu mnohdy nejasný. Metodika typu code and fix by nám tedy v praxi nevystačila. Jak jsme si již řekli, klient mnohdy ani neví, co chce, a tyto informace od něj musí často získat projektový manažer.

Firmy obvykle investují do IT jen kolem 6 % svého obratu.

Statistiky

Musíme si uvědomit, že softwarový vývoj je na rozdíl od elektrotechniky, které se lidstvo věnuje zhruba posledních 300 let, poněkud „mladá“ disciplína. Softwarovým vývojem se zabýváme pouze od roku 1960 (a to informační systémy nebyly tak komplexní jako dnes).

Z tohoto důvodu se úspěšně dokončí pouze 60 % projektů. Úspěšně dokončeným projektem rozumíme takový, jenž nepřesáhl předem domluvený rozpočet a termín dokončení (tzv. deadline).

Při tzv. tradiční metodice je úspěšnost pouze 40 %. Tradiční metodika je popsána dále v článku.

Protože zákazníci mají často nerealistická očekávání, projekt průměrně 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:

1. Téměř polovina vývojářů plně nechápe/nevidí přidanou hodnotu v softwaru.
2. Většina projektových manažerů nevěří v úspěch projektu.
3. Jedná se o příliš velký projekt (projekty s rozpočtem kolem 10 mil. dolarů 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, co zákazník přesně potřebuje. Mnohdy se stává, že zákazník zvolí nevhodné řešení, protože problematice pořádně nerozumí. Je na nás, abychom se kromě programování podíleli i na zapojování softwaru do business problematiky a pochopili jsme tzv. use case 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ší pro náš projekt.

Projektový trojimperativ (trojúhelník)

Kvalita projektu záleží na scope (rozsahu), price (rozpočtu) a delivery (termínu dodání).

Vraťme se k příkladu s e-shopem, který jsme si uvedli na začátku. Změna zákazníkových požadavků vedla ke změně rozsahu (klient požadoval vlastnost, s níž 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í, kteří mohou na projektu aktivně pracovat. Samozřejmě můžeme do jisté míry zkrátit dobu dodání, ale jen za cenu většího rozpočtu (většího týmu). Od určitého počtu členů týmu se však produktivita začne opět snižovat. Zaměstnanci si totiž začnou překážet a mohou způsobit spíše více problémů než užitku.

Když tedy změníme jeden parametr (např. rozsah), minimálně jeden další parametr tím ovlivníme. 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 SDLC. Tyto kombinace fixních a variabilních složek typicky rozdělujeme na dva typy metodik:

• tradiční metodika,
• agilní metodika.

Tradiční metodika

V tradičních metodikách platí, že fixní je 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. Jedním z důvodů 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 její point of sale (POS), tedy v překladu pokladní místo, obsahuje i samoobslužné kasy, ale my klientovi vyvíjíme POS, které je určeno pouze pro zaměstnance (prodavačky).

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ím metodikám mají projekty typicky vyšší kvalitu, jelikož se projekt adaptuje na vnější faktory. Konkurence přidá samoobslužné POS a nám nečiní problém se přizpůsobit a vytvořit jej také (rozsah projektu je variabilní).

Tato metodika lze znázornit zase tímto schématem:

Agilní metodika má, stejně jako tradiční, také řadu svých nevýhod. Agilní metodiky mají tendenci být kvůli měnícímu se rozsahu chaotičtější. Dále také více zapojují klienta. Klient však nemá vždy č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 upravuje podle sebe, aby lépe vyhověly vlastním případům užití.

V další lekci, Metodika SCRUM, se podíváme na vývojovou metodiku, kterou používá až 40 procent společností. Tato metodika se nazývá SCRUM.