ITERATION OU SPRINT?

Dans Scrum, il y a un terme que je n'apprécie plus trop: le Sprint.

ITÉRATION OU SPRINT?

Après 130 jours ouvrés de développement, nous en sommes à notre septième itération et nous en avons encore pour plus d'un an de développement.
Déjà, nos itérations se sont transformées en sprints dans le sens premier du terme. Nous n'en sommes plus à un rythme durablement soutenable.

VÉLOCITÉ ET COURSE

Nous mesurons notre vélocité, nous la publions et nous l'utilisons pour planifier les itérations. Nous subissons une forte pression provenant de nous même comme du management pour améliorer continuellement cette vélocité.
Classiquement, une telle course à la productivité se fait au détriment de la qualité. C'est la nature même du développeur. Heureusement, le secteur du logiciel critique n'autorise pas de prendre la qualité comme variable d'ajustement. Alors, nous rognions sur certaines tâches de fond que nous poussons devant nous au risque de nous ralentir un jour. Par exemple, nous délaissons la réorganisation de la base de gestion de configuration, la rapidité du build et la rotation des développeurs sur les différentes parties de l'application.

TUNNEL ET TRANSPARENCE

Ce qui est fou, c'est que nous sommes à l'origine de cette course à la vélocité.
Avant, nos projets avançaient "tranquillement" dans un tunnel. La pression venait tard car nous n'avions que tardivement une vision objective et réaliste de l'avancement du projet.
Depuis quelques projets, avec la publication régulière d'une vélocité pertinente et des estimations basées sur cette productivité, nous sommes rapidement conscients de la partie immergée de l'iceberg. La vision réaliste du projet est vite révélée. Et la pression arrive tôt.

DU MOU

En rétrospective d'itération, l'équipe a identifié la course à la vélocité comme étant le principal problème à régler. Nous avons demandé à expérimenter la chose suivante: le premier jour d'une itération sera exclusivement consacré à des tâches de fond et à des améliorations. Ce jour là, personne ne cherche à produire un incrément de fonctionnalité. Cela peut paraître un peu maigre comme avancée, mais il n'est pas évident de convaincre les managers de ralentir une locomotive rapide, mais en retard sur un horaire.

UNE QUESTION DE VOCABULAIRE?

Je suppose que le mot "sprint" plait aux managers et aux clients. Il sous-entend que l'équipe ne peut aller plus vite sans prendre le risque d'un claquage. Le problème est que nous ne pouvons sprinter longtemps. Je préfère le mot "itération". Il me parait plus serein. Il reste à concrétiser cette nuance de vocabulaire en un rythme durablement soutenable pour l'équipe.

METAPHORE V VERSUS ITERATIF ET INCREMENTAL

Aujourd'hui, nous cherchions une métaphore pour comparer le cycle en V à un cycle itératif et incrémental.

LE PARCOURS PRÉDICTIF

Il nous a semblé que conduire un cycle en V revient à prendre le temps de visualiser où on souhaite se rendre, à prévoir la trajectoire à suivre pour atteindre ce lieu, à estimer le temps qu'il faut pour parcourir le chemin, puis à fermer les yeux et se diriger sans voir vers cette destination. Quand la durée estimée du trajet est atteinte, on ouvre les yeux.

LE PARCOURS ADAPTATIF

Conduire un cycle itératif et incrémental revient à répéter en boucle la démarche suivante: jeter un coup d'œil rapide vers sa destination, fermer les yeux, faire quelques pas sans voir vers cet objectif et ouvrir les yeux. Plus le nombre de pas entre deux coups d'œil est réduit, et plus le pilotage est fin.

LA MÉTAPHORE CONCRÉTISÉE PAR UN ATELIER

Cette métaphore peut être jouée en atelier. Deux volontaires côte à côte se voient attribuer une même destination. Le premier doit se rendre à ce lieu en suivant la première démarche. Le second adopte la deuxième démarche.
Pour pimenter l'atelier, le parcours peut être initialement perturbé par un obstacle, comme une chaise ou une personne. Il est également intéressant d'ajouter un obstacle supplémentaire (une autre chaise ou une autre personne) en cours de parcours.
Ensuite, il peut être intéressant de rejouer le même atelier, mais cette fois avec deux volontaires adoptant la deuxième démarche. Le premier ouvre les yeux tous les pas. Le deuxième n'ouvre les yeux que tous les trois pas.

A EXPÉRIMENTER

J'utiliserai cette métaphore et j'essayerai ces petits ateliers avec les étudiants lors de mes prochains cours de génie logiciel pragmatique.

EN CONCLUSION

Cette métaphore ne suffit pas à illustrer les différences entre les deux démarches. Aussi, cette comparaison est caricaturale. Personne ne mène un cycle en V aussi aveuglément (rassurez-moi). En cours de développement, il y a bien sûr des réajustements (tardifs certes, mais il y en a toujours). Néanmoins, cette métaphore me semble être une bonne vulgarisation.

SCRUM AND XP FROM THE TRENCHES, HENRIK KNIBERG

J'ai profité de la traduction en français de ce livre pour enfin le lire.

Loin de la théorie de Scrum, l'auteur décrit de manière très pragmatique son implémentation de la démarche en révélant plein de petits conseils pratiques.

Après avoir lu un ouvrage de Ken Schwaber, ce livre est idéal pour se faire une idée concrète de comment Scrum peut être appliqué au jour le jour. Étant déjà praticien, j'ai trouvé très intéressant de confronter nos pratiques à celles de Henrik. Aussi, dans la multitude de petit conseils pratiques, tout le monde trouvera bien un petit quelque chose à expérimenter sur son projet.

Les 150 pages se lisent tranquillement et agréablement le temps d'un week-end.

Merci à Emmanuel Etasse, Bruno Orsier et leurs compères pour ce travail de traduction. Le livre est gratuitement et légalement téléchargeable ici.

FRAGILITÉ

On nous demande fréquemment quelles sont les limites à la pratique efficace d'une démarche agile. En dehors du périmètre de l'équipe de développement, qu'est-ce qui peut nuire à la productivité de l'équipe? Au-delà de la contraposé de chaque valeur, principe et pratique agile, voici quelques contextes de développement inadéquats.

LA MULTIPLICATION DES FRONTIÈRES ET DES CONTRATS

La multiplication des relations contractuelles et des frontières au sein d'un projet (entre équipes, entre métiers, entre lieux géographiques, entre bureaux, entre langues, entre l'organisation et ses sous-traitants) entraine un effort d'organisation. Cet effort peut-être vu comme un gaspillage (au sens du Lean) puisqu'il n'apporte aucune valeur au client.

LE MANQUE DE CONFIANCE ACCORDE AUX ÉQUIPES

Si l'organisation n'accorde pas sa confiance aux équipes de développement, elle gaspillera de l'énergie à planifier en détail les travaux (qui ne se dérouleront pas conformément aux détails), à formaliser et standardiser en détail les procédures (que les développeurs souhaiteront adapter à plusieurs reprises) et à contrôler les activités (au lieu de supprimer les obstacles). Aussi, elle démotivera les équipes et freinera la prise d'initiative et de décision.
Cet état d'esprit, qui consiste à vouloir séparer penser et faire, se concrétise souvent par des procédures très détaillées, des outils complexes et une planification microscopique et à long-terme.

LE MANQUE DE MATURITÉ DE L'ORGANISATION

L'organisation doit faire preuve de maturité et de sang-froid pour accepter et traiter les problèmes qui seront identifiés tôt par la pratique des démarches agiles. Une organisation immature sera tentée d'agir sur la démarche qui a révélé les problèmes et non sur la cause racine des problèmes.

LE GIGANTISME ORGANISATIONNEL

L'équipe doit croître de manière itérative et incrémentale pour éviter de démarrer le projet avec de trop nombreuses ressources ou d'ajouter des ressources à un moment où le projet prend du retard. Conduire un grand projet avec de nombreux développeurs n'est pas une fatalité. Cette vision des grands projets est souvent liée à la planification par homme/mois. La synchronisation de nombreux intervenants est un effort. Cet effort peut être vu comme un gaspillage (au sens du Lean) puisqu'il n'apporte aucune valeur au client.

UN LANGAGE DE PROGRAMMATION INADAPTÉ

L'utilisation d'un langage de programmation orienté-objet est un atout pour construire une application de manière incrémentale et pour rendre le logiciel testable. Faire l'impasse sur la programmation orientée-objet rend les applications plus laborieuses à tester et à construire par incréments.

ET LA LISTE N'EST PAS FINIE ...

Tous ces contextes réduiront les bénéfices d'une démarche de développement agile. D'ailleurs ces freins à l'efficacité ralentissent tous types de projets, agiles ou non. Malheureusement, il ne s'agit sûrement pas d'une liste exhaustive.

CMMI ET AGILE

Je viens enfin de finir de lire CMMI© or Agile: Why not Embrace Both! publié et mis en ligne par le SEI.
Il s'agit d'une étude montrant que les démarches CMMi et Agile seraient en fait compatibles et même complémentaires. Ainsi, il serait bénéfique de combiner les deux.

Malgré tout, je reste sceptique sur cette compatibilité, comme je j'avais dit dans un précédant billet. Ce nouvel article confirme certains de mes doutes.

Dans les chapitres 4 The Truth About CMMI et 5 The Truth About Agile, les auteurs essayent de rétablir des descriptions correctes des deux paradigmes en rectifiant certaines mauvaises interprétations.

Les trois et demi pages dédiées à l'Agilité m'ont semblé en donner une description claire et assez exhaustive. Ce chapitre est une synthèse réussie. Après sa lecture, un néophyte peut se construire une vision quasi concrète de ce qu'est un développement agile.
Par contre, les cinq pages dédiées au CMMI m'ont que peu aidé à clarifier ma vision du CMMI alors que je développe dans une organisation CMMI niveau 3 et que j'ai déjà été interviewé lors d'une évaluation officielle.

Je ne pense absolument pas que les auteurs de l'article ont failli à parler clairement du CMMI. Je pense simplement que le CMMI est un modèle abstrait, volumineux, très compliqué et difficile à appréhender. Il est donc difficile à décrire, d'où un premier rejet. Pourquoi faire compliqué alors qu'on peut faire simple et pragmatique? Ceci dit, l'agilité est simple à décrire mais compliquée à pratiquer ...

Le SEI rappelle que l'objectif de l'application du CMMI n'est pas l'obtention d'un niveau. C'est vrai, pourtant le CMMI a l'originalité et la particularité de proposer une évaluation payante aboutissant à l'obtention d'un niveau de maturité. J'espère que Scrum saura ne pas tomber dans la même démarche (je dis cela, mais je suis "certifié" ScrumMaster).

Je suis particulièrement sensible à un des arguments utilisés. Le CMMI pourrait renforcer l'efficacité de l'agilité dans le cadre de projets de logiciels critiques. C'est probablement une des raisons pour lesquels mon organisation a adopté le CMMI. Pourtant, certains de nos projets récents montrent que la démarche Agile est tout à fait pertinente dans de tels cadres pourvu qu'on l'adapte en tenant compte des normes incontournables de ces domaines, telle la DO178B pour l'avionique. Ainsi, on peut se passer de l'apport du CMMI car ces normes traitent justement des aspects critiques non abordés par les démarches agiles.

Aussi, les auteurs affirment que le CMMI peut étendre le rayon d'action de l'Agile aux processus de l'entreprise tout en réduisant les gaspillages. C'est un peu comme si le SEI s'inquiétait pour son CMMI du rapprochement enamouré entre le Lean et l'Agile.

Bref, je suis convaincu que les organisations qui ont pratiqué le CMMI ont progressé. De même pour celles qui ont appliqué l'agilité. Il est possible de mener conjointement les deux démarches. Il faut simplement être bien sûr que cela vaut l'effort investi.

PRATIQUES D'EQUIPE - 6EME EDITION

Et voici la 6ème édition de l'article sur les pratiques de notre équipe. Il y a quelques nouveautés dues au fait que trois équipes développent désormais en parallèle sur le même projet.
Consultez la 6ème édition de l'article ici.

Je prévois de proposer une conférence sur le thème de l'article aux prochains évènements (XP Days?, Agile Tour?) pour varier avec ma précédante présentation ("Agilité et avionique").

MODEL-DRIVEN ET AGILITE (MDE2)

Suite à mon précédant billet en réaction à un article sur la démarche de développement piloté par les modèles, je souhaite revenir sur la cohabitation de l'agilité et du MDE. Le développement piloté par les modèles et les démarches agiles sont-ils compatibles? Peut-on envisager un MDE agile? Pourquoi ai-je été si déçu par mon expérience du MDE et si motivé par ma pratique du développement agile?

DÉVELOPPEMENT PILOTE PAR LES MODÈLES

Entendons-nous, par MDE, je parle d'une démarche de développement où les modèles UML sont les principaux artefacts élaborés et maintenus par les développeurs. Par exemple, le code est généré par transformations de modèles.

MDE ET MANIFESTE AGILE

Pour sonder une éventuelle compatibilité, on peut commencer par se demander si le MDE est compatible des valeurs du Manifeste Agile.

Il me semble que le pilotage par les modèles met fortement l'accent sur les outils. L'éditeur UML, les transformations de modèles et les générateurs de code sont autant d'outils sur le chemin critique du développement. Ces outils particuliers viennent s'ajouter aux incontournables outils tels que le gestionnaire de versions, le compilateur, le framework de test, l'IDE, etc. D'ailleurs, on constate que cette démarche est essentiellement poussée par des vendeurs d'outils. Aussi, le MDE est souvent cité dans le cadre des fameuses "usines logicielles" avec leurs processus fortement automatisés. Tout ceci semble aller à l'encontre de la première valeur du manifeste: "Individuals and interactions over processes and tools".

Les modèles sont-ils assimilables à un logiciel opérationnel ou à une documentation exhaustive? Par transformations de modèles, on peut générer à la fois une documentation et un logiciel exécutable. Mais, est-ce que ce logiciel exécutable est pour autant un logiciel opérationnel? Le fait qu'une application apporte une valeur opérationnelle est lié au fait qu'il réponde correctement aux besoins des utilisateurs. Cette satisfaction passe souvent par la sanction de tests. Pourtant, il me semble que le test est peu traité par le MDE. Ainsi, je serais tenté d'émettre des réserves sur le fait que le MDE privilégie "Working software over comprehensive documentation".

Enfin, rien dans une démarche pilotée par les modèles ne me semble aller à l'encontre des deux dernières valeurs du manifeste, à savoir "Customer collaboration over contract negotiation" et "Responding to change over following a plan". De même, les douze principes du Manifeste Agile semblent pouvoir s'appliquer dans le cadre d'un tel développement.

MDE ET SCRUM

Dans la répartition des rôles, dans le cérémonial et dans la démarche de Scrum, je ne vois rien qui soit incompatible avec un développement piloté par les modèles. Scrum porte sur le pilotage du projet alors que le MDE adresse essentiellement les activités techniques. Il me semble qu'il doit être possible de conduire un développement piloté par les modèles avec une démarche Scrum, pour peu qu'on s'assure de livrer un produit opérationnel potentiellement livrable à la fin de chaque itération et pas seulement des modèles.

MDE ET EXTREME-PROGRAMMING

La confrontation du MDE et de XP me semble plus pertinente car les deux démarches adressent les aspects techniques du développement.

XP insiste sur le fait que le code et les tests sont idéalement les seuls artefacts à maintenir. Les autres artefacts doivent être générés à partir du code et des tests. Nous sommes à contrepied de la génération de code. Si le code est au centre du développement, c'est qu'il est primordial. C'est le code qui est transformé en logiciel exécutable ou interprété. C'est aussi le code que l'on déroule sous le débogueur pour les problèmes sérieux.

Le remaniement n'est pas pleinement efficace si le code ne peut être modifié directement, car généré. Certes, le modèle peut être remanié, mais cela ne garantit pas un code de qualité. Ne l'oublions pas, c'est le code qui est interprété ou compilé pour produire le logiciel exécutable, pas les modèles. C'est aussi le code qui est débogué. Le débogueur ne s'interface pas avec les modèles. Lorsque les choses finissent fatalement par se compliquer, il faut que les développeurs se plongent dans le code. C'est alors qu'un code remanié prend toute son importance. La suppression des duplications, la simplification du code et le gain en lisibilité résultant du remaniement facilitent l'assimilation du code par les développeurs.

Le cycle très rapide de test, codage et remaniement perd son rythme dynamique s'il faut passer par une étape supplémentaire de génération de code. Le passage très rapide des artefacts principaux au logiciel opérationnel est un fondamental d'XP. L'ajout de l'étape de génération de code va à l'encontre de ce fondamental.

L'intégration continue n'est possible que sur des artefacts pouvant être mergés. Or, comme nous l'avons vécu à nos dépens, à l'inverse du code, les modèles sont des artefacts dangereux à merger. Le développement concurrent et intégré en continue me semble impossible si les modèles sont les artefacts principaux. Ceci est très regrettable car une intégration continue efficace est un sacré atout pour réussir un projet.

Bref, il me semble impossible de conduire un développement piloté par les modèles avec une démarche XP.

MDE ET CODE

Un des avantages fréquemment cités du MDE est la possibilité de s'affranchir du code en élevant de niveau d'abstraction. Mais, il me semble qu'il ne faut pas se leurrer: pour générer du code, il faut saisir dans le modèle tout un tas d'informations non-graphiques utilisées par le générateur pour produire le code. Bref, cela revient presque à coder avec une autre notation.
Et puis, qu'on ne dise pas que les modèles affranchissent le développeur du code: le débogueur ne s'interface pas avec les modèles. Lorsque les problèmes deviennent sérieux, il faut bien en venir au code. A ce moment là, on espère avoir conservé quelques compétences en programmation.

Enfin, pour ce qui est du logiciel opérationnel, il va bien falloir en passer par les tests, même si on édite des modèles. Comment sont implémentés les tests? En code ou en modèles? Et si les tests sont modélisés, comment sont exprimées les assertions? En code.
Bref, je pense qu'il est un leurre de croire que les modèles permettent de s'affranchir du code pour développer une application. Cela est peut être vrai pour l'exemple pédagogique de la machine à café ou pour des applications simples. Le problème est qu'on ne paye pas des professionnels du développement logiciel pour construire des machines à café et des applications simples.

EN CONCLUSION

En fait, je pense qu'un développement piloté par les modèles gagne à être conduit dans une démarche agile, comme Scrum. Ainsi, le projet gagnera en transparence et du logiciel opérationnel sera régulièrement disponible.
Par contre, je ne vois pas ce qu'un projet agile gagne en utilisant les pratiques techniques pilotées par les modèles. Il me semble que centrer le développement sur le code et les tests va dans le sens de la simplification, de l'accélération du développement et de la production d'applications opérationnelles. Bien sûr, cela ne veut pas dire que l'équipe ne modélise pas. Il est très efficace de communiquer à l'aide de modèles utilisant une notation unifiée. Simplement, des marqueurs, des tableaux blancs et des appareils photos peuvent suffire (voir photo).