Propagace agilní kultury v rámci týmu

  • Článek

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019

S tím, jak váš tým roste, chcete, aby se s ním vaše nástroje rozrůstaly. A pokud podnik používáte agilní metodologie, chcete, aby vaše agilní nástroje podporovaly obchodní cíle vašeho podniku.

Úspěšné škálování agilního nasazení však vyžaduje řešení kultury i nástrojů ve vaší organizaci.

Poznámka:

Začínáte s Agilní? Další informace najdete v tématu Agile Culture and Scaling Agile to Large Teams.

Povolit autonomii

Organizace, které se snaží být agilní, musí zvážit povinnosti dvojčat při vytváření sladění v rámci podniku a podpory týmové autonomie. Tým potřebuje autonomii, aby byl efektivní. Podniky potřebují sladění mezi týmy a organizací, aby byly efektivní.

Příliš mnoho sladění s nedostatečnými vedoucími týmovou autonomií nepodporuje inovace ani flexibilitu týmů, aby se věci udělaly. Příliš málo sladění s každým týmem, který provozuje vlastní program, neposkytuje přehled a koordinaci vyžadovanou ke splnění obchodních cílů.

Díky správné úrovni sladění napříč organizací a týmovou autonomí se jednotlivci můžou inovovat a inspirovat ke spolupráci na splnění obchodních cílů.

Vytvoření zarovnání

Při plánování růstu sady agilních nástrojů zvažte následující oblasti. Tyto oblasti jsou klíčem k vytvoření podnikového sladění při vývoji týmové autonomie.

Plocha

Vytvoření zarovnání

Podpora autonomie

Zpracování obrazu produktu

Organizace definuje cíle a plán pro organizaci. Cíle můžete definovat jako náměty a funkce, které se zobrazují v backlogu portfolia.

Tým určuje, jak nejlépe splnit plán. Tým rozdělí cíle do uživatelských scénářů nebo položek backlogu produktů pomocí týmových backlogů.

Struktura týmu

Na základě obchodních cílů určují organizace počet a velikost týmů. Vertikálně strukturované týmy funkcí vedou k větší autonomii a efektivitě.

U týmů by měly existovat některé zavedené role, jako je vlastník produktu a vedoucí vývoje, ale také prostor pro otáčení rolí. Členové týmu se například můžou střídat jako Scrum Master, vyvíjet ukázky sprintů, spouštět retrospektivní sprinty nebo vytvářet e-maily sprintů.

Tempo vývoje

Agilní organizace potřebují pravidelně vydávat produkty a aktualizace funkcí. Vytvoření pravidelného plánu vydávání verzí a sprintů podporuje rytmus podnikání.
Každý sprint – časová iterace konstantní doby trvání mezi dvěma a čtyřmi týdny – zahrnuje plánování, provádění, poskytování hodnoty, odrazení a zapojení do průběžného vylepšování.

Všechny týmy spravují svou práci v nastaveném tempu sprintu. Tým poskytuje vstup do délky sprintu, která je pro ně nejvhodnější.
Tým zvolí agilní metody, které pro ně fungují, Scrum, Kanban nebo kombinaci obou. Tým také přebírá vlastnictví zahájení a jednání na vlastní sadě postupů průběžného zlepšování.
Některé týmy můžou spouštět v kratších sprintech. Pokud například organizace nastaví 2týdenní tempo sprintů, můžou se některé týmy rozhodnout, že budou fungovat v 1týdenních sprintech, a přitom budou stále v souladu s plánem organizace.

Četnost komunikace

Stejně jako sprinty přinášejí do toku práce přirozený rytmus, takže také pravidelná komunikace. Nastavením očekávání pro typy komunikace, které chtějí vidět, aby zůstali v souladu a jak často k nim dochází, organizace přirozeně vytvářejí sladění napříč týmy a podniky.
Příkladem takové pravidelné komunikace jsou e-maily týmových sprintů, stav panelu chyb a stav doručování funkcí týmu pro vydání.

Tým určuje podrobnosti, které komunikují a kdo vyvíjí komunikaci. E-maily sprintů můžou obsahovat souhrn předchozích úspěchů sprintu a další plány sprintů nebo ukázku nedávno dokončených funkcí.

Kvalita

Každá organizace musí nastavit kritéria a standardy, podle kterých vyhodnocují kvalitu a stanoví očekávání pro standardy kvality. Několik způsobů, jak definují kritéria, je nastavit výstupní kritéria pro nový vývoj funkcí, standardy pro správu technického dluhu a stropy chyb pro týmy nebo jednotlivce.
Můžou také monitorovat stav chyb a trendy vytvořením řídicích panelů chyb.

Tým si zvolí, jak splňují standardy kvality. Mohou připravit chyby pro nové funkce nebo na konci každého sprintu. Můžou zvolit jednotlivce, který bude fungovat jako štít chyby na obměně.

Řízení rizik, sledování práce

Organizace určuje, jak jednotlivé funkční jednotky komunikují o stavu a riziku. Stanoví "smlouvu o komunikaci" s minimálními požadovanými informacemi, které organizace potřebuje.
Organizace také poskytuje infrastrukturu, která snižuje rizika. Organizace dluží týmům cokoliv, co můžou udělat, aby snížila rizika, která jsou v různých týmech běžná.

Kromě splnění potřeb nastavených organizací týmy určí všechny další podrobnosti, které potřebují ke správě a sledování, aby snížily rizika. Ať už používají tabuli s rychlými poznámkami nebo úplnýM Ganttovým diagramem, spravují podrobnosti. Týmy můžou například přidat položku backlogu ke sledování závislosti, kterou mají v jiném týmu. Nebo mohou sledovat rizika prostřednictvím seznamu problémů nebo překážek. Týmy také pravidelně přispívají ke zlepšení procesu a infrastruktury, aby podporovaly schopnost organizace řídit rizika a získávat přehledy.

Strukturování týmů

Při škálování je jedním zch Horizontální týmové struktury tradičně rozdělují týmy podle architektury softwaru: uživatelské rozhraní, architektura orientované na služby a datové týmy.

Graf znázorňující vodorovné a svislé týmy

S přijetím agilních postupů však vertikální týmové struktury, které zahrnují architekturu, poskytují větší týmovou autonomii. Vertikální týmy můžou poskytovat funkce, které vlastní, díky práci v architektuře softwaru. Také šíří znalosti potřebné k práci na všech úrovních architektury ve všech týmech.

Nakonfigurujte týmy podél hodnotových toků, které chce vaše organizace poskytovat. Společnost Fabrikam Fiber například uspořádá své týmy do následujících sedmi funkčních týmů.

Chart showing seven feature teams: Shopping cart, Customer profile, Service status, Email, Voice, Internet, and TV

Každý tým plánuje funkce, které mají být k dispozici. Mají autonomii, aby určili, jak strukturovat data, navrhovat služby a navrhovat webová a mobilní uživatelská rozhraní. Plánují dodržování standardů kvality, které organizace stanoví a ke kterým přispívají všechny týmy.

Konfigurace agilních nástrojů pro škálování

S tím, jak vaše organizace roste, můžete škálovat agilní nástroje následujícími způsoby.

  • Přidání týmů a filtrovaných zobrazení backlogu: Přidáte týmy pro podporu samostatnosti týmu a poskytnete jim nástroje, které můžou nakonfigurovat a spravovat, které podporují způsob práce. Mezi tyto nástroje patří backlogy produktů, panely Kanbanu, backlogy sprintů, taskboardy a další.

    Týmy můžete také nakonfigurovat tak, aby podporovaly hierarchii backlogů a backlogů portfolia, aby správci portfolia mohli zkontrolovat prioritu a průběh napříč několika týmy.

  • Nastavení sprintů a verzí: Iterace můžete strukturovat tak, aby podporovaly plochou sadu sprintů nebo sadu sprintů vložených v rámci plánovaných verzí. Každý tým aktivuje sadu sprintů a vydaných verzí, ke kterým se musí zapojit.

  • Správa portfolií: nastavením hierarchie týmů a backlogů a aktivací backlogů portfolia Týmy funkcí zaměřené na podmnožinu backlogu produktu můžou zůstat zaměřeny jenom na backlog. Správci portfolia, kteří chtějí zobrazit a uspořádat backlogy ke sledování průběhu a závislostí, můžou spravovat backlogy portfolia funkcí a námětů.

    Pokud potřebujete další backlogy portfolia, například Scénáře nebo iniciativy, můžete je také přidat.

  • Konfigurace řídicích panelů: Pomocí týmových řídicích panelů můžete nakonfigurovat grafy, které sledují průběh v rámci týmu nebo napříč týmy. Konkrétně můžete přidat grafy stavu a trendu na základě dotazů, které vytvoříte.

  • Seskupování nebo kategorizace práce: Existuje několik způsobů, jak seskupit práci, kterou chcete sledovat. Backlogy filtrují pracovní položky na základě přiřazení týmových oblastí. A backlogy portfolia umožňují seskupit položky backlogu v části Funkce a Náměty.

    Pokud chcete sledovat a vykazovat pracovní položky na základě jiných seskupení, můžete. Značky můžete přidat do pracovních položek a pak filtrovat backlogy nebo dotazy na základě značek. Můžete také přidat cesty podoblasti, které představují podrobnější oblasti funkcí.

  • Přidejte složky a používejte oblíbené položky týmu: S růstem týmů uvidíte rostoucí seznam dotazů na pracovní položky, definic sestavení a složek zdrojového kódu. Pomocí složek, podsložek a oblíbených položek týmu můžete snadněji spravovat mnoho z těchto seznamů. Můžete přidat oblíbené položky týmu pro sdílené dotazy, zdrojový kód a definice sestavení.

Škálování s týmy a ne projekty

Organizace se často dívají na přidání projektu pro každý projekt vývoje softwaru.

Doporučujeme přidávat týmy pro škálování nástrojů místo přidávání projektů z následujících důvodů:

  • Viditelnost: Lepší zobrazení průběhu napříč všemi týmy
  • Sledování a auditování: Pro účely sledování a auditování je jednodušší propojit pracovní položky s jinými objekty .
  • Udržovatelnost: Minimalizujete údržbu skupin zabezpečení a aktualizací procesů.

Další informace najdete v tématu O projektech a škálování organizace.

Než budete moct vytvářet nebo pracovat s libovolnými agilními nástroji, potřebujete projekt. Pokud ho ještě nemáte, můžete si ho vytvořit.

Pokud jste připraveni přejít z jednoho týmu na dva týmy nebo nakonfigurovat několik týmů, přečtěte si téma Přidání týmů. Pokud chcete přidat správce týmu nebo nakonfigurovat týmové prostředky, přečtěte si téma Správa týmů a konfigurace týmových nástrojů.

Další informace naleznete v těchto článcích:

Agilní oborové zdroje