Otázky nás samozřejmě mohou také inspirovat ke zlepšením. Pokud na nějakou otázku odpovíme ne, můžeme se hned zeptat, proč toto nemáme/neděláme a jestli a jak to můžeme změnit a hned dohodnout konkrétní akce a naplánovat je v týmu jako součást následující iterace/sprintu. Jako další zdroj inspirace ke zlepšením vám může sloužit i e-kniha Ponaučení z jednoho projektu.
Joel uvádí, že většina týmů dle jeho zkušenosti dosahuje výsledku 2-3 (což je překvapivě nízké číslo vzhledem k otázkám) a že například týmy v Microsoftu (který byl mimochodem jeden z prvních razící a implementující agilní praktiky v týmech) dosahují hodnoty 12. Jako dobrý výsledek je považována hodnota 10 a vyšší. Hodnota 10 a nižší značí problémy. Samozřejmě tento test neříká nic o smyslu a využití softwarového produktu, který vytváříte a ani o vedení a schopnostech vašeho managementu. Naplnění 12 bodů vám zaručí disciplinovaný tým schopný pravidelně doručovat kvalitní kód.
A jaké že jsou tedy ty otázky (s mým stručným komentářem kurzívou)?
- Používáte verzovací systém? (pomáhá řešení konfliktů, přechod k předchozím verzím, které fungovali, sledování změn druhých)
- Můžete udělat build v jednom kroku (doručitelná verze vytvořená z nových změn)? (pomáhá ověřit kvalitu a redukovat integrační chyby a zavlečení chyb novou funkcionalitou či opravou chyb)
- Vytváříte denní buildy? (abychom předešli integraci nedokončené či chybné funkcionality a zanesení nových chyb)
- Máte databázi chyb (formální nástroj, ne uložené v hlavě)?
- Opravujete chyby před implementací nového kódu? (posouvat odstranění na později znamená dražší opravu – je třeba delší čas na pochopení co jsem to tam jako vývojář psal, komplexnost kódu je vyšší, je nutné vytvořit a doručit záplatu, chyba může blokovat uživatele v práci)
- Máte aktuální plán? (vytváření důvěry na základě sdílení aktuálních informací a problémů, zpoždění a jejich důvodů)
- Máte specifikace? (redukce nutných změn v dokumentaci je možná díky spustitelné dokumentaci – unit testy, Fitnesse akceptační testy, high level design dokument je pak nezbytný pro týmy údržby, ale například také pro nefunkční testování)
- Mají programátoři klidné pracovní prostředí? (cílem je zachovat produktivitu tím, že omezením přepínání kontextu)
- Používáte nejlepší nástroje, které se dají za daný peníz koupit? (cílem je usnadnění a automatizace rutinních úkolů – integrace a buildování z IDE nástroje, debugging GUI, propojení s modely)
- Máte v týmu testery? (opravdu si myslíte, že tímto ušetříte? Zkusili jste se zamyslet nad tím, kolik stojí oprava chyby aplikace v produkčním prostředí?)
- Píší kandidáti na nové členy týmu při pohovoru kód? (opravdu říká CV, jak je daný programátor schopný a jak čitelný píše kód?)
- Provádíte nějaké testování použitelnosti? (GUI používáme a chápeme každý jinak, pozorovat krátkou chvíli někoho jiného u námi napsaného GUI nám přinese spoustu námětů)
V posledním projektu, kde jsem pracoval jako vývojář (už je to tři roky…) jsme měli skóre 6 a produkt podle toho vypadal :). A jaký je výsledek vašeho týmu?
Pozn.: Celý text a podrobnější vysvětlení, zdůvodnění a návody si můžete přečíst v originále.
Máte k tomu co říct?