Být efektivní znamená sprintovat aneb Jak v SHEANu plánujeme práci

Požadavek, termín, čas, kapacita, efektivita. Jak vše skloubit tak, aby spolupráce agentury s klientem probíhala hladce a obě dvě strany byly spokojené? Otázka, která našemu vývojovému týmu vrtala hlavou do doby, než se zavedlo důkladné plánování práce. A než všichni začali sprintovat.

Proč je dobré nahlédnout do toho, jak pracujeme? Po přečtení článku budete přesně vědět, co od nás můžete očekávat a co můžeme udělat pro to, aby partnerská spolupráce klapala podle očekávání.

Jak pracují programátoři v SHEANu

Oddělení vývoje prošlo několika změnami. Od pár vývojářů ke stabilnímu týmu, který potřeboval zasadit do jasných procesů. A agilního řízení.

Z jakých specialistů se skládá náš „dev“ tým?

• Backend developer (BE) – řeší takové úkoly, které jsou pro uživatele webu většinou méně viditelné a reprezentují zejména logiku, výpočty a zpracování vstupů a výstupů.
• Frontend developer (FE) – tvůrci viditelnější stránky webu, realizují především řez a samotné napojení stránky, ale také aplikace v Javascriptu.
• UX a UI designer – pomáhá vytvářet uživatelsky přívětivé a intuitivní prostředí všech námi vyvinutých projektů.
• Product Owners (PO) – udržují myšlenkovou mapu a priority nad danými projekty a úkoly, v součinnosti s klientem definují business zadání a dohlíží nad plněním jejich obsahu.
• Agile Leadership (AL) – opatrovník celého týmu, jehož rolí je odstraňovat procesní, kapacitní, sociální a technické problémy, které znemožňují týmu kvalitně provádět svoji práci. Moderuje podněty v podobě zpětné vazby směrem do týmu a společně se snaží najít východiska a zlepšení směrem do budoucna.

Přes nejrůznější pokusy plánování práce jsme nakonec dospěli k agilnímu řízení týmu, kdy jsme převzali některé prvky a základy z metodiky SCRUM, dodali vlastní prvky aplikovatelné na řízení více projektů v rámci jednoho týmu a začlenili vícečetnost Product Owners, kteří si navzájem konkurují. Celý agilní vývoj je založen na týmu jako celku, sdílení informací, zpětné vazbě a společné snaze dosáhnout daného cíle. Projekty rozdělujeme na jednotlivé funkční části, z nichž se každá řeší zvlášť.

Práce na dílčích částech probíhají v tzv. sprintech (kratších, v našem případě vzhledem k dynamice požadavků týdenních úsecích). Díky tomu se nám daří budovat jasný plán s ohledem na kapacity týmu, který nám zároveň umožňuje flexibilně reagovat na nečekané incidenty nebo změnu priorit za běhu. Základem je tým, komunikace, přehled o alokacích a plnění dílčích úkolů v čase a možnost v klíčových bodech provádět změny, na kterých se jako tým shodneme.

Je důležité podotknout, že výše popsaný agilní model řízení práce je přizpůsobený pro naše podmínky a potřeby, a to právě z hlediska řízení více projektů současně.

Jak vypadá naše agilní řízení v praxi?

Agilní vývoj je z našeho pohledu krok kupředu vzhledem ke koordinaci práce na různorodých projektech a uspokojení potřeb všech klientů.

Jelikož tým není nafukovací a požadavky přicházejí z více směrů, je potřeba důkladně plánovat. Product Owneři si svým způsobem konkurují a „svádějí boj“ o čas vývojového týmu, proto je třeba určitá míra koordinace. K tomu slouží pravidelné strategické porady (PO meeting), které se částečně blíží situacím ve škálovaném SCRUMu, během nichž se představuje vize na následující sprint a zároveň predikce na několik týdnů dopředu. Koordinace je podstatná zejména z důvodu určení priorit, vytíženosti týmu a předcházení potenciálních rizik.

Plánování úkolů za pomoci sprintů

Zadání konkrétních úkolů řešíme na týdenní bázi (= sprint), v rámci týmového planningu. Startujeme každý týden v úterý. Úkolem Product Ownerů je připravit v součinnosti s týmem konkrétní technické zadání dílčích úkolů, schválit je s klientem a stanovit jejich časovou náročnost (estimate). Bez těchto parametrů je úkol nerealizovatelný a nevstupuje do vývojového procesu.

Kvalitně připravené úkoly tvoří pomyslnou hromadu (Backlog), ze které se následně dle priorit vybírají úkoly do realizace. Známe přesnou disponibilní časovou alokaci každého vývojáře, který je rozdělen na čas realizační a rezervní. Zároveň vidíme případné rezervy nebo potřeby přealokace na jiného realizátora. Planningu se účastní celý tým, řeší případné nedostatky, neúplné informace, kolize a potenciální rizika, či potřebnou koordinaci. Celkově vytváří závazek k tomu, že bude na konci týdne zaplánovaná práce dodána.

Součástí sprintu jsou také každodenní „stand-up“ meetingy celého týmu. Během nich vývojáři reportují svůj aktuální pokrok v rámci úkolů a řeší případné problémy. Díky tomu je jasný přehled o průběhu úkolů. Sdílíme informace napříč týmem a jsme schopni velmi flexibilně reagovat na nečekané události.

Proč právě takto?

• Hlavní výhoda spočívá především v efektivním rozdělení práce mezi všechny vývojáře.
• Jasný přehled o kapacitách jednotlivých odborníků. 
• Sdílení a tok informací napříč týmem.
• Flexibilní reakce a přizpůsobení se vzniklým situacím.
• Závazný termín vyhotovení konkrétního úkol.
• Příjemné a neagresivní prostředí pro vývojový tým.
• Možnost specializace vývojářů vybrané oblasti.
• Průběžný přehled nad čerpáním alokací a fakturovanými hodinami našim partnerům.
• Zpětná vazba a otevřené prostředí pro zavádění změn a optimalizaci procesů.
• Zploštělá řídicí struktura, kde není odpovědnost na jedné osobě, ale na celém týmu + zastupitelnost.

Přesně stanovený termín zahájení sprintu může být nevýhodou v případě nekompletních zadání od klienta. Pokud není známo zadání před úterním restartem sprintu, není možné úkol v týdnu realizovat a zařadit do pracovního plánu vývojářů.

Řešení úkolů mimo plán

Během týdenního cyklu se samozřejmě může objevit řada neplánovaných věcí. Může dojít například k neplánované chybě či problému. Z toho důvodu musí vývojáři pro týdenní plánování počítat také s rezervou pro případné nutné servisní požadavky.

V tomto ohledu pak rozeznáváme 3 různé případy požadavků: servisní chyba, servisní požadavek a expresní požadavek.

• Servisní chyba je takový stav, kdy dojde k neplánovanému problému (např. výpadek na e-shopu), který je nutný řešit téměř okamžitě. Řešení těchto chyb má pro naše vývojáře vždy jasnou prioritu.
• Servisní požadavek je součástí běžné týdenní agendy. Jedná se nejčastěji o různé úpravy současného řešení, které však nijak zásadně neovlivňují chod webu či e-shopu.
• Expresní požadavek je takové zadání klienta, které chce zapracovat co nejdříve (ideálně ihned). Pro expresní požadavky v rámci plánování práce vývojářů nevytváříme rezervu. Jejich řešení tak často vyžaduje práci „nad plán“. Z toho důvodu jsou expresní požadavky opatřeny specifickou hodinovou sazbu. Více informací o expresních sazbách v tomto článku.

Vývoj webů, e-shopů, ale hlavně týmu, který tyto oblasti rozvíjí, je nikdy nekončící proces. Neustále se posouváme dál a hledáme nové cesty, které zefektivní práci na projektech našich klientů. Věříme, že nahlédnutím do naší „bubliny“ jste pochopili mnohé návaznosti a třeba i lépe pochopili náplň práce našich programátorů.