Softwarové projekty

 

Tento krátky článok vznikol ako reakcia na prečítanie publikácie Jima McCarthyho (Softwarové projekty): Dynamic of Software Development – Microsoft Press 1995. Pri riadení softwarových projektov je veľmi dôležité, aby ľudia pochopili, o čom vývoj vlastne je – mám na mysli hlavne manažment, tak zhrniem základné fakty a pridám aj môj komentár a skúsenosti. Článok je písaný formou poznámok – čitateľ to dúfam odpustí:

-          Dôležité je si uzvedomiť, že programovanie (podobne ako medicína) nie je exaktná veda.

o   Ktorý lekár povie dopredu ako dopadne operácia? Tak ako sa podrobne nedá naplánovať operácia (design dokument) so všetkými vedľajšími faktormi, tak ani softwarový projekt. Dôležitejšie je ale správne rozhodovať keď sa začnú veci objasnovať počas vývoj (toto štádium ale manažerí nepoznajú, pre nich to skončilo posledným riadkom dokumentu).

o    Aj banálny zákrok (operácia / požiadavka) môže mať následky smrti (človeka / projektu). Preto je doležité vážiť si v tíme ľudí, ktorí sú schopní identifikovať problémy pred tým, než vôbec vzniknú – väčsina programátorov totiž inkliknuje ku pocitu, že všetko sa spraví... veď doteraz sa to spravilo. Tu by som podotkol, že riadenie softwarových projektov je pre zodpovednú osobu (líder) niečo ako ruská ruleta. Denno-denne  sa robia rozhodnutia, ktoré nemôže nikto dopredu garantovať a pritom ide väčšinou o osud firmy (a jej zamestnancov).

 

-          Rozdiel medzi manažérom a líderom je v tom, že manažér potrebuje vedieť kedy a ako sa veci spravia, líder musí vedieť čo a prečo sa to robiť má!

 

-          Software nie je možné riadiť Fordovým systémom, pretože sa jedná o duševnú prácu! Rozprával som sa s jedným kapitánom firmy Raynar. Povedal zaujímvú myšlienku (v časoch pritvrdzovania firemnej politiky), že ak šéf pôjde proti pilotom, môže sa mu to vypomstiť. Pilot ak CHCE, dokáže ušetriť tony paliva. Toto sa ale prikázať nedá. Ide totiž o motiváciu, ktorú dokáže pilot stratiť niečím takým, ako je zrušenie občerstvenia pre posádku! Rovnakou „správnou“ cestou vie aj programátor navrhovať systémy komponentárne, kde sa prihliada na znovapoužiteľnosť – takýmto spôsobom sa dajú ušetriť neuveriteľné prostriedky z hľadiska budúcnosti!

U nás sme identifikovali často opakujúce sa procesy a vytvorili sme sady knižníc či statických tried, ktoré sú „skopirovateľné“ a znovapoužiteľné takmer okamžite. Naštartovanie nového projektu trvalo mesiac (s prihliadaním na to, že sa to opakovať bude... v blízkej budúcnosti – aj keď požiadavka taká nebola... vedenie o postupoch nemá totiž prehľad). Keď sa predchádzalo na ďalší projekt, trvalo to už len 4 dni a pri poslednom len 6 hodín! Základné veci boli už natoľko odladené a tím vedel čo robiť, že netrebalo nič nové vymýšlať (jedná sa o často sa opakujúce veci ako je design, GUI komponenty, inštalátor, upgradovacie systémy databáz apod.).

 

-          V softwari nie je možné myslieť na všetky aspekty a toto si musí uvedomiť každý (hlavne vedenie) – ináč sa tím bude snažiť v prípade problému problém zakrývať (čo je kontraproduktívne). Nám sa to stalo, keď sme zle odhadli požiadavky zákaznika. Mysleli sme si, že systém je nutné spravovať on-line (ako väčšinu aplikácii zákazníka). Zákazník si myslel, že nie je problém tento systém spravovať off-line (desktop) a keďže sme nemali času, žiadna zo strán túto tému rozoberať nechcela (všetci radšej žili v ilúzii). Systém bol navrhnutý a vytvorený pod Silverlight technológiou kde síce možnosť desktopovej aplikácie bola, ale konfort bol tak malý (zbytočná SOAP vrstva ktorá komplikovala a spomaľovala vývoj) a predsta riešenia problémov aplikácie distribuovanej s webovým serverom je tak naivná, že ak by sme dopredu nezačali diskusiu na túto témy (hoci sa nikomu nechcelo), kľúčový produkt zákazníka mu mohol zlomiť väz!

 

-          Počas vývojá je projekt rozdelený medzi viacero zložiek:

o    časť je v plánoch (na papieri – tzv. design dokument)

o    časť v už existujúcom kóde

o    časť v hlave vývojára

o    o zvyšnej časti ešte nikto nevie

 

-          Ak je časový skĺz, sú riešenia:

o    Zväčšiť objem prác (zbohom víkendy a Vianoce) – pozor na vyhorenie kľúčových osôb (nezabúdajme na Guassa – 80% projektu urobí 20% ľudí).

o    Redukcia požiadaviek – tu by som poznamenal, že jeden náš projekt zbúchaný na rýchlo trebalo dať do stavu, ktorý by už aj zákazníkom vyhovoval. Problém bol ten, že vedenie (a marketing) chcelo prísť „druhýkrát“ s verziou, ktorá by zákazníka ohromila (niečo ako Apple a i-Phone). Ku niečomu takému sme asi nemali schopný tím (doteraz si na to ja osobne netrúfam) a tak sme 8 mesiacov sa točili dookola. Problém bol v požiadavkach – vedenie chcelo zachovať pôvodnú funkčnosť a pritom chcelo prekopať logiku od základov a pridať ďalšie možnosti. To čo vedenie chcelo bolo jasné a jednoduché – no my, ako dizajnéri sme neboli schopní všetky tieto veci pospájať naraz!!! Ak sme začali rozprávať o jednej časi, mali sme vo všetkom jasne. Ak sme rozprávali o inej, aj tam to bolo jasné – problém nastal až vtedy, ak sme to mali spojiť – nevedeli sme čo bude prvé a aké dôsledky vzniknú. Po 8 mesiacoch bol projekt v kríze. Vtedy som ho prebral a zistil som, že ja osobne nie som schopný navrhnúť všetko a preto som rozdelil projekt do 4 fáz. Najprv sme prekopali logiku (a zachovali funkčnosť). Vydali sme verziu. Potom sme prešli na rozšírenia ktoré sme postupne implementovali a dokázali sme za 4 mesiace vykonať 80% všetkého. Zvyšné veci sa ukázali ako nepotrebné a doteraz neboli implementované!

o    Viacej ľudí – tu treba podotknúť, že pri softwari viacej ľudí môže pôsobiť kontraproduktívne (Brooks) čo sa odhaduje až v 80% prípadoch (kto chce riskovať či je v tej „pravej“ pätine)? Tiež sa tu hodí analógia s medicínou. Ak napríklad jeden chirurg dokáže odoperovať slepé črevo za 2 hodiny (to je len tip), tak 10 chirugov to určite nespraví za 15 minút!

 

-          Tím musí pracovať na základe motivácie, nie nariadenia (lebo sa jedná o duševnú prácu, nevyhneme sa vplyvom ľudskej psychiky – takže pozor na autokratické riadenie).  Typickým príkladom je, že na programátora tlačí dokumentarista aby niečo mal v rukách, programátor na testera, aby mal výsledky najlepšie už na druhý deň apod. Vývoj treba zastrešiť komplexne a každý si musí uvedomiť svoje miesto a miesto druhých. Keď každý si určí cieľ pri vývoji bude sa ho to osobne dotýkať (ja ti dám verziu v piatok, ja ti dám výsledky do stredy apod.)

o    Tu sa odporúča vytvárať čiastočné výsledky – treba vývoj rozdeliť na menšie časti (zodpovednou osobou, nie vedením), rovnako ako požiadavky (viď hore), ohodnotiť časovo a dodržiavať plán – ak mešká jednotlivé štádium, vie sa na to patrične reagovať (viď sklz plánu) – Čiastočné výsledky by nemali presiahnuť 15 dní. Z vlastných skúseností viem, že ak projekt rozdelíme na jednotlivé časti, vieme sa vyhnúť rizikám a časovým prešľapom. Ja osobne rád navrhujem na začiatku urobiť všetky dôležité komponenty – ak sa jedná napr. O serverovú aplikáciu komunikujúcu s inými systémami, v prvom rade musíme rozbehať komunikáciu, potom nabaľujeme business logiku. Business logiku rozdelím podľa priorít: čo zákazník musí mať, čo by mal mať a čo by mať mohol. Neraz sa stane, že termín je nakoniec dôležitejší ako zadanie (čo si vedenie na začiatku neprizná, ale je to legislaltívne dané) a v tom prípade vieme výjsť s projektom vonku aj s „nedokončeným“  projektom (navrhli sme ho tak, aby to dôležité bolo už za nami čím skôr) – tie „zvyšné“ dokončenia môžu byť realizované neskôr ako updaty (takže vedenie má termín a neskôr aj celú funkčnosť – všetci sú radi). Pri jednom projekte v čase krízy obchodné oddelenie potrebovalo zákazníkov a jedného veľkého aj našli. Po procesnej analýze sa určili základné veci: import dát zákazníka zo starej aplikácie. Samozrejme si nikto neuvedomil, že okrem samotného importu je nutné prerobiť aj logiku programu (aby vyhovovla zákazníkovi) natoľko, že to zasiahne celý systém (aj keď podotýkam pozitívne). Vtedy som naplánoval tri štádia. Prerobenie logiky na začiatku (nevedeli sme povedať odhad importu kým nemáme logiku zmenenú v celom systému – viď horné časti), samotný import zákazníckych dát a jeden uchýlný import, voči ktorému som bol vysadený už na začiatku (mixovanie starých a nových dát, čo povedie jedine ku chaosu, a teda to nikto nebude používať – mrhanie energie). Prvé štádium sme skončili skôr ako sa očákavalo a teda sa to dostalo do testovania skôr, čo začalo generovať chyby, ktoré sa opravovali paralene s vývojom druhej (najdôležiješej) etapy – tam sme ten ušetrený čas dobehli a druhý termín sme napriek rýchlosti prvého štádiu vydali v odhadovanom termíne. Tretí termín som nadhodnotil (mysliac, že vedenie to zamietne, keďže zákazník to nepotrebuje – čo sa nestalo)... celá úloha sa ukázala ako 4 hodinová záležitosť (po tom, ako už boli vytvorené prve dve štádia)... vyzeral som trocha ako debil... :-)

o    Čiastočné plánovanie vedie aj ku tzv. Funknčným zostavovaním programu (my to preferujeme hlavne v záverečnej fáze projektu) – takto vie každý člen týmu ako je na tom celý projekt (vedia sa v prípade upravovať požiadavky). Celé to vychádza z jednoduchej logiky: stavbár so šatkou na očiach možno vie staviať dom, ale ani len netuší v ktorej je fáze, kým ho nevidí. Výhody:

§  Tlak na vývojárov ku kvalite kódu (nedá sa odfláknuť tá – ktorá časť).

§  Ukážu sa závislosti reálne (nie predpokladané).

§  Ak príde niekto s novou požiadavkou (bežná realita) – dopad sa vie lepšie odhadnúť na niečom celistvom, ako na niečom úplne rozkopanom.

Tu by som chcel dodať, že vedúci testovacieho tímu u nás zastával myšlienku: testovanie na konci. Jednoznačne to vylučuje testera z vývojového cyklu, vtedy vznikajú komické situácie, kedy sa chce tester cítiť dôležito a vytkne niekedy takú vec, ktorú programátor v kontexte náročnosti úlohy považuje za urážku (alebo somarinu) – nepochopenie celého „jeho“ systému. Vtedy vzniká napätie medzi tímami (čo nie je dobré)!