Existuje nespočet pracovních postupů, pomocí kterých tým developerů vyvine nový software. Ve FlowUpu jsme si za několik let našeho fungování ověřili, že nám nejvíce vyhovuje Scrum, obecně nejpopulárnější agilní metoda softwarového vývoje vůbec. V tomto článku vám popíšeme, proč jsme si Scrum vybrali, jak v rámci něj fungujeme a jaké výhody vám přinese, pokud se spolu pustíme do spolupráce.
1. Proč zrovna Scrum?
Podívejme se na pár důvodů, které vysvětlují, proč je Scrum ideálním přístupem k vývoji softwaru.
a. Zaměření na hodnotu produktu
Scrum rozděluje vývoj a dodání produktu na několik iterací, tzv. sprintů. V každém sprintu se produkt rozšíří o předem definovaný inkrement a výsledek této iterace se demonstruje na konci sprintu. Tým se dozvídá o plánovaném cíli a rozsahu iterace před jejím začátkem a dokáže tak odhadnout, jestli lze tento cíl v rámci sprintu realizovat a k jakému množství práce se dokáže zavázat. Díky tomuto principu na konci každého sprintu zaručeně vzniká přidaná hodnota, kterou zákazník může okamžitě využít. Doba trvání konkrétního sprintu se určí před startem a je neměnná.
b. Flexibilita k novým požadavkům a změnám
Scrum je agilní proces, který umožňuje vysokou míru flexibility. Co to ve skutečnosti znamená? Vy, jakožto stakeholder, můžete před každou iterací změnit priority či zadat změny již naimplementovaných částí, pokud si myslíte, že to přinese vyšší hodnotu než původně určené cíle. Tento přístup je diametrálně odlišný od klasického neagilního vývoje, kdy jsou všechny úkoly definovány a naplánovány předem. Jakékoliv změny či nové požadavky způsobují v rámci neagilních přístupů výrazné problémy a nejistotu, kolik toho tým nakonec dokáže doručit, a to především kvůli pevně stanoveným termínům dodání.
c. Míra angažovanosti na projektu je na vás
V rámci Scrumu si jako stakeholder můžete sami určit, do jaké míry chcete být zapojeni do samotného procesu vývoje. Buď se můžete stát součástí týmu jako Product Owner, nebo do této role dosadíme někoho jiného, z vaší nebo naší strany. Product Owner specifikuje a prioritizuje úkoly, představuje je týmu a kontroluje, zda jsou všem jasné. V případě, že by roli Product Ownera zastával někdo z naší strany, bychom s vámi průběžně probírali vaše požadavky a komunikovali je týmu zvlášť.
2. Scrum tým
Kromě investora, delivery managementu a projektové rady tvoří Scrum tým několik dalších odborníků, kteří hrají při vývoji produktu zásadní roli. Patří mezi ně Product Owner, což můžete, ale nemusíte být vy, Scrum Master a tým vývojářů.
Povinnosti jednotlivých členů týmu:
Product Owner
definuje, co je potřeba udělat
komunikuje s ostatními členy týmu
kontroluje, že tým přináší projektu přidanou hodnotu
Scrum Master
dohlíží na dodržování pravidel Scrumu
koučuje Product Ownera i vývojáře
zajišťuje, aby tým pracoval efektivně
v ideálním případě se pro tým stává časem nadbytečným
Vývojář
vyvíjí produkt
ručí za plnění úkolů během sprintů
sdílí s týmem možná rizika a hrozící problémy
3. Scrumové ceremonie
Většina schůzek je v rámci Scrumu naplánována předem. Tým si tak zvykne na zavedené tempo práce a jeho flow neohrozí mnoho zásahů zvenčí. Veškeré ceremonie (tak nazýváme schůzky ve Scrumu) jsou časově ohraničené a koncipované tak, aby zvyšovaly efektivitu fungování týmu. Ceremonie mohou být ukončeny, jakmile je splněn jejich účel.
a. Standup
Pravidelné schůzky a synchronizace jsou pro efektivitu klíčové.
Každodenní setkání jsou důležitá především pro vývojáře. Každý člen týmu během Standupu s ostatními sdílí to, kam pokročil, co zjistil, s čím potřebuje pomoci a také to, co mu brání v dosažení společných cílů. Product Owner nemusí být na Standupech přítomen, je ale žádoucí, aby byl k dispozici v případných navazujících diskuzích a mohl pomoci odstranit vzniklé překážky.
b. Planning & Refinement
Je důležité vědět, kam povede náš další krok.
Potřebujeme něco změnit nebo přidat? Chceme vytvořit nějaký odhad? Pojďme to probrat. Tyto dvě ceremonie jsou opět důležité především pro tým developerů, který potřebuje vědět, na čem bude pracovat v následujících iteracích. Zároveň je díky nim zaručeno, že je každý úkol přesně specifikován, a hlavně správně pochopen. Tyto dvě akce se obvykle konají odděleně, v menších Scrum týmech jsou ale často organizovány společně v rámci jednoho setkání.
c. Review
Sledujeme, co máme za sebou.
Tuto ceremonii vede Scrum Master ve spolupráci s Product Ownerem. Jejím účelem je vyhodnocení sprintu, ověření dosažení cílů sprintu a nahlédnutí do statistik (pokud jsou k dispozici).
d. Retrospektiva
Hledáme poučení pro příště.
Nedílnou součástí sprintu je finální diskuze o tom, co jsme udělali dobře, co je potřeba vylepšit a čemu se chceme příště vyhnout. Výstupy z této schůzky se nazývají SMART akční body (SMART action points). Tato ceremonie je zásadní pro celý tým, protože přináší řadu změn. Kdokoli se může přihlásit o slovo a otevřeně předat konstruktivní zpětnou vazbu, avšak s důrazem na navrhování akčních bodů, nejen popisování problému samotného.
4. Scrumové artefakty (Scrum artifacts)
Ve Scrumu používáme několik ověřených návodů a pomocných definic, které vedou ke snadnější estimaci práce týmu. Zároveň nám tyto definice pomáhají přesně určit, kdy lze považovat jednotlivé úkoly za hotové. Na formulaci definic se typicky podílí celý tým.
a. Definition of Ready
Tato definice udává, jaké podklady musí být poskytnuty a vyjasněny předtím, než se začne pracovat na daném úkolu.
b. Definition of Done
Definuje, co musí být hotové předtím, než lze daný úkol považovat za dokončený.
c. Estimační flow
Jedná se o seznam otázek, které si musí tým položit předtím, než estimuje zadaný úkol. Tyto otázky jsou zaměřeny na faktory, které mohou ovlivnit složitost zadaných úkolů, tedy které mohou potenciálně zvýšit jejich estimaci.
Scrum artifacts
Necessary documents for a successful Scrum team. Ready to use examples of DoR, DoD and our own Estimation flow checklist
8 min. čtení od
5. Delivery management
Samotný proces doručování projektu nemůže být úspěšný, pokud v týmu není dobře zvládnutý Delivery management. Díky našim bohatým zkušenostem dokážeme hravě balancovat na tenkých hranicích mezi všemi dílky složité skládačky a z procesu řízení tak činíme téměř až umění.
a. Řízení očekávání
Pravidelně se setkáváme a diskutujeme o tom, jak probíhala naše spolupráce minulý měsíc a jaké máme očekávání do budoucna. Kromě schůzek s týmem developerů se v rámci Scrumu pravidelně setkáváme také s klientem, a to každý měsíc (během tzv. Delivery Meetingu), abychom probrali celkovou spokojenost s odvedenou prací, informovali o rizicích a potenciálních problémech a vzájemně sdíleli naše očekávání. Připomínáme si, že jsme na jedné lodi a pracujeme na dlouhodobém partnerství.
b. Složení týmu
Aby veškerá práce proběhla podle plánu, je potřeba na ni vybrat ty správné odborníky. S tím vám dokážeme pomoci, a to tak, že pro vás navrhneme ideální tým.
c. Alokace
Abychom zajistili, že bude mít každý člen týmu vždy dostatek práce, musíme správně nastavit alokace. Na nové návrhy a změny se samozřejmě snažíme reagovat co nejrychleji, nicméně pokud jsou známy alespoň měsíc dopředu, je zaručena naše maximální efektivita.
d. Předpovědi
Co se týče předpovídání, od dob věštírny v Delfách jsme ušli dlouhou cestu. Dnes známe mnohem efektivnější způsoby sběru relevantních údajů, na základě kterých jsme schopni předpovědět množství práce, kterou dokážeme odvést v rámci konkrétního sprintu.
e. Reporting
Na závěr je potřeba reportovat veškerou vykonanou práci. Celkové reporty upřednostňujeme vypracovávat na konci každého sprintu, z čehož plyne, že i vy můžete report očekávat se stejnou periodicitou. V každé zprávě jsou uvedeny nejpodstatnější informace o daném sprintu. Kromě toho se dopředu můžeme dohodnout na některých specifických metrikách důležitých pro spolupráci, na které budeme klást speciální důraz.
6. Sdílení informací
V rámci každého projektu je důležité předem specifikovat způsoby a komunikační kanály, skrze které budeme sdílet a ukládat informace o projektu.
a. Mise a vize projektu
Pokud týmu osobně představíte svou vizi výsledného produktu, namotivujete ho k tomu, aby s vámi s nadšením doručil co nejlepší výsledek.
b. Přístup k informacím
Každý člen týmu, včetně zákazníka, by měl vědět, kde najít potřebné informace a odpovědi na veškeré otázky ohledně projektu. Pečlivě nastavený přístup k informacím zaručí, že je projekt transparentní pro celý tým. Všichni v takovém případě ví, kde najít projektovou dokumentaci, návrhy uživatelského rozhraní, materiály k workshopu, ostatní členy týmu nebo třeba kalendář.
c. Komunikační kanály
Včasné určení komunikačních kanálů, které budeme při spolupráci používat, zabrání zbytečným nedorozuměním, podpoří transparentnost a eliminuje potřebu komunikace skrze prostředníka. V rámci každého projektu jsou typicky zavedeny dva základní kanály – jeden pro celý tým, druhý pro management. Toto tematické rozlišení nám pomůže sdílet nejaktuálnější informace a efektivně řešit problémy.
7. FAQ
Co jsou to Story Points a proč je používáte jako jednotku pro měření složitosti?
Story Points měří úsilí (Effort). Zatímco čas strávený na úkolu závisí na tom, kdo ho implementuje, množství úsilí zůstává stejné. Díky použití Story Points se tým snadněji domluví na estimacích a zároveň nám tyto body poskytnou informaci o tom, kolik úkolů stihneme dokončit v rámci jedné iterace.
Může váš tým odhadnout konkrétní časovou náročnost (hodiny, dny) namísto vytyčení abstraktních bodů, tzv. Story Points v procesu plnění projektu?
Odhadování časové náročnosti ve skutečnosti není příliš efektivním přístupem k odvádění práce (v rámci agilních metod se nepovažuje za vhodný). Naší primární jednotkou měření je tzv. User Story. Čím více práce za sebou budeme mít, tím lépe dokážeme spočítat, kolika Story Pointů docílíme během konkrétního sprintu. Díky tomuto výpočtu zjistíme, kolik práce v průměru odvede developer za jeden pracovní den.
Budu muset platit za Scrum Mastera, i když tento člověk přímo nedoručuje můj produkt? Pokud ano, kolik?
Cena za Scrum Mastera je obsažena v hodinové sazbě týmu. Scrum Master je koneckonců součástí týmu, je týmu vždy po ruce a pomáhá efektivně doručovat produkt. Více informací o roli Scrum Mastera najdete výše v tomto článku.
Jakou máte reakční dobu? (Pokud se na něco zeptám, za jak dlouho můžu očekávat odpověď?)
Typicky je doba reakce jeden pracovní den, pokud není domluveno jinak (například v rámci SLA). V praxi to znamená, že na vás požadavek nebo dotaz odpovíme nejpozději následující pracovní den. Ne vždy je ale samotný problém v tomto časovém limitu kompletně vyřešen. To může trvat samozřejmě déle.
Mám nový nápad! Můžeme na něm hned začít pracovat?
Můžeme, ale pouze za předpokladu, že stávající sprint ukončíme předčasně. Rozsah sprintu je neměnný v rámci celého procesu, jedinou možnou výjimku tvoří závažné bugy (chybné chování aplikace). Samozřejmě se nic hrozného nestane, pokud bude sprint ukončen předčasně, nicméně se k takovému kroku uchylujeme pouze ve výjimečných a řádně odůvodněných případech.
Je opravdu nutné absolvovat všechny Scrum ceremonie? Netráví tak tým většinu času na schůzkách místo toho, aby pracoval na plnění úkolů?
Ano, veškeré ceremonie jsou skutečně nutné. Z pohledu developera je samotná implementace velmi často až tím posledním dílkem skládačky. Všechna architekturální a technická rozhodnutí učiněná před samotnou implementací jsou zásadní, protože ve velké míře ovlivňují nejen samotnou práci, ale i její výsledek. Aby bylo možné činit ta nejlepší rozhodnutí, musí mít tým dostatek prostoru na to, aby předem projednal všechny důležité aspekty.
Kde najdu nějaké informace o úspěšných agilních projektech?
Existuje mnoho úspěšných firem implementujících Scrum, ze kterých si můžeme vzít příklad. Zmíníme například tyto (zdroj):
Google vyvinul několik aplikací (například Gmail, Mapy Google, Kalendář Google, Google Assistant), které vyžadují časté aktualizace. Ty je potřeba důkladně otestovat ještě před tím, než se přímo představí uživatelům na trhu.
Jedním z klasických příkladů je to, jakým způsobem Google vytváří a vylepšuje svůj operační systém Android. Google umožňuje běžným uživatelům účastnit se testování v rámci beta programu, a to pomocí fungujícího systému Android. Postupně je jedna funkce nebo vybraná sada funkcí zpřístupněna beta testerům, kteří společnosti posílají zpětnou vazbu. Pokud jejich zprávy naznačují chyby nebo závažné problémy, aktualizace se vrátí zpět k vývojářům.
IBM
Agilní Scrum hrál obrovskou roli při zlepšování obchodních operací IBM. Přístup byl pro IBM natolik zásadní, že se společnost rozhodla nabídnout svůj vlastní software IBM Rational Team Concert, který zahrnuje agilní vývojové prostředí.
Konečným výsledkem je zlepšení procesu ve všech oblastech, jako jsou včasné dodávky, nevyřízené vady, beta defekty opravené před GA, údržba i inovace.
Spotify
Spotify dělí celý tým na menší skupiny zaměstnanců, kteří tvoří samostatné pracovní jednotky. Každá skupina je zodpovědná za vytváření a udržování specifické funkce aplikace Spotify. Díky tomuto přístupu dokáže Spotify přiřadit každému týmu vybrané úkoly, aniž by hrozilo, že jedno špatné rozhodnutí ohrozí celou platformu.
Jak často můžu sledovat, jak můj produkt aktuálně vypadá?
Po každém sprintu se odehrává demo, na kterém se představují nejnovější funkcionality a změny. Těchto prezentací se můžete kdykoliv účastnit. Obvykle se také definuje plán pro průběžné nasazování aplikace, v rámci kterého se domluvíme na frekvenci nasazení jak menších změn, tak nových verzí produktu na trh.
Narazili jsme na chybu. Kdo bude platit za opravu?
V agilním vývoji je povaha úkolu, na kterém tým pracuje, irelevantní. Jinými slovy, s chybou je nakládáno jako s jakoukoli jinou prací, která má být vykonána.
Už jsem se se Scrumem setkal, ale váš tým pracuje trochu jinak, než jsem zvyklý. Čím to je?
Nejedná se o nic neobvyklého – Scrum slouží pouze jako návod, určuje základní pravidla. Dílčí postupy se však mohou měnit a záleží na konkrétním týmu, jaký způsob práce mu vyhovuje nejvíce. Ve FlowUpu funguje několik scrumových týmů implementujících software pro různé typy zákazníků a každý z nich pracuje trochu jinak.
Co je to Scrum Board (scrumová nástěnka)?
Scrum Board je způsob, kterým lze efektivně sledovat průběh vývoje celého projektu. Na této nástěnce vždy vidíte, na kterých úkolech tým zrovna pracuje, které již dokončil a které budou následovat. Ve FlowUpu nejčastěji používáme nástěnky v GitHubu a Jira.
Proč se boarda od posledně nezměnila?
Tato otázka má několik možných odpovědí, záleží tady na situaci.
Pokud jsou například zadané úkoly náročnějšího charakteru, může trvat několik dní, než je vývojáři dokončí. Typicky se ale větší úkoly rozdělují do několika podúkolů, a to proto, aby byl posun v práci viditelnější.
Pokud má tým nižší alokaci na projektu, budou se úkoly na boardě pohybovat odpovídajícím způsobem.
Nejčastějším případem bývá, že je několik úkolů na konci sprintu ve sloupci "Review" nebo "Testing”. Tým se na tyto úkoly zaměřuje prioritně a snaží se je dokončit a nasadit, aby je byl schopen představit v rámci dema stakeholderům. Z toho důvodu se úkoly v ostatních sloupcích odkládají na později.
Nakonec zmíníme, že pokud máte nějaké úkoly, které pro vás mají velmi vysokou prioritu, dejte o tom týmu vědět. Developeři je pak z backlogu vyberou jako první.
8. Závěr
Použití agilního přístupu při vývojovém procesu je velmi výhodné pro obě strany, pokud ovšem víte, jak na to. Ve FlowUpu ctíme Scrum, protože nám pomáhá doručit tu nejlepší hodnotu pro zákazníka a zároveň zaručuje kvalitní vývojový proces. Jak týmu, tak vám nějakou dobu potrvá, než si na Scrum zvyknete a naučíte se v rámci něj efektivně fungovat. Opakováním si však přístup osvojíte a stane se pro vás automatickým a přirozeným. Dlouhodobé výhody Scrumu, které umožňují efektivní řešení problémů s vývojovým procesem, jasně převyšují dobu učení se tohoto přístupu.
