Product Delivery Management

Nous Contacter

Aperçu

Cycle de Sprint

Sprint Implementation Kanban

Sprint Execution 

  1. Les développeurs font un « Checkout » du code du Repository partagé, dans leur environnement local, effectuent les changements, les revues de codes et tests (automatisation recommandée  pour les revues codes & tests unitaires!)
  2. Lorsque le code est suffisamment stable (revues & tests passent), ils font un « Commit » du code dans le Repository partagé (au moins une fois par jour!)
  3. Suite au Commit, le Build (compilation/compression)  et  les Tests sont effectués
  4. Si tous les tests passent, cette  dernière version du code est déployée dans l’environnement d’intégration « INT » pour les tests manuels .
  5. Si les tests manuels passent (confirmation testeur), alors cette version est promue dans l’environnement « UAT » et ensuite « STG » selon le même principe
  6. Finalement,  si toute s les étapes précédentes se passent bien,  et sur autorisation du Support, cette version est déployée en production « PROD »

Un rapport  détaillé est communiqué aux parties prenantes à chaque étape!  Pour  être effective les opérations CI  et DI doivent être le plus possible automatisées

Qu’est ce que la Definition of Done?

Smart Project distingue deux types de DoD (Definition of Done)

  • DoD Parfait – ensemble des activités qu’une organisation doit mener pour livrer le produit aux utilisateurs finaux. Cela représente l’ensemble des critères que doivent satisfaire un Consumable Product Release. Définit avant le début du premier Sprint
  • DoD Sprint – un sous-ensemble du DoD Parfait. Cela représente l’ensemble des critères consensuels que chaque article d’une Release doit satisfaire dans le contexte d’un Sprint. L’objectif ultime de l’équipe étant de s’améliorer au fil des Sprints afin d’atteindre le DoD parfait. Ne surtout pas confondre avec les critères d’acceptation qui sont les conditions spécifiques que doivent remplir un article avant d’être accepté.
  • Définir les activités nécessaires pour produire et livrer le Consumable Product Release aux utilisateurs finaux (DoD Parait)
  • Bien challenger les activités liées aux artefacts intermédiaires. Il faut se demander pourquoi ils sont nécessaires? Exemple document stratégie de test
  • Décider en fonction du contexte, quelles sont les activités qui pourront être réalisées dans chaque Sprint (DoD Sprint)
  • Code terminé et ‘commité’ dans repository commun
  • Revue de code mené avec succès
  • Tests Unitaire mené avec succès
  • Critères d’acceptation démontrés/confirmés par PO
  • Packaging ok
  • Déploiement et Tests (INT): ok
  • Déploiement & Test (UAT et STAGING): ok
  • Infrastructure / Plateforme à jour
  • Documentation Techniques à jour
  • Manuel Support à jour
  • Manuel Utilisateur à jour

Sprint Planning 

  • Rituel pour préparer le Sprint. Il est constitué de deux sessions successives
    • Le Sprint Planning Definition est une session conjointe réunissant toutes les équipes du Product Delivery Team. Cette session permet de définir le «Quoi» (objectif et liste des articles souhaités par le CPO) du sprint. Lorsque le nombre d’équipes Delivery dépassent 2 alors chaque équipe désigne des représentants pour participer à cette session.
    • Sprint Planning Elaboration est une session séparée que tient chaque équipe du Product Delivery Team juste après le Sprint Planning Definition. Cette session permet à l’équipe de répondre au «Comment» (conception initiale et liste de tâches par article)
  • Préparation du Sprint Planning
    • Etablir la capacité de l’équipe DEV (en tenant compte vacances, congés, etc.)
    • Définir le FocusFactor –  en tenant compte du sprint précédent ou l’ensemble des sprint déjà réalisés ou en prenant comme référence des projets semblables
    • Vélocité  =  Capacité * FocusFactor
    • Définir le but du sprint prochain
    • Définir le Sprint Backlog Initial – liste des articles que le PO souhaite voir réaliser dans le prochain Sprint
    • S’assurer  le plus possible que les articles du Sprint Backlog Initial sont INVEST avec une estimation initiale en StoryPoint
  • Déroulement Sprint Planning – Définition
    • S’entendre sur le but du Sprint et réviser le DoD
    • Le   CPO ou le PO explique  et clarifie chaque article du  Sprint Backlog  Initial dans l’ordre des priorités.
    • Les Développeurs posent des questions  et ré-estiment les articles si nécessaire (planning poker)
    • Dans le cas  de plusieurs équipes Delivery, chaque article est assigné à une équipe par les développeurs
    • Identifier les articles qui nécessitent une coordination entre plusieurs équipes
    • Sélectionner légèrement plus d’articles que la vélocité de l’équipe (ces articles sont considérés comme des backups)
  • Déroulement Sprint Planning – Elaboration
    • Les équipes nécessitant une coordination tiendront leur session dans la même salle afin de facilité  la collaboration
    • Réviser et discuter chaque article, faire un design initial et créer les tâches d’implémentation
    • Estimer les tâches d’implémentation en jours-homme
    • L’équipe s’engage sur une liste d’articles correspondant à leur vélocité
    • Identifier et enregistrer les risques, problèmes et obstacles
    • Le Sprint peut démarrer officiellement

Sprint Planning Definition

Exemple Sprint Planning Definition

Exemple de définition du Sprint Backlog Initial pour un Sprint de 2 semaines (10 jours)

Sprint Planning Elaboration

Exemple Sprint Planning Elaboration  

Exemple de décomposition d’un article du Sprint Backlog en Taches d’implémentation

Daily Standup 

Exemple Daily Standup 

Exemple de résultats d’un Daily Standup – mis à jour par chaque membre de l’équipe avant la session

Sprint Review 

Retrospective

Déroulement Retrospective

  1. Démarrage
  • Matériel : Post-Its de 6 couleurs, Tableau, Stylos
  • Rappeler les objectifs, règles et principes de la rétro
  • Demander à chaque participant comment il a vécu le Sprint qui s’achève
    • Subdivisé une zone du Tableau en 3 colonnes libellées «Content», «Triste», «Très déçu» ou des émoticônes
    • Chaque participant marque d’un trait la colonne qui lui corresponde
  1.  Récolte des données Starfish (Etoile de mer) et Plan d’action
  • Les participants en silence écrivent sur des post-its ce qui a bien marché et ce qu’il faut améliorer dans le sprint qui s’achève, en les catégorisant selon Starfish (Continuer de faire, Plus-de, Commencer à faire, Moins-de, Arrêter de faire) => 10 à 15 mn
  • Chaque participant décrit ses post-its à haute voix et les place au Tableau dans la zone Starfish correspondante. Les autres participants peuvent poser des questions de clarification (mais pas de rejet ou d’acceptation) => 10 à 15 mn
  • Grouper les post-its semblables => 5 mn
  • Prioriser les points en demandant à chaque participant de marquer les post-its qu’il souhaite voir discuter en premier (3 votes par participants) => 5 à 10 mn
  • Discuter les points dans l’ordre des priorités en se focalisant sur les actions à mettre en œuvre dans le prochain Sprint => 1 h
  1.  Clôture
  • Demander à chaque participant quelle bénéfice il tire de cette réunion
    • Subdivisé une zone du Tableau en 3 colonnes libellées «Content», «Triste», «Très déçu» ou des émoticônes
    • Chaque participant marque d’un trait la colonne qui lui corresponde

Exemple Retrospective

Mesures et Indicateurs

Liste des types de mesures

Exemple

Product Dashboard

Sprint Burndown Chart

Qu’est-ce qu’un sprint burndown chart?
Un sprint  burndown chart (graphique d’avancement) est une représentation graphique de l’évolution de la quantité de travail restante par rapport à la durée du sprint. Le travail restant se situe sur l’axe vertical, alors que le temps est sur l’axe horizontal. Une interprétation simple (régression linéaire) permet d’avoir une prévision de l’état d’avancement à la fin du sprint (Ideal Trend en anglais)

Comment mesure-t-on le retard ou l’avance ?

  • Le retard c’est lorsque le reste à faire à un temps donné est au dessus de la régression linéaire (voir exemple ci-contre)
  • L’avance c’est lorsque le reste à faire à un temps donné est au dessous de la régression linéaire

Release Burnup Chart

Qu’est-ce que le MVP?
Le produit minimum viable (ou MVP de l’anglais :minimum viable product) est une stratégie de développement de produit, utilisée pour de rapides et quantitatifs tests de mise sur le marché d’un produit ou d’une fonctionnalité. Cette stratégie a été popularisée par Eric Ries pour les applications WEB.

Ici le MVP désigne les récits utilisateurs sans lesquels le produit est inutilisable, non viable, ou très compliqué à utiliser!

Qu’est ce que le Release Burnup Chart?
Le Release burnup chart permet de suivre  l’avancement global de l’équipe par sprint par rapport au contenu du backlog et le plan de prévision

Qu’est ce que le plan de prévision?
Le plan de prévision, la courbe idéale liée à la vélocité moyenne de l’équipe sur les sprints précédents. Commencer par une vélocité initiale estimée puis corriger au fur et à mesure de la réalisation des sprints

Risque Burndown Chart

Qu’est-ce que le Risk Burndown Chart?

Le Risk Burndown Chart permet de suivre l’évolution du niveau de risque global par rapport à une prévision linéaire de réduction du niveau de risque (Ideal trend en anglais) sur une période de sprint ou de release

Matrice des risques et actions

Equipe Distribuée

Modèle de distribution

Equipes Agile Delivery Team (ADT) isolées : Les équipes ADT sont isolées les unes des autres géographiquement. Eliminer la plupart des dépendances entre équipes ADT

Equipe Product Delivery Team (PDT) distribuée : Les équipes ADT sont isolées les unes des autres géographiquement et intégrées par des réunions de coordination régulières (Scrum-of-Scrum, etc.)

Equipe Agile Delivery Team (ADT) distribuée : les membres d’une même équipe ADT sont isolés les uns des autres géographiquement. Il serait utile d’avoir un membre de l’équipe local joué le rôle de ScrumMaster local. Pareil pour le rôle AO

Moyens de communication effective

Moyen adapté à l’activité

Le cas ProRail de Xebia

Le meilleur moyen d’illustrer le modèle distribué est de prendre un cas réel – le projet ProRail mené par Xebia

  • Le Projet
    ProRail, la branche infrastructure et logistique des chemins de fer néerlandais devait développer un nouveau système d’informations voyageurs. Les informations sur les horaires des trains sont centralisées et mises à jour par le réseau ferroviaire lui même. Quand un train est en retard ou en avance, l’information est collectée par des capteurs disséminés dans l’infrastructure ou dans certains cas, manuellement. Xebia a donc mené le projet d’affichage de ces informations aux voyageurs pour l’ensemble des Pays Bas.
  • Le temps était le critère majeur car des projets antérieurs, menés en cascade, n’avaient pas respecté leurs engagements.
  • La transparence et la recherche de l’amélioration continue ont été des critères déterminants pour le client dans le choix de Xebia.
  • Le choix du développement Offshore a été guidé par les coûts et la capacité à monter en charge rapidement
  • La taille totale du projet fût de 20 années/homme, 100.000 lignes de code sur une période de 11 mois

Approche Xebia

  • 3 semaines d’initialisation pour construire le Product Backlog Initial et une conception sommaire de Architecture
  • Une équipe co-localisée au Pays-Bas mena 2 sprints (sprint de 2 semaines sur tout le projet)
  • Dès le troisième sprint, les membres de l’équipe néerlandaise et ceux de l’équipe indienne furent regroupés au sein d’une même équipe, co-localisée, partageant un seul et même Product Backlog et des pratiques d’ingénierie d’XP
  • Durant les itérations co-localisées, les membres de l’équipe ont scellé des relations interpersonnelles qui ont perdurées jusqu’à la fin du projet et les équipes indiennes ont pu ainsi s’approprier pleinement le contexte du client
  • Cela a aussi permis d’aligner tout le monde sur des pratiques, des standards, des rôles et des outils communs
  • Après 3 itérations, l’équipe indienne retourna en Inde. Force est de constater qu’en 5 itérations (10 semaines), l’équipe avait atteint le niveau de l’hyper-productivité
  • Le Pair Programming furent largement utilisées pour accélérer l’apprentissage des nouveaux
  • Les équipes partagèrent le même Product Backlog mais chacune avait son propre Sprint Backlog.
  • A la fin du projet, les équipes furent peu à peu réduites et fusionnées entre elles.
  • La maintenance est prise en charge par des ingénieurs néerlandais (sans l’Inde)

Productivité

  • Le tableau ci-dessous montre aisément que les équipes Scrum Distribuées surperforment les équipes de projet classique.
  • Les résultats d’une équipe Scrum distribuée Xebia sont équivalents à ceux d’une équipe Scrum co-localisée et les performances de Xebia et SirsiDyniax sont équivalentes.
  • Ce tableau montre que la performance d’une approche Scrum distribuée est reproductible et non spécifique à SirsiDynix.

Communication facilité

  • Les Scrum Meetings facilitent grandement la communication. Cela est rendu possible dans une équipe Scrum distribuée par le fait que les objectifs sont complètement partagés.
  • Toutes les cérémonies de Scrum furent tenues en mode distribué en utilisant le système de vidéo conférence de Skype à l’exception des démos.
  • Des salles de réunion séparées furent créées avec l’équipement de conférence ad ’hoc.
  • Un outil de planification utilisant une version électronique du BurnDown Chart permettait d’avoir une vision partagée du statut du Sprint en cours pour l’ensemble de l’équipe.
  • Un microphone passait de main en main pour des raisons d’audibilité. Nous avons découvert que les face à face visuels accroissaient l’efficacité de la communication et permettaient d’améliorer les relations interpersonnelles.
  • Les Sprint Planning impliquaient tous les membres de l’équipe, utilisant les Planning Poker Cards afin que les équipiers des deux continents participent aux estimations.
  • Les Daily Stand Up meetings démarraient quand les européens arrivaient au travail (pas plus de 15mn)
  • Le Rétrospective Meeting était mené comme le Sprint Planning Meeting et durait environ 2 heures.
  • La démonstration, elle, n’était pas partagée afin de garder un maximum d’emphase et de réactivité face au client. Les Européens briefaient les indiens après la démo.
  • Les meetings Scrum de Scrum avaient lieu juste après les Daily Scrum afin de synchroniser les éventuelles dépendances entre les équipes, et d’identifier les obstacles ou les points techniques.
  • L’ensemble de ces meetings étaient donc conformes au cycle officiel. Les face à face étaient aussi tenus si nécessaires ainsi que les revues de conception.
  • Il n’y avait donc rien de différent par rapport à l’utilisation de Scrum co-localisée si ce n’est l’outillage

Consistance et qualité

  • Durant tout le projet, une attention toute particulière a été portée à la qualité.
  • La notion Scrum « Definition of Done » sur ce projet était la suivante:
    • couverture à 80% des tests unitaires,
    • chaine de tests fonctionnels complètement automatisée,
    • tests de non régression complets, tests de charge et de performance mis en place pour toutes les récits et production de la documentation nécessaire.
  • Pour chaque fonctionnalité, l’intégralité de l’équipe était impliquée afin de débattre de la conception et de refactorer si nécessaire.
  • En complément à cette propriété collective de la conception, chaque équipe employait un « Gardien de la Qualité».
  • Il s’agissait d’un membre de l’équipe responsable de la qualité et de la consistance des travaux menés.
  • Chaque fois qu’il soulevait un problème, il était traité par l’intégralité de l’équipe.
  • Tous les membres de l’équipe partageaient la même pièce et des membres d’une équipe participaient systématiquement aux phases de conception des autres équipes afin de maintenir une consistance architecturale de l’ensemble.
  • Le Pair Programming et la rotation entre les équipes servaient à éviter l’appropriation du code et maintenir la polyvalence

Problèmes rencontrés

Même si Scrum est facile à comprendre, le développement distribué ajoute une couche de complexité et le projet, comme tout projet, rencontra un certain nombre de difficultés dans ce domaine.

DevOps

En cours de préparation

« Nos experts travaillent avec vos équipes sur vos projets pour vous accompagner et aider à sécuriser vos engagements quel que soit votre niveau de maturité Agile. Nous vous aidons à mettre en place écosystème et conditions d’amélioration continue de votre Organisation.  Voir nos services »

Nous Contacter