SCRUMMOU

Après Ken Schwaber, Jim Shore, Alan Shalloway, c'est Martin Fowler qui dénonce la pratique de Scrum sans l'ajout de solides pratiques techniques. Le titre "Flaccid Scrum" de son billet illustre avec humour son propos.

Pour les références sur ce thème, consultez les propos de:

• Ken Schwaber: conférence chez Google et conférence Canary In A Coalmine
  

• Jim Shore: The Decline and Fall of Agile
  


• Alan Shalloway: Is Scrum Failing Us?

• Martin Fowler: Flaccid Scrum
  

Pour aller plus loin, je pense même qu'en plus de solides pratiques techniques (TDD, test-first, intégration continue, programmation par contrat), le développement itératif et incrémental exige une augmentation significative de la maturité en génie logiciel au sens large.

Par exemple, l'application des principes avancés de conception tels

• Open Closed Principle,
• Liskov Substitution Principle,
• Command Query Separation,
• Single Responsibility Principle,
• Dependency Inversion Principle,
• Interface Segregation Principle,
• Common Closure principle,
• Acyclic Dependencies Principle,
• Stable Dependencies Principle et
• Stable Abstractions Principle

aide à construire des logiciels extensibles. En fait, je pense que le pilotage par les tests suffit, mais la combinaison avec le respect de ces principes permet de développer encore plus vite. ll en est de même pour l'utilisation des design-pattern du GoF (voir billet Où sont les GoF?).

Pour découvrir ces grands principes de génie logiciel lisez le livre d'Uncle Bob et/ou consultez le dossier établi par Régis Médina.

Puisque j'ai évoqué le conférence Canary In A Coalmine de Ken Schwaber, voici le titre de Police en dédicace pour Claude Aubry ;o)

Découvrez The Police!

LES TESTS SONT DU CODE

LA SOUPLESSE GAGNÉE

L'Extreme-Programming est une sacrée aide. Grâce au TDD, au remaniement et à la conception simple, nous arrivons à mettre au point des logiciels ayant une architecture extensible. Nous ajoutons des incréments de fonctionnalité au fil des itérations. Les tests de recette et les tests développeur sont un tuteur qui aident le logiciel à pousser et un filet de sécurité contre les régressions. Ils permettent au logiciel de conserver sa souplesse, celle du SOFTware .

Nous pratiquons le TDD et le test-first. La couverture du code par les tests est intégrale. De plus, ayant les contraintes de sûreté de fonctionnement du logiciel critique, nous ne lésinons pas sur les cas de tests.

D'ailleurs, en démo nous nous livrons à un petit exercice. Nous proposons au client d'introduire un défaut dans la base de code et nous lui montrons que la suite de tests détecte sa modification.

Depuis plusieurs projets, nous constatons que nous avons plus de deux fois plus de lignes de code de test que de lignes de code de production. Étant donné qu'il faut vérifier de nombreux scénarios, le code des tests est souvent assez répétitif.

Vous voyez où je veux en venir?

LA SOUPLESSE PERDUE

Cette masse de tests est là en partie pour conserver la souplesse du logiciel testé. Elle est un tuteur construit autour de l'application. Mais si nous ne faisons pas très attention, cette masse de tests devient inflexible.

Tous ces cas de tests si ressemblants sont autant de mauvaises occasions de dupliquer du code. Tous ces mocks et tous ces stubs aux comportements légèrement différents doivent tous évoluer si leur interface de base est amenée à changer. Pour modifier une ligne de code de production nous en arrivons à devoir changer plus de 10 lignes de code de test. Le code des tests tend naturellement à devenir une masse pénible à faire évoluer. Les tests deviennent inflexibles. Le tuteur est devenu un massif baobab. Le logiciel perd alors sa souplesse d'évolution parce que les tests sont devenus inflexibles. Avec de bonnes intentions nous avons rendu l'application inerte. Elle a perdue sa souplesse parce que l'échafaudage qui l'enrobe est devenu un gros sac de nœuds.

LA SOUPLESSE GAGNÉE (BIS)

Heureusement, ce constat n'est pas une fatalité. Nous avons de la chance car les tests sont aussi du code. Nous devons donc porter au code des tests le même soin qu'au code de production. Les standards de codage s'appliquent au code de production et au code des tests. Nous devons systématiquement remanier le code des tests pour en éliminer les duplications, en réduire le volume et le rendre clair et expressif.
Il existe une architecture des tests. Si une classe hérite d'une autre alors son test unitaire hérite du test unitaire de la super-classe. Ainsi, nous rejouons des tests hérités sur une instance fille. Ceci nous permet de vérifier le si puissant Principe de Substitution de Liskov.
En remaniant les tests, nous devons faire bien attention à ne pas les faire régresser. Ceci est d'autant plus délicat que le code des tests est écrit sans tests! Quoique nous pouvons assimiler le code testé au test des tests (vous me suivez toujours?). Modifiez un test et vous aurez peut-être la chance de le voir échouer s'il n'est plus en cohérence avec le code testé. Ceci ne marche malheureusement pas si la modification du test l'a rendu plus permissif ...

En tout cas, ce qui est génial, c'est que tester c'est coder!

ET ROCK'N ROLL

Cette année, Claude Aubry a rebaptisé son blog Scrum, Agilité et Rock'n Roll. Il explique pourquoi dans un billet publié ce mois-ci. Je trouve son rapprochement entre les démarches agiles et l'esprit de rébellion très pertinent. Je rebondis sur son billet car je reconnais notre équipe dans ce qu'il décrit.

L'esprit de groupe est très prononcé dans notre équipe. Nous avons notre lieu, nos rythmes de travail, nos pratiques, nos rituels et notre réputation. Tout ce folklore créé et renforce l'identité de l'équipe.

L'équipe a le sens du rythme. Les itérations sont mensuelles, le build complet est journalier, le stand-up-meeting de 10 minutes (max) est quotidien et les réunions sont timeboxées avec des minuteurs.

La démarche de travail est brut de fonderie. Tout ce qui n'apporte pas de valeur est supprimé. On élimine les stocks en travaillant en flux continu et tendu. La durée des réunions est bornée.

L'équipe est toujours en concert. Elle enchaine des itérations de durée fixe devant son public. A la fin de chaque morceau, lors de la démonstration, elle espère les applaudissements du client.

L'esprit de rébellion est aussi très prononcé. Obstinément, l'équipe remet en cause les habitudes inefficaces et cherche à éliminer les gaspillages. Changer pour mieux faire est un acquis. Cet esprit est même officialisé par la rétrospective d'itération.

Se rebeller demande du courage. Il en faut lorsque l'équipe se heurte à une organisation rigide. De plus, l'équipe assume la part de risque qu'il y a dans toute démarche innovante.

Le rebelle prend aussi des coups. Les membres de l'équipe n'ont jamais été autant repris par notre hiérarchie pour des problèmes d'attitude ou à cause de conflits. Notre obstination à remettre en cause les habitudes et à éliminer les gaspillages choquent et dérangent parfois. Une conduite du changement devrait éviter ces maladresses. J'ai déjà consacré plusieurs billets (1 et 2) à ces problèmes.

Je pense que notre management est très conscient de cet esprit de rébellion. La hiérarchie est satisfaite de voir le bulldozer avancer mais aussi soucieuse des dégâts collatéraux. La gestion de l'équipe par le management est donc une combinaison contrastée de reconnaissance et de rappels à l'ordre.

C'est bien joli cet esprit de rébellion, mais apporte t-il de la valeur? Il se trouve que notre industrie est marquée par des pratiques anciennes, lourdes et peu efficaces. Tout le monde s'accorde pour reconnaitre qu'il faut conduire un changement assez radical. Pour porter une révolution au quotidien sur le terrain il faut des rebelles. Et puis maintenant nous avons l'avantage de ne plus en être à l'exploration. Après plusieurs années de pratique nous disposons désormais de métriques et de bilans d'affaires. Les faits montrent que les projets ne sont pas faciles mais ils s'arrangent. L'esprit rebelle a du bon. Par contre, j'imagine que cet esprit perdra en force (sans disparaitre pour autant) à mesure que les principaux obstacles seront surmontés.

Concluons en musique avec la question qui hante le rebelle. Spéciale dédicace à Claude Aubry ;o)

OU SONT LES GOF?

J'ai noté une mutation dans mon entourage. Peut-être l'avez-vous également remarqué autour de vous.

Il y a quelques années, nous avions tous un exemplaire du GoF sur notre bureau. L'ouvrage Design Patterns de Gamma, Heml, Johnson et Vlissides (le Gang of Four) était Le Livre. Pour nous, ce catalogue était La Référence des programmeurs compétents. Il trônait fièrement sur nos bureaux et nos architectures étaient enrichies de ses enseignements.

Puis, il nous a fallu plusieurs années pour graduellement et efficacement mettre en pratique l'Extreme-Programming. Curieux constat, aujourd'hui le GoF ne trône plus sur aucun de nos bureaux. Le mien est à la maison.

Comment expliquer cette lente mutation? Voici quelques causes possibles:

1. Nous ne concevons plus, nous codons comme des coyotes (alternative sauvage du cowboy-coding);


2. Nous maitrisons les Design Pattern et les mettons en musique de manière intuitive et inconsciente (rien que cela);


3. Nous concevons autrement, piloté par les tests;


4. Nous connaissons suffisamment les design-pattern et nous les faisons émerger avec parcimonie à mesure de la conception pilotée par les tests (fromage et dessert).

Alors, est-ce un abandon, une digestion, une révolution ou une mutation?

Sur plusieurs projets d'affilée, j'ai remarqué que je me fais moins de nœuds au cerveau concernant l'architecture. Avant, nous réfléchissions pas mal avant de nous mettre sérieusement au code. Nous dessinions de nombreux modèles au tableau et nous potassions le GoF à la recherche d'élégantes solutions.

Désormais, nous sommes plus directs. Nous cherchons la solution la plus simple à tester tout en respectant le principe de séparation commande/requête. Les associations, abstractions, héritages et implémentations viennent naturellement sur des critères de testabilité. Une fois que les tests passent, nous remanions notre travail pour réduire le volume de code, notamment en chassant les duplications. Au passage, nous nous assurons que l'organisation des classes respecte les principes de l'Oncle Bob. Et le plus incroyable est qu'au fur et à mesure des projets, il est de plus en plus aisé d'ajouter des fonctionnalités par incrément. Je trouve même que nos architectures sont élégantes. Elles ont l'élégance de la simplicité. Au passage, nous constatons que nos critères d'une bonne architecture sont par ordre de priorité: testabilité, simplicité, pas de dupplication, clarté.

Je ne pense pas pour autant que nous négligeons les patterns du GoF. Après en avoir abusé, nous les appliquons avec plus de parcimonie. En effet, dans nos architectures nous retrouvons toujours une séparation claire des responsabilités de fabrication des instances, d'utilisation des instances, de séquencement des instances et de gestion des états. Par contre, les Singleton sont toujours une vraie plaie pour les tests.

Ainsi, nous n'avons pas brulé nos GoF. Nous avons pris le temps d'en assimiler les enseignements et de les appliquer sans en abuser. Mais, je reconnais que pour nous, le GoF n'est plus La Référence. Nous n'en conseillons plus la lecture aux nouveaux arrivants. Ainsi, nous nous reposons peut-être trop sur l'expérience de ceux qui l'ont lu et l'ont trop pratiqué pour enfin apprendre à bien le pratiquer.

Et vous, il est où votre GoF?

AGILITE ET CRITIQUES COURANTES - V3

Concernant les démarches agiles de développement logiciel, j'entends souvent les critiques suivantes:

1. Ces démarches manquent de rigueur et de discipline.
2. Ces démarches abolissent la conception.
3. Ces démarches n'offrent pas de vision à long terme du déroulement du projet.
4. Ces démarches engendrent une reprise perpétuelle du travail fini.
5. Ces démarches ne permettent pas de s'engager sur un contour fonctionnel fixe.
6. Ces démarches ne sont pas adaptées aux produits critiques.
7. Ces démarches échouent comme les autres.
8. Ces démarches sont peu adaptées pour le développement géographiquement distribué.
9. Ces démarches sont peu adaptées aux grosses équipes.
10. Ces démarches sont adaptées pour des développeurs compétents et motivés.
11. Ces démarches risquent d'élaborer des architectures non-évolutives.
12. Ces démarches vivent sur l'utopie du consensus dans l'équipe.

A l'occasion de cours, de rencontres, de conférences, de présentations et du travail au quotidien, je suis souvent confronté à ces critiques et je suis amené à argumenter à leur encontre.
Cet article est une tentative de mettre par écrit ces argumentaires afin de les réutiliser plus aisément. Les publier permettra peut-être de les enrichir sur la base de l'expérience d'autres praticiens.
L'article est disponible ici.

La 2ème édition de cette note répond à la critique numéro 11.
La 3ème édition reformule l'argumentaire de la critique 5.

ETES-VOUS AGILE?

Denis Dollfus a conçu et mis en ligne sur son blog un questionnaire pour évaluer la mise en place du développement logiciel agile dans votre organisation.

L'évaluation est faite sur deux axes: les pratiques techniques et les pratiques de management.

L'idée n'est pas de se noter, mais de réfléchir à ce qui peut être fait sur votre projet.

Pour remplir le questionnaire, allez là.