Nepochopte mě špatně. Naprosto se ztotožňuji s principy agilního vývoje software a jsem přesvědčen, že:
- Krátký cyklus zpětné vazby a dobrá komunikace v týmu jsou důležité a dobře komunikující tým průměrných inženýrů dosahuje lepších výsledků – než izolovaní géniové hrající si na vlastních hřištích.
- Prototypování, časté dodávky a intenzivní zapojení zákazníka (businessu i IT) od počátku předchází nepříjemným překvapením v pozdních fázích vývoje a většinou znamená vyšší spokojenost zákazníka s finálním produktem.
- Není nutné (ani možné) mít před zahájením vývoje detailní specifikaci vytesanou do skály. Upřesňování i změny požadavků a jejich analýza probíhá po celou dobu vývojového cyklu.
Co mi ale opravdu vadí, je, že se z agility stalo moderní slovo, které má ambice vyřešit veškeré neduhy tohoto světa. Chopili se ho spisovatelé, šoumeni a konzultanti, kteří v životě nenaprogramovali ani řádek kódu a jejichž vzdělání, pokud vůbec nějaké mají, je častěji v oblasti filosofie a umění než v technických vědách. Bohužel tito lidé nemají žádný znalostní základ, aby pochopili a docenili základní myšlenky agilního vývoje software. Místo toho se sebevědomím jim vlastním prosazují absurdity a z pro mě nepochopitelných důvodů jim v korporacích často top management naslouchá víc než “prgačům”, kteří jsou bohužel bráni jako brzda pokroku. Výsledkem jsou naprosto špatně nastavená očekávání od softwarových projektů. Osobně jsem slyšel, že:
V agilním projektu nepotřebujeme projektový plán.
Všechny agilní metodiky obsahují plánování. Agilní přístup vyžaduje z podstaty věci časté přeplánovávání a upřesňování plánu. Agilita prostě není synonymum pro chaos.
Požadavky se vytvoří v týmu, takže nebudeme od businessu potřebovat konsolidované vstupy a každý může dávat jakékoliv požadavky.
Zásadní nepochopení. Pokud používáte tolik populární Scrum, tak víte, že role “Product Owner” je naprosto nenahraditelná pro zachycení User Stories, a tím pro formulování a prioritizaci požadavků. Pokud takový člověk neexistuje nebo nemá jasné pravomoce rozhodovat, nemá tým šanci vyprodukovat vůbec nic.
Požadavky lze zásadně měnit kdykoliv a tým na to musí být připraven.
Ano, to je sice v duchu agilních přístupů, ale neznamená to, že zásadní změna na hotovém produktu bude zadarmo a za dvě vteřiny. Zapojením klientské strany od počátku projektu se snažíme eliminovat rizika zásadních změn na poslední chvíli. Pokud se to nepodaří, tak stále platí železný trojúhelník rozsah-cena-čas, který žádný agilní čaroděj ještě neporazil. Tedy kromě týmu musí být na změny připraven také rozpočet a termíny.
Vývojáři nesmí obtěžovat business. Od pochopení požadavků máme analytiky.
Vytvářet izolovaná sila analytiků, vývojářů, testerů a businessu je korporátní nešvar, který nejen že je přímo proti základním principům agilního vývoje, ale ještě navíc snižuje zásadně efektivitu využívání zdrojů. V takovém prostředí se stále na někoho čeká, nikdo se nesmí na nic zeptat a ve výsledku nevznikne nic anebo produkt na míle vzdálený vizi.
Dokumentace je přežitek.
Není. Jen je nutné se v každém jednotlivém projektu racionálně rozhodnout, co má smysl dokumentovat a co ne. To je princip tzv. process tailoringu, který jsme v Profinitu používali už dávno před příchodem agilních proroků.
Analýzu ani architekturu nepotřebujeme, hned se začne programovat.
Pro analýzu a návrh opět platí princip tailoringu. Je nutné zajistit, aby došlo ke stabilizaci požadavků na systém do té míry, že je možné ukotvit architekturu. V opačném případě si připravte bezedný rozpočet a nekonečný čas. Poznámka pro nadšence do DevOps – předpokládám, že mi dáte za pravdu, že dělat desítky releasů do produkce za den není možné zvládnout jen rozpoložením ducha, ale že je potřeba na to mít připravenou pěkně rafinovanou architekturu dávno před tím, než se naprogramuje první řádek business logiky nebo uživatelského rozhraní.
Mimochodem, víte, že důraz na technickou excelenci, pořádný návrh software a dodržování profesních zásad softwarového inženýrství vůbec je jedním z dvanácti základních principů zformulovaných v “Manifesto for Agile Software Development” už v roce 2001?
Chtěli byste další zábavné příklady na téma nepochopení myšlenek agilního vývoje? Skvělý je např. článek od Stefana Wolperse s názvem Lipstick Agile.
Nevěřte na zázraky. Vývoj software je komplikovaná disciplína. Agilní přístupy jsou cenné a velmi dobře se snaží adresovat část rizik softwarových projektů. Jsou užitečnou pomůckou pro efektivní organizaci a zavádějí zdravé standardy do komunikace uvnitř projektového týmu i mimo něj. Nepřekonají ale fyzikální zákony, jak se vám to někteří agitátoři snaží podsunout. A také neřeší jeden ze základních problémů softwarového inženýrství, nad kterým si lámou hlavy již desítky let skuteční odborníci v oboru. Tím problémem je hledání optima mezi třemi vzájemně se ovlivňujícími faktory:
- Flexibilitou funkčních a nefunkčních požadavků
- Stabilitou architektury
- Finančními a časovými omezeními
Pokud byste si chtěli na toto téma přečíst něco skutečně seriózního, tak doporučuji začít u dosud nepřekonaného článku Barryho Boehma “Anchoring the Software Process”, který byl publikovaný v IEEE Software už v roce 1995.
Tomáš Pavlík, CEO Profinit