Collaboration en Equipe Produit - Partie3

1 154 vues

Publié le

Troisième partie du cours sur la culture produit, pour la formation MIDO M2 SITN de l'Université Paris Dauphine.

Cette partie présente l'usine logicielle de l'équipe Produit, c'est-à-dire l'outillage unifié permettant d'orchestrer et d'automatiser les tâches des différents membres de l'équipe.

Plan de la partie :
- Qu’apporte l’usine logicielle à l’équipe produit ?
- Comment mettre en place une usine logicielle ?
- La gestion des « User Stories » doit être manuelle et rigoureuse
- La gestion des sources requiert une stratégie de gestion des versions
- La gestion des « builds » ou l’automatisation du partage des livrables
- La gestion des tests repose sur une stratégie de test obligatoire
- La gestion de la documentation inclut de la rédaction et de la génération
- L’adoption de l’usine logicielle repose sur sa facilité d’utilisation
- Pour aller plus loin

Publié dans : Technologie
  • Soyez le premier à commenter

Collaboration en Equipe Produit - Partie3

  1. 1. Titre du slide Collaboration en équipe Produit Partie 3 : L’usine logicielle de l’équipe produit Qu’apporte l’usine logicielle à l’équipe produit ? Comment mettre en place une usine logicielle ? La gestion des « User Stories » doit être manuelle et rigoureuse La gestion des sources requiert une stratégie de gestion des versions La gestion des « builds » ou l’automatisation du partage des livrables La gestion des tests repose sur une stratégie de test obligatoire La gestion de la documentation inclut de la rédaction et de la génération L’adoption de l’usine logicielle repose sur sa facilité d’utilisation Pour aller plus loin Alexandre Estela (alexandre@estela.fr) Université Paris Dauphine Management & coaching d’équipes Produit Cours MIDO M2 SITN
  2. 2. Titre du slide Qu’apporte l’usine logicielle à l’équipe produit ?
  3. 3. Partie 3 – Diapositive 3 L’usine logicielle est la « fabrique » d’incréments de produit Doc Sources Tests Incréments de qualité La qualité de chaque nouvel incrément est assurée en suivant scrupuleusement la même chaîne d’étapes de fabrication.
  4. 4. Partie 3 – Diapositive 4 L’usine logicielle est en réalité un assemblage d’outils User Stories, Backlogs Démonstrations KPIs, Qualimétrie Mailing lists, Messageries CMS, Wikis Bug tracker Gestionnaire de sources Tests Intégration continue Rappel Partie 2 : « Boîte à outils de l’équipe Produit »
  5. 5. Partie 3 – Diapositive 5 Cet assemblage doit reposer sur deux principes forts Normalisation + Automatisation
  6. 6. Partie 3 – Diapositive 6 L’usine logicielle aide ainsi à orchestrer toutes les tâches d’équipe Qualification des « User Stories » Définition des itérations Rédaction des tests Codage Alimentation des « Backlogs » Exécution des tests manuels Compilation et configuration des sources Packaging des librairies et applications Calcul des indicateurs non liés au code Rédaction de la documentation Livraison dans un dépôt de packages Déploiement en environnement de validation Exécution des tests automatisables Calcul des indicateurs de qualité du code Gestion des branches Gestion des tâches Suivi des « commits » de code Revues de code Constitution d’une batterie de tests Génération de la documentation
  7. 7. Partie 3 – Diapositive 7 Mais le périmètre de l’usine logicielle va bien au-delà de l’équipe Equipe Produit (tous rôles confondus) Entité Outillage (transverse à l’organisation) Reste de l’organisation (dont Client) Opère Visite Installe
  8. 8. Titre du slide Comment mettre en place une usine logicielle ?
  9. 9. Partie 3 – Diapositive 9 Choisir, installer et/ou configurer une bonne dose de logiciels Leslogosetillustrationssontlapropriétédeleursdétenteursrespectifs.
  10. 10. Partie 3 – Diapositive 10 Définir les modalités d’utilisation de ces logiciels par l’équipe Quelles informations indiquer dans une « User Story » ? Comment faire référence à la « User Story » dans le code? Comment rédiger un test afin qu’il soit automatisable ? Comment tester la dernière version stable du produit ? Leslogosetillustrationssontlapropriétédeleursdétenteursrespectifs.
  11. 11. Partie 3 – Diapositive 11 Et surtout, ne pas oublier de documenter Normes de développement Normes de rédaction des tests Normes de création et de suivi des « User Stories » Normes d’utilisation des environnements Normes de configuration du poste de travail Normes d‘architecture
  12. 12. Partie 3 – Diapositive 12 Illustration d’une usine logicielle complète 3.Soumissiondecode 2. Affectation U.S. 1.CréationU.S. 4. Revue de code 5. Mise à jour U.S. Leslogosetillustrationssontlapropriétédeleursdétenteursrespectifs. 7. Exécution des tests 8. Analyse de code 9.Suiviqualité 6.Assemblage 10. Livraison (app + doc) 12. Test ou utilisation 11. Déploiement
  13. 13. Titre du slide La gestion des « User Stories » doit être manuelle et rigoureuse
  14. 14. Partie 3 – Diapositive 14 La gestion électronique des U.S. est un complément, pas une fin Gestion électronique des « User Stories » (et tâches associées) Gestion +/- rigoureuse des « User Stories » Estimations fiables ?U.S. de valeur ? Bonnes durées d’itération ? Bonne priorisation des U.S. ? Reflète
  15. 15. Partie 3 – Diapositive 15 Les tâches doivent être qualifiées méthodiquement La tâche concerne une U.S., anomalie, autre ? Format de titre (code, phrase…) ? Description textuelle détaillée ou lien vers un autre doc ? Quelle(s) application(s) ou version(s) sont concernées ? Quelle valeur apporte la tâche au produit ? Est-ce urgent (bug en production, fonctionnalité attendue par le marché…) ? Qui doit travailler sur la tâche ? Qui dépend de l’avancement de cette tâche ? Fichiers de log, captures d’écran, … tout ce qui aide ?
  16. 16. Partie 3 – Diapositive 16 L’état des tâches doit être tenu à jour Combien de temps passé sur la tâche ? (à rapporter au temps estimé initialement) Quel est le pourcentage d’avancement de la tâche ? Quel est le statut de la tâche ? Les autres membres de l’équipe qui étaient dépendants peuvent-ils démarrer leurs activités ? La U.S. associée est-elle terminée ?
  17. 17. Partie 3 – Diapositive 17 Les « backlogs » doivent être tenus à jour Backlog de produit Backlogs d’itération A compléter en fonction des nouveaux besoins (évolutions, corrections, etc) A créer et compléter à chaque itération (+ estimation et priorisation)
  18. 18. Partie 3 – Diapositive 18 Le « board » de management visuel doit être synchronisé
  19. 19. Titre du slide La gestion des sources requiert une stratégie de gestion de versions
  20. 20. Partie 3 – Diapositive 20 Rappel : un produit repose sur différentes versions d’application Itération 1 Itération 2 Itération 3 Itération 4 Itération 5 Itération 6 Version 1.0 Version 1.1 Version 1.2 User Story A User Story B User Story C User Story F User Story G User Story D User Story E Anomalie H Anomalie I Refactoring K User Story L User Story M User Story N Anomalie O Refactoring K
  21. 21. Partie 3 – Diapositive 21 Branche « Master » Un produit repose aussi sur différentes versions de code source Branche « Version 1.1 » Branche « User Story G » Branche « Anomalie H » Branche « Refactoring K » Version 1.0 Version 1.1
  22. 22. Partie 3 – Diapositive 22 Les développements doivent donc être liés à la bonne version Sélection de la bonne branche de travail Indication de la tâche de travail lors de la soumission (« commit ») du code
  23. 23. Partie 3 – Diapositive 23 Le code soumis par le développeur doit être accompagné de commentaires pertinents au niveau des classes, méthodes, fichiers de configuration, etc. Ceci offre plusieurs leviers à l’équipe :  Permettre aux nouveaux développeurs de s’approprier plus facilement le code  Permettre à des outils dans l’usine logicielle de générer de la documentation  Permettre de générer du code complémentaire Le développeur doit par ailleurs toujours documenter le code
  24. 24. Partie 3 – Diapositive 24 Les revues de code sont au final toujours une bonne pratique Les revues de code peuvent être faites en « Pair Programming », à posteriori dans un simple document Word, ou être intégrées à l’usine logicielle. Une revue de code intégrée à l’usine logicielle intervient cependant avant l’ajout des sources « à valider » auprès des sources déjà validées. Un système de vote peut être utilisé pour déterminer si la modification de code peut être rajoutée aux autres sources.
  25. 25. Titre du slide La gestion des « builds » ou l’automatisation du partage des livrables
  26. 26. Partie 3 – Diapositive 26 Le « build » ou « assemblage » est la transformation de tous les fichiers source en des livrables, suivie de leur partage dans un dépôt et leur déploiement éventuel. Qu’appelle-t-on un « build » ? Exemple de « build » d’une application web en Java effectué avec Maven et Jenkins Compilation des classes Java Génération des classes utilitaires Génération de la documentation Création des structures de fichier Remplissage des fichiers de config Minification du JavaScript & CSS Création des fichiers manquants Création des archives JAR Création de l’application web Notifications Déploiement des applications Livraison dans les dépôts
  27. 27. Partie 3 – Diapositive 27 Tout ce qui est automatisable doit être automatisé ! Le fait d’automatiser les tâches techniques répétitives de « build » permet de :  éviter des erreurs de manipulation humaine  gagner du temps par rapport aux déclenchements manuels  garantir un assemblage continu, et ainsi des livraisons et déploiements réguliers Les « builds » peuvent être lancés automatiquement à chaque « commit » de développeur Les « builds » peuvent être lancés automatiquement à intervalles réguliers (par exemple toutes les heures) Les « builds » peuvent être lancés automatiquement à une heure fixe (par exemple la nuit)
  28. 28. Partie 3 – Diapositive 28 Les dépôts doivent être préparés pour partager des librairies Publication d’une librairie dans le dépôt (version x.x.x) Utilisation d’une librairie disponible dans le dépôt (version x.x.x) <!-- Exemple de configuration Maven pour publier une librairie --> <groupId>fr.estela</groupId> <artifactId>exemple-lib</artifactId> <version>1.0.0</version> <!-- Exemple de configuration Maven pour utiliser une librairie --> <dependency> <groupId>fr.estela</groupId> <artifactId>exemple-lib</artifactId> <version>1.0.0</version> </dependency>
  29. 29. Partie 3 – Diapositive 29 Les déploiements se font sur des environnements spécialisés Environnement de développement Environnement d’intégration Environnement de pré-production Environnement de production
  30. 30. Partie 3 – Diapositive 30 Les notifications requièrent des e-mails et/ou des canaux dédiés Nouveau « build » (réussi ou échoué) Notification du résultat par e-mail (au développeur, à un groupe) Notification du résultat sur un espace de partage (messagerie électronique, CMS, …)
  31. 31. Titre du slide La gestion des tests repose sur une stratégie de test obligatoire
  32. 32. Partie 3 – Diapositive 32 Pourquoi une stratégie de test obligatoire ? La correction d’une anomalie coûte d’autant plus cher qu’elle est effectuée tardivement dans la vie du produit. Il est donc important de détecter au plus vite nouvelles anomalies et régressions au cours des itérations.
  33. 33. Partie 3 – Diapositive 33 Les tests doivent garantir une non-régression permanente Développements finaux Spécifications finales Exécution des tests Exécuter les tests une fois à la fin de tous les développements, c’est bien… Exécuter les tests dés qu’il y a un nouveau développement, c’est mieux ! Nouvelle spécification Nouveau développement Exécution des tests
  34. 34. Partie 3 – Diapositive 34 La batterie de tests doit être la plus complète possible Test de la couverture et du style de code Test des relations avec les autres systèmes Test du déroulement des scénarios fonctionnels Test des contraintes de performance Batterie de tests du produit
  35. 35. Partie 3 – Diapositive 35 La batterie de tests est cependant constituée au fur et à mesure Nombre de tests disponibles Nombre d’itérations déroulées La bonne pratique consiste à rédiger des tests pour TOUS les nouveaux développements au fur et à mesure
  36. 36. Partie 3 – Diapositive 36 Différents tests pour différents besoins et rédacteur(s) Besoin Rédacteur(s) Tests unitaires • Vérifier que tout le code développé est utilisé • Vérifier que le style de code est conforme aux normes de l’équipe (nommage, indentations...) • Vérifier que le code ne comporte pas de fautes de programmation (mémoire, code mort…) Développeurs Tests d’intégration • Vérifier que les applications communiquent correctement avec les systèmes dont elles sont dépendantes (base de données, web services, système de fichiers…) Développeurs Architectes Tests d’acceptation • Vérifier que les scénarios fonctionnels associés aux « User stories » sont bien réalisables Concepteurs Testeurs Tests de performance • Vérifier que les applications fonctionnent normalement lorsqu’elles sont soumises à une forte charge (tests de charge, « stress tests ») • Vérifier que les applications fonctionnent normalement sur une longue période d’activité (tests d’endurance) Développeurs Architectes Exploitants
  37. 37. Partie 3 – Diapositive 37 Ces tests doivent être rédigés au plus tôt TDD = « Test Driven Design » Rédaction des tests au début 0% de réussite Développement et implémentation des tests Exécution des tests jusqu’à 100% de réussite 1 2 3
  38. 38. Partie 3 – Diapositive 38 Ces tests doivent être orientés fonctionnellement BDD = « Behavior Driven Design » En tant que… Visiteur Je veux… Consulter Pour… Acheter Test d’acceptation 2 (scénario d’erreur)  Etant donné… un visiteur mineur  Quand… il consulte un article  Alors… le bouton acheter est désactivé Test d’acceptation 1 (scénario nominal)  Etant donné… un visiteur adulte  Quand… il consulte un article  Alors… le bouton acheter est activé
  39. 39. Partie 3 – Diapositive 39 Ces tests doivent être idéalement automatisables Tous les tests doivent idéalement être rédigés avec des outils permettant leur intégration aux « builds » automatiques de l’usine logicielle. Tests automatisables Tests unitaires Tests d’intégration Tests d’acceptation Tests de performance Tests non automatisables Tests rédigés sur des documents Word, à exécuter manuellement Tests rédigés dans des outils pouvant piloter l’exécution mais non intégrables à une usine logicielle Leslogosetillustrationssontlapropriétédeleursdétenteursrespectifs.
  40. 40. Partie 3 – Diapositive 40 Eviter les « mocks » et favoriser les vrais jeux de données ! « Mocks » • Rapides à mettre en œuvre • Permettent d’exécuter les tests sans dépendance à aucun système tiers (BDD, services partenaires…) • Vision souvent technique du test (couverture du code) • Ne testent pas du tout la cible fonctionnelle bout-à-bout Vraies données • Permettent de mettre en œuvre des tests très proches de la cible (vrais données, voire vrais systèmes tiers) • Les mesures effectuées peuvent être considérées comme reflétant la cible (temps de traitement, …) • Pour être pertinents, les jeux de données doivent souvent être fournis et maintenus par des équipes tierces • Si utilisation de systèmes tiers, leur disponibilité doit être assurée
  41. 41. Titre du slide La gestion de la documentation inclut de la rédaction et de la génération
  42. 42. Partie 3 – Diapositive 42 Différents modes de création pour différents types de document Document d’accueil Normes de l’équipe Organisation de l’équipe Architecture et composants Journaux des modifications … Point commun : toute documentation doit avoir une utilité ! « Javadoc » Diagrammes UML Modèles de données Contrats d’Interface Rapports d’analyse de code …
  43. 43. Partie 3 – Diapositive 43 Les documents rédigés doivent être maintenus Beaucoup de documents rédigés doivent être actualisés au fil du temps. Cela inclut les tableaux et diagrammes qu’ils contiennent…
  44. 44. Partie 3 – Diapositive 44 Les documents générés doivent être à jour, filtrés et accessibles Seuls certains documents générés sont pertinents pour l’équipe, ils doivent être remontés séparément et régulièrement pour tous les membres intéressés.
  45. 45. Partie 3 – Diapositive 45 Les contrats d’interface sont à considérer avec attention V1 V2 A migrer A migrer En cours de migration En cible
  46. 46. Partie 3 – Diapositive 46 Le « bug tracker » doit également servir à remonter des KPIs Le gestionnaire de demandes est également capable de générer de nombreux types de rapport pouvant documenter une itération, une livraison, etc.
  47. 47. Partie 3 – Diapositive 47 Les rapports d’analyse de code doivent être mis en avant Les rapports d’analyse de code générés quotidiennement doivent faire l’objet d’un suivi permanent pour garder des standards élevés de qualité de code. Couverture du code par les tests Style du code Performance Risques
  48. 48. Titre du slide L’adoption de l’usine logicielle repose sur sa facilité d’utilisation
  49. 49. Partie 3 – Diapositive 49 L’usine logicielle doit s’insérer dans le paysage de l’équipe
  50. 50. Partie 3 – Diapositive 50 La complexité de l’usine logicielle doit être masquée
  51. 51. Partie 3 – Diapositive 51 La responsabilité de l’usine logicielle doit être claire
  52. 52. Partie 3 – Diapositive 52 Coaching, Séniorité et Formation sont toujours indispensables
  53. 53. Titre du slide Pour aller plus loin
  54. 54. Partie 3 – Diapositive 54 Bibliographie  Jez Humble & David Farley, 2010, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation  Gene Kim, 2013, The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win  Andrew Hunt, David Thomas, 1999, The Pragmatic Programmer: From Journeyman to Master  Kent Beck, 2002, Test Driven Development: By Example  Gojko Adzic, 2009, Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing

×