Ce billet traite des rôles pour les développement agiles et des outils informatiques utilisables pour les projets agiles. Notamment, voici quelques rôles pour les développements agiles :

• PRODUCT OWNER - CLIENT;
• PROGRAMMEUR;
• PRODUCT OWNER - TESTEUR INTEGRATEUR;
• TRACKER;
• QUALITE CMMI;
• SCRUM MASTER - MANAGER;
• COACH.

A chacun de ces rôles, sont dévolues des pratiques XP parmi treize, recommandations concrètes, chacune bénéfique en elle-même, sur la façon de conduire ou de réaliser un projet ; il est conseillé de les maitriser d'abord en les appliquant consciencieusement, puis de les adapter.

1. Test unitaires (Unit Test, test codé par les programmeurs dans le même langage que celui utilisé pour le reste de l'application. Chaque classe du logiciel en développement possède un test unitaire correspondant qui exerce une ou plusieurs instances de la classe testée et en vérifie automatiquement le comportement au moyen d'assertions)
2. Test de recettes (Acceptance Test, test permettant d'assurer de manière automatique et contractuelle la conformité du logiciel avec les exigences du client)
3. Planification itérative (planning game, consiste à établir, au terme d'une séance de planification, un plan de livraison (release) et/ou un plan d'itération (sprint) comprenant un certain nombre de scénarios client. Ces plans sont revus à chaque itérations)
4. Client sur site
5. Programmation en binôme (pair programming, association de deux programmeurs sur une même machine pour l'écriture de code. Les binômes sont renouvelés régulièrement)
6. Intégration continue (Continuous Integration, démarche consistant à intégrer aussi fréquemment que possible (au moins une fois par jour) les développements unitaires sous forme d'une application globale, prête au déploiement et susceptible de passer les tests de recette)
7. Remaniement (refactoring, consiste à revenir sur le code en permanence pour le rendre plus simple et plus clair et faciliter ainsi l'ajout de nouveau code : cela permet de faire émerger la conception de manière progressive tout au long du développement)
8. Livraisons fréquentes (Release, fourniture fréquente au client, pour utilisation immédiate d'une version du logiciel en état opérationnel et vérifiant tous les tests de recette exigés pour cette version)
9. Conception simple (Simple Design, étape consistant à modéliser (ou plus généralement réfléchir à) ce qui doit être codé. Dans le cadre XP, conception et programmation sont indissociables : la conception ne produit par ailleurs pas nécessairement un autre "document" que le code source lui-même)
10. Métaphore (Metaphor, c'est la description de haut niveau, en termes imagées et compréhensibles par toute l'équipe, non développeurs compris, de l'architecture technique et fonctionnelle du projet)
11. Responsabilité collective du code
12. Règles de codage
13. Rythme durable

Pour des précisions sur l"adaptation de ces pratiques XP dans le cadre de Scrum, reportez-vous au chapitre 13 de l'ouvrage référencé en deuxième position dans les références.

Définition des rôles

A part celui du coach, chacun des rôles suivants est joué par un membre de l'équipe de développement.

PRODUCT OWNER - CLIENT

Qui est-il ?

• Pas nécessairement le client contractuel
  • Assistant à maîtrise d’ouvrage
  • Représentant des utilisateurs
• A défaut quelqu’un pour agir comme client « artificiel »
  • Chef de projet
  • Ingénieur chargé des spécifications

Client sur site et feedback

• Intégré à l’équipe de développement
• Plus de cahier des charges vague ou incompréhensible
• Plus de démo truquée
• Explique se qu’il souhaite aux développeurs
  • Vision plus rapide du résultat
  • Prise de conscience en cas d’erreur

Scénarios clients

• Description informelle d’une fonctionnalité ou d’une interaction avec l’utilisateur
• Le plus simple possible

Démarrage du projet

• Des scénarios initiaux sont dégagés et présentés
• Ils sont classés par priorité et répartis en itérations

A chaque itération...

• Grâce au feedback introduit (logiciel fonctionnel) :
  • Il peut revoir le contenu des itérations
  • Modifier ses scénarios
• Il est garant des fonctionnalités du logiciel

Tests de recette

• But : préciser les contours des scénarios
• Données concrètes levant les ambiguïtés
• Preuve que le système fait ce qu’il demandait
• A chaque fin d’itération tous les tests de recette doivent passer avec succès

Pratiques XP

• Planification itérative
• Rédaction des scénarios clients
• Séances de planification
• Tests de recette
• Intégration continue
• Rythme durable

Qualités évaluées

• Qualité des relations avec le client final
• Utilisation des forums de communication avec le client final
• Préparation des recettes clients
• Compte-rendu des recettes clients
• Retours du client final à l'équipe, priorisation du product backlog

Le client est en charge du Product Backlog et de la démonstration lors de la réunion de revue de Sprint devant M. Bourgault.

Il met à jour le Product Backlog

• en début de Sprint lors de la planification
• suite à la revue de Sprint pour prendre en compte les fonctionnalités acceptées ou refusées par M. Bourgault
• en milieu de Sprint pour retirer des fonctionnalités en accord avec M. Bourgault en cas de retard (en accord avec le Manager)

Il prépare avec les autres clients les revues de Sprint.

PROGRAMMEUR

Responsabilisation

• Retour du programmeur comme rôle central
• A la fois : codeur, testeur, concepteur et analyste
• Apprentissage → Qualités humaines nécessaires
• XP : Ecole de l’excellence
• Responsabilisés pour donner le meilleur d’eux même
  • ex. : estimation des charges et délais

Pratiques XP

• Programmation en binôme
• Tests unitaires
• Conception simple
• Remaniement
• Responsabilité collective du code
• Règles de codage
• Intégration continue
• Rythme durable

Qualités évaluées

• Pratique du TDD
• Utilisation de JUnit
• Utilisation de JavaDoc
• Utilisation de SVN
• Respect de l'engagement

PRODUCT OWNER - TESTEUR :

Le bras droit du client

• Définit et automatise les tests de recette
• Conseille le client sur la testabilité d’une fonctionnalité
• Utilisation d’outils différents pour scripter
• Garant du sentiment de réussite sur le projet
• Test fonctionnel réussi → Progression
• Communiquer pour motiver (graphique de progression...)

Compétences requises

• Programmeur hétéroclite (maîtriser l’outillage de test)
• Rigoureux et intègre

Pratiques XP

• Suivi des tests (planification itérative)
• Tests de recette
• Intégration continue
• Rythme durable

Qualités évaluées

• Rigueur
• Respect des normes qualité
• Utilisation et maitrise des outils
• Utilisation et maitrise des méthodes
• Respect des délais

Il est en charge des scenarii de tests pour l'intégration et la recette. Il veille au bon déroulement de ces tests. Il doit rédiger les tests d'acceptation en début de Sprint et en lien avec le client. Il suit les anomalies et assure la qualité de l'ensemble des développements de son équipe.

Il prépare avec les autres testeurs les livraisons des fins de Sprint.

SCRUM MASTER - TRACKER :

Missions

• Suivre les tâches en cours d’itération
• Interroger les programmeurs
  • Savoir où ils en sont
  • Ne pas les mettre sur des charbons ardents
  • Attention à ne pas dériver en discussion technique
• Détecter les problèmes avant qu’il ne soit trop tard
  • Révélateur
  • Pas de prise d’initiative
• Il fait en sorte que la tâche de 3 jours en prenne 4 et non 6

Qui est-il ?

• Pas un supérieur hiérarchique
• Quelqu’un a qui on peut se confier
• De préférence pas un programmeur, mais quelqu’un d’extérieur
  • Pour éviter les discussions techniques
  • A défaut, ce rôle peut tourner entre les programmeurs à chaque itération

Pratiques XP

• Planification itérative

Qualités évaluées

• Rigueur
• Respect des délais de mise à jour de la GP
• Qualité des comptes-rendu d'activité sur le Wiki
• Tâches correctement décrites
• Avancement mis à jour régulièrement, sprint backlog

Il est en charge du Sprint Backlog. Il l'établit avec toute l'équipe lors du Sprint Planning. Il le met à jour quotidiennement après chaque Scrum Daily Meeting. Il veille à relever les problèmes rencontrés et évoqués lors des Scrum Daily Meeting et les reporte sur sa page WIKI.

Il reporte la planification de chaque tâche et son suivi dans l'outil Tâches de SourceSup ou via Trello. Il met à jour l'avancement de chaque tâche en fin de journée.

QUALITE CMMI :

CMMI, sigle de Capability Maturity Model + Integration, est un modèle de référence, un ensemble structuré de bonnes pratiques, destiné à appréhender, évaluer et améliorer les activités des entreprises d'ingénierie. Il couvre les compétences et processus techniques et managériaux permettant de transformer des besoins utilisateurs en un produit technique. La théorie et les concepts de l'amélioration de la qualité, comme la mise en œuvre de la qualité par la prévention et la détection des erreurs, l’amélioration continue, et la focalisation sur les besoins du client, sont tous applicables au domaine du logiciel. Le modèle définit cinq niveau de maturité, exigeant chacun certaines activités et processus clé.

1. Initial.
2. Discipliné.
3. Ajusté.
4. Géré quantitativement.
5. En optimisation.

Les grandes approches de la qualité, comme le Lean, la roue de Deming, Kaizen, Six Sigma, le management de la qualité totale (TQM) et le Plan-Do-Check-Act PDCA, sont des approches qui peuvent être utilisées pour atteindre les objectifs de qualité. Ces approches peuvent conjointement utiliser les normes et les pratiques exemplaires telles que: l’ISO 9001, le CobiT, ITIL/ISO 20000, le CMMI/ISO/CEI 15504 et le référentiel d’amélioration de la maintenance du logiciel, le S3M.

Dans CMMI-Dev 1.3 au niveau de l'assurance qualité processus et produit (PPQA pour Process and Product Quality Assurance), pour les environnements agiles, les équipes ont tendance à se focaliser sur les besoins immédiats de l'itération plutôt que sur les besoins organisationnels à plus long terme et plus vastes. Pour s'assurer que les évaluations objectives sont perçues comme ayant de la valeur et comme étant efficaces, il convient de savoir très tôt :

1. comment réaliser les évaluations de manières objectives ;
2. quels processus et produits d'activité sont évalués ;
3. comment les résultats des évaluations seront intégrés dans les rythmes de l'équipe ( par exemple, au cours de réunions quotidiennes, dans des listes de contrôles, des revues de pairs, des outils, une intégration continue, des rétrospectives).

Pour le XP, les tests unitaires, tout comme les tests de recette au niveau d'abstraction supérieur, n'ont pas pour objectif de garantir qu'un programme est en tout point conforme aux attentes que d'amener programmeur et clients à mener un projet en ce concentrant sur leur objectif, et d'éviter ce que l'on pourrait appeler la "programmation par coïncidences" : quand le programme fonctionne, on ne sait pas pourquoi ni comment il fonctionne - on saura encore moins pourquoi il ne fonctionne pas ! Lorsqu'ils ont identifié un défaut dans leur programme, les programmeurs XP ont pour premier réflexe, avant la correction de ce défaut, d’écrire un nouveau test unitaire, écrit de telle sorte qu'il échoue parce que le défaut constaté est présent. Lorsque le défaut est corrigé, le test doit immédiatement passer.

La qualité interne fait référence à des points qui habituellement ne sont pas visibles par l'utilisateur, mais qui ont un profond effet sur la maintenabilité du système. Des choses comme la cohérence de la conception, la couverture des tests, la lisibilité du code, les remaniements (refactoring). La qualité interne n'est pas sujette à discussion. C'est la responsabilité de l'équipe de maintenir la qualité du système dans toutes les circonstances.

Responsabilités

• Garant de la qualité des développements (norme, test, intégration continue, versionning) via la surveillance des builds avec l'outil Sonar de SourceSup
• Responsable de la capitalisation et membre actif sur les différents sujets de veilles technologiques

Les points clés du CMMI par la pratique

• Satisfaction des utilisateurs = Le respect des exigences
• L'anticipation des problèmes = Le pilotage par les risques
• La qualité des livrables = La stratégie de vérification

Pour prévoir les résultats futurs d’un processus, on peut par exemple utiliser des modèles de performance de processus pour prévoir les défauts latents dans le produit livré à l’aide de mesures de défaut provisoires identifiées au cours d’activités de vérification du produit (comme les revues par les pairs et les tests).

Exemples de mesures de sous-processus :

• volatilité des exigences ;
• rapports entre les valeurs estimées et mesurées des paramètres planifiés (par exemple taille, coût et calendrier) ;
• couverture et efficacité des revues par les pairs ;
• couverture et efficacité des tests ;
• efficacité de la formation (par exemple pourcentage de formation planifiée

achevée et scores obtenus aux tests) ;

• fiabilité ;

Les critères d’évaluation et d’acceptation doivent être :

• clairement et correctement énoncés ;
• complets ;
• non contradictoires ;
• identifiés de façon unique ;
• appropriés à mettre en œuvre ;
• vérifiables (testables) ;
• traçables.

Exemples de normes de conception (ou de critères, en particulier dans les circonstances où les normes n’ont pas été établies) :

• normes d’interface utilisateur ;
• scénarios de test ;
• normes de sécurité ;
• contraintes de conception (par exemple compatibilité électromagnétique, intégrité des signaux et contraintes liées à l’environnement) ;
• contraintes de production ;
• tolérances de conception ;
• normes liées aux pièces (par exemple déchets et rebuts de production).

Exemples d’outils :

• modèles de dynamique des systèmes ;
• analyseurs de couverture de tests automatisés ;
• outils de contrôle statistique de processus et de contrôle qualité ;
• outils d’analyse statistique.

Exemples de méthodes de vérification :

• tests de la couverture des chemins ;
• tests de charge, de stress et de performance ;
• tests basés sur des tables de décision ;
• tests basés sur la décomposition fonctionnelle ;
• réutilisation de cas de test ;
• tests d’acceptation.

Exemples de méthodes de tests unitaires :

• test de la couverture des instructions ;
• test de la couverture des branches ;
• test de la couverture des chemins ;
• test de la couverture des prédicats ;
• test des valeurs des bornes ;
• test des valeurs spéciales.

Exemples de ressources et d’outils :

• outils de gestion des tests ;
• générateurs de cas de test ;
• analyseurs de couverture des tests ;
• simulateurs ;
• outils de test de charge, de stress et de performance.

L'outil Fichiers de SourceSup, listant les fichies des releases finales des années précédentes, vous donnent accès aux normes de codages, de nommages des fichiers en vigueur lors des sessions précédentes et à des tutoriels pour l'emploi des outils Eclipse pour le TDD notamment.

Qualités évaluées pour ce rôle

• Rigueur
• Respect de l'engagement
• Respect des contraintes qualités
• Informations de contrôle qualité
• Application des normes qualités dans l'équipe
• Utilisation des outils de contrôle qualité

SCRUM MASTER - MANAGER :

Position dans l’organisation

• Supérieur hiérarchique des programmeurs
• Ne fait pas partie intégrante de l’équipe
• Chef du service auquel appartient l’équipe
• Chef de projet global (dans le cadre d’un sous-projet)

Responsabilités

• Il s’occupe matériellement de l’équipe
• Il demande des comptes (sur les engagements pris)
• Interface avec l’extérieur (dans le cadre d’un sous-projet)

Pratiques XP

• Scénarios client
• Planification itérative
• Rythme durable

Qualités évaluées

• Esprit d'équipe
• Communication externe (coach, inter-équipe, directeur de projet)
• Prise de décision
• Animation de l'équipe, daily meeting
• Motivation de l'équipe

Il est le coordinateur de l'équipe. Il coordonne avec les autres managers le bon déroulement du projet.

Il est l'interlocuteur du Coach (historiquement Dominique de Prémorel) et du responsable du projet (Michel Dubois).

Il veille à ce que l'équipe travaille dans les meilleurs conditions et maintient sa cohésion.

Il anime le Scrum Daily Meeting, et s'assure que les problèmes soient bien résolus.

Il met à jour le WIKI de suivi de son équipe.

COACH

Garant du processus

• Il réunit tout les autres rôles
• Vérifie que chaque rôle est respecté
• Ses buts ultimes :
  • Équipe autonome
  • Chaque programmeur est en amélioration continue
• Ses qualités
  • Expert de la méthode XP
  • Expert technique
  • Programmeur chevronné
  • Architecte
  • Pédagogue et sensible
  • Sang-froid

Pratiques XP

• Toutes !

Historiquement ce rôle a été joué par Dominique de Prémorel qui suivait les équipes au jour le jour. Vu ses compétences, Patrice Petit fera du Coaching le Jeudi 29 Janvier 2015.

Répartition des rôle dans une équipe de développement projet Wa11y 2014-2015

Pour simplifier les évaluations, on peut décider de ne pas changer les rôles durant les 3 phases de développement ou Releases (1 / 2 / finale). On peut aussi changer les rôles pour un meilleur apprentissage.

• La release 1 se termine mercredi 28 janvier 12h pour être présentée au client l'après-midi.
• La release 2 se termine mercredi 4 février 12h pour être présentée au client l'après-midi.
• La release finale se termine mercredi 11 février 12h pour être présentée au client l'après-midi.

Le bémol au changement de rôle lors du changement des phases c'est que ces dernières sont très courtes. Or il faut du temps pour apprendre un rôle en amélioration continue... La décision peut être reportée après la rétrospective de la release 1 qui aura lieu en présence du coach Patrice Petit le jeudi 29 janvier.

Rôles pour le projet La Poste 2014-2015
Equipe	Nom	Prenom	Rôle XP	Rôle secondaire	Release
A	GAUTIER	Kévin	PROGRAMMEUR	PROGRAMMEUR	1 / 2 / finale
A	SOLIS	Ivan	PRODUCT OWNER - CLIENT	PROGRAMMEUR	1 / 2 / finale
A	LE MOAL	Florian	PRODUCT OWNER - TESTEUR INTEGRATEUR	PROGRAMMEUR	1 / 2 / finale
A	CABON	Thomas	TRACKER	PROGRAMMEUR	1 / 2 / finale
A	GARRET	Quentin	QUALITE CMMI	PROGRAMMEUR	1 / 2 / finale
A	MARO	Erwan	SCRUM MASTER - MANAGER	PROGRAMMEUR	1 / 2 / finale
B	ALMAGUER	Jose	PROGRAMMEUR	PROGRAMMEUR	1 / 2 / finale
B	ELAIN	Thomas	PRODUCT OWNER - CLIENT	PROGRAMMEUR	1 / 2 / finale
B	TOULLEC	Brice	PRODUCT OWNER - TESTEUR INTEGRATEUR	PROGRAMMEUR	1 / 2 / finale
B	INFANTINO	Jean	TRACKER	PROGRAMMEUR	1 / 2 / finale
B	MARTIN	Jessy	QUALITE CMMI	PROGRAMMEUR	1 / 2 / finale
B	THUILLIER	Pierre	SCRUM MASTER - MANAGER	PROGRAMMEUR	1 / 2 / finale

Outils de suivi

• JIRA est un système de suivi de bugs, un système de gestion des incidents, et un système de gestion de projets. JIRA est associé à Confluence, un système d'information partagée par une équipe. Atlassian propose JIRA et Confluence gratuitement pour les projets open source, les organisations non commerciales et les projets éducatifs. Une Community Edition est aussi déployable dans un conteneur de servlet alternativement à la création de compte sur le nuage ;
• ICESCRUM, est un outil d'aide à la gestion de projet Scrum. Il est particulièrement apprécié pour la finition de son interface aboutie et originale et pour sa gratuité. On peut directement se créer un compte dans un nuage dédié ou télécharger une Community Edition qui est déployable dans un conteneur servlet comme tomcat ou jetty par exemple;
• TRELLO, utilisé par les deux équipes de développement en 2014-2015, est un outil de gestion de projet en ligne inspiré par la méthodologie Kanban de Toyota. Il est basé sur une organisation des projets en planches listant des cartes (tâches). Les cartes sont assignables à des utilisateurs et sont mobiles d'une planche à l'autre, traduisant leur avancement. Une meilleure adaptation à Scrum passe par l'extension chrome Scrum for Trello et par l'extension Burndown for Trello. La version de base est gratuite, tandis qu'une formule payante permet d'obtenir des services supplémentaires (workflow facilité, administration centrale, synchronisation Google Apps, invitations restreintes, exports, etc.). Aux Trello du projet pour la release 1, Trello du projet pour la release 2 et Trello du projet pour la release finale,s'ajoutent le Trello de l'équipe A et le Trello de l'équipe B.

Présentation SCRUM

En complément de la formation de Patrice Petit, voici une présentation en Creative Common. Pour la télécharger en version powerpoint ou Apache OpenOffice/LibreOffice car la traduction flash pose quelques problèmes d'affichage, voir les références plus bas.

Presentation SCRUM

Vocabulaire SCRUM

Une feature

Une feature est - comme sa traduction l'indique - une fonctionnalité; par exemple "Gérer les utilisateurs et leurs droits sur l'application".

Une userstory

Une userstory est un point particulier d'une feature. Cela pourrait correspondre à "Gérer l'authentification" - qui est une partie intégrée à "Gérer les utilisateurs et leurs droits sur l'application", ladite feature.

La roadmap ou timeline

Une roadmap est un planning découpé par des releases. Contrairement aux plannings des démarches prédictives, les charges de travail ne rentrent pas en compte.

La release

La release est un laps de temps de plusieurs mois, défini initialement avec le client. Il y en a donc plusieurs dans un projet. A chaque fin de release, une livraison d'une partie du projet pleinement fonctionnelle est à effectuer. Il est nécessaire de déterminer avant chaque début de release, les features qui devront être livrées.

Le sprint

Chaque release est découpée en sous-éléments que nous nommons les sprints. Selon le projet, un sprint est de 2 à 3 semaines. Pour chaque sprint, le client et l'équipe de développement dressent l'ensemble des tâches et des fonctionnalités à réaliser pendant cette période par rapport aux fonctionnalités à réaliser pendant ladite release.

Le backlog

Il s'agit d'un document qui énumère, classe et organise l’ensemble des features et des userstories que souhaite le client pour le projet.

Le product backlog

Un élément constitutif du backlog listant les fonctionnalités par ordre de priorité et par estimation relative des charges de travail. Le product backlog est créé en début de projet et est actualisé au cours du temps.

Le sprint backlog

Également constitutif du backlog, le sprint backlog énumère l'ensemble des fonctionnalités à réaliser pendant un sprint. Un sprint backlog est rédigé en accord avec l'équipe de développement et le client.

Références

• "L'extreme Programming avec deux études de cas",J.L. Bénard, L. Bossavit, R. Médina, D. Williams, Eyrolles, Paris, 2002, ISBN 2-212-11051-0.
• "Scrum et XP depuis les tranchées", 2007, traduction de "Scrum and XP from the Trenches", Henrik Kniberg (traducteurs : Guillaume Mathias, Bruno Orsier, Emmanuel Etasse et Christophe Bunn).
• "Scrum et XP depuis les tranchées - Version du Réalisateur", 2015, traduction de "Scrum and XP from the Trenches", Henrik Kniberg (traducteurs : Guillaume Mathias, Bruno Orsier, Emmanuel Etasse et Christophe Bunn).
• "Une introduction à SCRUM", traduction de "An Introduction to Scrum", Mike Cohn (traducteur : Claude Aubry)