My v Kentico fičíme na agilní metodologii Scrum. Všechny vývojové týmy. Já patřím též do jednoho z vývojovýho týmů, avšak ne ledajakého. Narozdíl ode všech ostatních týmů, které tvoří naše bezva produkty Kentico CMS a Kentico EMS, my fungujeme jako taková malá webová angetura. Vytváříme software, webové stránky a aplikace pro interní účely, aby se firma prezentovala prostřednictvím média internet jak se sluší a patří a interní procesy držely po kopě.
Zavádění Scrumu
V době, kdy jsme zaváděli Scrum, jsme všichni byli v silném psychickém napětí, neb všichni museli měnit své mindsety a zažívat si nová, občas na první pohled podivná, pravidla. Jednou z hlavních překážek bránící efektivní týmové spolupráci bylo dělení user stories mezi členy týmu. Scrum totiž ve svém základu počítá s tím, že na jakékoliv user story je schopen pracovat jakýkoliv člen týmu. U nás to však nebylo dost dobře možné. Neb je náš tým sdílený zdroj pro celou firmu a je po něm žádáno pracovat na velmi rozličných úkolech. Od práce s datovými sklady, back-end programování v C#, přes front-end programování v JavaScriptu, tvorbu webových šablon až po prototypování, tvorbu grafiky a uživatelské testování. Takový rozptyl si vyžaduje specialisty a po odborníkovi na tvorbu webových šablon přeci nemůžu najednou chtít, aby psal rozsáhlé dotazy do databáze.
T-Shaped lidé nestačí
Náš vývojový tým se skládá ze tří back-end vývojářů, dvou front-end vývojářů/designerů a testera. Už před nasazením Scrumu náš tým pracoval ve stejném složení na stejném rozptylu typu úkolů s tím, že si je dle domluvy dělil, případně na nich spolupracoval. Se Scrumem však najednou přišel tlak na to, aby každý z týmu byl schopný pracovat na jakémkoliv typu úkolu, což bylo vskutku vyčerpávající. A i když už z předchozích bezscrumových dob jsme se cítili jako nabušení T-Shaped lidé, jednotlivci nebyli schopni pokrýt celý rozsah úkolů směřovaných na tým. Věděli jsme, že děláme někde chybu.
Řešení
Abychom situaci vyřešili, celý tým jsme se sešli, zamysleli se nad situací a podnikli akční kroky:
- Sepsali jsme si typy User stories, které jako tým dostáváme (navrhnout webovou stránku, synchronizovat data napříč databázemi, zajistit asynchronní načítání dat na webové stránce, ...).
- Sepsali jsme členy týmu a jejich schopnosti (Milan - návrh wireframe, HTML, CSS, JS, ...).
- Přiřadili členy týmu podle schopností k daným user stories.
- Analyzovali a seskupili jsme členy týmu, jež mají podobné schopnosti a jsou schopni dělat na stejných user stories.
V konečném důsledku nám krásně vyšlo logické rozdělení Back-end vs. Front-end, kdy Back-end členové týmu jsou schopni se starat o serverovou část projektů a Front-end o klientskou.
- Vytvořili jsme labely "back-end" a "front-end", které při Backlog groomingu přiřazujeme jednotlivým user stories.
- User stories, jež vyžadují spolupráci se vytvoří sub-tasky, které dostanou tyto labely.
- Při Planning meetingu si dáváme do sprintu User stories přibližně v poměru velocity Front-end a Back-end členů týmů.
Tým v konečném důsledku pracuje tak, že specialisté pracují na User stories, jež odpovídají jejich odbornosti a celková komunikace mezi členy týmu se zefektivnila. Je nutno přiznat, že jsme Scrum trošku poprznili, nicméně práce jde jako po drátkách a celkově se uvolnilo napětí.
Žádné komentáře :
Okomentovat