Agilní vývoj v praxi
Od sepsání manifestu agilního vývoje uplynuly už víc než dvě dekády. Pro představu: herní peckou toho roku bylo GTA III, vyšel mac OS X a Windows XP. Dvacet let je v IT velmi dlouhá doba. Proč je tedy agilní vývoj stále relevantní, když Windows XP už dávno (ehm) umřel? A proč o agilním vývoji píšu, když už o něm za ta léta bylo napsáno snad všechno? Hlavním důvodem je fakt, že stále nepoužíváme agilní vývoj tak často, jak bychom si přáli.
Pokud jste o agilním vývoji nikdy neslyšeli, začněte u principů, které za agilním manifestem stojí. Na těchto principech jsou vybudovány jednotlivé metodiky. Mezi ty nejznámější a nejpoužívanější patří Scrum nebo Kanban.
Agilní vývoj: Jak to funguje?
Jak funguje agilní vývoj v praxi? V Ackee používáme metodiku Scrum, kterou jsme přizpůsobili agenturnímu vývoji aplikací:
Nejprve se projekt rozdělí do menších časových úseků, kterým se říká sprint nebo iterace. Práce se plánuje vždy jen na několik týdnů dopředu (typicky dva nebo tři).
Před začátkem každého sprintu se tým vývojářů sejde se zákazníkem (sprint planning) a společně se domluví, co bude jeho náplní. Tato náplň by se již během sprintu neměla měnit. Všechny případné změny a nové funkcionality, které není možné do sprintu zahrnout, se vloží do backlogu, což je místo, kde se shromažďují všechny budoucí úkoly.
V rámci každého sprintu proběhne krátká technická analýza, UX/UI design, vývoj a testování. Výstupem je funkční verze aplikace, kterou je možné prezentovat. Tím se agilní vývoj liší od klasického waterfall modelu, kde na sebe všechny práce postupně navazují (jako vodopád). Nejdříve se provede technická analýza celé aplikace, potom UX/UI design celé aplikace a tak dále.
Je potřeba si uvědomit, že sprint není závazek, ale doporučení. Může se totiž stát, že objem práce je velký a není možné ji během daného času stihnout. Stejně tak může být práce naplánováno naopak málo a pak je možné do sprintu zařadit nějaký úkol z backlogu. Z těchto chyb v plánování by se měly všechny strany poučit.
Základem agilního vývoje je úzká spolupráce se zákazníkem a pravidelná komunikace. Zákazník se zapojí do celého procesu vývoje a během něj dostává produkt, na kterém se sám podílí. V Ackee se proto většinu nových projektů snažíme začínat agilně. Díky tomu jsme schopni dodávat parádní appky ve velmi krátké době a šetřit čas a peníze.
All hail to Agile
Podíváme-li se na všechny výhody agilu, existuje vlastně nějaký důvod používat jinou metodiku? Ano!
Prvním principem agilního vývoje totiž je: “...vyhovět zákazníkovi časným a průběžným dodáváním hodnotného softwaru.” Jenže to není vždy vyhovující postup. Aby mohl agile skutečně fungovat, musí zákazník mít zájem a především čas s vývojovým týmem spolupracovat. Product owner (tj. osoba, která tvoří produktová rozhodnutí) musí s týmem na denní bázi komunikovat, podílet se svými rozhodnutími na samotném vývoji, účastnit se sprint planningů a mít o vývoji určitý přehled.
Dle dalšího principu agilního vývoje jsou změny v požadavcích vítány. To je samozřejmě v pořádku – svět se rychle vyvíjí a produkt se musí vyvíjet s ním. Zde hraje zásadní úlohu právě product owner, který musí umět rozhodnout, co je důležitá funkcionalita a co jen drobné vylepšení. Špatná prioritizace totiž může způsobit, že se sprintuje a sprintuje, a na konci není ani produkt ani peníze. Je tedy jasné, že pro agilní vývoj je role product ownera, který reprezentuje zájmy zákazníka, naprosto klíčová.
Špetka právničiny
V Ackee pro vývoj software využíváme dva typy smluv: Fixed Time Fixed Price (FTFP) a Time & Material (T&M).
V prvním případě smlouva definuje dílo, které má vzniknout a být dodáno za pevně stanovenou částku a v pevně stanoveném čase. Z právního pohledu se tak jedná o Smlouvu o dílo, kterou se: “zhotovitel zavazuje na svůj náklad a nebezpečí provést pro objednatele dílo a objednatel se zavazuje dílo převzít a zaplatit cenu.” (§ 2586 odst. 1 NOZ)
Time&Material naopak vyžaduje Rámcovou smlouvu o poskytování služeb. Taková smlouva však nedefinuje žádné dílo, ale pouze služby, které bude dodavatel zákazníkovi poskytovat (například design, programování, testování atp.). Jednotlivé služby jsou poskytovány na základě dílčích objednávek, které typicky následují například po sprint planningu.
Bystrému čtenáři již zřejmě došlo, že kombinace Time&Material a agilního vývoje jde k sobě.
Kdy agile a kdy ne?
Agilní metodiky jsou skvělé pro rychlý vývoj software, který se v průb ěhu času mění. Agile však není univerzálně aplikovatelný na všechny projekty a všechny zákazníky. Pro úspěch je nicméně vždy důležitá role product ownera, jehož absence či nerozhodnost může paralyzovat celý vývojový tým.
Kdy tedy agile ano a kdy ne? Klasická odpověď zní: pokud zákazník přesně neví, co chce, volte agile. Pokud jste zákazník, volte agenturu, která má zkušenosti a poradí vám, která metoda vývoje je pro váš projekt nejvhodnější. Rozhodující je přístup. Agilní projekty vyžadují čas, zápal a vytrvalost.
Pokud jimi nedisponujete, promyslete projekt společně: analyzujte požadavky, navrhněte řešení a otestujte ho. Jakmile máte v ruce toto základní zadání, postupujte klidně waterfallem. Ani více než 20 let po vydání agilního manifestu to není chyba.
Tento blog byl napsán za pomocí principů agilní metodiky SCRUM.
