Trocha toho extrémismu

9. prosince 2002

•

Ve svém předchozím článku jsem se zmínil o typických rizicích, která na nás záludně číhají při každém rozsáhlejším softwarovém projektu. Tentokrát se pokusím nastínit metodiku projektového řízení, která je na předcházení rizik přímo postavena.

Co lze vlastně na chování programátorů v divočině vypozorovat? Každý snad někdy zažil projekt, který začal nadšeným leč bezhlavým kódováním, vyznačoval se nechutí k vypracovávání či dokonce respektování jakékoli rozsáhlejší projektové dokumentace, tu a tam si někteří vývojáři přepisovali kusy kódu pod rukama, zkrátka děs a hrůza. A výsledkem byl pochopitelně chaos, který podle závažnosti výsledného fiaska dovedl i nejzarytější sklepní programátory k poznání potřeby jakési ucelenější metodiky, která nám pomůže projekt držet poněkud lépe pod kontrolou.

V expozici předchozího článku jsme si vyjmenovali typická rizika a seznámili se s krizovými stavy, které mohou nastat i při důkladné aplikaci tradičních postupů řízení projektu. Víme o nich, že je lze eliminovat pouze na základě odhadů vycházejících ze zkušeností s projekty obdobnými a s notnou dávkou předvídavosti. Nyní na scénu vstupuje alternativní metodika řízení projektů, a protože zde již máme metodiku tradiční, nadchází nevyhnutelně menší…

Kolize

Nyní si zkusíme trochu rozvést zvídavé otázky typu „a nešlo by to nějak jinak“ z minulého článku do konstruktivnější podoby „a nešlo by to třeba takhle?“

Zpoždění harmonogramu

Co kdyby od nás klient nežádal suplování delfské věštírny, ale na místo toho s důvěrou přijal skutečnost, že rychlý vývoj je v zájmu obou stran, a vývoj by se namísto dlouze plánovaných etap skládal z krátkých a poměrně předvídatelných iterací o délce jednoho až tří týdnů?

Přemíra chyb ve výsledném produktu

Co kdybychom – nejlépe ve spolupráci s klientem – jak pro každý integrační krok, tak i pro každou dílčí funkcionalitu definovali správnost balíkem jednoduchých testů? A co teprve, kdybychom tyto testy vytvořili ještě před první čárkou funkčního kódu a jejich co nejčastějším průběžným spouštěním se ujišťovali o relativní bezchybnosti vyvíjeného kódu?

A co teprve kdybychom projekt nerozškatulkovávali mezi separované vývojáře, kteří si každý v klidu píší svou ideálně zapouzdřenou komponentu, ale na místo toho směřovali své programátory k sdílení svých problémů, intenzivní komunikaci, ba dokonce toto vynucovali tím, že je necháme cirkulovat mezi jednotlivými projektovými moduly? Nebojte se, že by je to začalo příliš bavit – samozřejmě, že začne, ale to je přece dobře, ne?

Nepochopení zadání

Co kdybychom namísto rozsáhlé analýzy, která zabírá spoustu času a budí v nezkušeném klientovi nedůvěru („Vážně pro mě za těch půl mega máte jen tenhle štůsek papírů?“) zkusili s klientem komunikovat jazykem, kterému rozumí jak on, tak naši programátoři? Tedy jazykem jednoduchých a rychle vytvářených prototypů požadovaného produktu.

A co teprve, kdyby nám dal klient k dispozici na co nejvyšší úvazek jednoho svého pracovníka, nejlépe uživatele produktu, a ten by sledoval vývoj z největší blízkosti? Pokud by byl technicky zdatný, třeba by se i zapojil do vývoje, a hlavně by měl neustále jasnou představu o tom, nakolik se začínáme odchylovat od původních představ.

Časté průběžné změny zadání

Co kdyby k nim díky přítomnosti klienta na pracovišti a krátkým vývojovým iterakcím vůbec nemuselo dojít? A pokud ano, co kdyby se díky silné komunikaci mezi programátory daly náklady na změnu snáze odhadnout? A ty testy, nedodají nám při zavádění změn trochu odvahy, když nás budou okamžitě upozorňovat na problémy, které si zanášením změn vytváříme?

Zbytečně komplikovaný produkt

Co kdybychom na základě výše zmíněných návrhů jako sdílení znalostí mezi programátory a důkladné testovaní, na základě důkladného využívání současných vývojových nástrojů, na základě co nejjednoduššího dosud realizovaného návrhu a mimo jiné i na základě dosud nezmíněného řešení problémů fluktuace pracovníků, dokázali získat oprávněnou důvěru v to, že náklady na změnu neporostou s časem exponenciálně, jak se často stává, ale tempem mnohem únosnějším?

To bychom se pak s klidným srdcem mohli soustředit na problémy, které máme, a potenciální zobecňování a rozšiřování odložit na čas, kdy budeme vědět, že jejich potřeba skutečně nastala.

Fluktuace pracovníků

Co kdybychom zde již nevymýšleli žádné další „co kdyby“? Velké části kódu rozumí víceméně všichni zúčastnění programátoři (možná i zástupce klienta) a navíc námi vytvořené testy drží chování produktu pevnou rukou pohromadě. Problém škrtáme.

Och… nebylo by to krásné?

Expozice podruhé

Nyní známe rizika a dokonce už i máme nějakou vizi, kudy by se snad dalo cestou k jejich eliminaci ubírat. Z nadpisu článku tušíme, že nastala ta pravá chvíle říci si něco o tom, co že to to slavné extrémní programování (dále též XP) vlastně je. Odbočme nyní od krásných představ o avantgardních technikách slalomu mezi riziky a podívejme se na XP od základů.

Stejně jako buddhismus vychází ze čtyř vznešených pravd, má i extrémní programování čtyři základní hodnoty:

Komunikace

Mnoho potíží vyplývá z chyb v komunikaci. XP tento problém řeší rafinovaně: nutí nás věnovat pozornost činnostem testování jednotek, společnému plánování jednotlivých krátkých iterakcí, a dokonce zavádí věc od pohledu extrémní, a to programování ve dvojicích. Jistě uznáte, že tyto postupy si dobrou komunikaci zkrátka vynutí.

Jednoduchost

Klíčová otázka XP zní: „Jaká nejjednodušší varianta by ještě mohla fungovat?“

Výše zmíněné dilema, zda ztrácet čas zobecňováním či nikoli, rozsekává XP tím, že zavádí principy, které usnadňují pozdější implementaci změn. Díky tomu můžeme předpokládat, že je lepší implementovat jednoduché a přímočaré řešení dnes (a možná zaplatit o něco více za případné úpravy zítra), než vyhodit předem peníze za geniální abstrakci, kterou dost možná nikdy nevyužijete.

A stejně jako u následujích hodnot, už zde si můžeme všimnout jisté provázanosti: dobrá komunikace nám pomáhá udělat si lepší obrázek o tom, co je a co není třeba, a naopak o jednoduchém systému se komunikuje bezesporu snáze než komplexním monstru.

Zpětná vazba

Nevím, čím to, ale všichni programátoři, které znám (včetně mé osoby), trpí ohledně funkčnosti svého kódu doslova chorobným optimismem. Proto se každý rozumný project manager snaží přimět své ovečky k intenzivní konfrontaci s realitou. XP v tom není výjimkou. Zpětnou vazbu po nás chce neustále, v krátkodobém i dlouhodobém horizontu, od testů jednotek přes rychlé prototypování až po integrační testování, testování funkčních požadavků a vlastně i podporu systému po uvedení do provozu, to vše samozřejmě s maximální účastí zákazníka.

Opět vidíme souvislost s komunikací a jednoduchostí. Zpětná vazba usnadňuje komunikaci, jasná komunikace a jednoduchost systému usnadňuje testování a naopak testování nám pomáhá udržet systém jednoduchý.

Odvaha

Stávat by se to nemělo, ale realita je někdy jiná. V půlce projektu zjistíme, že je všechno špatně. Návrh systému jsme zvorali jak jen mohli. Zdrojový kód se stává jedním velkým „dirty-patchem“, začínáme se zamotávat do látání nedostatků, kterými způsobujeme další závady, produktivita klesá, znechucení programátorů roste. Z této agonie se můžeme přitom dostat velmi snadno – velkou část zdrojového kódu prostě zahodíme a začneme znovu. Sice nám práce napodruhé jistě půjde lépe od ruky, určitě však tento krok vyžaduje notnou dávku odvahy.

Jindy se ve stadiu návrhu nemůžeme rozhodnout mezi několika základními variantami. Projektová porada se mění v rétorické cvičení a výsledek žádný. Nežli zabít několik dní diskusemi o architektuře, může být efektivnější pro každou variantu načrtnout jednoduchý zdrojáček, jen abychom si své teoretizování ověřili v praxi. Neživotaschopné návrhy po vzoru starých Sparťanů hodíme ze skály a jedeme dál.

Obecně řečeno – máme nápad? Tak o něm nebudeme jen mluvit, místo toho se pustíme do práce a předvedeme ho ostatním v praxi. Pokud si věříme, proč ne?

Jeví se vám tyto kacířské myšlenky čirým hazardem? Samozřejmě, že bez aplikace prvních tří hodnot budete mít pravdu. Avšak komunikace, jednoduchost i zpětná vazba nám dodávají potřebnou jistotu a na oplátku s trochou odvahy se jistě snáze vyhneme pokušení zanášet do systému zbytečně komplexní prvky.

Nevěříte? Zkuste to. V příštím článku se ponoříme do konkrétních peripetií nasazování extrémního programování v praxi.