Frameworks agiles – Extreme Programming ou XP

Nous avons évoqué Kanban, son histoire et son implementation. Nous continuons notre série sur les frameworks agiles avec l’extreme programming (XP).

L’objectif de ce blog est de vulgariser l’agilité. Néanmoins, il est difficile, voire impossible de ne pas évoquer les termes techniques en XP.
N’hésitez pas à m’écrire en commentaire ou google concernant vos incompréhensions.

L’extreme programming est connu pour être un ensemble de pratiques pour les développeurs. On ne pourrait cependant être plus loin de la réalité.
Cette incompréhension est peut-être due a la manière dont le créateur Kent Beck l’a vendu au tout début. Cela ressemblait à un requiem pour la socialisation des développeurs.
Après m’être documentée pour l’écriture de cet article, je suis tombée amoureuse de la philosophie que je n’avais pas perçue.

Un peu d’histoire.

Kent Beck a créé l’Extreme programming, comme il aime si bien le raconter, sur le chemin d’une conférence avec des collègues à l’époque où il travaillait pour 3C en 1996. Oui, c’était avant la signature du manifeste agile. Kent en est d’ailleurs l’un des signataires. Fort de ses expériences dans différentes entreprises, Kent et d’autres personnages tels que Martin Fowler ont travaillé sur comment améliorer le développement logiciel. C’est ainsi que XP est né

XP est Un Style de développement logiciel axé sur une excellente application des techniques de programmation, une communication claire et un travail d’équipe qui nous permet d’accomplir des choses que nous ne pouvions même pas imaginer auparavant.

Kent Beck, Cynthia Andres. « Extreme Programming Explained – Embrace Change, Second Edition

Kent Beck décrit l’extreme programming comme: une philosophie de développement logiciel basée sur les valeurs; un ensemble de pratiques utiles et des principes.

Les Valeurs d’XP

 

Communication

« Une fois que vous trouvez un problème surprenant, la communication peut vous aider à le résoudre. Vous pouvez écouter les gens qui ont eu des problèmes semblables dans le passé. Vous pouvez parler en équipe pour vous assurer que le problème ne se répète pas. »

Kent Beck

La communication va créer une solidarité et une connexion dans l’équipe.

Simplicité

Quelle est la chose la plus simplifiée que vous pouvez livrer qui va répondre à la demande du client ?
« L’amélioration de la communication aide à simplifier les choses en éliminant les exigences inutiles ou différées des préoccupations d’aujourd’hui. La simplicité vous permet de communiquer beaucoup moins. » Kent Beck.

Feedback

Ne pas attendre d’avoir le produit parfait avant de livrer et recevoir un feedback. Durant le temps que cela prendrait de construire le produit parfait, il pourrait déjà avoir un changement dans les besoins du client.

Courage

Avoir le courage de dire ce qui ne va pas. Le courage de donner des estimations même si elles vont à l’encontre des deadlines. Avoir le courage de dire non à l’absence de qualité.

Respect

« Si les membres d’une équipe ne se soucient pas les uns des autres et de ce qu’ils font, XP ne fonctionnera pas. Si les membres d’une équipe ne se soucient pas d’un projet, rien ne peut le sauver. »

Kent Beck, Cynthia Andres. « Extreme Programming Explained – Embrace Change, Second Edition

Les principes d’XP

Je n’ai cité que celles qui me paraissaient intéressantes.

Humanité
La sécurité de base est d’être à l’abri de la faim, des blessures physiques et des menaces pour les êtres chers. Ainsi la peur de perdre son emploi menace ce besoin.
Le fait d’appartenir à un groupe permet de s’identifier à ce groupe.
Les membres du groupe reçoivent validation et responsabilités. Tout le monde contribue à des objectifs communs. Ainsi ils accroissent ainsi la possibilité d’élargir leurs compétences et leur perspective.  » Tous ensemble ».

Finance
Quelqu’un doit payer la facture des développements. Il faut donc s’assurer qu’on ne produit que des fonctionnalités à grande valeur ajoutée en respectant les budgets. Les budgets ne sont pas toujours  » élastiques ».

Gagnant- Gagnant
Dans XP, l’avantage mutuel consiste à chercher des pratiques qui sont avantageuses pour moi maintenant, pour moi plus tard et pour mon client également. C’est-à-dire faire des tests, faire du refactoring etc. Ce sont des pratiques qui bien que couteuses au départ apportent de la qualité et de la rapidité.

Amélioration
En XP on dira qu’il n’y a pas de conception parfaite pour les produits ou de stories parfaites. Par contre nous pouvons continuellement les perfectionner. Nous pouvons par contre perfectionner le design et les stories.

Diversité
XP promeut la diversité de profil et de culture. C’est ainsi qu’on découvre de nouvelles techniques et qu’on améliore les techniques existantes.

Réflexion
Les bonnes équipes ne se contentent pas de faire leur travail, elles réfléchissent à leur façon de travailler et à leurs raisons. Elles analysent pourquoi elles ont réussi ou échoué. Elles n’essaient pas de cacher leurs erreurs, mais de les exposer et d’en tirer des leçons. Personne ne naît dans l’excellence.

Flow
L’objectif est de livrer des fonctionnalités à un rythme constant afin d’être prédictible.

Responsabilité acceptée
La responsabilité ne peut être attribuée; elle ne peut qu’être acceptée. Si quelqu’un essaie de vous donner des responsabilités, vous seul pouvez décider si vous en prenez la responsabilité ou pas.
Les pratiques agiles sont indissociables de la responsabilité acceptée en suggérant, par exemple, que quiconque s’inscrit pour faire du travail l’estime également. La personne responsable d’une Story est responsable de la conception, de la mise en œuvre et de la mise en production de la story.

 

Les practices d’XP

 

S’assoir ensemble

Plus vous avez de temps en personne, plus le projet est humain et productif. Si vous avez un projet multisite et que tout va bien, continuez à faire ce que vous faites.
Si vous avez des problèmes, pensez à des façons de vous asseoir plus souvent ensemble. Même si cela signifie de voyager si vous êtes une équipe nationale ou internationale.

Une équipe

« Nous avons tous notre place, nous sommes dans le même bateau.Nous soutenons le travail, la croissance et l’apprentissage de chacun ».

Transparence et visibilité dans l’espace de travail

Toute personne qui vient dans l’espace de travail XP devrait pouvoir savoir où l’équipe en est dans le projet en 15 mins

Le rythme de travail

Ne travailler que le nombre d’heures pendant lesquelles nous pouvons être productifs.
En fait cette pratique milite contre le fait de faire travailler les équipes trop longtemps. À partir d’un moment, ils ne sont plus productifs et on en arrive à du « présentéisme ».

Le binômage ou pair programming

Travailler en binôme permet d’être focus, de brainstormer sur les améliorations du système et de clarifier des idées. Cela permet à un des membres du binôme de prendre l’initiative lorsque leur partenaire est coincé, ce qui réduit la frustration. Par ailleurs cela permet de se tenir mutuellement responsables des pratiques de développement de l’équipe.

Users stories (US) et estimations

Bien que beaucoup l’ignorent les US viennent d’XP. Il s’agit de planifier en utilisant des unités (story points) de fonctionnalité visibles par le client. On peut traduire User stories ou story par des histoires utilisateurs. L’expérience que l’on souhaite apporter au client.
L’estimation donne, aux perspectives commerciales et techniques ,une chance d’interagir. Ce qui permet de créer de la valeur tôt, en identifiant l’idée qui a le plus de potentiel. Lorsque l’équipe connaît le coût des fonctionnalités, elle peut diviser, combiner, ou étendre la portée en fonction de ce qu’elle sait sur la valeur des fonctionnalités.

Itérations d’une semaine

Il faut planifier le travail une semaine à la fois. Ensuite tenir une réunion au début de chaque semaine pendant laquelle l’équipe va examiner les progrès réalisés à ce jour. Y compris si les progrès réels de la semaine précédente correspondaient aux progrès prévus. Et finalement demander aux clients de choisir une semaine de stories à mettre en œuvre cette semaine. L’équipe devra diviser les stories en tâches. L’équipe s’engage sur les tâches et les évalue.

Ce principe est passé d’une durée de 3 semaines pour une itération en 1999 à 1 semaine en 2004.

Prendre le temps de respirer

On peut structurer le repos/recul de plusieurs façons. Une semaine sur huit pourrait être la « Geek Week ». 20% du budget hebdomadaire pourrait être consacré aux tâches choisies par les programmeurs.
Chaque membre de l’équipe devra peut-être commencer par lui-même, en se demandant combien de temps il pense qu’une tâche prendra et en se donnant le temps de la faire « bien ». Même si le reste de l’organisation n’est pas prêt pour une communication honnête et claire.

Déployer en 10 min

Il est important d’intégrer son changement avec ceux de nos collègues afin de vérifier que le nouveau développement n’apporte pas de régression.
XP préconise de déployer automatiquement tout le système et exécutez tous les tests en dix minutes. Par ailleurs, un déploiement qui prend plus de dix minutes sera utilisée beaucoup moins souvent. Ce qui diminue les opportunités de rétroaction et de correction s’il y a un problème.

Intégration continue

L’étape d’intégration est imprévisible, mais peut facilement prendre plus de temps que le développement. Donc plus on attend pour intégrer les développements ensemble, plus cela coûte cher et plus le coût devient imprévisible.

Test development driven (TDD) ou test-first design

Une des méthode créée par Kent Beck est d’écrire les tests unitaires (codes) et les tests d’acceptation (utilisateurs) avant d’écrire la moindre ligne de code. Il s’agira ensuite de développer en essayant de faire passer un test après l’autre jusqu’à ce que tous les voyants soient verts. On s’assure de ne construire que ce dont on a besoin.

Faire du design en continue et du Refactoring

Il faut investir dans la conception (design) tous les jours. Plus précisément il faut s’efforcer de faire en sorte que la conception réponde parfaitement aux besoins du système du jour. Ne pas sur-designer des futurs besoins.
Le refactoring est une technique qui permet de restructurer le code existant. Il s’agit de modifier sa structure interne sans changer son comportement externe. XP conseille de faire du design et du refactoring tous les jours.

 

Les rôles en XP

 

Les attentes d’XP concernant des potentiels rôles:

Les clients/Utilisateurs d’une équipe XP aident à rédiger et à choisir des stories. Ainsi qu’à prendre des décisions sur le produit pendant le développement.
Les utilisateurs sont particulièrement précieux s’ils ont une vaste connaissance ainsi qu’une vaste expérience des systèmes semblable à celui en cours de construction. Encore plus s’ils ont des relations solides avec la communauté des utilisateurs qui utiliseront le système une fois qu’il sera entièrement déployé.

Les product managers or Product Owners d’une équipe XP écrivent des stories, choisissent des thèmes et des stories à implementer trimestriellement. Ainsi que celles qui doivent être développées chaque semaine. Ils répondent à des questions au fur et à mesure que l’équipe pendant la mise en œuvre découvre informations ou points de blocage.
Ils ne se contentent pas de choisir un tas stories au début du projet, puis se reposent. La roadmap en XP est un exemple de ce qui pourrait se produire, et non une prédiction de ce qui se produira.

Les Business Analystes côté technique sont ceux qui fournissent les premiers feedbacks à l’équipe de développement. Ils voient les fonctionnalités lorsqu’elles ne sont qu’à l’étape de brouillon et rédigent des explications sur les fonctionnalités pour les clients. Ils ont aussi la responsabilité d’être en contact étroit avec le client, ceci afin de comprendre leurs besoins au fil des feedbacks et de les aider dans la rédaction des stories.

Les concepteurs d’une équipe XP écrivent des stories et évaluent l’utilisation du produit pour trouver de nouvelles stories.
Répondre aux préoccupations des utilisateurs éventuels est une priorité pour l’équipe.
Les outils de conception des interactions tels que les personas (construction d’un profil client), aident l’équipe à analyser et à donner un sens au monde de l’utilisateur. Bien que cela ne remplace pas une conversation avec de vrais clients.
 
Les développeurs estiment les stories et les tâches. Ils divisent les stories en tâches, rédigent des tests, écrivent du code pour mettre en œuvre les fonctionnalités. Les développeurs automatisent le processus de développement et améliorent graduellement la conception du système. Ils travaillent avec tous les corps de métier liés au développement logiciel et doivent donc acquérir de bonnes compétences sociales et relationnelles.

Les architectes d’une équipe XP recherchent et exécutent des refactorings à grande échelle. Aussi ils rédigent des tests au niveau du système qui mettent l’accent sur l’architecture et mettent en œuvre les stories.

Les testeurs d’une équipe XP aident les clients à choisir et à rédiger des tests automatisés au niveau du système avant la livraison du produit. Par ailleurs, ils encadrent les programmeurs sur les techniques de tests.

Les chefs de projet (Project managers) d’une équipe XP facilitent la communication au sein de l’équipe et coordonnent la communication. Ils maintiennent la communication avec les clients, les fournisseurs et le reste de l’organisation. Aussi ils agissent à titre « d’historiens », rappelant à l’équipe les progrès qu’elle a réalisés.
 
Le leadership, les parties prenantes, les sponsors apportent courage, confiance et responsabilité à une équipe XP.
 Et si l’objectif de l’équipe ne correspond pas aux objectifs de l’entreprise? Que faire si le but dérive en raison des pressions et des excitations du succès? 
Définir et maintenir des objectifs à grande échelle est une tâche importante pour ceux qui parrainent ou supervisent des équipes XP. Une des responsabilités de ceux qui parrainent ou supervisent des équipes XP consiste à surveiller, encourager et faciliter leur amélioration.

Le coach remarque les goulots d’étranglement dans la communication et s’en occupe. De plus il motive les équipes afin qu’elles utilisent les pratiques XP. Il incarne des valeurs et des pratiques efficaces.
Le coach est responsable du processus dans son ensemble. Il s’assure de maintenir le travail de l’équipe à un rythme durable et veille à ce qu’ils continuent de s’améliorer.
Un coach n’est pas indispensable en XP. Certaines transformations ont réussi sans coach. Il peut néanmoins être d’un grand soutien en fonction de la culture de l’entreprise ou de la maturité de l’équipe.

 

Les rôles au sein d’une équipe XP mature ne sont pas fixes et rigides. L’objectif est que tout le monde puisse apporter ce qu’il a de mieux à offrir pour le succès de l’équipe. Au début, des rôles fixes peuvent aider à apprendre de nouvelles habitudes. Comme par exemple le fait que les lead techniques prennent des décisions techniques et que les business prennent des décisions sur ce qu’il faut construire.
Après l’établissement de nouvelles relations mutuellement respectueuses entre les membres de l’équipe, des rôles fixes interfèrent avec l’objectif de faire de son mieux. Les programmeurs peuvent écrire une story s’ils sont dans la meilleure position pour écrire une story. Les managers de projet peuvent proposer des améliorations architecturales s’ils sont les mieux placés pour le faire.

Kent Beck

Par ailleurs, il ne s’agit pas d’un rôle pour une personne. Des personnes peuvent avoir plusieurs casquettes. Ils doivent juste être en capacité de le faire et d’en assumer les responsabilités.
Kent Beck met l’accent sur les ressources humaines comme un élément indispensable de la réussite. Ils doivent par exemple être capable de recruter et d’évaluer les membres qui correspondent aux valeurs et principes XP

Aujourd’hui Kent Beck lance une nouvelle méthode de gestion de projet basée sur son expérience chez facebook et les retours d’expérience d’utilisateurs de l’extreme programming appelé 3X: Explore, Expand, Extract. Ci-dessous la video pour en savoir plus (en anglais).