Objectifs du PI (SAFe)

De Wiki Agile

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.

 
Figure 1. Les 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.

 
Figure 2. Des features aux objectifs ; certaines features apparaîtront dans les objectifs du PI de plusieurs équipes.

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é.

Dans ce cas, il est prudent de fixer quelques objectifs non engagés (pas plus de 2 ou 3). Cependant, les équipes font de leur mieux pour réaliser les objectifs non engagés, et ils sont inclus dans la capacité et le plan du PI. Cependant, comme ces objectifs peuvent ne pas être terminés dans le PI, les parties prenantes planifient en conséquence.

Les objectifs non engagés présentent plusieurs avantages :

  • Amélioration des facteurs économiques - Sans objectifs non engagés, une équipe s'engage à réaliser un projet à 100 % dans un délai fixe. Cela oblige les équipes à faire des compromis sur la qualité ou à intégrer d'autres buffers dans le système. Les autres buffers peuvent s'accumuler et convertir "une anticipation incertaine en un retard certain", ce qui réduit le débit global.
  • Une fiabilité accrue - Les objectifs non engagés représentent un périmètre variable, ce qui permet d'avoir confiance dans la réalisation des principales priorités. À son tour, le respect des engagements déclarés est le facteur le plus important pour établir la confiance entre les équipes et les parties prenantes.
  • Adaptabilité au changement - Pour assurer la fiabilité d'une cadence, les objectifs non engagés fournissent la marge de capacité nécessaire pour respecter les engagements, tout en modifiant les priorités si nécessaire, lorsque les données factuelles changent.

Ecrire des objectifs de PI SMART

Les objectifs du PI de l'équipe sont un résumé du plan de l'équipe pour le PI. Ils sont d'une importance capitale. Parfois, les descriptions peuvent être très techniques et/ou un peu vagues. En guise de contre-mesure, les équipes font en sorte que leurs objectifs soient SMART :

  • Spécifique - Énoncer le résultat attendu de manière aussi concise et explicite que possible. (Conseil : essayez de commencer par un verbe d'action).
  • Mesurable - Ce que l'équipe doit faire pour atteindre l'objectif doit être clair. Les mesures peuvent être de descriptives, oui/non, quantitative ou indiquer un intervalle.
  • Atteignable - L'équipe doit pouvoir contrôler et influencer la réalisation de l'objectif.
  • Réaliste - Admettre les facteurs qui ne peuvent être contrôlés. (Conseil : évitez de faire des hypothèses de type "route de la joie").
  • Délimité dans le temps - La période de réalisation doit être comprise dans le PI, et tous les objectifs doivent donc être dimensionnés de manière appropriée.

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.