Loading screen logo with motto

Největší omyl ohledně software v současném světě

Software je neodmyslitelnou součástí dnešního světa. A přestože samozřejmě existují vývojáři na volné noze, většinu software pro nás zajišťují korporáty, velké firmy, střední firmy, menší firmy – zkrátka ty samé organizace zajišťující výrobu automobilů, oblečení, nebo třeba prodej párků v rohlíku na rohu ulice. Všechny tyto subjekty – pokud chtějí uspět – mají společného to, že musí plánovat, optimalizovat, maximalizovat zisk. V tvrdě konkurenčním světě, kde nepřežívá nejsilnější, ale nejefektivnější, existuje pouze málo věcí s větší hodnotou, než dobře spočítané odhady náročnosti, realisticky stanovené deadliny a dodržené rozpočty. Tento způsob uvažování napříč průmyslovými odvětvími je vyzkoušený a zcela nepochybně správný.

Vývojáři si ovšem neuvědomují jednu věc. Neuvědomují si ji ani učitelé na školách. A neuvědomují si ji ani projektoví manažeři. Dalo by se říct, že ji ignoruje celý průmysl. Vývoj software nemá mnoho společného s ostatními technickými obory, ani např. s výzkumem. Celý proces psaní software, od prvotní vize, přes podrobnější popis dílčích problémů, až po samotné psaní kódu, připomíná mnohem více skládání opery, psaní knihy, nebo malbu obrazu. Cesta od nápadu po program běžící na zařízeních po celém světě je vysoce kreativní a na rozdíl od ostatních průmyslových odvětví jsme zatím ani nevykročili na cestu k tomu celý proces automatizovat.

Dovolil bych si tvrdit, že všichni bez výjimky, kdo jsme kdy vedli libovolně rozsáhlý softwarový projekt, jsme vinni hříchem pokládání nesmyslných otázek, na které sebezkušenější vývojář z principu věci nemůže znát odpověď. Představte si, jak absurdní by celá situace byla v odvětvích, kterými se vývoj software inspiruje:

Všichni máme rádi Dana Browna. Manažer vydavatelství, se kterým Dan Brown spolupracuje, dostane informaci, že má Brown nápad na novou knihu s Robertem Langdonem v hlavní roli.

Manažer: Mohu se zeptat, kdy bude kniha hotová?

Brown: To nedokáži říct, mám v hlavě nápad, ale ještě jsem nezačal psát.

V tuto chvíli manažer popřeje Brownovi hodně štěstí a začne se zajímat o jiné spisovatele. Ví, že žádný z nich pravděpodobně tak dobrou práci jako Brown neodvede, na druhou stranu nemá smysl jednat se spisovatelem, jehož kniha je ve fázi mlhavého nápadu. Metodiky vývoje software, hojně prezentované na univerzitách, školené za nekřesťanské peníze kouči po celém světě, popř. obsažené v nespočtu knih a publikací, nás ale učí něco jiného:

Manažer: Mohli bychom se domluvit na dodání a prezentaci MVP koncem tohoto měsíce? Nemusí se jednat o odladěnou verzi textu, zákazníkům bychom prezentovali jen pár pasáží, o které by byl největší zájem. V průběhu příštího sprintu byste knihu postupně dopsal, mezitím bychom se zákazníky udělali pár předváděcích akcí a pokud by na konci sprintu zbylo trochu času, mohli bychom několik kapitol prohnat korekturou, nebo ještě lépe zapracovat požadavky klientů sesbírané z prezentací a celý projekt dokončit ještě toto čtvrtletí.

Brown: To asi nepůjde.

Manažer: A co třeba takhle? Začneme tím, že jednou za dva týdny vydáte jednu kapitolu příběhu. Po několika takto vydaných kapitolách již budeme mít představu o rychlosti Vašeho psaní a budeme tedy moci přesně stanovit termíny vydávání dalších kapitol, stejně tak jako odhadnout jejich celkový počet. Tyto termíny následně oznámíme zákazníkům, včetně data zveřejnění poslední kapitoly, kdy slavnostně vydáme knihu jako celek! Není to skvělé?

Moc rád bych znal reakci jakéhokoli spisovatele po takovémto výstupu. Pokud nejste vývojáři, může Vám tato situace připadat směšná a nadsazená. Pravda je ale taková, že podobné rozhovory jsou pro programátory naprostou rutinou.

Výsledek tohoto jednání? Vývojáři jsou v tomto ohledu manažery a scrum mastery pravidelně tlačeni do kouta a aby si zachovali svá místa, musejí lhát. Bez reálných podkladů dávají odhady bez jakékoli vazby na realitu softwarového vývoje a manažeři pak tyto odhady považují za deadliny. Tyto deadliny programátory následně tlačí do vydávání v lepším případě pouze ošklivého, v horším případě rozbitého kódu. Kdysi jsem na toto téma četl úvahu ne nepodobnou té mé, ve které autor zcela trefně označil takto vyvinutý program za román obsahující hezký úvod a následně spoustu prázdných stránek, popř. několik set stran Lorem Ipsum, aby vypadal opravdověji.

Znamená to, že je celý koncept metodik špatně? Že nic jako agilní vývoj software neexistuje? Rozhodně ne. Fanoušci Dana Browna se s čekáním na jeho další knihu o půl roku či rok déle nakonec nějak smíří. Organizace, čekající na klíčovou aktualizaci programu zajišťujícího chod poloviny jejich výrobních zařízení, by asi podobnou trpělivost neprojevila. Pravidla v průmyslu fungují jinak než pravidla v umění a software zkrátka je součástí průmyslu. Je ovšem výzvou pro nás všechny, kdo máme zodpovědnost za to, aby klient dostal software v odpovídající kvalitě a včas, abychom nezapomínali na jistou specifičnost odvětví. Věřím, že pouhým uvědoměním si toho, že vývoj software není lineární a bezchybně plánovatelný proces, lze zlepšit život všech vývojářů v organizaci, a nakonec i výslednou podobu produktu.