Přijetí agilní kultury

Pokud se z posledního desetiletí "agilních transformací" dozvíte jednu lekci, znamená to, že neexistuje žádné řešení pro přijetí nebo implementaci agilního přístupu. Každá organizace má různé potřeby, omezení a požadavky. Slepé následování předpisu nepovede k úspěchu.

Agilní pohyb spočívá v neustálém hledání způsobů, jak zlepšit praxi vytváření softwaru. Není to o dokonalém denním stand-upu nebo retrospektivě. Místo toho se jedná o vytvoření kultury, kde se správná věc děje častěji, než ne. Aktivity, jako jsou standupy a retrospektivní, mají své místo, ale nezmění kulturu organizace.

Tento článek podrobně popisuje základní prvky, které každá organizace potřebuje k vytvoření agilního myšlení a kultury. Doporučení by se neměla slepě řídit. Každá organizace by měla použít to, co dává smysl v daném prostředí.

Plánování a rytmus

Neexistuje žádná dokonalá délka sprintu. Týmy byly úspěšné s délkami sprintů, které jsou v rozsahu od jednoho do čtyř týdnů. Nejdůležitější je konzistence.

Vyberte délku sprintu, která bude fungovat pro kulturu, produkt a přání vaší organizace poskytovat aktualizace. Například divize Developer Tools v Microsoftu (zhruba 6 000 lidí) funguje ve třítýdenních sprintech. Vedoucí tým nevybral tuto délku sprintu; pochází z přímé zpětné vazby od technických týmů. Celá divize funguje na tomto třítýdenním cyklu sprintu. Sprinty se od té doby staly srdcem organizace. Všechny týmy teď pochodují podle stejného rytmu.

Je důležité vybrat délku sprintu a držet se s ní. Pokud existuje více agilních týmů, měli by všichni používat stejnou délku sprintu. Pokud zpětná vazba vede ke změně, buďte citliví. Bude jasné, kdy je správný termín zaveden.

Kultura dopravy

Peter Provost, hlavní manažer programu skupiny v Microsoftu, řekl: "Nemůžete podvádět dopravu." Jednoduchost a pravda tohoto prohlášení jsou základním kamenem agilní kultury. To, co tím Peter myslí, je, že nasazení vašeho softwaru vás naučí věci, kterým nemůžete a nepochopíte, pokud svůj software skutečně nasazujete.

Lidskou povahou je pozdržet nebo se vyhnout provádění věcí, dokud to nezbytně není nezbytné. To nemůže být pravda, pokud jde o vývoj softwaru. Týmy odsunují řešení chyb na konec cyklu, nepřemýšlí o nastavení nebo upgradu, dokud nejsou nuceny to udělat, a obvykle se vyhýbají lokalizaci a přístupnosti, kdekoli je to možné. Jakmile se tento model objeví, týmy vytvářejí technický dluh, který bude potřeba zaplatit později. Doprava požaduje zaplacení veškerého dluhu. Nemůžeš podvádět dopravu. Pro vytvoření agilní kultury začněte tím, že se pokusíte doručit produkt na konci každého sprintu. Zpočátku to nebude snadné, ale když se o to tým pokusí, rychle zjistí všechny věci, které by se měly dít, ale nejsou.

Zdravé týmy

Neexistuje žádný recept na perfektní agilní tým. Několik klíčových charakteristik ale výrazně usnadňuje dosažení úspěchu.

Spoluumístění týmů, kdykoli je to možné

Může tým najít úspěch s lidmi rozloženými do různých geografických oblastí? Ano, ale je to obtížnější. Když lidé sedí ve stejné místnosti, ty správné rozhovory se přirozeně odehrají. Stále je možné uspět s týmy umístěnými po celém světě a různými časovými pásmy. Ale neměl by stejný tým výhodu bez všech těchto překážek?

Udržujte týmy beze změny po přiměřenou dobu

Umožňuje týmům zvládnout umění vytváření softwaru společně. Když jsou týmy zamíchané, jakákoli dynamika, kterou vyvinuli, se narušuje. Někdy je vhodné změnit uspořádání, ale týmy jsou obvykle produktivnější, když mají čas naučit se spolupracovat. Jako vodítko se snažte udržet týmy nedotčené alespoň po dobu 12 měsíců.

Vyrovnávejte zatížení práce, ne lidí

Někdy týmy zapadají a potřebují pomoc. Běžnou taktikou, jak to vyřešit, je půjčovat člověka z jednoho týmu do druhého. To ale může být kontraproduktivní. Lepším řešením je rozdělit práci na jiný tým, namísto rozdělování lidí mezi nimi. Přesunutím člověka z jednoho týmu do druhého můžete narušit oba týmy, a může to frustrovat osobu, která je dočasně přemístěna. To vše má vliv na produktivitu týmu a pravděpodobnější než ne, negativně ovlivňuje schopnost vrátit se zpět podle plánu.

Rozložení zátěže místo osob umožňuje týmu, který je již etablován, aby vstoupil a pomohl. Stává se diskuzí o prioritách, ne o lidech.

Umožnit týmům vlastnit oblasti funkcí, ne vrstvy architektury

Snažte se vytvářet vertikální týmy, které vlastní oblasti funkcí. Tyto týmy zodpovídají za veškerou práci potřebnou k přidání funkcí do jejich oblasti– od změn databáze až po změny uživatelského rozhraní. Tým je zmocněn dodávat a vlastnit kompletní zážitek.

Když vodorovné týmy vlastní vrstvy architektury, žádný tým není zodpovědný za celkový zážitek. Přidání funkce vyžaduje ke koordinaci více týmů a vyžaduje vyšší úroveň správy závislostí. Řešení chyb vyžaduje, aby několik týmů prozkoumalo, jestli vlastní kód potřebný k opravě chyby. Chyby jsou předávány, když týmy zjistí, že se nejedná o jejich chybu, a přiřadí je jinému týmu.

Funkční týmy tyto problémy nemají. Vlastnictví a odpovědnost jsou jasné. Pro některé architektonické týmy může existovat místo. Vertikálně zaměřené týmy jsou ale efektivnější.

Další kroky

Když se týmy pustí do své vlastní agilní transformace, mějte na paměti tyto základní principy. Nezapomeňte, že neexistuje jediný recept, který bude fungovat pro každou organizaci. Agilní transformace představují cestu. Proveďte změny a seznamte se s nimi. V průběhu času bude organizace vyvíjet agilní kulturu, která potřebuje.

Microsoft je jednou z největších agilních společností na světě. Přečtěte si další informace o tom, jak Microsoft přijal agilní kulturu pro plánování DevOps.

Přečtěte si, jak Azure DevOps umožňuje týmům přijímat a škálovat agilní kulturu.