Baser les jalons sur une évaluation objective des systèmes de travail.

—Principe Lean-Agile #5

La System Demo est un événement important qui fournit une vue intégrée des nouvelles Features de la dernière itération proposée par toutes les équipes du train Agile Release Train (ART). Chaque démo donne aux parties prenantes de l’ART une mesure objective des progrès accomplis au cours d’un Programme Increment (PI). Une démonstration du système est un événement critique. Il s’agit de la méthode permettant de recueillir immédiatement les réactions des personnes qui effectuent le travail, ainsi que des Business Owners, des sponsors, des parties prenantes et des clients. La mesure réelle de la valeur, de la vitesse et du progrès est la démonstration du travail entièrement intégré de toutes les équipes lors de la précédente itération. Planifier et présenter une System Demo utile nécessite du travail et de la préparation de la part des équipes. Mais c’est le seul moyen d’obtenir rapidement le retour d’information nécessaire pour construire la bonne solution.

Détails

L’objectif de la démonstration du système est de tester et d’évaluer le système complet dans l’environnement de staging sur lequel l’ART travaille et d’obtenir les commentaires des principales parties prenantes. Ces parties prenantes comprennent des Business Owners, des sponsors exécutifs, d’autres équipes agiles, des responsables du développement, des clients (et leurs mandataires) qui fournissent des informations sur l’adéquation de la solution en développement. Le retour d’information est essentiel, car ils sont les seuls à pouvoir guider (voir la figure 1) le train doit rester sur sa trajectoire ou prendre des mesures correctives.

Figure 1. La System demo

La System Demo a lieu à la fin de chaque itération. Il fournit une vue intégrée et complète des nouvelles fonctionnalités fournies par toutes les équipes du train lors de la dernière itération. Il offre à l’ART une mesure factuelle des progrès actuels au niveau du système au sein du PI. C’est la seule mesure réelle de la vitesse de l’ART. Pour ce faire, vous devez mettre en œuvre les pratiques d’ingénierie évolutives nécessaires à la prise en charge de l’intégration et de la synchronisation dans ART. À la fin de chaque PI, l’ART tient une dernière démonstration du système PI. C’est une affaire quelque peu structurée et formelle, dans la mesure où elle présente une augmentation qui inclut toutes les fonctionnalités développées au cours de l’IP. Cette démonstration fait généralement partie de l’événement Inspect and Adapt (I&A), qui alimente les métriques rétrospectives et les progrès de du PI, y compris la «mesure de prévisibilité du programme» et les «métriques de performance du programme».

Remarque : l’environnement de staging est le mieux adapté à la démonstration système, car il reflète généralement autant que possible la production. Dans les grands trains de solutions, la démonstration du système est intégrée à la démonstration de solution.

Le timing de la System demo

La System Demo a lieu le plus près possible de la fin de l’itération, idéalement le lendemain. Il peut y avoir certaines complications, ce qui peut rendre ce moment impraticable. Ceux-ci inclus:

  • En règle générale, les résultats de l’intégration complète ne sont disponibles qu’à la fin de l’itération. (Bien entendu, l’objectif est de rechercher l’intégration continue sur toute la pile, mais ce n’est pas toujours faisable.)
  • De plus, chaque nouveau incrément peut nécessiter des extensions de l’environnement de démonstration, de nouvelles interfaces, des composants tiers, des outils de simulation, etc. Bien entendu, la System Team et les équipes agiles peuvent planifier cette opération, mais certains éléments de dernière minute sont inévitables.

Cependant, la System Demo doit avoir lieu dans les délais de l’itération suivante. Sinon, le retour d’information aux équipes sera retardé, ce qui mettra potentiellement le PI en danger. L’ART doit faire tous les investissements nécessaires pour permettre à la démonstration du système d’intervenir rapidement.

Équilibrer l’effort d’intégration et les commentaires

La démonstration du système a pour objectif de tirer parti des expériences de développement les plus récentes et d’ajuster le cours des actions. Toutefois, lorsque les préoccupations relatives à un logiciel ART, au matériel, aux systèmes mécaniques et aux composants fournis par le fournisseur s’étendent, l’intégration de tous les actifs toutes les deux semaines risque de surcharger les capacités et de générer un coût de transaction inacceptable. Simplement, l’intégration continue peut ne pas être économique ou pratique dans de tels environnements.

Cependant, l’intégration différée, voire aucune intégration, est bien pire. Il inhibe considérablement l’apprentissage et crée un faux sentiment de sécurité et de rapidité. Par conséquent, si cela n’est pas pratique, il est essentiel de trouver le bon équilibre et d’améliorer continuellement l’intégration et les tests automatisés afin de réduire le coût des intégrations futures. La figure 2 illustre une optimisation des coûts en «courbe en u» pour les efforts d’intégration.

Figure 2. Optimisation des coûts d’intégration de la courbe en u

Lorsque l’intégration complète à chaque itération est trop coûteuse, les équipes doivent prendre en compte:

  • Intégration d’un sous-ensemble de capacités, composants ou sous-systèmes
  • Intégration pour illustrer une fonctionnalité, une capacité ou une exigence non fonctionnelle (NFR) particulière
  • Intégration partielle à l’aide de prototypes et de maquettes
  • Intégration moins fréquente (par exemple, toutes les deux itérations) jusqu’à ce qu’il soit possible de le faire plus souvent

Il est également important de rappeler que l’intégration continue représente un défi naturel pour les groupes qui passent encore aux méthodes Lean et Agile. C’est normal et cela ne devrait pas être une excuse pour réduire la portée ou l’ampleur de l’intégration. La plupart des défis devraient disparaître à mesure que le train mûrit, mais seulement si les équipes démarrent immédiatement.

L’intégration continue validée par la démonstration du système contribue à la capacité de l’entreprise Lean à atteindre le délai de commercialisation plus rapidement grâce à un flux de valeur plus continu pour ses clients, comme indiqué dans les compétences DevOps et Release on Demand.

Processus et agenda

Avoir un agenda défini et une heure fixe permet de réduire les coûts de transaction de la démo système. Un exemple d’ordre du jour suit :

  • En bref, passez en revue le contexte commercial et les objectifs du PI (environ 5 à 10 minutes)
  • Décrivez brièvement chaque nouvelle fonctionnalité avant la démonstration (environ 5 minutes).
  • Démonstration de chaque nouvelle fonctionnalité dans un cas d’utilisation de bout en bout (environ 20 à 30 minutes, au total)
  • Identifier les risques et les obstacles actuels
  • Discussion ouverte de questions et de commentaires
  • Terminez en résumant les progrès, les commentaires et les mesures à prendre.

Participants

Les participants incluent généralement :

  • Product Managers et Product Owners, généralement responsables de la démonstration
  • Un ou plusieurs membres de l’équipe système, souvent chargés de la configuration de la démonstration dans l’environnement de transfert
  • Business Owners, sponsors exécutifs, clients et mandataires de clients
  • System Architect/Engineering, opérations informatiques et autres participants au développement

Vous trouverez ci-dessous quelques conseils pour une démonstration réussie du système:

  • Timebox la démo à une heure. Une courte période est essentielle pour maintenir l’implication continue et bihebdomadaire des principales parties prenantes. Il illustre également le professionnalisme des équipes et la préparation du système.
  • Partagez les responsabilités de démonstration entre les teams lead et les Product Owners dotés de nouvelles fonctionnalités
  • Démo utilisant l’environnement de staging
  • Minimiser l’utilisation des diapositives; à la place, ne démontrez que des solutions fonctionnelles et testées
  • Discuter de l’impact de la solution actuelle sur les NFR
  • Concentrez-vous sur la manière dont le système a évolué par rapport aux contributions d’équipe par équipe

Apprendre encore plus

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
[2] Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007.

© Scaled Agile, Inc.

Source de l'article