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).

MODELISATION, GENERATION ET AGILITE (MDE1)

Je souhaite réagir à l'article "Productivité, agilité, industrialisation : même combat?" paru ce mois dans le numéro 113 du magazine PROgrammez. Cet article fait parti d'un dossier spécial dédié à la productivité.

L'auteur y défend l'efficacité de la démarche Model-Driven avec génération du code. Il utilise certains arguments pour lesquels j'ai d'autres points de vue.

Tout d'abord, l'auteur affirme que "[la maintenance des modèles] est moins coûteuse que celle d'un code car celui-ci est dépendant de la technologie, des évolutions des outils, etc."
L'auteur a en tête les Platform-Independant-Models qui ne dépendent pas de la plateforme technologique. Par contre, il ne faut pas se leurrer: le modèle est très dépendant de la technologie MDE, de l'outil de modélisation, des outils de transformation de modèles et de l'outil de génération de code. Ainsi, les modèles restent dépendants de la technologie et des évolutions des outils.

Ensuite, l'auteur affirme que "L'éclectisme du code résultant des cultures et sensibilités diverses et variées des programmeurs se paye aussi comptant au moment du calcul des prix de revient des applications." Par expérience, j'ai remarqué qu'il existe autant de manières de modéliser une idée que de manières de la coder. Malgré un standard commun, j'ai pu constater que plusieurs développeurs au sein d'un même projet modélisent de manières différentes. UML n'est qu'une notation. De même, plusieurs rédacteurs rédigeront une même histoire de façons multiples.

Puis, l'auteur donne un avis avec lequel je suis fortement en désaccord: "Comment faire pour qu'un programmeur maintienne sans effort conséquent le code d'un autre? Comment faire pour qu'un programmeur retouchant celui d'un autre n'introduise pas, par simple incompréhension, des bogues? Réponse : le transformer en créateur de modèles et générer le code à partir de ses modèles!" La pratique du pilotage par les tests, le remaniement en continu, la suppression systématique des duplications et l'adoption de la solution la plus simple qui soit viable sont des voies pour modifier du code à moindre effort. Surtout, le pilotage par les tests (systématiques et couvrants) offre la seule garantie concrète que l'application ne régresse pas suite à une modification de code. La génération de code à partir de modèles n'offre pas de telles garanties. Qu'est-ce qui vous garantit que les défauts n'ont pas été introduits dans le modèle? Pourquoi les diagrammes n'exprimeraient que des idées justes? Pourquoi un modèle serait-il correct à priori? Seule l'exécution du logiciel permet d'affirmer qu'il est correct. Ne croyez pas que je dévalorise les modèles. En équipe, nous modélisons tous les jours ... avec des marqueurs et sur des tableaux blancs. Et puis, si nous modélisons en mode esquisse, c'est aussi parce que nous avons échoué en approche MDE ...

Plus loin dans son article, l'auteur avance que "maintenir un logiciel c'est raisonner sur des modèles UML sans présumer d'une technologie spécifique." Pour toutes les raisons vues précédemment, je ne suis d'accord avec aucune partie de cette affirmation. Nous maintenons efficacement des logiciels sans avoir recours à des modèles électroniques. Aussi, la modélisation électronique présume de technologies spécifiques.

Enfin, un leitmotiv flotte à travers l'article. Il est dit qu'il n'est pas toujours possible de développer avec "du personnel d'excellence", des "programmeurs hors-pairs". Parfois, il faudrait se contenter de "simples développeurs". Et puis pourquoi parle t-on si souvent de programmeurs et non simplement de développeurs? La modélisation et la génération de code seraient-ils des outils permettant de tirer le niveau vers le bas? Ces pratiques permettraient-elles de ne pas développer les compétences des équipes? Clairement, il me semble que l'auteur ne fait pas confiance aux développeurs et que la programmation est considérée comme une tâche ingrate.

Mais, pourquoi le mot "agilité" est-il utilisé dans le titre?

SCRUM ET ICEBERGS

Le dernier billet de Bruno Orsier m'a beaucoup plu. Notamment, il m'a fait découvrir la passionnante vidéo d'une conférence donnée par Ken Schwaber à Google.

Parmi les sujets abordés par le co-créateur de Scrum, il y en a un qui me touche beaucoup en ce moment. Il y a peu, je l'ai abordé à l'occasion d'un billet sur les conflits qui apparaissent tôt lorsqu'on pratique une démarche agile.

Ken Schwaber affirme que la pratique de Scrum par une organisation est un test de sa capacité à accepter les problèmes qui seront soulevés souvent très tôt.

Ces problèmes sont dévoilés tôt par les démarches agiles car elles visent à livrer très tôt un produit partiel et potentiellement livrable. Livrer au plus tôt un produit oblige à exercer au plus tôt toutes les formes de collaboration, de communication et de travail d'équipe nécessaires à la création de valeur pour le client. Exercer au plus tôt toutes les activités révèle au plus tôt les obstacles à la création de valeur.

Ces problèmes ne sont pas dûs à la pratique de Scrum. Ils existaient bien avant, cachés et ignorés. Par contre, l'application de Scrum (ou d'une autre démarche agile) révèle vite la partie immergée de l'iceberg. La transparence, le retour d'information et le cycle itératif et incrémental contribuent à identifier au plus vite les obstacles.

Révéler les freins à la productivité est un test pour l'organisation. Aura t-elle la maturité et le recul pour accepter ces obstacles en son sein? N'est-il pas plus confortable à court terme de revenir à une ancienne démarche et de se rassurer en pensant que tout va bien pour le moment?

Au sein d'une même organisation, considérons deux projets. L'un travaille en cycle en V alors alors que l'autre avance en agile. Immanquablement, le deuxième projet révèlera plus tôt des difficultés. Quelle conclusion hâtive est si aisée?

Comme j'ai déjà eu l'occasion de le dire lors d'un précédant billet, nous avons déjà vécu cette situation. Sur un projet d'envergure, nous avancions en mode eXtreme-Programming au sein d'un programme plus large travaillant en cycle en V. A l'époque, on nous a reproché de révéler trop tôt et trop fréquemment des problèmes. Notre équipe dénotait car elle butait déjà sur des obstacles. Notre organisation n'avait probablement pas la capacité de reconnaitre que nous déterrions tôt certains problèmes en son sein.

De même, lorsque tôt dans le projet les mesures de vélocité montrent que le produit ne pourra être livré à la date anticipée, l'organisation sera tentée de penser que l'équipe est inefficace alors qu'elle ne fait que révéler tôt que le planning initial est intenable sans réorganisation. Alors, plusieurs choix sont possibles: refuser d'admettre les faits, trouver une organisation projet mieux adaptée, revenir à une ancienne démarche de travail ou exiger une plus grande vélocité, ce qui se fera immanquablement au détriment de la qualité et donc de la date de livraison.

Face à une telle situation, l'organisation doit décider si elle veut agir sur le problème ou sur ce qui a révélé le problème. Accepte t-elle de voir la partie immergée de l'iceberg? En effet, l'organisation passe un test de maturité.

AGILE TOUR VALENCE VU PAR LES PARTICIPANTS

Ainsi, l'Agile Tour est passé à Valence le jeudi 23 Octobre 2008. Nicolas Blanpain a synthétisé les questionnaires de satisfaction remplis par les participants.

Il s'avère que 111 participants se sont déclarés le jour J à l'accueil, sans compter les membres de l'ESISAR. Le taux de participation est de 78% du nombre d'inscriptions. 12% des participants se sont présenté sans être préalablement inscris. 70% des participants ont eu la gentillesse de remplir un questionnaire de satisfaction dont vous lisez actuellement une synthèse. Les participants étaient à 50% des développeurs, à 20% des chefs de projet et à 15% des managers hiérarchiques. Sur une échelle de familiarité avec l'agilité de 1 à 5 par ordre croissant, les participants s'évaluent en moyenne à un niveau de 2. Il ne s'agit donc pas encore d'une communauté de praticiens.

Concernant la valeur apportée par cette demi-journée aux participants, 96% d'entre eux affirment qu'ils reviendront en 2009. En moyenne la réponse aux attentes des inscris est notée à 3,97 sur 5. Quand à elle, l'appréciation globale de l'évènement est évaluée en moyenne à 4.35 sur 5. Concernant le format de l'évènement, 44% des participants sont favorables au maintient du format sur une demi-journée alors que 38% préfèreraient un évènement sur une journée complète. Du point de vue organisation de l'évènement, sur une échelle de satisfaction croissante de 1 à 5, l'accueil des participants a été noté à 4.61, la restauration a été appréciée à 4.57, l'introduction et la conclusion ont été notées à 4.33, les infrastructures ont été appréciées à 4.54 et le timing a été évalué à 4.84.

Parmi les sujets attendus pour la prochaine édition, nous trouvons une présentation des méthodes agiles les plus courantes, la conduite du changement, convaincre dans un environnement hostile, la gestion des conflits, l'agilité dans l'industrie, agilité et criticité, le management agile, l'entreprise agile, agilité et sous-traitance avec la fameuse contractualisation des prestations agiles.

Parmi les aspects positifs, les participants ont apprécié la qualité des présentations, l'accès à des ateliers ainsi que les compétences, le dynamisme et l'enthousiasme des orateurs. Aussi, ils ont retenu la convivialité de l'évènement et le respect d'un timing soutenu.

En revanche, les participants ont regretté le peu de temps restant pour les questions/réponses. Le format en 50min semble un peu court pour les présentations. Aussi, il faudrait identifier les pré-requis pour les séances, voire proposer des circuits thématiques.

Parmi les orateurs et participants, certains ont publié des billets. Vous pouvez lire ceux d'Alexandre Boutin, d'Emmanuel Etasse,de Bruno Orsier, d'Aline Paponaud, de Developpez.com.

A partir des questionnaires, la rétrospective de l'évènement par les organisateurs permettra d'identifier des axes d'amélioration pour la prochaine édition. Ce travail aura lieu la semaine prochaine.

Merci à Nicolas pour sa grande implication dans l'évènement et pour cette synthèse. A l'année prochaine!

PRATIQUES D'EQUIPE - 4EME EDITION

Voici la quatrième édition de l'article décrivant les pratiques de notre équipe de développement.

Cette édition tient compte des remarques de relecture faites par Rémy Sanlaville et par mon chef de service. La principale différence est l'ajout de d'appréciations sur la rentabilité de chaque pratique.

Vous pouvez consulter la nouvelle version de l'article là: http://manu40k.free.fr/articlePratiquesDEquipe.pdf

Attention, le document pdf est assez volumineux car il contient de nombreuses photos de l'équipe "en action".

Une cinquième édition pourra inclure les pratiques de planification d'itération et de rétrospective d'itération, ainsi que les pratiques techniques.