Dark Scrum

Parlons un peu de “Dark Scrum”. Trop souvent, du moins dans le domaine du développement logiciel, Scrum semble opprimer les gens. Trop souvent, l’équipe Scrum ne livre pas assez rapidement, de manière aussi fiable, ou aussi régulièrement qu’elle devrait le faire. Et le plus souvent, ce sont les développeurs qui souffrent plus que quiconque.

Dernièrement, le thème qui me préoccupe le plus est le suivant :

Kent Beck, mon mentor “Agile” originel, m’a dit un jour qu’il avait inventé Extreme Programming pour rendre le monde plus sûr pour les développeurs. Il s’avère que le monde d’aujourd’hui n’est pas devenu plus sûr pour les développeurs que celui d’hier. Scrum peut vraiment devenir risqué pour les développeurs. Pour paraphraser Ken Schwaber, l’un des co-créateurs de Scrum, dans un autre contexte : “Cela me rend triste”.

Scrum, même lorsqu’il est seulement à peu près bien appliqué, est un bon cadre de travail. Je suis vraiment sincère quand je dis ça. Avoir une relation forte avec le métier pour décider de ce qui doit être fait, et de ce qui doit être différé, c’est bien. Avoir toutes les compétences nécessaires pour réaliser le produit dans l’équipe, c’est bien. Réaliser un produit tangible et testé toutes les deux semaines, le montrer aux parties prenantes, revoir comment les choses se sont passés, et comment les améliorer, c’est bien. Depuis des années, j’ai étudié, travaillé, et réfléchi à propos de Scrum et tout ce qu’il y a dedans est plutôt bien. Pas parfait, mais c’est plutôt bien, sincèrement.

Malheureusement, ça, c’est le concept Scrum, c’est l’idéal Scrum, c’est l’application de Scrum tel qu’il a été voulu. Comme pour toute bonne idée, la réalité est quelques fois plus rude. Parfois, elle est vraiment très rude. J’appelle ce résultat “Dark Scrum”¹.

Dark Scrum : Quelques abus typiques de Scrum

Jetons un coup d’œil sur comment les choses peuvent mal se passer mal avec Dark Scrum. Dans cette section, nous observerons une équipe souffrant du Dark Scrum. Les responsables Dark Scrum veulent bien faire : c’est juste qu’ils s’y prennent mal.

L’auto-organisation met du temps à venir

Soyons clair, cela prends du temps d’être bon en Scrum. Scrum amène avec lui de nouveaux rôles et de nouvelles activités. Encore plus difficile, il demande à ce que nous intégrions de nouvelles valeurs. Nous sommes supposés laisser les développeurs s’auto-organiser pour faire le boulot. C’est facile d’organiser des réunions Scrum et de nous appeler par les noms des rôles Scrum. Ce n’est pas du tout pareil de marcher vraiment dans ses pas.

Généralement Scrum commence avec très peu de personnes qui sont formées à Scrum, encore moins qui le comprennent et avec davantage de personnes qui pensent qu’elles savent ce qu’elles sont supposées faire. Cela ne devrait donc pas être une surprise si elles l’appliquent mal, et très souvent c’est ce qu’elles font.

Souvent, ceux qui détiennent le pouvoir ² aujourd’hui pensent que leur travail est de décider ce que leur personnel doit faire, de leur dire de le faire, et voir ce qu’il fait. Scrum enseigne autre chose : expliquer ce qui doit être fait, puis se mettre en retrait et laisser les personnes s’auto-organiser pour le faire.

Les personnes ne peuvent pas simplement passer en mode Scrum sur un simple claquement de doigts. Cela prends du temps de désapprendre les anciennes habitudes. Cela prends du temps d’acquérir de nouvelles habitudes, du temps pour apprendre à faire confiance à l’équipe. Cela prends du temps à l’équipe pour apprendre comment être prise au sérieux : d’une certaine manière c’est le message sous-jacent de cet article. La formation sur Scrum commence par ce processus d’apprentissage pour les gens qui reçoivent cette formation.

Le Dark Scrum commence lorsque les gens qui connaissent leur ancien travail, mais pas encore leur nouveau travail Scrum, commencent à faire les activités Scrum. Cela se passe alors comme ça :

Super, nous pouvons aider l’équipe tous les jours !

Chaque jour, l’équipe est supposée se retrouver et organiser le travail de la journée. Cette pratique, la “Mêlée Quotidienne”, est imposée à l’équipe Scrum type. Il y a sûrement une personne dans la pièce, le ScrumMaster, à qui on aura dit comment cela est censé se passer. Pas les développeurs. Assez souvent, même le Product Owner n’est pas au courant. Et de manière quasi systématique, les autres qui détiennent du pouvoir ne le sont pas non plus.

Mais celui qui détient le pouvoir lui connait déjà son boulot. Son boulot est de diriger ce qui est fait par tout le monde, d’être certain qu’ils font les bonnes choses, et de les recadrer s’ils ne le font pas. Comme c’est pratique qu’il y ait une réunion obligatoire où il peut le faire, et ça tous les jours de la semaine.

Le résultat : à la place d’avoir une équipe qui se mobilise sur sa mission commune et qui détermine une approche adaptée pour la journée, une personne externe leur arrache l’information, la fait mouliner dans leurs têtes et dit à chacun quoi faire. Étant donné que depuis la veille au soir, rien ne s’est passé comme prévu, l’approche malhonnête de cette réunion s’accompagne souvent de reproches et se déroule sous une certaine tension.

Tous les jours, le Dark Scrum opprime donc l’équipe. L’auto-organisation ne peut pas émerger dans de telles conditions.

Et il y a aussi une session fréquente de planification bien pratique !

Lors de chaque Sprint, le Product Owner Scrum est supposé rencontrer l’équipe, et décrire ce qui est demandé. L’équipe alors regarde ce qu’elle peut faire pour répondre à ces besoins, et commence à le développer. Eh bien, ça c’est la théorie. En pratique, il n’y a peut être même pas un Product Owner côté métier. Et même s’il y en a un, il y a de grandes chances qu’il n’ait pas été formé pour devenir Product Owner³.

Eh bien, ceux qui détiennent le pouvoir sont peut être novices en Scrum, ils n’en savent pas moins comment gérer ce type de problème. Donc toutes les deux semaines, ils se montrent et disent aux développeurs ce qu’ils doivent développer. Oh, les développeurs renâcleront. Ils sont paresseux, et récalcitrants. Mais ceux qui détiennent le pouvoir continueront à mettre la pression, parce que c’est comme ça que l’on gère le personnel. Ils disent donc à l’équipe ce qu’elle doit faire et qu’elle ferait mieux de le faire.

Bien sûr, ceux qui détiennent le pouvoir en savent très peu ou n’ont aucune idée sur comment développer et généralement les développeurs, eux, ont au moins quelques pistes. Ils n’ont aucune idée sur l’état actuel du code, les développeurs, eux, le savent généralement. Les développeurs sont supposés décider de la quantité de travail à prendre en charge en Scrum, mais en Dark Scrum, ceux qui détiennent le pouvoir savent mieux qu’eux bien sûr. Ils empilent les travaux à faire encore et encore. Ils voient cela comme faisant partie de leur boulot : piloter l’équipe.

Les résultats sont toujours les mêmes. L’équipe essaie sincèrement de faire ce qui lui est demandé. Elle sait qu’en aucune manière elle ne peut dire que c’est impossible, même si cela s’avère être le cas. Elle se ferait juste traiter de paresseuse, stupide, fauteur de trouble. Elle fait donc de son mieux mais ce n’est pas suffisant.

À la fin du sprint, les résultats ne sont pas ceux qui étaient demandés. La magie encore une fois n’a pas opéré. Les développeurs ont à nouveau échoué. Heureusement, nous avons justement encore une chance de les remettre dans le droit chemin : la revue du sprint !

Nous avons à critiquer ce qui est fait — et ce qui ne l’est pas.

Lors de chaque sprint les parties prenantes regardent ce que l’équipe a accompli et donnent des indications sur la manière d’aller plus loin. Bien belle théorie, rarement mise en en pratique lorsque les organisations ne sont pas expertes en Scrum.

En pratique, la Revue du Dark Sprint commence avec le rappel par quelqu’un à destination de tous les participants de ce que l’équipe avait “promis” de faire. (C’est-à-dire, ce qui a été demandé juste avant que l’équipe dise “Nous essaierons”. C’est une promesse, on est d’accord hein ?). Puis nous regardons le résultat minable que l’équipe a eu l’audace de nous présenter.

Et devinez quoi ? L’organisation a demandé plus que ce qui pouvait être fait et elle ne l’a pas eu. L’équipe a essayé, et en essayant, elle a pris tous les raccourcis auxquels elle a pu penser pour terminer toutes ces folles demandes. Elle a lésiné sur les tests. Elle a lésiné sur la conception. Elle a continué de travailler même quand elle était trop fatiguée pour penser correctement.

Elle a échoué et ce qu’elle a accompli n’était pas super. L’équipe a échoué. Encore.

Heureusement, le Dark Scrum a les détenteurs de pouvoirs, des Product Owners et des parties prenantes pour poursuivre cet effort. Et ils font en sorte que les développeurs soient bien conscients de leurs échecs.

Nous devons leur dire comment s’améliorer

Dans la Rétrospective du Sprint, l’équipe regarde en arrière sur le Sprint précédent, et sur l’histoire passée. Elle observe ce qui s’est bien passé et ce qui ne s’est pas bien passée. Elle détermine comment améliorer son processus pour la prochaine fois.

En pratique, les responsables Dark Scrum les aident dans cette démarche. Nous rappelons à l’équipe qu’elle a échoué, peu importe le degré de proximité avec lequel nous avons pu la manager. Nous faisons ressentir clairement aux développeurs que leur échec — et qu’il s’agit bien d’un échec — est clairement dû à une combinaison de paresse et d’incompétence.

Pour inciter l’équipe à faire mieux, nous pointons du doigt les conséquences de ne pas s’améliorer, ce qui inclura certainement quelques coupages de têtes. Ça attire toujours l’attention.

Quelques fois l’équipe proposera des suggestions. Laissez-moi donc vous donner quelques informations pour vous y préparer. Voici le genre de choses qu’ils pourraient dire, et comment vous pourriez y répondre.

Développeurs : Nous devons faire plus de tests pour diminuer le nombre d’anomalies.

Ceux qui détiennent le pouvoir : Non. Vous n’êtes déjà pas capable de finir les fonctionnalités. Vous devez coder plus intelligemment. Arrêtez de faire des anomalies et vous n’aurez pas à les corriger. Nous avons besoin de fonctionnalités, non de tests !

Développeurs : La conception commence à partir dans tous les sens. Nous devons refactorer pour l’améliorer.

Ceux qui détiennent le pouvoir : Non. Pourquoi avez-vous fait une conception de merde d’abord ? Personne ne vous a dit de faire une conception de merde. Arrêtez donc de faire ça et corrigez ce qui ne va pas. Le week-end arrive. Faites-ça à ce moment-là.

Développeurs : Les exigences ne sont pas claires, elles ne gagnent pas en clarté dans le temps, et par conséquent, tout que ce que nous avons construit est rejeté à la toute dernière minute.

Ceux qui détiennent le pouvoir : Nous vous avons embauché pour que vous agissiez intelligemment et pour déterminer ce qu’il y a à faire. Vous êtes supposés vous auto-organiser pour résoudre ce type de problèmes. Arrêtez d’être vissés le cul sur vos chaises et faites donc ce que nous vous disons de faire !

Vous voyez ce que je veux dire. Faites les trimer et mettez-les sur le grill. C’est toujours comme ça qu’il faut faire pour obtenir un logiciel. Scrum ne change rien à cela.

Eh ben, c’était déprimant

Oui, bien sûr, Scrum essaye vraiment de changer cela. Mais jusqu’à ce que les cœurs et les esprits de l’organisation changent réellement, il y aura encore trop de management à l’ancienne … et désormais cela se produit toutes les semaines … et bien trop souvent tous les jours de la semaine !

Qu’est ce que nous, développeurs, pouvons-nous faire ?

Ce qui se passe en Dark Scrum est clairement de l’abus. C’est en totale opposition avec ce que Scrum essaye de nous enseigner. Aucun véritable expert Scrum n’irait recommander aucune de ces choses-là. Les gens qui font ces choses-là ne font pas “les choses correctement”. Tout le monde est d’accord là-dessus. Néanmoins, le Dark Scrum existe, et il existe bien trop souvent. De mon point de vue, les abus sont presque toujours inévitables jusqu’à ce que les personnes apprennent vraiment les principes et les valeurs de Scrum.

Il semblerait bien que l’équipe soit dans l’incapacité de faire quoi que ce soit si ce n’est accepter cette oppression. Heureusement, ce n’est pas le cas. La bonne nouvelle c’est qu’il y a quelque chose de très fort que nous pouvons faire. La mauvaise nouvelle c’est que ce n’est pas facile. L’autre bonne nouvelle, toutefois, est qu’il s’agit essentiellement de développement et que nous sommes généralement assez bon à ça.

À l’origine d’une partie importante de la pression qui est mise par le Product Owner et/ou d’autres personnes qui ont du pouvoir est une absence de vision sur ce que nous sommes en train de faire. Si nous pouvons rendre parfaitement transparent⁴ l’avancement du projet, nous pouvons changer la manière dont nous sommes traités.

• Si le produit comporte beaucoup d’anomalies connues, notre hiérarchie supposera qu’il y en a encore plus, et ils auront peur. Sous l’effet de la peur, ils nous mettront encore plus de pression, et la peur se manifestant souvent sous la forme de la colère, ils seront en colère contre nous. Et souvent, très en colère.

• Si nous sommes en train de travailler sur la conception ou l’infrastructure avant de travailler sur les fonctionnalités, il semblera alors la livraison de ces dernières est plus lente. Cela a pour conséquence de faire craindre à nos responsables que nous serons en retard ou que nous échouerons à livrer des fonctionnalités importantes. À nouveau, nous sommes sujets à la peur et à la colère.

• Si nous sommes ralentis parce que notre conception nous lâche, nous produisons moins de fonctionnalités. Moins de fonctionnalités, plus de peur, plus de colère, plus de pression.

Quand l’encadrement ne peut pas voir un logiciel opérationnel, elle prend peur pour le futur — et avec raison. Elle montre cette peur, invariablement sous des formes qui ne nous aident pas vraiment, et qui sont généralement douloureuses. Les développeurs ne peuvent pas empêcher que cela se produise. La seule manière que je connaisse, c’est de livrer un logiciel. Un vrai, en chair et en os (manière de parler), logiciel opérationnel. Avec des fonctionnalités visibles !

Le pouvoir de l’incrément

Scrum nous demande de livrer un incrément du produit, testé, intégré, opérationnel et potentiellement livrable à la fin de chaque Sprint. Nous verrons d’ici peu comment faire cela. Pour l’instant, imaginons simplement que nous pouvons le faire : nous avons la capacité de livrer un incrément opérationnel du produit toutes les deux semaines.

Une bonne partie de la peur s’évanouira d’elle-même, parce que l’encadrement pourra voir de vrais résultats. Toutefois, toute la peur ne s’évanouira pas, car il est fort probable que les résultats réels seront en décalage par rapport à leurs espoirs et à leurs rêves. Tout le monde rêve d’une voiture de sport, mais parfois vous aurez seulement un vélo. Peut-être vouliez-vous un poney, mais que vous avez eu seulement un chien, et pas même un chat, ce que tout homme serait à même d’espérer. (Mais je digresse).

Toutefois, avec un incrément solide, testé, intégré, et contenant les fonctionnalités les plus importantes qu’elle nous a donné à faire entre nos mains, nous pouvons changer la conversation comme cela :

Ceux qui détiennent le pouvoir : Vous n’en avez pas fait assez : vous devez en faire plus.

Développeurs : Nous faisons tout ce que nous pouvons, et nous continuerons de nous améliorer. En attendant, tout ceci fonctionne et est utilisable. Il serait pertinent d’utiliser notre taux de livraison réel pour prédire la vitesse à laquelle nous allons. Il serait mieux de faire en sorte que nous puissions travailler sur les items les plus importants du backlog d’abord. Il serait mieux d’affiner chaque item afin qu’il soit le plus mince possible.

Cela ne va pas marcher du jour au lendemain par un simple coup de baguette magique. Mais cela donne un coup de pouce pour commencer, et plus l’incrément prendra forme concrètement, plus il aura d’influence sur les gens afin qu’ils regardent la réalité en face et basent leur management dessus. Contrairement à ce que nous pensons souvent, nos responsables ne sont pas stupides. Ils font de leur mieux avec les informations qu’ils ont. Si nous pouvons leur donner une meilleure information, sous la forme d’un logiciel qui fonctionne, ils commenceront à utiliser cette information. Munis de cette information, ils seront moins enclins à mettre la pression et commettront moins d’abus.

À nouveau, il n’y pas de magie et cela n’arrivera pas du jour au lendemain. Toutefois, j’ai déjà vu ce genre de choses arriver encore et encore. Et cela ailleurs que dans les organisations les moins organisées sur Terre — et seule une poignée d’entre vous, chers lecteurs, y travaillent — cela fonctionne, si nous nous y tenons.

Il y a un truc.

Il y a toujours un truc. Le truc ici est qu’afin de changer la conversation, afin de réduire la pression et les abus, l’incrément doit vraiment fonctionner. Il doit vraiment être testé, intégré, prêt à être livré, contenir tous les items du backlog que nous avons pris en charge.

Cela n’est pas toujours facile. Et c’est même pire, nous n’apprenons pas pendant les cours de programmation comment le faire. Nous n’avons pas appris en ingénierie logicielle comment le faire. Nous n’avons pas appris comment le faire dans les instituts de technologies de l’information, et nous ne le trouvons pas non plus dans Votre langage préféré pour les nuls. Il y a des pratiques qui sont faites toutes spécialement pour permettre aux équipes de faire un logiciel de manière incrémentale, en le gardant bien testé, bien conçu, focalisé sur les fonctionnalités, et prêt à être livré à tout moment.

Si nous changeons le Dark Scrum en Scrum tel qu’il devrait être mis en œuvre, nous devons apprendre ces pratiques. Heureusement, elles ne sont pas difficiles à acquérir, même si à l’image de la programmation, elles demandent de la pratique et du travail si nous voulons être bon dans leur utilisation. Plus loin dans cette série, nous les regardons plus en détails, mais regardons-en quelques-uns brièvement ici :

Tests d’acceptation

Il est assez habituel qu’il y ait des affrontements à la fin d’un Sprint, pour savoir si l’équipe a ou n’a pas fini ce que le Product Owner “voulait”. Ces affrontements sont stériles et tendent à diviser, le Product Owner d’un côté et les développeurs de l’autre. Nous voulons qu’ils travaillent ensemble de manière rapprochée, et non qu’ils se battent entre eux.

Une des pratiques les plus importantes est pour le PO et les développeurs de se mettre d’accord, sur des tests d’acceptations concrets et exécutables pour chaque story. Une manière productive de l’aborder est d’y penser comme à des “exemples”.

Équipe : OK, nous voulons que le système montre tous les comptes clients de l’entreprise qui ont 30 jours de retards de paiements avec le total des arriérés. Voici une table de comptes et une table montrant ce que cela pourrait donner pour les comptes identifiés avec la somme des arriérés.

PO : Non, ce n’est pas tout à fait ça. Nous ne les voulons pas à 30 jours, seulement au-delà de 30 jours.

Équipe : OK, comme ça alors ?

PO : Exactement ! Ça marche !

Chaque petit exemple devient un test d’acceptation pour la story ou pour l’item du backlog en question. Par convention, si les tests ne s’exécutent pas, alors l’équipe n’aura pas fini cette story. À contrario, si les tests s’exécutent, le Product Owner et l’équipe sont d’accord pour dire que ce qui a été fait correspond à ce qui a été demandé.

Il est possible, bien sûr, que le Product Owner n’apprécie pas ce qu’il voit. Mais à ce moment-là, la conversation aura changé. Il ne pourra pas dire légitimement “Ce n’est pas ce que je voulais”. C’est ce qu’il voulait lorsque nous nous sommes mis d’accord. Il a appris quelque chose et maintenant il veut quelque chose de différent. C’est quelque chose de normal tout simplement, c’est le boulot du PO de trouver sa voie pour avoir le meilleur produit possible. Travailler à partir de tests d’acceptation concrets nous aide à comprendre ce qui nous est demandé, nous aide à savoir quand nous avons fini, et nous aide à avoir quand nous avons affiner notre compréhension et quand demander à changer quelque chose.

Cadeau bonus important, quand nous automatisons ces exemples, nous pouvons tous les exécuter et montrer avec certitude que le produit continue toujours à faire ce sur quoi nous nous sommes mis d’accord qu’il devrait faire.

Conception incrémentale

Dans un projet Scrum, nous sommes supposés livrer un incrément du produit testé, opérationnel, potentiellement livrable après chaque Sprint. Il ne nous est pas possible évidemment de déterminer toute la conception dès le début : nous savons juste grosso modo ce que le produit pourrait être. De manière toute aussi évidente, nous devons arriver avec une bonne conception à la fin. Par conséquent, la conception de notre logiciel doit être faite de manière incrémentale, un bit à la fois.

C’est OK : lorsque le produit est encore balbutiant et incomplet, il ne nécessite pas besoin de bénéficier d’énormément de conception. Au fur et à mesure qu’il grandit, il a besoin d’une conception plus large, plus robuste et meilleure. Nous devons seulement augmenter le degré de conception au fur et à mesure que le produit grandit.

“Seulement”. Le mot le plus dangereux en développement logiciel. Élaborer la conception au fur et à mesure que nous avançons est difficile. Cela exige de la compétence en conception, de la compétence en test, de la compétence en refactoring. Nous allons explorer cela ci-dessous, et dans d’autres articles de cette série. En temps et en heure, nous vous fournirons des informations complémentaires sur ces sujets⁵.

Mais la vérité première reste : si nous voulons livrer un Incrément du Produit à chaque Sprint, nous devons trouver une manière de faire une bonne conception de manière incrémentale.

Refactoring

La meilleure voie que nous connaissons aujourd’hui pour faire de la conception incrémentale est se nomme “Refactoring”. Le refactoring est le processus d’amélioration de la conception du code existant — sans le casser !

Le refactoring n’est pas une réécriture. Il est certain que si nous avons un programme mal conçu, nous pouvons écrire un nouveau programme mieux conçu. Il est probable que je devrais dire ici “seulement écrire”, parce que ce truc marche rarement. Mais en principe nous pourrions. Cela prendrait toutefois beaucoup de temps et en Scrum nous n’avons pas beaucoup de temps : nous avons besoin d’une bonne conception en fin de sprint.

Le refactoring est un processus de transformation du code, généralement petits pas par petits pas, en vue de l’améliorer. Les environnements de développement modernes nous aident à faire cela : la plupart d’entre eux offrent un certain nombre de refactoring automatiques. Ils peuvent extraire un morceau code qui est utilisé fréquemment et le transformer en méthode ou en fonction. Ils peuvent déplacer le code d’une classe à une autre. Ils peuvent renommer des choses, ou changer la signature d’une méthode.

En utilisant bien le refactoring, nous pouvons améliorer incrémentalement notre conception au fur et à mesure que nous avançons. Toutefois, le mot clé ici est “bien”. Nous devons monter en compétence dessus.

L’amélioration incrémentale de la conception est indispensable. Le refactoring est la manière par laquelle nous accomplissons cela.

Tests faits par les développeurs

Nous avons besoin de tests faits par les développeurs en plus des tests d’acception. Chaque fonctionnalité que nous construisons est composée de plusieurs étapes de développement. À chacune de ces étapes, nous pourrions faire une erreur. Nous pouvons éviter ces erreurs avec des tests faits par les développeurs. L’une des meilleures formes de ces tests est le développement piloté par les tests que l’on peut résumer à peu près ainsi :

1. Pensez à la prochaine étape présente sur le chemin de notre fonctionnalité. Écrivez un test qui devrait s’exécuter lorsque cette étape est passée. Exécutez-le : vous devez être sûr qu’il ne passe pas pour l’instant.
2. Écrivez le code de telle manière à ce que cette étape soit passée. Exécutez le test : vous devez être certain qu’il passe à présent.
3. Vérifiez le code pour voir s’il vous paraît assez clair. Dans la négative, refactorez-le. Exécutez le test à nouveau pour être sûr que tout fonctionne toujours.
4. Répétez jusqu’à ce que la fonctionnalité soit terminée

Cela n’est pas la seule manière dont nous pouvons faire les choses, mais il s’agit d’une des meilleures que nous connaissons à présent. D’une manière ou d’une autre, il est très utile d’avoir beaucoup de petits tests supportant un test d’acceptation plus grand, parce que les petits tests nous disent sur quel morceau de code nous nous sommes trompés alors que le test d’acceptation nous indique seulement en hurlant “Y’a quelque chose de cassé !”

Ces tests nous aident aussi dans le cas de gros refactorings. Je suppose qu’un développeur expert en TDD ⁶ pourrait parfaire la conception pendant son cycle de TDD, mais mon expérience montre que parfois je ne remarque pas tout de suite une problème de conception. Quand cela arrive, je devrais peut être fournir un effort supplémentaire de refactoring la prochaine fois que je travaillerai avec ce code. De la même manière que nous avons développé une fonctionnalité, nos tests nous aident pour que nous soyons sûr que nous n’avons rien cassé lorsque nous changeons notre conception.

Intégration continue

Scrum exige d’avoir un incrément opérationnel, complètement testé, utilisable et contenant tous les items des backlogs des sprints précédents

Il est évident que cela demande que tous les travaux de l’équipe soient intégrés, testés et fonctionnent ensemble à la fin du sprint. Une intégration tardive révèle des problèmes, dont beaucoup d’entre eux demanderont un déboggage substantiel. Plus nous attendons, plus cela sera pire. À l’inverse, en intégrant après avoir fait plusieurs petites modifications, cela devient beaucoup plus facile.

Un processus d’intégration automatisé, exécutant la suite des tests système, s’avère être une part essentielle du processus de développement d’une équipe Scrum. Dans la plupart des équipes, plus l’intégration est faite fréquemment, mieux les choses se passent. Intégrer “tout le temps” semble être la meilleure chose, ce qui explique pourquoi cette pratique est appelée Intégration Continue.

Survivre au Dark Scrum

TL;PL

• L’étape du Dark Scrum reste assez répandue, et elle est d’ailleurs sans doute inévitable dans beaucoup d’implantations de Scrum
• Les situations de Dark Scrum suivent un schéma connu
• L’équipe de développement peut rendre les choses meilleures pour elle-même, et peut passer du Dark Scrum au vrai Scrum, qui est, quand même, un endroit bien plus agréable.

Si vous voulez apportez votre contribution sur ce sujet, écrivez-moi à l’adresse suivante ronjeffries at acm dot org.

Auteur : Ron Jeffries
Source : Dark Scrum
Date de parution originale : 8 Septembre 2016

Traducteur : Nicolas Mereaux
Relecteur : Claude Aubry
Date de traduction : 20/11/2016

Ce(tte) oeuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.