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. Nevidomé sledování předpisu povede 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 standupu nebo retrospektivním. 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 neměla být sledována slepě. 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 plánu sprintu. Sprinty se od té doby stávají prezenčních signálů organizace. Teď každý tým pochoduje k beatu stejného bicí.

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. Peter znamená, že expediční software vás naučí věci, které nemůžete a nebudou rozumět, pokud skutečně dodáváte svůj software.

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. Teams na konci cyklu nepřemýšlí nad nastavením nebo upgradem, dokud nebudou nuceni, a obvykle se vyhýbají lokalizaci a přístupnosti všude, kde 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. Pokud chcete vytvořit agilní jazykovou verzi, začněte tím, že se pokusíte produkt odeslat 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.

Společné vyhledá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ž se lidé nacházejí ve stejné místnosti a sedí ve stejné místnosti, správné konverzace se obvykle stávají. 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 rozbité, všechny chemické látky, které se vyvinuly, se přeruší. 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ávání 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 vyrovnávat zatížení práce s jiným týmem místo vyrovnávání zatížení mezi nimi. Přetažením člověka z jednoho týmu pomůžete jinému narušit oba týmy a může frustrovat přesun osoby, i když je dočasná. 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.

Práce na vyrovnávání zatížení místo lidí umožňuje týmu, který je již zaveden, krokovat a pomoct. Stává se konverzací o prioritách, ne o konverzaci 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 má možnost poskytovat a vlastnit ucelené prostředí.

Když vodorovné týmy vlastní vrstvy architektury, nezodpovědí za kompletní prostředí žádný tým. 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 posazované, protože týmy zjistí, že se nejedná o jejich chybu , a přiřaďte je jinému týmu.

Týmy funkcí tyto problémy nemají. Vlastnictví a odpovědnost jsou jasné. Některé týmy založené na architektuře můžou mít nějaké 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.