Partager via


Promouvoir une culture Agile au sein de votre équipe

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

À mesure que votre équipe grandit, vous souhaitez que vos outils évoluent avec elle. Et si vous êtes une entreprise qui adopte des méthodologies Agile, vous souhaitez que vos outils Agile prennent en charge les objectifs métier de votre entreprise.

Toutefois, pour réussir la mise à l’échelle d’Agile, vous devez traiter à la fois la culture et les outils au sein de votre organisation.

Remarque

Vous débutez avec Agile ? Pour plus d’informations, consultez Culture Agile et Mise à l’échelle d’Agile vers de grandes équipes.

Activer l’autonomie

Les organisations qui aspirent à être agiles doivent prendre en compte les obligations jumeau de la création d’un alignement au sein de l’entreprise et de la prise en charge de l’autonomie de l’équipe. Une équipe a besoin d’autonomie pour être efficace. Et les entreprises ont besoin d’un alignement entre les équipes et des organisations pour être efficaces.

Un alignement trop important avec des prospects d’autonomie d’équipe insuffisants ne prend pas en charge l’innovation ou l’agilité des équipes pour accomplir les choses. Un alignement trop faible avec chaque équipe exécutant son propre programme ne fournit pas les informations ni la coordination nécessaires pour atteindre les objectifs de l’entreprise.

Avec le bon niveau d’alignement sur l’organisation et l’autonomie de l’équipe, les individus sont en mesure d’innover et inspirés pour collaborer et atteindre les objectifs de l’entreprise.

Créer un alignement

Lorsque vous planifiez la façon dont vous souhaitez développer votre ensemble d’outils Agile, tenez compte des domaines suivants. Ces domaines sont essentiels pour créer un alignement d’entreprise tout en développant l’autonomie de l’équipe.

Zone

Créer un alignement

Prendre en charge l’autonomie

Vision du produit

L’organisation définit les objectifs et la feuille de route de l’organisation. Vous pouvez définir des objectifs comme des épopées et des fonctionnalités qui s’affichent dans le backlog du portefeuille.

Une équipe détermine la meilleure façon de respecter la feuille de route. L’équipe décompose les objectifs en récits utilisateur ou en éléments de backlog de produits à l’aide de leurs backlogs d’équipe.

Structure de l’équipe

En fonction des objectifs métier, les organisations déterminent le nombre et la taille des équipes. Les équipes de fonctionnalités structurées verticalement conduisent à une plus grande autonomie et efficacité.

Avec les équipes, il doit y avoir certains rôles établis, tels que le propriétaire du produit et les prospects de développement, mais aussi de la place pour faire pivoter les rôles. Par exemple, les membres de l’équipe peuvent se relayer en tant que Scrum Master, développer des démonstrations de sprint, exécuter des rétrospectives de sprint ou créer des e-mails de sprint.

Cadence de développement

Les organisations agiles doivent publier des mises à jour de produits et de fonctionnalités à intervalles réguliers. L’établissement de calendriers de sortie et de sprint réguliers favorise le rythme de l’entreprise.
Chaque sprint, une itération de temps encadrée d’une durée constante comprise entre deux et quatre semaines, inclut la planification, l’exécution, la prestation de valeur, la réflexion et l’engagement dans l’amélioration continue.

Toutes les équipes gèrent leur travail dans la cadence de sprint définie. L’équipe fournit des informations sur la longueur du sprint qui lui convient le mieux.
L’équipe choisit les méthodes Agile qui fonctionnent pour elle, Scrum, Kanban ou un mélange des deux. L’équipe prend également en charge le démarrage et l’action sur leur propre ensemble de pratiques d’amélioration continue.
Il est possible pour certaines équipes de s’exécuter dans des sprints plus courts. Par exemple, si une organisation définit une cadence de sprint de 2 semaines, certaines équipes peuvent choisir de fonctionner dans des sprints d’une semaine, tout en s’alignant sur le calendrier de l’organisation.

Cadence de communication

Tout comme les sprints apportent un rythme naturel au flux de travail, il en va de même pour les communications régulières. En définissant des attentes pour les types de communications qu’elles souhaitent voir rester alignées et la fréquence à laquelle elles se produisent, les organisations créent naturellement un alignement entre les équipes et l’entreprise.
Les e-mails de sprint d’équipe, les états de barre de bogues et les états de distribution de fonctionnalités d’équipe sont des exemples de ces communications régulières.

Une équipe détermine les détails qu’elle communique et qui développe la communication. Ses e-mails de sprint peuvent contenir un résumé des réalisations précédentes du sprint et des plans de sprint suivants ou inclure une démonstration des fonctionnalités récemment terminées.

Qualité

Chaque organisation doit définir les critères et les normes selon lesquels elles évaluent la qualité et définissent des attentes en matière de normes de qualité. Ils définissent les critères de manière à définir des critères de sortie pour le développement de nouvelles fonctionnalités, des normes pour gérer la dette technique et des limites de bogues pour les équipes ou les individus.
En outre, elles peuvent surveiller les états et les tendances des bogues en créant des tableaux de bord de bogues.

Une équipe choisit la façon dont elle répond aux normes de qualité. Elles peuvent mettre en place des bogues pour de nouvelles fonctionnalités ou à la fin de chaque sprint. Elle peut choisir quelqu’un pour protéger les bogues sur une base tournante.

Gérer les risques, suivre le travail

L’organisation détermine la façon dont chaque unité fonctionnelle communique l’état et les risques. Elles établissent un « contrat de communication » quant au minimum d’informations requises par l’organisation.
En outre, l’organisation fournit l’infrastructure pour réduire les risques. L’organisation doit aux équipes tout ce qu’elles peuvent faire pour réduire les risques communs entre les équipes.

Au-delà des besoins définis par l’organisation, les équipes déterminent tous les autres détails qu’elles doivent gérer et suivre pour réduire leurs risques. Qu’elles utilisent un tableau blanc avec des notes collées ou un diagramme de Gantt complet, elles gèrent les détails. Par exemple, les équipes peuvent ajouter un élément de backlog pour suivre une dépendance qu’elles ont sur une autre équipe. Elles peut également suivre ses risques en utilisant une liste de problèmes ou d’obstacles. En outre, les équipes contribuent régulièrement à l’amélioration du processus et de l’infrastructure pour soutenir la capacité des organisations à gérer les risques et à obtenir des insights.

Structurer les équipes

À mesure que vous effectuez une mise à l’échelle, l’une des tâches les plus importantes à prendre en compte est la façon dont vous structurez vos équipes. Traditionnellement, les structures d’équipe horizontales divisent les équipes en fonction de l’architecture logicielle : interface utilisateur, architecture orientée service et équipes de données.

Graphique montrant les équipes horizontales et verticales.

Toutefois, avec l’adoption des pratiques Agile, les structures d’équipe verticales qui couvrent l’architecture offrent une plus grande autonomie d’équipe. Les équipes verticales peuvent fournir les fonctionnalités qu’elles possèdent en travaillant sur l’architecture logicielle. Elles diffusent également les connaissances nécessaires pour travailler à tous les niveaux d’architecture au sein de toutes les équipes.

Configurez vos équipes le long des flux de valeur que votre organisation souhaite fournir. Par exemple, Fabrikam Fiber, organise ses équipes dans les sept équipes de fonctionnalités suivantes.

Graphique montrant sept équipes de fonctionnalités : Panier d’achat, Profil client, État du service, E-mail, Voix, Internet et TV

Chaque équipe planifie les fonctionnalités à fournir. Les équipes disposent de l’autonomie nécessaire pour déterminer la façon dont elles vont structurer les données, concevoir les services et concevoir les interfaces utilisateur web et mobiles. Elles planifient en respectant les normes de qualité définies par l’organisation et auxquelles toutes les équipes contribuent.

Configurer vos outils Agile pour la mise à l’échelle

À mesure que votre organisation grandit, vous pouvez mettre à l’échelle vos outils Agile comme suit.

  • Ajoutez des équipes et des affichages de backlog filtrés : vous ajoutez des équipes pour prendre en charge l’autonomie et leur fournir les outils qu’elles peuvent configurer et gérer et qui prennent en charge leur fonctionnement. Ces outils incluent les backlogs de produits, les tableaux de bord, les backlogs sprint, les tableaux de tâches et d’autres.

    En outre, vous pouvez configurer des équipes pour prendre en charge une hiérarchie de backlogs et des backlogs de portefeuille afin que les gestionnaires de portefeuilles puissent passer en revue les priorités et la progression au sein de plusieurs équipes.

  • Configurer les sprints et les versions : vous pouvez structurer vos itérations pour prendre en charge un ensemble plat de sprints ou un ensemble de sprints incorporés dans des versions planifiées. Chaque équipe active l’ensemble des sprints et des mises en production auxquels elle doit participer.

  • Gérer les portefeuilles : en configurant une hiérarchie d’équipes et de backlogs et en activant les backlogs du portefeuille. Les équipes de fonctionnalités qui se concentrent sur un sous-ensemble du backlog de produit peuvent rester concentrées uniquement sur leur backlog. Les gestionnaires de portefeuilles qui souhaitent afficher et organiser les backlogs pour suivre la progression et les dépendances peuvent gérer les backlogs du portefeuille de fonctionnalités et d’épopées.

    Si vous avez besoin d’autres backlogs du portefeuille (par exemple, scénarios ou initiatives), vous pouvez également les ajouter.

  • Configurez les tableaux de bord : avec les tableaux de bord d’équipe, vous pouvez configurer des graphiques qui suivent la progression au sein d’une équipe ou entre les équipes. Plus précisément, vous pouvez ajouter des graphiques d’états et de tendances en fonction des requêtes que vous créez.

  • Regrouper ou catégoriser le travail : il existe plusieurs façons de regrouper le travail que vous souhaitez suivre. Les backlogs filtrent les éléments de travail en fonction des affectations de zone d’équipe. De plus, les backlogs du portefeuille vous permettent de regrouper des éléments de backlog sous Fonctionnalités et Épopées.

    Si vous souhaitez suivre et créer des rapports sur des éléments de travail basés sur d’autres regroupements, vous pouvez le faire. Vous pouvez ajouter des balises aux éléments de travail, puis filtrer les backlogs ou les requêtes en fonction des balises. Vous pouvez également ajouter des chemins de sous-zone pour représenter des zones de fonctionnalités plus granulaires.

  • Ajoutez des dossiers et utilisez les favoris d’équipe : à mesure que vos équipes grandissent, vous voyez une liste croissante de requêtes d’éléments de travail, de définitions de build et de dossiers de code source. En utilisant des dossiers, des sous-dossiers et des favoris d’équipe, vous pouvez gérer un grand nombre de ces listes plus facilement. Vous pouvez ajouter des favoris d’équipe pour les requêtes partagées, le code source et les définitions de build.

Mettre à l’échelle avec des équipes et non des projets

Souvent, les organisations cherchent à ajouter un projet pour chaque projet de développement de logiciels.

Il est recommandé d’ajouter des équipes pour mettre à l’échelle vos outils plutôt que d’ajouter des projets pour les raisons suivantes :

  • Visibilité : il est plus facile d’afficher la progression dans toutes les équipes
  • Suivi et audit : il est plus facile de lier des éléments de travail aux autres objets à des fins de suivi et d’audit
  • Maintenabilité : vous réduisez la maintenance des groupes de sécurité et traitez les mises à jour.

Pour plus d’informations, consultez À propos des projets et de la mise à l’échelle de votre organization.

Avant de pouvoir créer ou utiliser l’un des outils Agile, vous avez besoin d’un projet. Si vous n’en avez pas encore, vous pouvez en créer un.

Si vous êtes prêt à passer d’une équipe à deux équipes ou à configurer plusieurs équipes, consultez Ajouter des équipes. Pour ajouter un administrateur d’équipe ou configurer des ressources d’équipe, consultez Gérer les équipes et configurer les outils d’équipe.

Pour plus d’informations, voir les articles suivants :

Ressources du secteur de la culture Agile