Pyxis

Pendant un planning d’itération, il est commun de demander à l’Equipe de fixer/choisir/établir son “engagement”. Et la plupart du temps, le comportement attendu consiste à choisir un ensemble de fonctionnalités à livrer au client à la fin de l’itération qui commence ce jour là.

Dans Scrum, ce rituel de planning se répète à chaque commencement d’itération.

Pendant l’itération, c’est le temps de la réalisation. C’est là que les artistes-artisans informaticiens réalisent le miracle de leur art pour livrer un morceau de logiciel d’une qualité exceptionnelle. Hum… Mais au fait, c’est quoi pour vous la Qualité ? Autour d’un café on devrait probablement s’entendre sur le fait que des professionnels de l’informatique devraient livrer des logiciels de qualité. Voire, que leur “engagement” a quelque chose à voir avec “livrer un logiciel de qualité”.

Durant les dix dernières années, une technique appelée TDD s’est développée. J’imagine que vous connaissez ça très bien, ainsi que sa représentation la plus populaire :

La couleur pour le côté du refactoring est parfois le vert pour exprimer que pendant une opération de refactoring, “les tests passent toujours”. J’ai pris ici le gris surtout parce que sur ma magnifique casquette tdd, le refactoring est en gris.

Mais au fait : quelle est la vocation du refactoring ? Parce que si le test passe, je pourrais livrer le code et n’en parlons plus ! Bien sûr la plupart du temps le logiciel n’est pas fini ; il faut continuer. Pour pouvoir continuer, on met à profit ce temps de refactoring pour transformer le code que l’on a écrit à la va-vite pour faire passer le test en un “code de qualité”. L’objectif semble donc être la qualité. Autrement dit, l’artiste-artisan informaticien professionnel construit un code de qualité pendant le refactoring. Encore autrement dit : l’artiste-artisan informaticien respecte son engagement de qualité pendant le refactoring.

Maintenant si je dessine le cycle du TDD plutôt comme ça, est-ce que vous me voyez venir ?

En mélangeant les notions d’engagement du planning d’itération et de refactoring du tdd, on pourrait vivre la situation suivante : pendant un planning d’itération, l’Equipe considère les premiers éléments de carnet de produit, écrit les tests et les fausses implémentations qui font passer les test, et réfléchit à son engagement : quel part du code écrit pendant le planning pouvons-nous transformer en code de qualité pendant l’itération ? Par exemple pendant le planning on a fait passer 4 tests mais notre engagement ne couvre que la livraison du code faisant passer les 3 premiers.

Cette approche met au premier plan les notions de qualité et de professionnalisme des équipes on affichant que la valeur des professionnels de l’informatique va se chercher pendant le refactoring. “Pisser du code” ne s’appliquerait plus qu’au code écrit le plus vite possible pendant le planning pour faire passer les tests, pas au code que l’on livre.

En y pensant un moment, il nous est apparu que dans beaucoup de sociétés autour de nous, sociétés de services entre autres, il y avait des consultant en inter-contrat et que “gérer” ces personnes était pour certaines un petit casse-tête. Une des préoccupations souvent évoquée est comment profiter du passage en inter-contrat pour améliorer les compétences des personnes concernées ?

Il y a quelques temps j’ai appelé un ami dans une de ces sociétés et je lui ai proposé de venir animer un coding-dojo pour tous les consultants en inter-contrat de son service. Je me rappelle que lorsque que je lui proposé cela, il a tout de suite été emballé et m’a dit “demain ?”.

Ils m’ont accueilli fin septembre pour animer un coding-dojo randori chez eux et les participants en redemandent. C’était la première fois qu’ils participaient à un coding-dojo alors nous avons dédié 30 minutes, sur les 4 heures, à en parcourir les principes et le fonctionnement. Je me suis limité au rôle d’animateur et de coach TDD. Le soir cela me manquait de ne pas avoir touché le clavier .

Si vous aussi vous avez des inter-contrat et que l’expérience vous intéresse, appelez-nous !

Ce que je tente d’expliquer pendant les cours de Test-Driven Development (TDD) c’est que le TDD est une approche générique pour aborder un développement logiciel.

“Malheureusement”, quand on lit “TDD”, on comprend souvent tests “unitaires”. Sans doute parce qu’historiquement les premiers tests écrits en suivant cette approche ont été des tests “unitaires”. Mais le concept peut se voir plus globalement.

Par exemple si on ne prend les deux cours suivants proposés par Pyxis:

• Test-Driven Development
• Specifications exécutables avec GreenPepper

Le premier propose des ateliers d’écriture de tests automatiques écrits avec un framework xUnit alors que le second se concentre sur l’écriture de tests automatiques écrits avec GreenPepper. En lisant plusieurs forums je réalise que certains contributeurs classeraient sans doute naturellement le premier dans une case TDD et le second dans une case DDD, voire BDD. En fait les deux cours appartiennent à la catégorie TDD.

“Test-Driven” est seulement une autre manière de dire : définissons ce que nous attendons sous la forme d’un test. Pour moi – je suis ScrumMaster – cette approche est similaire à avoir une définition de “terminé”. Cette façon de nous exprimer pourrait d’ailleurs nous emmené sur plusieurs branches si nous poursuivions l’analogie avec Scrum. Quel est votre fil de penséé ? tests->liste de tests->backlog de tests->specifications exécutables->Product Backlog ?

Bien sûr, en premier lieu, un ScrumMaster est convaincu de la valeur de Scrum en tant que prisme à travers lequel il appréhende les évènements, les situations.

Scrum est très simple à décrire et très difficile à mettre en oeuvre.

Un bon ScrumMaster comprend en quoi Scrum est difficile. Défis humains, défis organisationnels, défis techniques. Lesquels seront les plus pénalisant pour le projet ? Cela dépendra des contextes. A chaque projet cela sera différent, plein de surprises, enrichissant.

Un bon ScrumMaster aide tout le monde à tirer le meilleur profit de Scrum. Au delà de sa connaissance pointue de Scrum, la forme de cette aide peut varier du tout au tout selon les contextes. Un bagage technique aidera-t-il à déceler une incompréhension entre deux membres d’équipe ? Peut être. Une attitude enjouée favorisera-t-elle la motivation pendant les mois d’hivers ? Peut être. Un naturel curieux permettra-t-il d’apprendre par hasard une information capitale à la machine à café ? Peut être. En se concentrant sur les aspirations personnelles des gens, un ScrumMaster aidera-t-il à favoriser le climat de confiance si chère à l’émergence d’une équipe auto-organisée ? Peut être. Peut être cette fois-ci. Sans doute pas à chaque fois.

Aspirer à ce que tout le monde tire le meilleur profit de Scrum c’est aussi reconnaître que Scrum ne se met pas en place en 1 jour. Patience. Gardons-nous de juger hâtivement un ScrumMaster en regardant “son” Scrum sans lui en parler. Il a sans doute lui aussi un backlog d’adoption, une stratégie incrémentale de mise en place des pilliers de Scrum, qui sont comme une petite musique dans sa tête :
- équipe auto-organisée
- backlog priorisé
- livraison d’incréments terminés à chaque fin d’itération
- processus empirique

J’ai pas mal souffert pour utiliser des variables et faire des calculs dans Selenium IDE. Et finalement j’ai fini par découvrir la commande assertEval qui m’a sauvé la vie

On nous demande souvent “Quels outils faut-il pour faire du Scrum ?”. Parfois un mur et des post-it peuvent faire l’affaire. D’autres fois l’Equipe et le Product Owner ne sont pas sur le même site ; au moins pas tout le temps. Alors on a envie d’avoir un outil pour partager les backlogs.

Read more…

Scrum est née au cours de année 90 en réaction aux problématiques de gestion rencontrées par les projets de développement logiciel. Scrum est une approche agile de gestion de projet. En tant qu’approche agile, Scrum intègre les préocupations prioritaires des approches agiles. A savoir mettre les individus et leur intéractions au centre de tout, privilégier le logiciel fonctionnel, la collaboration avec le client et la réponse au changement en cours de projet.

Read more…

Une équipe Scrum est constitué d’un Product Owner, d’une Equipe de réalisation et d’un ScrumMaster (A distinguer de l’Equipe d’un Scrum). Chercher les pré-requis d’une équipe Scrum nous impose de bien comprendre ce qu’est Scrum. Considérant que la compréhension de Scrum est partagée, nous pouvons chercher des pré-requis dans ses règles de fonctionnement.

Read more…

Scrum propose de confier la responsabilité des priorités et du retour sur investissement à une seule et même personne. Cette personne doit avoir l’autorité d’exercer cette responsabilité dans son organisation. L’unicité de cette personne est là pour empêcher les indécisions pour raison de conflit entre plusieurs intérêts contradictoires.

Cela ne veut pas dire que cette personne soit seule au monde. Un Product Owner peut s’entourer d’une équipe qui l’aide dans ses prises de décisions. De fait de nombreux Product Owner le font dans le cas de produits complexes, difficiles à appréhender par un seul individu.

Cette question revient souvent, que ce soit pendant les formations Scrum, ou bien pendant des missions d’accompagnement pendant lesquelles la question émerge naturellement chez les chefs de projets qui voient leur organisation mettre en place Scrum.

Read more…