Sablona prispevky MSI

Prepis

1 STIHNEME TO? PROBLÉMY S PLÁNOVANÍM SOFTVÉROVÉHO PROJEKTU Lenivosť zabíja akýkoľvek projekt. Róbert Sopko Slovenská technická univerzita Fakulta informatiky a informačných technológií Ilkovičova 3, Bratislava Xsopkor1[zavináč]stuba[.]sk Abstrakt. Softvérové produkty sa st{vajú st{le potrebnejšou súčasťou našich životov a prenikajú do všetkých sfér spoločnosti. Do vývoja softvéru sa vkladajú nemalé finančné prostriedky a tiež nemalé n{deje, že softvér prinesie očak{vané výhody a bude spoľahlivo fungovať. Napriek tomu je množstvo vyvinutého softvéru odsúdené na zahodenie, pretože buď nespĺňa požiadavky z{kazníkov alebo obsahuje príliš veľa chýb. Ďalšia veľk{ skupina softvérových projektov síce dok{že priniesť želaný produkt, ale za cenu značne prekročených časových a finančných nákladov. Dôvodov, ktoré tento stav spôsobujú je viacero, ale hlavným z nich je väčšinou zlé pl{novanie. V tejto eseji som zhodnotil možnosti boja s neurčitosťou v plánovaní softvérového projektu pomocou agilných metód vývoja. Kľúčové slová: plánovanie, adaptívne plánovanie, agilné metódy Úvod Každý, kto sa púšťa do akéhokoľvek projektu dúfa, že jeho projekt bude úspešný. Čo je to však úspešný projekt? Je to projekt ukončený včas? Projekt spĺňajúci všetky požiadavky? Projekt, ktorý neprekročí pridelené prostriedky? Vo väčšine prípadov je to kombinácia týchto troch požiadaviek, pričom z{leží na tom, ktorá z nich je pre daný projekt dôležitejšia. Je však zrejmé, že nie každý projekt sa v konečnom dôsledku podarí úspešne dokončiť, pre niektoré projekty je dokonca lepšie, ak sa včas rozhodne, že v projekte nemá Manažment projektov softvérových a informačných systémov, 2009, s. 1-7

2 2 Róbert Sopko zmysel pokračovať. Na túto tému raz Ježiš hovoril svojim učeníkom takto: Lebo keď niekto z v{s chce stavať vežu, či si najprv nezasadne a nespočíta n{klad, či m{ z čoho dostaviť? Aby sa mu potom, keď položil z{klad, a nemohol dostavať, nezačali všetci, ktorí to vidia, posmievať a hovoriť: Tento človek začal stavať, a nemohol dostaviť [7]. Väčšina neúspešných projektov končí práve takýmto štýlom - položia sa základy, do projektu sú investované nemalé časové aj finančné prostriedky a nakoniec, často až veľmi neskoro, sa zistí, že projekt nie je možné s dostupnými zdrojmi dokončiť včas a v požadovanom rozsahu. Okrem posmievania sa všetkých konkurenčných spoločností má krach projektu spravidla vždy za následok aj nemalé finančné straty, ktoré môžu viesť až k existenčným problémom takejto neúspešnej spoločnosti a jej zákazníkov. Realizovať projekt netriviálnych rozmerov je však vždy riskantná z{ležitosť. Na jeho priebeh vplýva veľké množstvo faktorov, niekedy úplné nepredvídateľných. Nikto preto na začiatku nedok{že s istotou povedať, či projekt bude úspešný alebo nie. Teda nie je možné presne určiť, či projekt bude spĺňať všetky požiadavky, či bude ukončený včas a či budú stačiť zdroje, ktoré sú k dispozícii. Napriek tomu, na tieto tri základne otázky Čo? Kedy? A za koľko? si potrebujeme odpovedať ešte pred začiatkom projektu. Preto plánujeme a vytvárame odhady. Nie vždy sa n{m to však darí. Prečo plán zlyháva? Vývoj softvéru nie je rutinn{ činnosť, ktor{ by sa dala ľahko a jednoznačne napl{novať na z{klade predošlých skúseností alebo dobre zn{mych podmienok. Každý projekt musí byť z istého hľadiska jedinečný, inak nem{ zmysel ho robiť, a t{to jedinečnosť spôsobuje, že projektový manažér pri pl{novaní projektu nemôže čerpať z predošlých skúseností, keďže často žiadne nie sú, a nevie určiť všetky podmienky, ktoré budú vplývať na vývoj projektu. Zo známeho Boehmovho kužeľa neistoty vyplýva, že časové odhady v začiatočnej f{ze projektu sú typicky 60% až 160% mimo re{lnych hodnôt. Neistota pri odhadovaní a pl{novaní projektu sa znižuje ako projekt napreduje *1]. Preto pokusy o vytvorenie presného plánu na začiatku projektu, berúc do úvahy v danom čase zn{me požiadavky z{kazníka a podmienky vplývajúce na projekt sú pri netrivi{lnych projektoch vždy len utópiou. Akokoľvek l{kavo to môže vyzerať, takéto pl{novanie je veľmi nebezpečné, keďže v prvotných fázach projektu vytvára ilúziu, že všetko ide podľa pl{nu. N{ročné a riskantné elementy, ako integr{cia systému a testovanie sú v rozvrhu odsunuté až na z{ver projektu a teda až neskôr sa zistí, že časový pl{n je podhodnotený a konkrétne definované termíny nie je možné stihnúť *5+. Príliš podrobný pl{n môže podľa môjho n{zoru u manažéra spôsobovať neochotu tento pl{n upraviť, keďže musel vynaložiť nemalé úsilie na vytvorenie takéhoto pl{nu. Strnulé dodržiavanie pôvodného pl{nu a pôvodných požiadaviek môže vyústiť do vývoja úplne nespr{vneho a neželaného produktu, keďže požiadavky z{kazníka sa môžu počas vývoja meniť a v prvotných f{zach nemusia byť úplne zrozumiteľne definované. Akokoľvek presný a detailný pl{n m{me, ak nie je flexibilne upravovaný a neodráža zmenené podmienky, ktoré v projekte nast{vajú, je vysoko pravdepodobné, že projekt nebude vedený k spokojnosti z{kazníka. Jedným z faktorov, ktoré značne vplýva na dĺžku projektu je takzvaný študentov syndróm, ktorý hovorí, že ak je na uskutočnenie nejakej činnosti napl{novan{ časov{ rezerva, tak sa t{to rezerva spotrebuje ešte skôr, ako sa činnosť vôbec začne *3]. Z vlastnej

3 Stihneme to? Problémy s plánovaním softvérového projektu 3 skúsenosti viem, že tento výrok je skutočne pravdivý. Napriek odv{žnym predsavzatiam typu "už nikdy nebudem odkladať veci na poslednú chvíľu," tento syndróm neustále útočí na vôľu každého študenta a spôsobuje, že naše úlohy plníme pod časovým stresom, čo sa samozrejme odr{ža na kvalite vykonanej pr{ce. N{sledky takéhoto prístupu celkom výstižne opísal kr{ľ Šalamún v jednom zo svojich prísloví: "Ešte trochu pospať, ešte trochu podriemať, trochu ruky zložiť a ležať - tvoja chudoba ťa prepadne ako tul{k a nedostatok ako ozbrojenec [7+." Lenivosť však nie je problémom iba študentov, ale veľmi často aj tých, ktorí už d{vno doštudovali. Vyplýva to niekedy aj z prirodzených podmienok na niektorých pracovisk{ch. Pracovníkovi je pridelen{ úloha, ktorú musí splniť za určitý čas. Pracovník vie, že túto úlohu by stihol aj za kratší čas, avšak na čo by to bolo dobré? Nebodaj si jeho manažér ešte pomyslí, že svoju skoro odovzdanú pr{cu odflákal. V takomto prostredí je teda veľmi jednoduché riadiť sa podľa Parkinsonovho z{kona, ktorý zovšeobecňuje študentov syndróm takto: "Pr{ca sa rozpína do takej miery, aby vyplnila čas potrebný na jej uskutočnenie *1]." Keďže nedok{žeme na začiatku projektu objektívne odhadnúť n{klady a čas potrebný na realizáciu, plány, ktoré nakoniec vzniknú, sú takmer vždy príliš optimistické. Keď softvérové spoločnosti bojujú o lukratívny kontrakt, je samozrejmé, že sa všetky snažia prísť s čo najlepšou ponukou a teda m{lokto v tej chvíli berie do úvahy možný negatívny vývin udalostí v priebehu projektu. Tento názor potvrdzuje aj prieskum, ktorý v roku 2004 uskutočnila spoločnosť Standish Group medzi ukončenými komerčnými a vládnymi softvérovými projektmi. Spomedzi všetkých projektov, ktoré sa zúčastnili prieskumu, len 29% bolo ukončených v r{mci rozpočtu a načas, 18% projektov vôbec nedokázalo vytvoriť použiteľný produkt. Zvyšných 53% projektov bolo ukončených neskoro a s prekročeným rozpočtom *6]. Manažéri projektu v priebehu vývoja skôr či neskôr prídu na to, že termín ukončenia nie je možné stihnúť a často sa snažia projekt rôznymi skratkami urýchliť. V praxi to býva skr{tenie alebo vypustenie niektorých f{z projektu, často pr{ve testovacej f{zy, alebo prijatie nových zamestnancov. V tomto spočíva pasca pre manažérov, ktorí si myslia, že zvýšenie počtu ľudí pracujúcich na projekte urýchli jeho vývoj. Ako to vyjadril Frederick P. Brooks, Jr. vo svojej eseji The Mythical Man-Month, pridávanie pracovných síl do meškajúceho softvérového projektu spôsobí jeho ešte väčšie omeškanie *1]. Noví zamestnanci totiž najprv potrebujú čas na zozn{menie sa s projektom, ktorý v neskorých f{zach vývoja býva už značne komplikovaný a teda ich nasadenie na projekt celkovo znižuje efektivitu všetkých pracovníkov. Z tohto vidíme, že problémy vytvorené príliš optimistickým pl{novaním na začiatku projektu sa neskôr riešia len veľmi ťažko a môžu mať za n{sledok výrazné omeškanie projektu, prípadne odovzdanie neotestovaného a chybového produktu a n{sledne veľmi nespokojných zákazníkov. Pomôžu nám agilné metódy? Riešením uvedených problémov s pl{novaním softvérového projektu môže byť nasadenie agilných metód a adaptívneho plánovania do vývoja projektu. Agilné metódy vývoja softvéru, ako sú napríklad SCRUM a extrémne programovanie (XP - extreme

4 4 Róbert Sopko Programming), dodržiavajú niekoľko z{sad a postupov, ktoré spoločne vytv{rajú priaznivé podmienky pre efektívny vývoj softvéru. Medzi ne patria [2]: Spoločn{ pr{ca v tíme. Agilné metódy zdôrazňujú dôležitosť spolupr{ce a komunikácie v rámci tímu a tiež dôležitosť častej komunik{cie so z{kazníkom. Odporúča sa dokonca mať z{kazníka fyzicky k dispozícii kvôli častému prehodnocovaniu požiadaviek na z{klade už vykonanej pr{ce. Vývoj softvéru v krátkych iteráciách. Iterácie sú spravidla krátke (1-2 týždne pri metóde XP, 30 dní pri metóde SCRUM) a každ{ iter{cia je presne časovo ohraničen{, t.j. termín ukončenia iter{cie je pevne daný a nikdy sa neposúva. Ak sa niektoré vlastnosti systému naplánované pre aktuálnu iteráciu nestihnú implementovať, presúvajú sa do ďalšej iter{cie. V každej iter{cii vyvinúť a odovzdať niečo, čo funguje. Všetky vlastnosti a funkcie produktu, ktoré sa v iter{cii podarilo implementovať, musia byť na konci iter{cie otestované a prezentovateľné zákazníkovi. To umožňuje z{kazníkovi dať vývoj{rom v každej iter{cii spätnú väzbu, či sa projekt uber{ želaným smerom a prípadný odklon od požiadaviek, prípadne ich zlé pochopenie alebo problémy s realizáciou sú rýchlo a včas odhalené. Zamerať sa na obchodné priority. Vlastnosti, ktoré m{ produkt mať a ich prioritu určuje z{kazník pomocou tzv. používateľských príbehov (user stories). Tie majú väčšinou takúto jednoduchú formu: "Ako <typ používateľa> chcem <funkčnosť/vlastnosť>, aby <komerčný význam>", teda napríklad "Ako kupca knihy chcem vyhľad{vanie kníh podľa ISBN, aby som vedel rýchlo n{jsť tú spr{vnu knihu." Vývoj{ri analyzujú a v iter{ci{ch implementujú používateľské príbehy podľa priority, ktorú z{kazník určil. Kontrola a prispôsobovanie sa. Pri agilnom vývoji softvéru je neustále kontrolovaný stav projektu. Po každej iter{cii je jasné, ktoré vlastnosti výsledného produktu už sú funkčné a ktoré nie. Používa sa adaptívne pl{novanie, teda pl{ny sa prispôsobujú novým inform{ci{m, ktoré prinesie každ{ iterácia. Manifest agilného vývoja softvéru tiež odporúča uprednostňovať: ľudí a ich pr{cu pred procesmi a nástrojmi funkčný softvér pred vyčerp{vajúcou dokument{ciou spoluprácu so zákazníkom pred vyjednávaním o zmluve zohľadňovanie zmien pred dodržiavaním plánu Tieto z{sady a postupy agilného vývoja spolu navz{jom veľmi úzko súvisia a dopĺňajú sa. Napr. Wells o agilných metódach píše *5+: "Je to niečo veľmi podobné skladačke, v ktorej m{me množstvo malých kúskov. Samostatne tieto kúsky ned{vajú zmysel, ale keď skombinujeme, môžme vidieť kompletný obraz. " Je preto veľmi riskantné upravovať agilné metódy vynechaním niektorých postupov. Nasledovanie týchto z{sad môže výrazne zefektívniť pr{cu na softvérovom projekte a skr{tiť čas úspešného vývoja. Výhodou pri agilnom vývoji je adaptívne plánovanie, ktoré je schopné neustále reagovať na zmeny podmienok a pritom nie je zložité na realiz{ciu - na začiatku sa nevytv{ra podrobný pl{n pre celý projekt. Používa sa pl{novanie na troch úrovniach:

5 Stihneme to? Problémy s plánovaním softvérového projektu 5 pl{novanie vydania softvéru, pl{novanie iter{cie a denné pl{novanie. Na každej úrovni sa plánuje s primeranou granularitou detailov. Plánovanie vydania softvéru býva v horizonte troch až šiestich mesiacov a predstavuje hrubé odhady času dokončenia časti systému. Tieto odhady sa prehodnocujú a zjemňujú s každou ďalšou iter{ciou. Iter{cia sa pl{nuje detailnejšie, v horizonte jedného (XP) až štyroch týždňov (SCRUM). Pred každou iteráciou sa odohráva takzvaná plánovacia hra (planning game), v ktorej zákazník, alebo jeho z{stupca určí ešte nezrealizované používateľské príbehy, ktoré sú pre neho dôležité a vývojový tím po vzájomnej komunikácii so zákazníkom a spresnení detailov odhadne čas potrebný na uskutočnenie týchto používateľských príbehov. Po vz{jomnej dohode z{kazníka s tímom sa teda určí, ktoré vlastnosti softvérového produktu je re{lne implementovať v najbližšej iter{cii. N{sledne každý (alebo každý druhý) deň v priebehu iter{cie sa tím stret{va a každý člen tímu si volí spomedzi element{rnych úloh tvoriacich jednotlivé používateľské príbehy. Tím spoločne určí každému úlohy na daný deň a každý tiež na tímovom stretnutí referuje čo už dosiahol a s čím m{ problém. Tento systém kr{tkych denných stretnutí tímu m{ podľa môjho n{zoru z{sadný vplyv na úspešné dodržiavanie pl{nu iter{cie, pretože rýchlo odhaľuje vzniknuté problémy a umožňuje ich kolektívne riešenie. Členovia vývojového tímu sa zlepšujú v odhadovaní času, ktorý potrebujú na zvl{dnutie jednotlivých úloh. Z{roveň je takto veľmi rýchlo odhalený každý člen tímu, ktorý potenci{lne trpí študentovým syndrómom. Pevne stanovený termín ukončenia iter{cie (tzv. timeboxing) tiež motivuje vývojový tím k dosahovaniu dobrých výsledkov v podobe funkčných a otestovaných častí softvérového produktu. Neoceniteľnou výhodou agilných metód riadenia projektu je intenzívna komunik{cia so z{kazníkom. Vďaka tomuto princípu je takmer nemožné aby tím vyvíjal niečo, čo z{kazník nepotrebuje, alebo čo nespĺňa jeho požiadavky, dlhšie ako je trvanie jednej iterácie. Neustála kontrola, či produkt spĺňa požiadavky a testovanie každej funkčnej časti produktu pred ukončením iter{cie d{va vývoj{rom odvahu robiť zmeny vyplývajúce z nových požiadaviek z{kazníka, ktoré by za iných okolností (neotestovaný systém) mohli spôsobiť neočak{vané a ťažko riešiteľné problémy. Dá sa to ešte vylepšiť? Hoci agilné metódy vývoja softvéru prin{šajú vyššie spomenuté výhody umožňujúce jednoduchšie pl{novanie, efektívnejšie využitie schopností členov vývojového tímu a rýchlejší vývin želaného produktu s minim{lnym počtom chýb, nedok{žu riešiť všetky problémy ktoré s vývojom a plánovaním softvérového projektu súvisia. Aj pri agilnom vývoji je dlhodobé pl{novanie st{le veľmi neisté. Keďže v r{mci agilných metód sa počíta s možnou zmenou požiadaviek pri každej iterácii, nemá zmysel a ani nie je odporúčané pl{novať viac iter{cií dopredu. Z toho dôvodu nie je presne zn{me koľko iter{cií bude potrebných na dokončenie projektu. Pl{novanie používateľských príbehov, ktoré sa budú implementovať v aktu{lnej iterácii je tiež neurčité. Ako to vyplýva z niektorých prípadových štúdií *4], vývojári niekedy nevedia spr{vne odhadnúť ako dlho bude trvať implement{cia daného príbehu, ktorý v sebe môže skrývať detaily vyžadujúce viac pr{ce, ako sa predpokladalo. Zaujímavé možnosti však prin{ša výskum v tejto oblasti, ktorý sa snaží n{jsť riešenie tejto neistoty pri pl{novaní agilného vývoja použitím štatistickej simul{cie *6]. Agilné metódy

6 6 Róbert Sopko určovania komerčnej priority používateľských príbehov a veľkosti príbehu (času potrebného na jeho realiz{ciu) obohacuje o použitie troch hodnôt odhadu miesto jednej. Nový postup vyžaduje pesimistický, najpravdepodobnejší a optimistický odhad pre každý príbeh. Z týchto hodnôt sa vytvorí pravdepodobnostné rozloženie pomocou PERT distribúcie. Výhodou tohto postupu je možnosť určiť, ktoré príbehy je pravdepodobne možné realizovať v najbližšej iter{cii a tiež pravdepodobný počet iter{cií celého projektu. Ako teda vieme, či to stihneme? Je pravdou, že nikdy s absolútnou istotou nevieme určiť reálny čas dokončenia softvérového projektu. Samozrejme, je možné, že ak určíme termín ukončenia s dostatočnou rezervou, projekt sa podarí v danom čase ukončiť. Ako však bolo spomenuté, v praxi sa spravidla termíny ukončenia projektu určujú skôr optimisticky ako pesimisticky a prípadn{ časov{ rezerva sa vďaka Parkinsonovmu z{konu väčšinou minie veľmi rýchlo. Použitie agilných metód pri riadení softvérového projektu síce tiež ned{va istotu, ale vďaka svojim charakteristickým vlastnostiam spomenutým v tejto eseji prin{ša oproti iným klasickým metódam vyššiu pravdepodobnosť, že projekt bude úspešne ukončený v stanovenom termíne a s maxim{lnym množstvom vlastností, ktoré sú pre z{kazníka dôležité. Použitá literatúra 1. Brooks, F.: The mythical man-month : essays on software engineering 2. Cohn, M.: Agile estimating and planning 3. Hajkr, J., Staníček, Z.: Řízení projektů zav{dění IS do organizací 4. Janoff, N., Rising, L.: The Scrum Software Development Process for Small Teams 5. Larman, C.: Agile and iterative development : a manager's guide 6. Logue, K., McDaid, K.: Handling Uncertainty in Agile Requirement Prioritization and Scheduling Using Statistical Simulation 7. prekladateľské skupiny pre Starú zmluvu a Novú zmluvu: Ekumenická Biblia, Slovensk{ biblick{ spoločnosť, 2008 Annotation Can we make it? Difficulties with software project planning Software products represent a constantly greater and greater need in our lives and they already penetrate all areas of our society. Great financial resources and high hopes are poured into software development, expecting that the software will bring anticipated advantage and that it will be reliable. Nevertheless, a great amount of software is destined to be thrown away because it either doesn t meet the customer s requirements or it contains too many bugs and failures. Another great group of software projects is able to produce a desired product, but with the cost of highly exceeded time and budget. There are more factors that cause this situation, but the main one is usually bad

7 Stihneme to? Problémy s plánovaním softvérového projektu 7 planning. In this essay I review the most common causes that affect the quality of software project planning negatively and the benefits that the agile methods of software development bring into software project planning and estimation.