Máme tendenci neustále něco srovnávat. I softwarové inženýrství srovnáváme. S vojenstvím, strojírenstvím nebo se stavebním inženýrstvím. Martin Fowler v článku New Metodology, který byste si měli rozhodně přečíst (i když je dlouhý), popisuje motivace a vznik agilních metodik a vyvozuje závěr, že pro softwarové inženýrství je takové srovnání zavádějící. Přeložil jsem několik vybraných odstavců a doplnil o svoje poznámky.

Pamětihodnosti


Joseph (by-nc-sa 2.0)

Srovnání softwarového inženýrství a stavebnictví mi vrtá hlavou již dlouho. Lidstvo staví monumentální architektonická díla obřích rozměrů a odpovídajících rozpočtů jako například Sagrada Família. Po mnoho desetiletí na podobných stavbách dřou stovky dělníků. Po letech k těmto výtvorům zhlížíme, i kdyby to byly zříceniny. Srovnejte to s softwarovými projekty, které jste měli možnost vidět. Nemluvě o tom, že projekty jistě měly řádově nižší počet dělníků i samotný rozpočet. Nezřídka je to spíš hned od začátku slum, v lepším případě se z toho velmi brzy stane barabizna.

Shody a rozdíly

Mám za to (když stavím dům), že si můžu malé srovnání dovolit. Oproti softwarovému inženýrství má stavebnictví výhodu hmatatelné zpětné vazby. Ostatně, jak už psal Jiří Fabián, určité agilní prvky mohou být shodné - například iterace, malé dodávky oproti stavbě na klíč. V něčem se obory naopak diametrálně liší. Ve stavebnictví existuje profese rozpočtář. Spočítá vám, kolik bude stát kubík nosné zdi, jak práce tak materiál. Existují tabulky s údaji o pracnosti, díky čemuž víte, že směrná pracnost zdění cihly POROTHERM 42,5 T Profi je přibližně 0,93 hod/m2 respektive 2,19 hod/m3. Zkuste říct, kolik bude stát login formulář. Když zákazníci šťourají do rozpočtu, přijde mi to, jako bych instalatéra podroboval křížovému výslechu, zda si je jistý, že svařováním skutečně stráví tolik a tolik času. Ne, jednoduše se s ním domluvím, že takovou investici si nemůžu dovolit, tak kde lze ušetřit.

Vybrané pasáže z článku

Obvyklou inspirací pro metodiky jsou inženýrské disciplíny jako strojírenství nebo stavebnictví. Tyto disciplíny zdůrazňují plánování předcházející samotné stavbě. Takoví inženýři budou pracovat se sérií výkresů, které přesně ukazují, co je potřeba postavit a jak věci zapadají do sebe. Mnoho designových rozhodnutí, jako například jak se vypořádat se zatížením mostu, je vyřešeno již ve fázi výkresů. Ty jsou předány různým skupinám, často z jiných firem, a předpokládá se, že podle nich budou stavět. V praxi se stavitelé setkají s nějakými problémy, ale ty jsou obvykle malé.
Návrh je obtížné předpovědět navíc vyžaduje drahé a tvůrčí lidi, naopak stavbu je snazší předpovědět. Jakmile máte návrh, můžete plánovat stavbu. Máte-li výkresy, lze se zabývat stavbou mnohem předvídatelnějším způsobem. Ve stavebnictví je samotná stavba větší jak náklady, tak časem, oproti návrhu a plánování.
Výkresy specifikují díly a to jak mají být dány dohromady. Rovněž slouží jako základ pro podrobný stavební plán, ze kterého můžou vzejít úkoly, které je potřeba udělat, a jaké mezi nimi existují závislosti. To umožňuje sestavit obstojný harmonogram a rozpočet. Také to podrobně říká, jak mají lidé na stavbě dělat svou práci. Stavba je méně intelektuálně náročná, zato je často náročnější na manuální zručnost.
Problém s návrhem v podobě UML atd. je to, že může dobře vypadat na papíře, ale až dojde na skutečnou implementaci, tak se mohou objevit vážné vady.
Dalším tématem je porovnání nákladů. Stavíte-li most, náklady na projektanty jsou kolem 10 % celého rozpočtu, zbytek je samotná stavba. U softwaru je množství času stráveného kódováním mnohem a mnohem menší. McConnell navrhuje, že u velkých projektů je kódování a jednotkové testy pouze 15 %. Téměř perfektně obrácený poměr ke stavbě mostu. I kdybyste považovali veškeré testování za stavbu, tak bude návrh stále 50 % práce.
U softwaru je stavba tak levná, že lze téměř říct, že je zdarma. V softwaru je veškeré úsilí návrh, a ten vyžaduje tvůrčí a talentované lidi. Kreativní procesy nelze snadno plánovat, a proto může být předvídatelnost beznadějným cílem. V případě softwaru bychom se měli vyvarovat tradičním inženýrským metaforám. Jedná se o jiný druh aktivity, která potřebuje jiné procesy.
V každé problémovém projektu slyším refrén - vývojáři přijdou a říkají mi: „Potíž s tímto projektem je, že se požadavky stále mění.“ Na věci mě překvapuje, že to vůbec ještě někoho překvapuje. Při vývoji podnikového softwaru je pravidlem, že se požadavky mění. Otázkou je, co s tím uděláme.
Organizace jako NASA je klasickým příkladem, kdy softwarový vývoj může být předvídatelný. To vyžaduje spoustu času, procesů, velké týmy a stabilní požadavky. Jsou takové projekty jako raketoplány, ačkoliv si nemyslím, že by mnoho podnikového softwaru spadalo do této kategorie. Pro ně potřebujete jiný typ procesu.
Většina tvůrců metodik chce, aby jejich metodiky byly použitelné pro kohokoliv, takže nerozumí okrajovým podmínkám nebo je nepublikují. Což vede k tomu, že lidé používají metodiku za špatných okolností, jako například použití předvídatelné metodiky na nepředvídatelné situace.
Jednotlivci nejsou tak důležití, pouze role jsou. Pokud plánujete projekt tímto způsobem, tak nezáleží jakého dostanete analytika nebo testera, prostě víte, kolik jich potřebujete. To ovšem nastoluje otázku, zda jsou lidé zapojení do softwarového vývoj zaměnitelné součástky. Jedním z klíčových znakem agilních metodik je, že tento předpoklad odmítají.
Předvídatelné procesy vyžadují komponenty, které se chovají předvídatelně. Nicméně lidé nejsou předvídatelné komponenty. Lidé jsou nejdůležitějším faktorem softwarového vývoje.
Navzdory našemu nejlepšímu úsilí nejsme u softwaru schopni měřit tu nejjednodušší věc jako je produktivita.

Ostatně na toto téma sepsal Martin Fowler samoastatný článek Cannot Measure Productivity

Pokud měříte výkonnost, musíte brát v potaz všechny důležité činitele. Cokoliv bude chybět, povede k nevyhnutelnému důsledku, že dělníci zaměří své úsilí pouze k měřeným veličinám, i když to výrazně sníží jejich efektivitu práce. Tato dysfunkce měření je Achillovou patou managementu řízeného jen na základě měření.

Edit

Je chybou, že jsem nezmínil, že i softwarové inženýrství má své skvosty, ke kterým vzhlížíme. Patří mezi ně samozřejmě Stackoverflow. Denně vyřídí 148 miliónu HTTP requestů, další podrobnosti v článku What it takes to run Stack Overflow