Slovník IT pojmů

Pojem Agile už jsi někdy slyšela, ale nevíš, co si pod tím reálně představit? A co takový sprint nebo Scrum Master? Pojď si s námi projít hlavní pojmy, se kterými se setkáš při práci na IT projektu.

Agile (Agilní vývojový model)

Způsob vedení projektu, kdy se k cíli dostáváme postupně v rámci kratších časových úseků, tzv. iterací nebo sprintů. Na začátku projektu víme, jaký software chceme dodat, rozdělíme si ale práci do několika iterací a dodáváme software po malých dávkách zákazníkovi. Zákazník tak může lépe reagovat na to, co se vyvíjí a případně měnit své požadavky. Na tyto změny je tým schopný pružně (agilně) reagovat. V rámci Agilního vývoje rozeznáváme tzv. týmové ceremonie:

• grooming;
• planning;
• retrospektiva;
• demo;
• scrum/standup.
  

Backlog

Je to místo, které shromažďuje všechny projektové úlohy (epic, user story, task, bug), které jsou definované pro dokončení celého projektu. V agilně řízených projektech je to živá věc, často se mění a spravuje ho Product Owner. Z tohoto backlogu pak přesouváme jednotlivé user story a jí přiřazené tasky do tzv. sprintu – to je práce, na které budeme pracovat a kterou doručíme v dané iteraci (sprintu). Spravuje se v nějakém systému pro řízení projektu (JIRA, Azure, TFS a další).

Bug

Je to typ projektové úlohy, zpravidla na stejné úrovni jako User story. Bug, neboli chyba, defekt je specifikace chyby v kódu, která byla nalezena v procesu testování. V rámci Bugu definujeme následující:

• popis, co je špatně – všeobecný popis;
• proč to je špatně – zde zmiňujeme nějaké požadavky, definice user stories, epiců apod. (musíme jasně dát najevo, proč je to chyba, zda porušujeme nějaký konkrétní požadavek atd.);
• kroky k reprodukci, které 100% vedou k chybě;
• severita, neboli jak je chyba závažná (kritická, blokující, minoritní, majoritní atd.);
• možný dopad na zákazníka;
• můžeme navrhnout i řešení chyby.
  

Demo (sprint review)

Je to společný meeting všech lidí v týmu, kde se prezentuje dodaná funkcionalita v rámci uplynulého sprintu. Tohoto meetingu by se měl zúčastnit zákazník, nebo jeho zástupce a reagovat na to, zda je vyvinutá funkcionalita v souladu s požadavky. Primárním cílem tohoto meetingu je včas podchytit situaci, kdy pracujeme na něčem, co zákazník nechce nebo si díky tomuto meetingu uvědomí, že to chce jinak.

Epic

Je to typ projektové úlohy, který popisuje větší část funkcionality vyvíjeného systému. Například, kdybychom vyvíjeli e-shop, tak jeden epic by popisoval funkčnost třeba přihlášení/registrace, další například proces nákupu, další konfigurace platební brány atd. Soubor epiců popisuje kompletní funkcionalitu celého systému. Epicy se dále dělí na menší projektové úlohy User stories a ty se dále dělí na tasky.

Estimace

Estimace je pojem, který budeš hodně slýchat na sprint planning meetingu. Jde o odhad, jak dlouho nám naše práce bude trvat. Taková estimace se dělá pro jednotlivé User stories ve formě tzv. story points, které udávají jak časovou tak technickou náročnost dané user story (čím vyšší hodnota, tím náročnější), tak ve formě hodin (v případě Tasků). Cílem takové estimace je tedy dát týmu informaci o tom, jak náročná daná úloha je a jak dlouho bude trvat. Pokud by byla příliš náročná, Scrum master pak bude hledat cesty, jak takovou úlohu rozdělit. Cílem agilního vývoje je mít práci rozdělenou do co nejmenších úloh, tak abychom mohli sledovat progress týmu nejlépe, jak můžeme.

Grooming

Je to společný meeting všech lidí v týmu, kde si vyjasňují, jak bude funkcionalita, kterou se tým zavázal implementovat v rámci sprintu, fungovat. Jak ji chápou všichni lidé v týmu a jestli to je v souladu s tím co chce zákazník. Zpravidla se tzv. grooming session objevuje u projektů řízených agilní metodikou (Agile).

‍

Planning (plánování)

Je to společný meeting všech lidí v týmu, kde se zavazují, jakou funkcionalitu a hodnotu doručí zákazníkovi v rámci jednoho sprintu. Zpravidla by měl nastat po groomingu, kdy už všichni chápou, co budeme dělat. Na planningu zpravidla říkáme, jak dlouho nám daná práce bude trvat a jestli je reálné doručit danou funkcionalitu v rámci daného sprintu.

Product Owner

Je to role v týmu, která má za cíl přenášet vizi projektu na všechny členy týmu. Zpravidla má největší znalosti o vyvíjeném systému, zastupuje v týmu pohled zákazníka a jeho motivací je doručit nejvyšší možnou hodnotu zákazníkovi. Není členům týmu nadřízen, spíše členy týmu podporuje a zajišťuje informace, které potřebuje k úspěšnému doručení softwaru.

Retrospektiva (Retrospective)

Je to společný meeting všech lidí v týmu, kde se vyhodnocuje uplynulý sprint z pohledu lidí v týmu – co šlo špatně, co šlo dobře. Může se vypíchnout i konkrétní úspěch týmu nebo jednotlivce. Cílem tohoto meetingu je neustále zlepšovat proces a odstranit problémy, které se vyskytují v týmu.

Scrum/standup

Je to společný meeting všech lidí v týmu, který se zpravidla koná každý den. Na tomto meetingu každý reportuje svou odvedenou práci, na čem bude dále pracovat a jestli má nějakou překážku, která mu znemožňuje pokračovat dále. Tento meeting by měl být super rychlý, neslouží k povídání si.

Scrum Master

Je to role, zpravidla zastoupená v projektech řízených agilní metodikou. Tento člověk je zodpovědný za to, že nikdo nemá žádnou překážku, která by mu znemožnila doručit jeho práci a pokud se taková překážka objeví, tak pracuje na jejím odstranění. Jeho úlohou je moderovat meetingy týmu a sledovat jeho progress a případně upozornit na to, pokud progres týmu není takový jaký bychom očekávali.

Story point

Udává náročnost User story. Je to forma estimace časové a technické náročnosti dané User story, tedy jak dlouho bude implementace User story trvat a jak je pro mě technicky náročná. Čím vyšší hodnota, tím náročnější je. Zpravidla se používá Fibonacciho číselná posloupnost, tedy 1, 2, 3, 5, 8, 13, 21 atd... O tom, co jednotlivá čísla znamenají, je nutné se v týmu domluvit. Dá se ale říct, že 1 story point by měla být náročnost několik hodin, 5 story pointů cca 2-3 dny, 13 cca jeden týden. Je nutné se ale domluvit v rámci týmu a používat stejná měřítka.

Task

Je typ projektové úlohy, která je součástí user story. Soubor tasků pod danou user story má za cíl implementovat funkcionalitu popsanou v user story a doručit tak hodnotu zákazníkovi. Typicky, takové tasky mohou být na implementaci kódu pro vývojáře, design testů pro testery, definice požadavků pro product ownery a další, které jsou potřeba pro dokončení dané user story. Každý task je tzv. “Estimován”, tedy je definováno, jak dlouho bude trvat, než bude dokončen (zpravidla v hodinách).

Test manager/test lead

Je člověk zodpovědný za tým testerů a za jejich dodanou práci. Je to člověk ve vedoucí pozici a je zodpovědný za to, jak tým naplňuje testovací strategii či testovací plán. Zpravidla rozděluje práci a reviduje práci ostatních testerů v týmu. Můžeš se setkat i s tím, že test manager bude chápán spíše jako people manager a nebude technicky řídit testování na projektu.

User story

Je to typ projektové úlohy, která specifikuje, jakou hodnotu máme zákazníkovi dodat. Další typy projektových úloh můžou být Epic, Task, Test case. V rámci User story popisujeme dílčí funkcionalitu systému, nikoliv funkčnost celého systému. Například, pokud bychom měli v rámci projektu implementovat ERP systém, tak projektová úloha “Epic” s názvem “Docházkový systém” by mohla shrnovat set “User stories” pro tento systém, které je potřeba implementovat, abychom měli funkční docházkový systém. Dá se tedy říct, že “Epic” je nadřazen “User story”. User stories by měly být vždy psány z pohledu uživatele a měly by specifikovat, jakou hodnotu zákazníkovi dodává. Každá User story by měla obsahovat akceptační kritéria – tedy kdy bude zákazník považovat User story za kompletně hotovou. Standardně mezi takové akceptační kritéria může patřit například – 1. implementace kódu, 2. unit testing, 3. analýza požadavků, 4. test design, 5. množství a severita bugů atd…. Každá user story je tzv. “Estimována” pomocí tzv. “Story pointů” – tyto story pointy odráží náročnost dané user story (technickou, časovou).

Waterfall

Je způsob vedení projektu, kdy jednotlivé úkony/aktivity (vývoj, analýza, testing, akceptační testování atd.) na sebe plynule navazují, nekonají se však současně. Nejprve se tak definuje potřeba zákazníka, vytvoří se požadavky, ty se přemění ve funkční kód, a až je kompletně produkt hotový, předává se testerům k otestování. Po otestování se předává zákazníkovi k akceptaci. Nevýhodou tohoto modelu je hlavně to, že zpětná vazba na testovaný systém přichází příliš pozdě (chyby se odhalí až po jejich implementaci), protože tým a ani zákazník nemůže pružně reagovat na to, co se vyvíjí.

‍

Slovník pojmů pro tebe připravili lektoři Czechitas Robin Weiss a Vojta Barta.

‍