neděle 24. ledna 2010

Nedělní rozjímání nad softwarovým vývojem

Nemálo lidí přemýšlí o různých technikách zefektivnění softwarového vývoje. Zažil jsem metodologií, která byla klasický vodopád obohacený a milestony po šesti týdnech. Tedy na začátku se udělal sběr požadavků, jejich analýza, pak design, implementace a verifikace/testování na závěr. Každou z těchto činnosti dělal v podstatě jiný tým lidí. Sběr požadavků dělal tým funkčních architektů, analýzy techničtí architekti, design a implementaci vývojáři a verifikaci a testování oddělení kvality. Ačkoliv tento systém vývoje fungoval, mohl fungovat daleko efektivněji a lépe.

Prvním problémem je více méně striktní rozčlenění odpovědností, ačkoliv by se to mohlo zdát jako logické a správné, tak je to ve své podstatě kontraproduktivní. Práce každé skupiny má totiž jasný začátek a konec, s tím, že na ní navazuje práce jiné skupiny. Bohužel to sebou šílený redundanci v podobě sdílení informací. Když osoba A na začátku celého řetězu něco vymyslí nebo změní, je potřeba tuto informaci rozšířit přes všechny navazující skupiny a to v jakýkoliv okamžik.

Aby se této redundanci v předávání informací zamezilo, vznikají dokumenty. Celé řádka dokumentů v různých revizích, které popisují co prěsně autor zamýšlel. Máme sice jedno místo, kde se udržují informace, ale lidé musí pálit čas tím, aby tyto informace sepsali a další lidé tím, aby je vstřebali.

Obecně si myslím, že rozškatulkovaný vývoj na skupiny lidí prostě nefunguje kvůli sociálním problémům. Jedna skupina si něco vymyslí a další za měsíc zjistí, že to je neproveditelné. Vznikají zbytečné třenice díky tomu, že architekt požaduje Táčmahál a vývojáři jsou schopni dodat v lepším případě srub kanadského dřevorubce nebo v tom horším kůlničku na dříví.

Druhý problém je v tom, že fáze analýzy je sice ukotvená na začátku celého procesu nicméně pouze pro to, aby se na jejím základě dokázaly udělat časové odhady náročnosti a proto, aby mohli další skupiny lidí pracovat. Bohužel tento přístup má poměrně zásadní nedostatek. Né vždy totiž vidíme plně pod kapotu celého řešení. Spíše naopak, vidíme pouze tu část, se kterou jsme dobře seznámeni a dopad na navazující části nám často uniká. Takže naše analýza z principu stojí na vodě. Zkuste v takovém případě udělat odhad časové náročnosti.

Teď jsme si popsali, některé z nevýhod a teď jak proces zrefaktorovat, tak aby fungoval k plné spokojenosti všech zúčastněných.

Prvním problém je odstranění informační bariéry a sdílení informací.

Psát v případě funkčních požadavků desetistránkové pamflety je nesmysl. Nejpochopitelnější je načárat funkční specifikaci na chování uživatelského aplikace a přidat stručný popis. Pokud to nedokážete, pak je nejspíše problém v tom, že zadání je příliš složité. Příliš složité zadání na úrovni uživatelského rozhraní nejspíše neznamená, že by zadání bylo složíte. Spíše to svědčí o tom, že to co uživatel chtěl bylo špatně pochopeno. Když chce uživatel skalpel, dejte mu skalpel a nikoliv multifunkční švýcarský nožík, který obsahuje navíc šroubovák, vývrtku a pilník.

Nepište analýzy pokud to není opravdu potřeba a rozhodně je nepoužívejte jako zadání práce pro někoho jiného a nebo k časovým odhadům. Důležitá rozhodnutí, která mají tendenci se v analýzách objevovat, odložte až na poslední možnou chvíli (viz Lean software development) kdy budete mít všechny potřebné informace.

An agile software development approach can move the building of options earlier for customers, thus delaying certain crucial decisions until customers have realized their needs better. This also allows later adaptation to changes and the prevention of costly earlier technology-bounded decisions.

Prací softwarového vývojáře není sepisování esejí či jejích louskání. Nejefektivnější způsob výměny informací je přímá komunikace a zapojení se všech členů týmu ve všech činostech vývojového cyklu. Striktní rozdělení činností vede pouze k vytváření bariér. Vedlejším efektem je to, že se určitá část lidí specializuje pouze na určitou část řešení. Dochází potom k třenicím, že lidé co dělají uživatelské rozhraní se cítí odstrčení od jádra systému a ty co dělají jádro nemají potuchy co potřebují ti co dělají uživatelské rozhraní. Stejný kastovní systém dělá problém i při dělení na vývojáře a architekty.

Možná je to anarchie, možná je to cowboy coding, ale podle mého soudu by všichni měli dělat všechno. Tím se nejlépe sdílí týmové znalosti a nutí to k větší míře komunikace. A lidi to pochopitelně víc baví. Striktní rozdělení na architekty a vývojáře neexistuje. Zásadní rozhodnutí se přijímají společně. Funkci architekta v uvozovkách drží vývojáři, kteří jsou respektování zbytkem týmu a mají dostatečnou autoritu fungovat jako arbitr sporu typu použijeme knihovnu typy X nebo Y.

Vsuvka:Role manažera spočívá pouze v tom, že poskytuje servisní služby zbytku týmu. Dělá zapisy meetingu, zajišťuje hardware/software, dohlíží a připomíná na termíny, zajišťuje komunikaci s dalšími tými. V podstatě slouží jako tlumič různých byrokratických omezení. Manažer nikdy neděla technologická rozhodnutí nicméně jeho názor je vítán a respektován.

Občas mám pocit, že se různé procesy a metodiky vývoje hodně přeceňují. Z výše uvedených řádku by mohl leckdo nabít dojmu, že jsem vodopád zrefaktoroval například na Scrum. Přiznám se, že nevím, agilních metodik je celá řada. Někdy je to hra se slovíčky a ve výsledku se dospěje k tomu samému. Já osobně věřím ve dvě věci při softwárovém vývoji.

  • komunikace, komunikace a zase komunikace namísto byrokracie snažící se komunikaci suplovat
  • silné individuality jako jádro malých týmů, kde každý člen se podílí na všech činoostech

Jestli tomu bude říkat nebo v tom hledat Scrum, Iterative and incremental development či Lean software development je poměrně nezajímavé.