Jiří Hradil blog

Proces vývoje software odráží několik posledních let jasný trend - nestálost prostředí a připravenost na změny. Pokud shrneme několik agilních metodik (extrémní programování, Scrum, RUP), tak řeší v podstatě naprosto stejné věci-krátké iterace, testy, otevřenost, zeptej se kódu, atd.  Některé z těchto pravidel rozeberu.

Vyvíjíme po malých částech, čili v iteracích=cyklech=sprintech. Jedním z důvodů je nestálost prostředí, ve kterém má být software používán (např. situace na trhu či legislativa), ale hlavně neschopnost a nemožnost vyprodukovat stabilní analýzu systému, podle které se dá programovat. Analytiky software považuji za dinosaury, jejichž doba dávno skončila a při vývoji software jednoduše nejsou potřeba. Základ software z pohledu uživatele má navrhnout klient a proveditelnost návrhu určují koneční vývojáři. Setkal jsem se s tím, že analytik (který nikdy neprogramoval), vygeneroval stovky stránek krásných diagramů a dokumentů, které si nechal nebohým klientem schválit. Klient samozřejmě netušil, co ty obrázky znamenají (když ony byly tak hezky barevné…). Poté se tento stoh dokumentů předhodil vývojářům, kteří obrázkům taky nerozumněli, ale dostali jasný pokyn - “programujte!” Po několikaměsíčním vývoji při prezentaci systému klient zjistil, že vlastně teď potřebuje už něco úplně jiného a software se do produkce vůbec nedostal.

Doporučení:

• iterace je dlouhá max. 1 měsíc, v počátcích vývoje kratší, klidně i 1 týden
• vývojáře musíme protlačit ke klientovi, protože jedině zadavatel a tvůrce systému umí pokládat správné otázky a generovat správné odpovědi
• po každé iteraci následuje prezentace klientovi, který potvrdí aktuální verzi a na jejím základě generuje požadavky další
• popis systému je obsažen ve zdrojovém kódu a v uživatelských zadáních
• podrobná dokumentace je zbytečná - vývojáři ji nepotřebují, tvůrce ji musí aktualizovat a koneční uživatelé jsou tak frustrovaní množstvím software, který musí ovládat, že ji číst nebudou. Složitá sice může být problémová doména, kterou software řeší (třeba statistický software), ale nikdy nesmí být složitý software samotný. Pokud např. posadíme statistika k našemu statistickému softwaru, musí ho být schopen do několika minut bez problémů ovládat, protože ovládá problémovou doménu, do které je náš software zasazen a kopíruje ji.

Testujeme - test simuluje používání systému uživatelem. Ať už to schováno pod pojmy test jednotkový (na úrovni metody), integrační (na úrovni větší části systému), zátěžový, opičí, či jiný, smyslem testu je software nastartovat, aby ukázal, co umí. Testy se mají psát průběžně a to z toho důvodu, že na konci je už nikdo psát nebude. Stejně tak s každým testem vytvoříme nekonečného automatického robota, který nám bude hlásit, jestli pořád software dělá, co dělat má. Psaní testů z krátkodobého pohledu zdržuje, ale dlouhodobě nám právě testy drží software stabilní.

Doporučení:

• kontrolovat pokrytí software testy (např. v Javě přes Cobertura), stanovit si hranici, pod kterou nesmíme jít, ideálně nad 80%)
• maximálně urychlit psaní a spouštění testů (mock objekty, databáze v paměti)
• nepřetržitě integrujeme pomocí integračního serveru (Continuum, Hudson, Bamboo…)

Jsme malí - neudržujme velké týmy. Čím více vývojářů, tím více tření, komunikace, rozhodování, administrativy a neefektivity, kterou nakonec (zbytečně) platí klient.

Doporučení:

• ideální velikost týmu je 3-5 vývojářů, pokud se jich vývoje účastní více, uděláme více týmů a každý z nich má svou problémovou doménu. Tyto týmy však musí být vzájemně synchronizovány, např. pomocí scrum of scrums-porad, kterých se účastní pouze vyhrazený člověk z každého týmu, nikoli všichni členové  dohromady.

Posaďme tým dohromady, čili  “seat the team together”. Tým musí sedět pohromadě. Tečka. Tohle je nejrychlejší způsob řešení komplikací během vývoje a udržení synchronizovaných znalostí o systému. Pokud má kdokoli v týmu otázku, může ji položit a dostane se mu okamžité odpovědi.

Doporučení:

• respektovat klid pro práci - pokud máme otázku, nekřičíme na celou místnost, ale zeptáme se, zda můžeme vyrušit, v extrémních případech si zavedeme každou hodinu několik minut na otázky a odpovědi
• červená čepice - jednoduché pravidlo - v týmu je k dispozici symbol “červené čepice” (ať už cedulka, nebo opravdová kšiltovka), kdo ji má na hlavě, ten nesmí být rušen
• nepracovat z domova přes Internet, bohužel, zatím se ukazuje, že je stále efektivnější být fyzicky pohromadě v 1 místnosti, než komunikovat přes Skype, Jabber, atd. Budu rád, když mi tuto neefektivitu někdo vyvrátí a přidá praktické zkušenosti.