15.07.2010

Rychlý test kvality vašeho kódu

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)?

  1. 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)
  2. 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)
  3. Vytváříte denní buildy? (abychom předešli integraci nedokončené či chybné funkcionality a zanesení nových chyb)
  4. Máte databázi chyb (formální nástroj, ne uložené v hlavě)?
  5. 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)
  6. 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ů)
  7. 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í)
  8. Mají programátoři klidné pracovní prostředí? (cílem je zachovat produktivitu tím, že omezením přepínání kontextu)
  9. 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)
  10. 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í?)
  11. 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?)
  12. 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?

Napsat komentář

Vaše emailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *