Collaboration en Equipe Produit - Partie3

1 073 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
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
1 073
Sur SlideShare
0
Issues des intégrations
0
Intégrations
11
Actions
Partages
0
Téléchargements
101
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • Une usine logicielle est un concept, dérivant de celui d’intégration continue (issu de l’XP).
    L’idée est d’aider à garantir de la qualité (=valeur) à chaque incrément.
    En sortie, on a du logiciel qui fonctionne, mais aussi des indicateurs pour continuer à s’améliorer.
  • Normalisation = ordre des tâches, nature des demandes, statut des demandes, design du code, frameworks employés
    Automatisation = utilisation massive de scripts pour automatiser tout ce qui peut l’être
  • Ce qui signifie que tous les membres de l’équipe vont s’en servir.
  • Entité Outillage présente dans le cas d’une grosse organisation
  • Les exemples présentés concernent essentiellement le monde Java
    Plusieurs serveurs sont concernés, sans oublier les différents environnements de validation
    Considérer de prendre une partie de ces services en Saas (comme Github)
  • BESOIN DE NORMES POUR BIEN REMPLIR UNE TACHE
  • Le statut des tâches doit être actualisé
    Le temps passé doit être actualisé
  • Une version peut être « release » ou « snapshot »
    Les membres de l’équipe, et notamment les développeurs, doivent associer leurs travaux à la bonne version
    Parfois ils peuvent l’associer à une version dans le futur
    Parfois une tâche peut être à cheval sur plusieurs versions (par exemple le refactoring)
  • Commentaires pertinents = pas d’évidence, traits d’esprits ok si acceptés par la culture de l’équipe (le code appartient à tout le monde)
    Documentation = contrats d’interface, …
  • Compilation des classes Java = peut utiliser des librairies / dépendances téléchargées depuis les dépôts
  • Principe d’intégration continue
    La nuit pour les traitements longs
  • Dépôt = repository ou package manager (Nexus, NPM, Bower….)
  • Les environnements suivants sont à préparer :

    Développement : simple
    Intégration : BDD, flux avec des partenaires extérieurs
    Pré-production : validation finale comme dans la cible (load-balancing, charge…)
    Production : cible
    Dans le cas d’un déploiement directement en Production, on parle de DevOps.

    Notion de « staging » en anglais
  • Exemple de plugin : Slack
  • Principe du « Defect cost increase »
    Une anomalie découverte tardivement coûte cher en temps de correction mais aussi en image utilisateur…
  • Il faut trouver le temps pour rédiger les tests !
  • Méthode Given – When - Then
  • Exemples du monde Java
  • Mocks = bouchons
    Mocks plutôt pour les tests unitaires
    Vraies données indispensables pour les tests d’intégration, acceptation et performance
  • Rappel : automatiser tout ce qui peut être utilisé
  • Par exemple spécifications Word, organisation Wiki…
  • Intégration = choix des documents utiles, personnalisation des thèmes, filtrage des informations, intégration à une base de connaissances plus globales (wiki, …)
  • Exemple des contrats d’interface, qu’ils soient générés ou rédigés
    Exemple de génération : Javadoc, Swagger
    Deux points d’attention forts : gestion des versions ET compréhension par le consommateur
  • Un peu comme un membre supplémentaire de l’équipe
    + smartwatchs, etc
  • Normes !!
  • Normes !!
  • 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

    ×