Temná strana agile vývoje: Teorie stranou. Dodávejte funkční produkt (1/5)

eMan, Dark Side of Agile

Byl jsem u toho, když se zaváděl agilní vývoj v eBay. Pracoval jsem jako Scrum Master v software house. A když jsem nastoupil do eManu, získal jsem i zkušenosti ze strany dodavatele softwaru do nadnárodních společností. Agile mám rád, ale nikdo nemluví o jeho temných stránkách. Přišel čas si na ně posvítit.

V této sérii článků se postupně zaměřím na hlavní úskalí agile metodiky. Nebudu dopodrobna vysvětlovat, co to je a jak se liší od klasických waterfall metod – to všichni víme. A pokud ne, je tu agile manifesto. Povinná četba pro každého, kdo se chce s agile metodikami seznámit blíž.

V prvním díle tohoto seriálu tedy stručně shrnu hlavní rozdíly při práci ve vodopádovém modelu, fixed price, T&M a agile vývoji z pohledu vývojářské práce a klientského rizika.

 

Waterfall

Jedná se o nejklasičtější přístup – na začátku se pevně definují požadavky, technologie, rozpočet, rozsah projektu a alokace lidí. Jedna fáze striktně navazuje na druhou a každá skončená fáze musí být prakticky dokonalá. Což je v praxi velice těžce proveditelné, situace se mění ze dne na den a co vypadá na papíře přijatelně, nemusí v praxi fungovat.

Fixed price

Představuje klasický formát, se kterým nikdo nemá problém. Je to takový bod nula. Stanoví se cíl a timing, domluví se přesně, kolik to bude stát. Tento formát spolupráce ale může být neefektivní pro klienta, který přesně neví, co vlastně chce (a který není IT firma). Takovým zadavatelům bych raději doporučil T&M přístup.

T&M

Je částečně podobná SCRUMu. Tuto formu krátkodobé efektivní spolupráce využívá většina moderních firem, pokud nemají agile. Prostě zadáváte práci na týdenní nebo dvoutýdenní bázi a průběžně sledujete výsledky za danou dobu. Platíte za využitý čas a materiál.

Agile

Funguje na principu běhů na krátkou vzdálenost, v případě SCRUMu takzvaných sprintů. Vždy se určí jedna konkrétní věc, která bude na konci sprintu hotová. Na té se pak pracuje a nečeká se, že během daného sprintu bude hotová ještě jiná část projektu. Měřítkem úspěchu je množství dodaného softwaru. Tato metodika je ideální pro klienty, kteří nejsou IT firmy a ještě nemají jasnou představu, jaká bude komplexní podoba výsledného softwaru. Díky agile metodice dostane klient samostatné fungující kusy výsledné stavebnice a nikoliv prozatímní změť jednotlivých částí. A to je vlastně první nástraha agile – už to totiž musí fungovat.

 

Tolik stručné představení jednotlivých přístupů. A teď si představte, že jste vrcholový manažer. Máte na starost vývoj softwaru a opakovaně se vám nedaří dosáhnout zadaných cílů. Důvodů je hned několik a většinou jsou docela složité. Potřebujete zázračnou pilulku. Kouzelné abrakadabra, řešení všech vašich potíží a námahy – agile. Existuje hned několik relativně nových metodik, jak projekty agilně vést, třeba SCRUM nebo Kanban. Potíž je v tom, že 90 % firem, co chtějí SCRUM zavést, jenom zneužívá terminologii a přitom pokračuje v neefektivních procesech a nezdravém rozhodovacím klimatu. Neberou si z metodiky toho to nejlepší. Navíc velmi záleží na schopnostech a disciplíně zaměstnanců firmy. Čím větší je firma, tím víc se to projeví. A právě tomu se budeme věnovat v dalším dílu naší „agilní“ série.

Pokud lačníte po dalších informacích: Takeuchi & Onaka: The New New Product Development Game

Dmytro Trofymchuk
Division Director

RSS