Blog | Co je Scrum?

Co je Scrum?

Scrum patří mezi takzvané agilní metodiky. Co znamená agilní podrobně vysvětluje článek o agilitě. Metodika znamená, že se jedná o ucelenou manažerskou metodiku, která zahrnuje kompletní řešení toho, jak zorganizovat práci v týmu. Scrum je primárně zaměřen na organizaci vývojového týmu, byť se dá použít i mimo vývoj software.

Agilních metodik je více, byť Scrum je nejrozšířenější. Každá metodika má nějakou konkurenční výhodu. Výhodou Scrumu je předvidatelnost a odhadnutelnost práce. Díky tomu je Scrum oblíbený u stabilních firem, agentur, velkých firem. Naopak pro startupy může působit trochu svazujícím dojmem – což ale nemusí být nutně nevýhoda. I pro startup může být Scrum užitečný, to ale v situaci, kdy neexistuje žádný plán nebo zakladatelé trpí tím, že mění názor několikrát denně a vývoj je paralizován tím, že než cokoliv dokončí, zase se mu to změní pod rukama.

Scrumové týmy mívají obvykle 4–10 lidí. Pokud je lidí více, obvykle je týmů více, pokud méně, dochází k osekání metodiky.

Pro organizaci práce používá Scrum takzvané backlogy. Backlogy jsou seznamy úkolů, v kterých se hromadí práce. Existují 2. Product Backlog a Sprint Backlog. Product Backlog je seznam úkolů, které se budou dělat v budoucnu. Sprint Backlog jsou úkoly, které se mějí dělat právě teď.

Další důležitý termín jsou sprinty. Sprint je čas, ve kterém tým chce realizovat jeden Sprint Backlog. Obvyklá délka je jeden nebo dva týdny.

Scrum je postaven na rolích:

  • Člen týmu – pracuje na úkolech, které jsou v Sprint Backlogu. Člen týmu si může ze Sprint Backlogu vybrat úkol volně. Nesmí si ale vzít úkol mimo něj, třeba v Product Backlogu.
  • Scrum Master – zajišťuje chod, stará se o tým, věnuje se tomu, aby vše fungovalo, pomáhá PO, může být zároveň člen týmu. Scrum Master může být zároveň členem týmu, pokud to stíhá.
  • Product Owner – je typicky člověk z businessu nebo zástupce zákazníka. Zadává práci, kontroluje práci, může být zároveň člen týmu (vzácné), nesmí být ale Scrum Masterem.
  • Stakeholder – zastupuje zbytek světa

Ale svět je bohatší, občas je potřeba role upravovat, přidávat, rozdělovat. Zde naleznete některé z rolí, které jsem ve své kariéře zažil jako doplněk k Scrumovým rolím.

  • Business Analytik – když je doména problému složitá a vývojáři ani Producr Owner nemají čas nebo erudici ji prozkoumat, vzniká role Business Analytika, který zodpovídá za domyšlení zadání.
  • Release Manager – když je složitá infrastruktura a nasazení aplikace není jednoduché, pomáhá vývojářům Release Manager.
  • Testeři z businessu – když Product Owner nemá čas osobně akceptovat všechny úkoly, lze přenést akceptaci úkolo na testery z businessu. Pozor, to není totéž, co běžní softwaroví testeři, tito testeři jsou často lidé, kteří budou skutečnými koncovými uživateli systému a tuto roli dělají jako doplňkovou pár procent své pracoví doby.
  • Product Owner Proxy – pokud není PO dostupný, je v jiné lokalitě, ještě hůř v jiném časovém pásmu, ale je potřeba rychlejších reakcí, lze zvolit PO Proxy. Ten se snaží fungovat jako náhrada PO a nabízí reprodukovaný pohled na problém. PO Proxy by neměl mít vlastní názory, ale měl by se snažit fungovat jako „prodloužená mysl“ skutečného PO, takže když něco schválí PO Proxy, je víc než devadesátiprocentní šance, že to schválí i PO.

Celý Scrum je organizován pomocí procesů. Těch procesů je celá řada. Všechny jsou změnitelné podle potřeb. Toto jsou ty

Proces plánování

Slouží pro to, aby Product Owner uměl zadat práci a tým si ji převzít.

  • Vše se dává do product backlogu
  • Existuje formát úkolu, který se nazývá User Story, ten je preferovaný, nicméně existují alternativy
  • Úkoly jsou v backlogu seřazeny pomocí procesu prioritizace
  • Tým si vybírá úkoly, které stihne a udělá z nich tzv. sprint backlog, vždy bere úkoly z vrchu Product Backlogu a bere si tolik úkolů, kolik předpokládá, že stihne. Vkládá je do Sprint Backlogu
  • Tento Sprint Backlog je objem práce, ke kterému se tým zavazuje

Proces prioritizace

Slouží pro seřazení úkolů v Product Backlogu

  • Existuje více přístupů
    • Demokratický – lidé se mají shodout, co je nejdůležitější
    • Polo-demokratický – lidé diskutují priority, ale jeden má poslední slovo
    • Autokratický – existuje jasně daná hierarchie požadavků
    • Vyhnutí se problému – zvolí se, že jeden tým má jednoho Product Ownera a od dalších lidí práce nejde, takže si priority nastavuje jeden člověk sám
  • Výsledkem je, že jsou vybrány úkoly, které jsou nyní nejdůležitější

Proces schvalování práce

Slouží pro určení, že je úkol hotov.

  • Existuje podproces zvaný „Definition of Done“, která určuje, co musí být splněno, než je úkol považován za hotový
    • Součástí je tzv. akceptace, tedy schválení úkolu:
      • Práci schvaluje Product Owner
      • Má právo odmítnout úkol z jakéhokoliv důvodu

Proces vyhodnocení

Slouží pro vyhodnocení práce a určení, jak se má tým dále zlepšovat.

  • Na konci bývá často release
    • Ikdyž Scrum nevyžaduje release cyklus svázaný se sprinty
  • Zároveň retrospektiva
    • Při ní se lidé sejdou a vyhodnocují fungování a snaží se přijít na to, jak fungovat lépe

Těch procesů je víc, dál Scrum obsahuje i podprocesy, jako zmíněná akceptace, tvorba Definition of Done, denní organizační schůzka zvaná stand up. Co je ale podstatné, že organizace je přenena z Project Managerů na lidi. Scrumové týmy obvykle nepotřebují projekťáky.

Scrum jako manažerská metodika neřeší některé věci a vyžaduje ohnutí nebo dopracování. Například se Scrum vůbec nijak nestaví ke schvalování dovolených, jestli má existovat team leader, jestli a jak mají být hodnoceni pracovníci, neřeší, jak mají být lidi nabíráni a propouštěni. Neřeší téměř reporting. Některé reporty sice existují, ale nepokrývají bežné potřeby projektového řízení.

Obecně platí, že Scrum je jen začátkem a všechny procesy se v čase mění a vyvíjí. Vysoká míra autonomie, která je společná pro všechny agilní metodiky, vede k tomu, že týmy optimalizují pro potřeby zákazníků, optimalizují pro využití vlastních talentů a tomu, kam se hýbe trh i použité technologie. Zpětná vazba je mnohdy až radikální a jsou běžné různé experimenty a pokusy způsob fungování vylepšit.

Agile

Předejte zkušenosti i dalším a sdílejte tento článek!



Jiří Knesl
Business & IT konzultant

Jiří Knesl poprvé začal programovat v roce 1993. Od té doby, díky skvělým učitelům a později zákazníkům, měl možnost neustále růst v oboru vývoje webových aplikací a informačních systémů. v roce 2002 se přidal zájem o ekonomii a v roce 2006 o organizaci práce. Vším tím se konstantně profesně zabývá jak ve svém podnikání, tak i u zákazníků. Za posledních 5 let vydal na tato témata přes 400 článků.

Prohlédněte si moje reference

Mám zkušenosti z rozsáhlých projektů pro korporace, velké podniky, střední i malé firmy, ale i pro startupy v cloudu. Zvyšoval jsem jejich know-how, pomáhal nastavovat jejich organizační strukturu, byl lektorem a mentorem v náročných situacích. Podívejte se, jak vidí můj přínos samotní klienti.

Sledujte mé postřehy na sociálních sítích