« Objectifs du PI (SAFe) » : différence entre les versions
De Wiki Agile
| (9 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 75 : | Ligne 75 : | ||
* '''Atteignable''' - L'équipe doit pouvoir contrôler et influencer la réalisation de l'objectif. | * '''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"). | * '''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 | * '''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. | ||
===Communiquer la valeur métier avec les objectifs du PI=== | |||
Lorsque les objectifs sont finalisés au cours de la planification du PI, les Business Owners attribuent ensemble une "valeur métier" à chacun des objectifs de l'équipe lors d'une conversation en face à face. La valeur de cette conversation particulière avec l'équipe ne peut pas être sous-estimée, car elle communique la stratégie et le contexte derrière ces décisions de pondération. Les Business Owners utilisent une échelle de 1 (le plus bas) à 10 (le plus haut) pour évaluer chaque objectif. Ils n'ont pas besoin d'être "normalisés" entre les équipes ; chaque équipe a certains éléments hautement prioritaires (notés 10). | |||
La valeur métier est attribuée, et non calculée, et sert à alimenter les réflexions sur la réalisation. De nombreux objectifs de l'équipe apportent une valeur directe et immédiate à la solution. D'autres, tels que les [https://www.scaledagileframework.com/enablers/ Enablers] (par exemple, les améliorations de l'infrastructure, les environnements de développement et les initiatives de qualité) permettent de créer plus rapidement une valeur métier future. Tous ces facteurs doivent être pris en compte dans la pondération finale. | |||
===Finaliser les objectifs du PI de l'équipe=== | |||
Lorsque les objectifs ont été rendus plus "SMART", que les objectifs non engagés ont été identifiés et que la valeur métier a été établie, les objectifs de la figure 1 peuvent évoluer pour ressembler à ceux de la figure 3. | |||
[[Fichier:PI-Objectives F03 WEB-new-1.png|border|link=|400px|center]] | |||
<div style="text-align: center;">'''Figure 3. Objectifs finaux du PI de l'équipe avec un objectif non engagé et une valeur métier attribuée.'''</div> | |||
===Engagement sur les objectifs du PI=== | |||
Un vote de confiance est organisé peu avant la fin de la planification du PI, lorsque les équipes s'engagent à atteindre les objectifs du PI. (Les objectifs non engagés ne sont pas inclus dans cet engagement.) Toutefois, il doit s'agir d'une demande raisonnable pour les personnes qui effectuent le travail. Par conséquent, l'engagement SAFe comporte deux parties : | |||
* Les équipes acceptent de faire tout ce qui est raisonnablement en leur pouvoir pour atteindre les objectifs engagés. | |||
* Au cours du PI, si l'on découvre que certains objectifs ne sont pas réalisables, les équipes acceptent de remonter immédiatement le problème afin que les parties prenantes soient informées et que des mesures correctives puissent être prises. | |||
De cette façon, toutes les parties prenantes savent que soit les résultats du programme seront atteints comme prévu, soit elles seront prévenues suffisamment à l'avance pour pouvoir atténuer les problèmes et prendre des mesures correctives, ce qui minimisera les perturbations du métier. C'est à peu près tout ce qu'il est possible de faire, car il s'agit, après tout, de recherche et de développement. | |||
===Création des objectifs de PI du programme et de la solution=== | |||
Le résultat du processus de planification du PI sera un ensemble de fiches d'objectifs PI approuvées par les équipes, une par équipe. Les équipes votent sur le niveau de confiance des objectifs pris dans leur ensemble, et si la confiance est suffisamment élevée, l'ensemble des objectifs devient le plan ART engagé. Le [https://www.scaledagileframework.com/release-train-engineer/ Release Train Engineer] récapitule les objectifs des équipes dans les objectifs du PI du programme dans un format adapté à la communication avec le management. | |||
Les objectifs résumés doivent être SMART, tout comme les objectifs du PI des équipes, et comporter des objectifs non engagés. De même, comme les objectifs du PI des équipes, les objectifs du PI du programme peuvent décrire les features de l'entreprise sur lesquelles travaille l'ART, les enablers ou d'autres objectifs métiers ou techniques. | |||
Si l'ART fait partie d'un [https://www.scaledagileframework.com/solution-train/ Solution Train], lors de l'événement [https://www.scaledagileframework.com/pre-and-post-pi-planning/ Post-PI Planning], après que tous les ARTs ont été planifiés, les objectifs sont remontés par le [https://www.scaledagileframework.com/solution-train-engineer/ Solution Train Engineer], et les objectifs de PI de la Solution sont récapitulés. Il s'agit du niveau le plus élevé des objectifs du PI dans SAFe, et ils communiquent aux parties prenantes ce que le Solution Train va fournir dans le PI à venir. La figure 4 ci-dessous illustre ce résumé des objectifs du PI des équipes au programme et du programme à la solution. | |||
Il est important que la valeur métier soit uniquement attribuée aux objectifs du PI des équipes. La métrique de prédictibilité elle-même est remontée pour déterminer la prédictibilité à un niveau supérieur. | |||
[[Fichier:PI-Objectives F01 web.png|border|link=|center]] | |||
<div style="text-align: center;">'''Figure 4. Remontée des objectifs de PI des équipes, du programme et de la solution.'''</div> | |||
===Réduire le WIP avec des objectifs de PI réalistes=== | |||
Lors de la revue des objectifs du PI des équipes, il est apparu que tout ce qui a été envisagé par les différentes parties prenantes ne sera probablement pas réalisé dans les délais du PI. Par conséquent, une partie du travail prévu devra être réévaluée avec les Business Owners pour obtenir un accord sur les objectifs du PI. | |||
Ces éléments de travail moins prioritaires sont replacés dans le [https://www.scaledagileframework.com/program-and-solution-backlogs/ Backlog du Programme]. La réduction de l'excès de WIP permet de réduire les coûts indirects et la surcharge de travail, et d'augmenter la productivité et la vélocité. Le résultat net est un ensemble d'objectifs de PI réalisables, acceptés par toutes les parties prenantes et tous les membres de l'équipe, ainsi qu'une efficacité accrue et une probabilité plus élevée de réussite de la mise en œuvre. | |||
La planification au niveau de la solution globale peut être très similaire ; les planifications des ARTs se répercutent les unes sur les autres, repoussant certains travaux dans le [https://www.scaledagileframework.com/program-and-solution-backlogs/ Solution Backlog] pour une réévaluation dans un PI ultérieur. | |||
==En savoir plus== | ==En savoir plus== | ||
[1] Leffingwell, Dean. ''Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise.'' Addison-Wesley, 2011.<br/> | [1] Leffingwell, Dean. ''Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise.'' Addison-Wesley, 2011.<br/> | ||
[2] Reinertsen, Donald. ''The Principles of Product Development Flow: Second Generation Lean Product Development.'' Celeritas Publishing, 2009. | [2] Reinertsen, Donald. ''The Principles of Product Development Flow: Second Generation Lean Product Development.'' Celeritas Publishing, 2009. | ||
