Objectifs du PI (SAFe)
Auteur : © 2010-2022 Scaled Agile, Inc.
Source : PI Objectives
Date : 04/10/2022 (dernière mise à jour)
Traducteur : Fabrice Aimetti
Date : 13/11/2022
Traduction :
Prendre et respecter de petits engagements permet de renforcer la confiance.
- Nonaka et Takeuchi, The Knowledge-Creating Company.
Objectifs du PI
Les objectifs de l'incrément programme (PI) sont un résumé des objectifs métiers et techniques qu'une équipe ou un train Agile a l'intention d'atteindre dans l'Incrément programme (PI) à venir.
Au cours de la Planification du PI, les équipes créent des objectifs de PI, qui sont les éléments qu'elles ont l'intention d'accomplir dans le prochain incrément programme (PI). Ces objectifs présentent plusieurs avantages :
- Ils fournissent un langage commun pour communiquer avec les parties prenantes métiers et technologiques.
- Ils créent une vision et un objectif à court terme.
- Ils permettent à l'ART d'évaluer sa performance et la valeur métier atteinte via la Mesure de Prédictibilité du Programme.
- Ils communiquent et soulignent la contribution de chaque équipe à la valeur de l'entreprise.
- Ils exposent les dépendances qui nécessitent une coordination.
Description détaillée
SAFe s'appuie sur une vague continue d'engagements à court terme de la part des équipes et des trains Agile pour contribuer à la planification et aux résultats de l'entreprise, ce qui permet d'améliorer l'alignement et la confiance entre les parties prenantes du développement et de l'entreprise. Ceux-ci sont communiqués par le biais des objectifs du PI.
Bien que, par nature, le développement soit incertain, l'entreprise dépend des équipes pour obtenir des prévisions fiables et prévisibles. Trop peu, et l'entreprise ne peut pas planifier. Trop, et l'entreprise s'engage dans des plans à plus long terme, qui sont au mieux incertains, et limitent également l'agilité. Les parties prenantes métier et technologiques ont besoin de trouver un juste milieu, et c'est l'un des principaux objectifs du PI. Outre l'alignement, le processus de définition d'objectifs réalistes permet également d'éviter un excès de travail en cours (WIP) dans le système. Les objectifs du PI sont construits en grande partie de manière ascendante, à mesure que les équipes les identifient pendant la planification du PI.
Construire les objectifs du PI de l'équipe
Au cours de la planification du PI, les équipes se voient présenter de nouvelles Features et planifient les Stories dont elles ont besoin pour les réaliser, en plus des Stories qui représentent le travail dans leur contexte local. Ce travail est décrit comme un ensemble d'objectifs du PI spécifiques à l'équipe. Pour ce faire, il faut estimer et planifier, connaître la capacité de l'équipe, analyser les features à venir, définir des stories pour le Backlog de l'Équipe et, enfin, résumer les informations en termes commerciaux simples et compréhensibles par tous.
Quant au nombre d'objectifs qu'une équipe doit fixer, il n'y a pas de règle fixe, mais 7 à 10 objectifs engagés (plus 2 à 3 non engagés ; voir ci-dessous) semblent donner les meilleurs résultats. Plus, et les détails et la spécificité sont difficiles à comprendre et à traiter par les autres équipes et les partenaires métiers de l'équipe. Plus, il y en a trop à examiner et à traiter dans un ART de taille moyenne à grande. Moins, et le niveau d'abstraction ou d'agrégation est probablement trop élevé pour être mesuré objectivement à la fin du PI.
La figure 1 présente un exemple des objectifs du PI d'une équipe.
Différencier les Features et les objectifs du PI
Les objectifs du PI de l'équipe sont souvent directement liés aux features prévues ; en fait, ils sont souvent identiques. Toutefois, la relation n'est pas toujours directe, car certaines features nécessitent la collaboration de plusieurs équipes, comme l'illustre la figure 2.
Notez que certaines features (comme la feature A) peuvent être réalisées par une seule équipe ; d'autres (la feature B) nécessitent la collaboration de plusieurs équipes. En plus des features et des contributions aux features, d'autres objectifs d'équipe apparaîtront également. Il peut s'agir d'objectifs techniques (par exemple, la preuve de concept de la figure 1) qui permettent la réalisation de features futures, d'améliorations de l'infrastructure de développement, de jalons et autres. Tous les résultats du processus de planification sont repris dans les objectifs de l'équipe.
Les features et les critères d'acceptation sont d'excellents outils pour aider à comprendre, appréhender et collaborer autour du travail à effectuer, mais il est trop simple de se laisser entraîner à "finir les features" et de manquer les objectifs globaux qui s'y cachent. Les objectifs du PI permettent de ne plus se concentrer sur le développement des features mais sur l'obtention des résultats métiers souhaités.
Une meilleure compréhension de l'intention offerte par des conversations directes avec les Business Owners amène souvent les équipes à offrir de nouvelles perspectives aux Architectes/Ingénieurs Système et au Product Management et à trouver rapidement des moyens de mettre en œuvre leur expertise pour créer de meilleures solutions.
(Note : l'article sur le thème approfondi Rôle des objectifs du PI explique plus en détail les différences entre les objectifs et les features du PI de l'équipe et fournit des informations supplémentaires sur leur utilisation et leur valeur).
Objectifs engagés et non engagés
S'engager à réaliser une série d'objectifs à court terme contribue à renforcer la confiance. La confiance permet à toutes les parties prenantes d'avancer avec assurance et de fonder leurs décisions et leurs plans sur ce qui est "très probablement vraisemblable dans un futur proche". Mais il est difficile de planifier avec confiance face à l'incertitude inhérente à la recherche et au développement. Les choses ne se passent pas toujours comme prévu, et il est donc prudent de prévoir une petite marge de sécurité dans le système. Si le buffer est trop important, on risque d'accomplir moins de choses que ce qu'on aurait pu faire autrement. Si le buffer est trop petit, de nombreux engagements peuvent s'avérer irréalisables et la planification et la confiance risquent de s'éroder. Pour remédier à cela, SAFe recommande aux équipes d'utiliser des objectifs engagés et non engagés pendant la planification. Les objectifs non engagés permettent d'améliorer la prédictibilité de la livraison de la valeur métier puisqu'ils ne sont pas inclus dans l'engagement de l'équipe ou ne sont pas comptabilisés contre les équipes dans la mesure de la prédictibilité du programme.
Les objectifs non engagés sont utilisés pour identifier les travaux qui peuvent être soumis à des changements dans le cadre du PI. Le travail est planifié, mais le résultat n'est tout simplement pas certain. Les équipes peuvent appliquer des objectifs non engagés chaque fois que la confiance dans la réalisation de l'objectif est faible. Cela peut être dû à de nombreuses circonstances :
- Les dépendances avec une autre équipe ou un autre fournisseur ne peuvent être garanties.
- L'équipe a peu ou pas d'expérience avec ce type de fonctionnalité. Dans ce cas, les équipes peuvent planifier des "Spikes" au début du PI pour réduire l'incertitude.
- Il y a un grand nombre d'objectifs assez critiques dont l'entreprise dépend et l'équipe est déjà chargée à presque pleine capacité.
En savoir plus
[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
[2] Reinertsen, Donald. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.