nav line

Svět je rychlejší, pracujme agilně

Co je to ta tajemná agilita, proč je nyní tak moderní a žádaná a jaké jsou předpoklady správně organizovaného agilního týmu?

Svět je rychlejší, pracujme agilně

Co je to ta tajemná agilita, proč je nyní tak moderní a žádaná a jaké jsou předpoklady správně organizovaného agilního týmu?

Proč agilně?

Protože doba se nám opravdu velice zrychlila a člověk/klient nechce čekat půl roku nebo i déle na něco, co si objednal už loni. Chce vidět alespoň kousek hned nebo co nejdříve. Spokojí se s tím, že si ochutná kousek nyní, další kousek třeba již za měsíc a takto se postupně dostane k celé své objednané porci.
Největší výhoda agilního, přírůstkového (iterativního) vývoje a dodávání je, že můžete kdykoliv říct, že chcete něco jinak a tato změna nebude znamenat kompletní přeorganizování a přepracování již hotové práce a tedy zbytečné náklady navíc.

Jak to začalo? Přirozeně.

Kdokoli se pohybuje kolem IT projektů ví, že ještě před pár lety byl nejčastějším projektovým standardem tzv. waterfall, čili řízení projektu po jednotlivých blocích od analýzy, přes návrh, vývoj, testování, nasazování a konečně – předání do provozu.

Pojďme si to projít na příkladu: velká korporace se rozhodla, že chce nový firemní intranet. Vypsala proto výběrové řízení na dodavatele, protože projekt nemohla zajistit vlastními kapacitami. Vybrala vítěze a nastartovala projekt. V jeho první - analytické části - přišly do firmy business analytici a začali zkoumat klienta a jeho potřeby, co vlastně přesně chce, aby ten intranet uměl. Všechno si zapsali, vyrobili 150 stránkový dokument zvaný business analýza, který měl spoustu textu, grafů, schémat a celá tato fáze zabrala většinou 2-3 měsíce.

Poté se tento dokument schválil do "výroby" a nastoupila armáda vývojářů, kteří podle tohoto zadání celý intranet začali vyrábět. A už po 5 měsících tvrdé dřiny měli první verzi, kterou postupně ukazovali nejprve vlastním testerům a poté klientovi. Ten "už" tedy po 3/4 roce viděl, co si vlastně objednal a většinou zjistil, že minimálně polovinu chce jinak a zadal tedy změnový požadavek, který vedl buď k navýšení ceny, nebo k prodloužení projektu v čase. Změny se zapracovaly, došlo na finální testování a jednoho dne byl nový intranet spuštěn mezi řadové zaměstnance. Od výkopu po spuštění uběhl klidně celý jeden rok. Z praxe víme, že teprve tito zaměstnanci objevili spoustu chyb, protože s intranetem byli zvyklí nějak pracovat a ten nový se najednou ovládá jinak a nemohou tam rychle najít to, co zrovna potřebují.

Scrum

Takovýchto projektů proběhly v českém i světovém IT miliony. Postupem času si tedy všichni uvědomili, že je nutné zrychlit a jít s výrobkem, ať je to cokoliv, k opravdovým zákazníkům co nejdříve, získat co nejdříve zpětnou vazbu, tu zapracovat a zase co nejrychleji dodat hotový, již vylepšený produkt. A hle, zrodil se nám agile. Agilních metodik a agilních přístupů je mnoho, ale zřejmě nejrozšířenější a nejznámější je Scrum.

Scrum  je praktický, univerzální průvodce, který definuje, jak by měl vypadat ideální projektový tým, jak by měly být obsazeny role v týmu, aby správně a samostatně fungoval a jakým způsobem by měl tým vyrábět očekávaný produkt.

Podívejme se nyní na to, z čeho a z koho se Scrum skládá a jak vlastně funguje.

Role

Scrum rozlišuje tři hlavní role - Scrum Master, Product Owner a Scrum Team.

Pojďme je projít.

  • Scrum Master je bystrý, všímavý a komunikačně schopný organizátor, který neustále dohlíží na to, aby celý tým spokojeně pracoval, nebyl rušen a měl vždy v zásobníku dostatek dobře promyšlených nápadů a úkolů. V praxi je to většinou bývalý klasický „projekťák“, který zvládá komunikaci s ředitelem firmy i s juniorním testerem. Organizuje všechny scrumové seance/meetingy, a funguje jako SPOC (Single Point of Contact). Dělá bariéru a zároveň komunikátora mezi okolním světem a týmem.
  • Product Owner, jak název napovídá, je osoba, která vymýšlí a připravuje to, co se vlastně má vyrobit. Má k tomu pečlivě organizovaný a přehledný seznam, který se jmenuje Backlog - tedy zásobník práce. Je to člověk, který zastupuje klienta, tedy jedná v jeho zájmu a chce mu co nejrychleji dodat to, co si klient objednal.
  • Scrum Team je tvůrčí tým, to jsou ty ruce, které to všechno vyrobí. Běžně jsou to vývojáři, kodéři, testeři, analytici atp. Nejběžnější scrumový tým se skládá většinou z 5-10 lidí. Méně i více je na škodu a tým s více jak 10 lidmi již není tak agilní a efektivní.

Obecné schéma fungování metodiky Scrum. Zdroj: Uniberasoft.com

Artefakty - neboli hlavní stavební prvky

Artefakt v metodice softwarového vývoje znamená viditelný výstup, který vznikne během vývoje.

Stejně jako klasický waterfall projekt, i projekty s agilním vývojem mají své artefakty. Pod tímto pojmem se skrývají (převážně) fyzické výstupy či dokumenty, které sledují průběh projektu, nicméně oproti vodopádovým projektům jsou tyto výstupy mnohem živější, upravují se častěji a jsou obsahově řádově kratší, tedy pro rychlý vývoj praktičtější.

Backlog - ten už jsme nakousli výše. Představte si jej jako seznam všech úkolů, zásobník práce, který je potřeba vyřešit nebo vyrobit a dodat. Položky, které jsou nahoře, mají nejvyšší prioritu a musí se na nich začít pracovat co nejdříve. Výsostným správcem je pouze Product Owner, ale úplně každý má právo přispět a dodat svůj nápad, svoji myšlenku. Tu potom Product Owner zhodnotí a rozhodne se, klidně po poradě s týmem, zda nápad bude realizován nebo ne a určí jeho prioritu.

Sprint - jde o časovou, ucelenou jednotku, nejčastěji 2 týdenní blok, který má jasný začátek i konec a v ideálním případě platí, že co si na začátku tým naplánuje, to taky na konci dodá klientovi.

Sprint Backlog je právě ta část Backlogu, která je náplní jednoho bloku vývoje - Sprintu. Prostě seznam úkolů a práce pro jeden Sprint.

Inkrement - nehezké slovo, které můžeme nahradit českým ekvivalentem „přírůstek“. Je to přesně ten kousek hotového produktu, který se dá už nějakým způsobem použít. Představte si jej například jako stěrače v autě – má to již tu ovládací páčku, motorek i vlastní stěrače a když se to celé připojí k elektrice, tak stěrače stírají. A z takovýchto podobných kousků (inkrementů) je složen celý výsledný produkt – v tomto případě auto.

Burn-down-chart - něco shořelo, že? Naštěstí ne. Jde jen o propracovaný graf, který nám ukazuje, jak si vedeme s plněním jednotlivých úkolů během sprintu.

Scrum Board je nástěnka, nejlepší je opravdu stará dobrá tabule nebo zeď a nové moderní post-it lístečky. Každý člen týmu má svůj řádek, má své přidělené úkoly (co úkol, to lísteček) a ty postupně přelepuje mezi jednotlivými sloupci (TO DO - IN PROGRESS - DONE), aby bylo jasné co už má hotovo, na čem dělá a co teprve bude dělat. Nástěnka by měla být veřejná, aby i člověk mimo projekt mohl jedním pohledem zjistit, jak si tým vede a co už má hotové.

Seance

Seance v kontextu vývoje znamená schůzku, setkání lidí pracujících na projektu.

Agile dovoluje mnohem pružnější komunikaci mezi zákazníkem a dodavatelem (ať už se jedná o interní, či externí vztahy), nicméně i tato komunikace musí mít svůj řád. Agile totiž neznamená, že se může všechno pořád měnit, ale jasně udává kdy je vhodný moment pro případný zásah. Scrumové meetingy, neboli seance, tedy pomáhají držet správný směr a zároveň ukazují, kdy je dobré zasáhnout a směr poupravit.

Planning - jde o naplánování další práce pro následující Sprint. Product Owner určí Sprint Goal - tedy hlavní cíle, které musí být dosaženy a tým si rozebere jednotlivé "lístečky" s úkoly. Scrum Master poté oficiálně zahájí Sprint. Tento meeting by neměl trvat déle jak jednu hodinu.

Grooming slouží k tomu, aby vývojový tým zhodnotil a zoponoval nápady, které do týmu přinesl Product Owner. Ten si například vymyslí, že by chtěl všechna tlačítka a další aktivní prvky na všech obrazovkách přemalovat, zvětšit a zároveň jim přidat nové funkce. Myslí si, že se to zvládne za jeden Sprint a tým mu to buď potvrdí nebo vyvrátí a vysvětlí proč to je nebo není jednoduché. Rovněž i Grooming by ideálně neměl trvat déle než hodinu.

Stand-up je asi nejznámější pojem z celého agilního vývoje. Jde o velice svižný, rychlý, synchronizační meeting, který by měl ideálně trvat právě tolik minut, kolik je členů na Stand-upu. Osmičlenný, skvěle organizovaný tým tedy zvládne tento meeting za 8 minut. Každý člen totiž během své minuty slávy řekne jen to, co dělal včera, čemu se bude věnovat dnes a zda má nějaké překážky nebo problémy. Tyto překážky si Scrum Master zaznamená a vyřeší je AŽ po skončení tohoto meetingu, protože ne všechny zajímají tytéž potíže. Výhoda je, že na denní bázi ví každý člen týmu, co se děje na projektu. (Na rozdíl od týdenních statusů). Hlavním cílem Stand-upu ovšem není micro-management jednotlivých členů, ale především vědět, co bude dělat tým jako celek v nejbližších hodinách.

Demo - po skončení Sprintu následuje Demo. Na Demo chodí zástupci klienta, klidně může přijít i samotný klient, prostě lidi mimo projekt a těm se předvádí, co tým zvládl udělat během posledního Sprintu. Klienti můžou dodat zajímavé reakce i zpětnou vazbu, diskutují s týmem, dodávají podněty. Časově demo zabere zhruba hodinu, v případě velkého a aktivního obecenstva i více, maximálně však 2 hodiny.

Retro - neboli retrospektiva - je interní meeting členů týmu, kde zhodnocují svoji vlastní práci a přístup k ní. Předávají si pozitivní i rozvíjející zpětnou vazbu na sebe i na tým. Sdělí si, co je baví, co ne, s čím by chtěli začít, s čím skončit. Na konci se určí 3-4 hlavní výstupy, těm potom Scrum Master určí odpovědnou osobu a ta do další retrospektivy zajistí nápravu. Tento meeting by opět neměl trvat déle než naši magickou jednu hodinu.


Více času na práci

Pokud tedy vezmeme ideální tým, správně naplánovaný dvoutýdenní Sprint a dobře promyšlený Backlog, tak se dá jednoduše spočítat, že není potřeba trávit denně 2-3 hodiny meetingováním a rokováním o projektu, ale stačí nám 1x planning, 1x grooming, 1x demo, 1x retro a 10x denní stand-up. Celkem tak meetingováním strávíme maximálně 3 hodiny týdně... Rozdíl, že?

Scrum se dokonce ujal jako účinný nástroj a pomocník i mimo IT svět a běžně se tak setkáváme s tím, že firemní pravidelné porady se odehrávají formou Stand-upů, management firmy neplánuje pětiletky, ale spíše krátkodobé cíle, které obratem zpětně vyhodnocuje, zpětná vazba v celé probíhá formou interních retrospektiv, týmy se potkávají častěji, ale po výrazně kratší dobu a nikdo není z dlouhých porad otráven.

Scrum je tedy skutečně univerzální způsob vývoje a pokud je dobře organizován uspoří mnoho času i prostředků. Jeho největší výhoda je, že extrémně rychle reaguje na změny a dodá vám jen to, co opravdu chcete. Naopak klade vyšší důraz na organizaci týmu a zapojení jednotlivců než standardní „vodopádové“ vývojové postupy – určitě to není a ani nesmí být chaos.

Ohodnoťte článek

Svět je rychlejší, pracujme agilně

Související články

Vyhledávání na blogu

Webová integrace

Webová integrace jako nová oblast pro business „velkých" webových agentur.

o webové integraci

Profily blogujících