Quelque chose que je trouve vexant depuis un certain temps, c’est la fréquence à laquelle beaucoup dans l’industrie utilisent des termes comme » Scrum mais …. » dans un sens péjoratif, impliquant que les équipes ne devraient suivre que le petit ensemble de pratiques qui font partie de Scrum. En réalité, pour qu’une équipe Agile soit en mesure de fournir de manière répétée des logiciels fonctionnels sur une période de temps significative, Scrum ne suffit pas. Qu’elles le réalisent ou non, la grande majorité des équipes qui s’appellent elles-mêmes des équipes Scrum fonctionnent comme un hybride Scrum-XP, ou un hybride Scrum-Kanban-XP, où elles emploient au moins un sous-ensemble des pratiques techniques qui proviennent de XP.
Laissez-moi aller sur l’enregistrement et dire que les équipes qui suivent seulement les pratiques Scrum ont peu de chances de réussir à long terme, parce qu’au moins un sous-ensemble des pratiques techniques XP sont un must pour le succès continu en tant qu’équipe de livraison Agile.
J’ai observé qu’il n’y a pas assez de personnes qui comprennent ce que Scrum inclut et n’inclut pas, alors commençons par là.
Ce que Scrum est – un ensemble de pratiques de gestion
Scrum est l’application du contrôle empirique du processus, ce qui est une façon fantaisiste de dire que nous devrions prendre des décisions basées sur l’expérience, et non sur un ensemble hypothétique d’hypothèses qui ne sont pas fondées sur la réalité.
Simplifié, Scrum consiste en un petit ensemble de pratiques de gestion qui visent à aider les équipes à collaborer efficacement et à livrer le travail de manière itérative (permettez-moi d’insister une fois de plus – il y a zéro pratique technique dans Scrum).
Pour résumer brièvement le contenu du guide Scrum :
- Il y a une équipe Scrum, qui est composée de développeurs, du propriétaire du produit et du Scrum Master.
- Il y a des événements Scrum, qui se composent du Sprint, de la planification du Sprint, du Scrum quotidien (alias Daily Standup, dans XP), de la revue du Sprint et de la rétrospective du Sprint.
- Il y a des artefacts Scrum, qui consistent en le Backlog de produit, le Backlog de sprint et l’Incrément, où un Incrément existe dès qu’un élément du Backlog de sprint répond à la définition de Done.
- Il y a une définition de Done, où toute équipe Scrum a une compréhension partagée de ce que « done » signifie pour tout élément du Backlog de produit. Notez que, contrairement aux critères d’acceptation, la définition de Done est appliquée globalement, tandis que les critères d’acceptation sont spécifiques aux éléments individuels du Backlog de produit.
Ce que Scrum n’est pas
Contrairement à la croyance populaire, aucune des choses suivantes ne fait partie de Scrum:
- User stories. Les éléments de travail dans le Backlog de produit ou le Backlog de sprint d’une équipe Scrum donnée sont rédigés comme des user stories (souvent sous le format « En tant que <personne/rôle>, je veux <but>, afin que <résultat souhaité> »), mais Scrum n’impose aucune construction ou format particulier. Notez que les user stories font partie de XP.
- Estimation. Même si la grande majorité des équipes Scrum effectuent une estimation à un certain niveau, la pratique de l’estimation ne fait pas partie de Scrum.
- Vélocité. La vélocité ne fait pas non plus partie de Scrum ; la notion de vélocité du projet fait partie de XP.
- Pratiques techniques. Comme indiqué ci-dessus, il n’y a pas de notion de pratiques techniques (CI, CD, programmation en binôme, TDD, etc.) dans Scrum. La grande majorité des pratiques techniques que les équipes suivent généralement proviennent de XP.
Qu’est-ce que l’Extreme Programming?
Il y a plus de deux décennies que la première équipe d’Extreme Programming (XP) a été formée, où elle a travaillé sur un projet appelé Chrysler Comprehensive Compensation (C3). Les méthodes que l’équipe a employées proviennent en grande partie des années 1980, lorsque Kent Beck et beaucoup d’autres expérimentaient de meilleures façons de développer des logiciels, c’est-à-dire une alternative à l’approche « waterfall » qui était devenue dominante à cette époque.
Rendre le travail visuel a toujours été un moyen important d’informer la façon dont les équipes Agile travaillent. Par conséquent, en tant qu’introduction à XP, je recommande que toute personne souhaitant en savoir plus serait bien servie en commençant par ces diagrammes :
- Projet de programmation extrême (diagramme de bout en bout)
- Itération (diagramme se concentrant sur ce qui se passe à l’intérieur d’une itération ; notez que ce que XP appelle une itération est conceptuellement similaire à ce que Scrum appelle un Sprint)
- Développement (diagramme se concentrant sur les interactions et les activités de développement)
- Propriété collective du code (diagramme se concentrant sur les pratiques techniques de base)
Note : Pour un visuel qui combine plusieurs des éléments des diagrammes ci-dessus sur une seule page, voir l’aperçu de l’Extreme Programming de Bill Wake.
Lectures supplémentaires sur XP
Si les visuels ci-dessus vous intriguent suffisamment pour vouloir en lire plus sur XP, consultez les sources d’information suivantes, qui sont listées plus ou moins dans l’ordre du plus court à lire > plus long à lire :
- Don Wells, Extreme Programming : a gentle introduction
- Martin Fowler, BeckDesignRules (voir aussi Xp Simplicity Rules)
- Kent Beck, Ward Cunningham, et al., Pratiques de base de l’Extreme Programming (alias les 12 XpXtudes)
- Don Wells, Les règles de l’Extreme Programming
- Ward Cunningham, et al.,Extreme Programming (alias le WikiWikiWeb)
- Ron Jeffries, Qu’est-ce que l’Extreme Programming?
- Kent Beck &Cynthia Andres, L’Extreme Programming expliquée : Embrasser le changement (2e éd.)
Références supplémentaires
Toutes les références de cette section proviennent du site Web XP de Don Wells, sauf indication contraire.
- Les modèles agiles sont des peintures, pas des photographies (tous les modèles sont faux ; certains sont utiles)
- Proverbes du processus agile (des mots pour toute équipe à vivre)
- Bill Wake, Arrange, Act, Assert (patron pour écrire des tests unitaires)
- Bill Wake, Sudoku Solver (variation intéressante sur TDD)
- Bill Wake, Tests from a Hat (une approche créative vers l’écriture de tests unitaires)
- Des plans honnêtes (à quoi ressemble l’estimation en pratique)
- Gérez vos objectifs plutôt que vos activités (principales différences entre le développement Waterfall et Agile)
- Les valeurs de l’Extreme Programming (Simplicité, Communication, Feedback, Respect, Courage)
- XP et les bases de données (un modèle basé sur les bases de données or > argent > bronze )
.