PLANNING EXTREME PROGRAMMING, KENT BECK ET MARTIN FOWLER

Ce livre a été conjointement écrit en 2001 par Kent Beck et Martin Fowler et préfacé par Tom DeMarco. Cela fait trois grosses signatures pour un seul et même ouvrage.

LA GESTION DE PROJET

Les auteurs consacrent le livre à la planification et au pilotage d'un projet mené dans une démarche XP. Ils cherchent à montrer qu'en plus de pratiques techniques, la panoplie XP contient toutes les pratiques nécessaires et suffisantes pour planifier et piloter un projet.

XP + SCRUM OU XP?

On dit souvent que Scrum apporte aux pratiques techniques d'XP les pratiques de pilotage de projet et d'équipe. Ce livre tend à montrer que XP est déjà auto-suffisant pour la gestion de projet. La sur-couche Scrum ne fait que recouvrir avec son propre vocabulaire et ses rôles des pratiques pré-existantes dans XP. Ceci dit Scrum apporte plus de formalisme et de cérémonial, ce qui est une bonne chose à mon avis.

DE L'EAU DANS LE VIN

D'une manière générale, Martin et surtout Kent ont mis de l'eau dans leur vin. Dans ce livre, je trouve que l'aspect extrême d'XP est diminué. Déjà, en préface, les auteurs rappellent que XP n'est pas une destination mais un parcours. Une pratique conforme au livre d'XP doit servir à identifier ce qui dans la démarche doit être adapté au contexte du projet.

La durée de l'itération est devenue un sujet d'expérimentation. Le cycle hebdomadaire n'est plus une référence. L'essentiel est de rester en dessous du mois et de ne pas glisser!

De même, la pluridisciplinarité de chaque membre de l'équipe n'est plus encadrée par une rotation systématique des binômes sur toutes les parties de l'application. La spécialisation des développeurs est même encouragée à partir du moment qu'elle est liée à une motivation personnelle.

Aussi, les auteurs sont plus permissifs quand à l'existence de bugs dans le produit. La correction de bugs mineurs n'est pas nécessairement une priorité pour l'équipe.

Enfin, les auteurs sont moins impératifs sur la nécessité de développer les fonctionnalités de bout en bout. L'essentiel est désormais que tout ce qui est développé dans l'itération soit testé à la sortie de l'itération.

Personnellement je désapprouve le calcul d'une vélocité individuelle pour chaque développeur. Je suis peut-être un peu Bisounours, mais je ne vois pas comment cela peut rester compatible d'un esprit d'équipe efficace. Je préfère calculer la vélocité de l'équipe pour mesurer sa capacité de travail par itération et éventuellement diviser cette vélocité par le nombre de développeurs pour surveiller l'impact de l'intégration de nouveaux membres dans l'équipe.

Enfin, j'ai apprécié le désaccord entre Kent et Martin portant sur la priorité des fonctionnalités à développer. Kent accorde une plus grande priorité à celles qui apporte le plus de valeur au client alors que Martin accorde les plus hautes priorités à celles qui comportent le plus de risques. C'est le pilotage par retour sur investissement contre le pilotage par les risques.

EN CONCLUSION

Bref, si on connait déjà XP et Scrum, il ne me semble pas que la lecture de ce livre soit si importante. Par contre, si on croit que XP ne contient que des pratiques techniques, alors ce livre est une occasion de se détromper. Il se lit très vite gràce au style reconnaissable de Kent: une succession de petits chapitres de 2 ou 3 pages au plus.

ARMURE OU MOBILITE?

En 2000, Tom DeMarco (co-auteur du brillant PeopleWare) a rédigé une préface vraiment intéressante pour le livre Planning Extreme Programming de Kent Beck et Martin Fowler.

LE BALANCIER

Il évoque que dans le livre On War, Carl von Clausewitz constate que l'histoire de la guerre est assimilable au mouvement d'un balancier. Au fil du temps, ce balancier oscille entre avantages relatifs de l'armure et de la mobilité.

Les chevaliers en lourdes armures ont écrasé les fantassins peu protégés. La cavalerie légère a décimé les chevaliers trop lents. Les chars ont piétiné la cavalerie trop fragile. Les guérilléros armés de lance-roquettes transpercent les chars trop aveugles .. (et Paix sur Terre aux hommes de bonne volonté).

ET LE DÉVELOPPEMENT LOGICIEL DANS TOUT CELA?

Tom DeMarco constate que le développement logiciel suit le même mouvement de balancier entre l'armure (les processus lourds) et la mobilité (les démarches légères).

Au commencement, les développeurs adoptaient des démarches empiriques et rapides. Puis, avec le volume croissant des logiciels et les pertes de visibilité sur les projets, des processus lourds et formels ont été mis en place pour se protéger des échecs. Désormais, fatigués par l'inertie de ces démarches lentes et lourdes, les équipes passent à l'offensive et cherchent à réussir par des développement éclairs.

On dit d'ailleurs d'un process qu'il est lourd (comme une armure?). Aussi, l'"agilité" est un mot proche de "mobilité". De plus, l'agilité prône la réactivité et celle-ci n'est autre que la mobilité transposée au développement!

Il fut un temps où on cherchait ce qu'on pouvait ajouter à son process pour mieux se protéger contre le fiasco. Maintenant, les équipes pistent ce qu'elles peuvent retirer de leur process pour gagner en rapidité et gagner tout court.

PLUS GÉNÉRALEMENT

Il semble que lorsqu'on renforce son armure, on cherche à ne pas perdre. Par contre, lorsqu'on allège son armure, on cherche à gagner.

LE MOT DE LA FIN

Ces réflexions me ramènent bien sur au CMMi et à l'agilité. De quel côté se trouve le CMMi? De quel côté se range l'agilité? Cela a t-il un sens de les associer? Doit-on parler de CMMi et d'Agile ou de CMMi puis d'Agile? Le CMMi ouvre-t-il la porte à l'agilité car il voit le balancier le quitter pour pencher vers la mobilité? Vers où penchera le balancier après l'agilité?

CARA, PREMIERE REUNION A VALENCE

Hier soir, s'est tenue la première réunion du CARA à Valence. Elle a eu lieu dans les locaux de l'IUT.
Nous étions 13 participants provenant de plus d'une demi-douzaine d'entreprises locales.
Le compte-rendu de la session est disponible sur le site du CARA.

Les premières rencontres sont toujours un peu délicates car il n'y a pas de programme pré-établi. Nous avons donc choisi de conduire un forum-ouvert. En tout cas, nous n'avons pas eu de flottement et les discussions coulaient naturellement.

Merci aux participants et rendez-vous au mois de Janvier!

LEAN EVENT, PAR ADACORE

Je suis invité au mois de Mars pour présenter une conférence sur les thèmes de l'avionique, de l'agilité et du Lean à l'occasion d'un évènement sur le Lean organisé par AdaCore.

Jim Sutton, co-auteur de Lean Software Strategies, sera la guest-star de l'évènement. Les conférences seront en anglais. Il faut donc que je me mette au travail!

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

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.

PROGRAMMEZ PAR CONTRAT!

Vous avez sûrement entendu qu'il est peut être efficace de favoriser la collaboration avec le client plutôt que la négociation du contrat?
Et bien, je vous assure qu'il est efficace de programmer par contrat!

Cela n'a rien avoir avec la dualité collaboration/contrat du Manifeste Agile, mais cela a peut-être suscité votre curiosité. Pour découvrir en quoi la programmation par contrat contribue à la mise en pratique des principes agiles et du Lean, lisez le court article suivant: Programmez par Contrat!

ANALOGIES ENTRE L'EQUIPE ET SON LOGICIEL (2NDE EDITION)

La récente conférence de Géry Derbier à l'Agile Tour à Valence et les conflits que nous avons vécu il y a peu sur notre projet m'ont amené à ajouter d'autres dualités dans mon article sur les analogies entre une équipe et son logiciel.
La seconde édition de l'article est consultable ici.

AGILE TOUR 2008 VALENCE - REGIS MEDINA

Pendant 50 minutes, Régis Medina (Crossbow Labs) remanie du code en direct.
Cette session permet de recentrer l'attention des participants sur le (beau) code et les pratiques techniques.

AGILE TOUR 2008 VALENCE - ALEXANDRE BOUTIN 2

Alexandre présente un retour d'expérience sur la transition vers l'agilité chez Yahoo!.
Pragmatisme et franc-parler sont au rendez-vous.

AGILE TOUR 2008 VALENCE - GERY DERBIER 2

Après son alelier "Spécifieurs et Artistes", Géry termine les conférences avec une présentation de la démarche Crystal.

AGILE TOUR 2008 VALENCE - PATRICE PETIT 2

Patrice Petit commence les conférences avec une introduction aux démarches agiles en 50 minutes.

AGILE TOUR 2008 VALENCE - OUVERTURE ET CLOTURE

Nicolas Blanpain a mené l'ouverture et la clôture des conférences.

AGILE TOUR 2008 VALENCE - PARTICIPANTS

L'amphithéâtre de l'ESISAR était plein. Environ 120 participants sont venu partager cet évènement.

AGILE TOUR 2008 VALENCE - FRANCOIS BRUN

François Brun anime à son tour un forum ouvert, le dernier de la journée.
Il faut une sacrée expérience pour animer ce genre de session destinée à accueillir les sceptiques.

AGILE TOUR 2008 VALENCE - ALEXANDRE BOUTIN

Après son retour d'expérience sur Yahoo!, Alexandre Boutin enchaine en animant un forum ouvert pour les curieux et les sceptiques.

Alexandre a publié un billet sur sa participation à l'évènement.

AGILE TOUR 2008 VALENCE - GERY DERBIER

Géry Derbier fait un carton en animant son atelier "Spécifieurs et Artistes".
Il démontre en pratique que le développement est bien un jeu coopératif d'invention et de communication.

AGILE TOUR 2008 VALENCE - PATRICE PETIT

Patrice Petit, organisateur de l'Agile Tour, présente les sponsors globaux de l'évènement.

AGILE TOUR 2008 VALENCE - COFRAMI

Nicolas Blanpain passe la parole au sponsor COFRAMI.
Bruno Morata, responsable de l'agence de Valence, explique pourquoi COFRAMI mise sur le développement logiciel agile.

AGILE TOUR 2008 VALENCE - THALES

Nicolas Blanpain passe la parole aux sponsors de l'Agile Tour.

Loïc LeGall parle au nom de THALES. L'accent est mis sur le développement logiciel agile, le Lean et de nouvelles relations entre clients et fournisseurs.

Je chronomètre la minute de temps de parole de chacun.

AGILE TOUR 2008 VALENCE - L'ACCUEIL

Jean-Pierre, Emmanuel, Marie, Nicolas et Jean-Christophe accueillent les participants.

VERIFICATION STATIQUE ET EXTREME PROGRAMMING

Christophe Baillon de la société SOGILIS (http://sogilis.com/) m'a transféré la publication Static Verification and Extreme Programming (www.praxis-his.com/pdfs/svandxp.pdf). L'article parle notamment de l'étonnante cohabitation entre le développement de logiciels critiques et la pratique de XP.

Christophe a bien vu de me faire connaitre cette publication. En effet, cet article m'intéresse à plusieurs égards. D'abord, je développe en équipe des applications très critiques tout en appliquant une forme adaptée de l'eXtreme-Programming. Aussi, j'ai publié un article sur la criticité et XP (Agilité et Avionique) et j'ai présenté une conférence sur ce thème aux XP Days 2008 et à l'Agile Tour Grenoble 2008 (Agilité et Avionique). Enfin, lors de ma session à Grenoble, Bruno Orsier m'a interroge sur notre éventuelle utilisation des outils de vérification statique. J'aurais mieux fait de lire l'article transmis par Christophe bien avant pour mieux répondre à Bruno!

J'écris ce billet pour réagir à certaines affirmations de l'article.

Tout d'abord, l'auteur explique qu'un outil de vérification statique est en partie assimilable à un relecteur dans la pratique du pair-programming. En effet, un tel outil saura efficacement déceler certaines erreurs mieux et plus rapidement qu'un humain. Néanmoins, cette comparaison me semble se fonder sur une vision très réductrice du binômage. En effet, en plus d'une relecture en continue, la pratique du pair-programming offre un moyen efficace d'assurer la propriété collective du code et permet d'homogéneiser la conception et le code au delà des règles de nommage et de constructions élémentaires. Aussi et surtout, la conception et le code convergent vers un bon produit grâce à la confrontion de deux points de vues (et même plus, puisque le binômes permutent).

Ensuite, l'auteur montre que la vérification formelle permet de détecter des régressions introduites lors d'un remaniement. L'exemple donné est très proche d'une utilisation de la programmation par contrat, mais non compilable. Fort heureusement, depuis la sortie de l'article, AdaCore (http://www.adacore.com/home/) nous a gratifié d'un compilateur Ada2005 incluant un sous ensemble très efficace d'une véritable programmation par contrat (pré-conditions et post-conditions compilées et exercées à l'exécution). Cette nouvelle manière d'utiliser Ada n'exige même pas d'employer un sous-ensemble du langage comme la vérification statique de SPARK l'impose. Bref, la vérification formelle est sûrement un outil puissant, mais un peu moins lorsque la programmation par contrat est pratiquée.

De plus, je pense que l'auteur a tord de suggérer d'éviter de remanier pour les cas ou cela dégraderait la couverture structurelle du code par les tests. Sur nos projets nous remanions sans retenue car l'analyse de la couverture du code par les tests est automatisée dans le build complet activé par l'intégration continue. Les branches non pertinentes sont systématiquement éliminées par les développeurs ou alors les tests sont complétés. Ces pratiques permettent au code de rester malléable.

Enfin, l'auteur regrette de ne pouvoir disposer d'un client sur site. Je pense qu'il s'arrête à une vision dogmatique d'XP. Certes, l'organisation optimale prévoit un client sur site. Sur nos projets, nous n'y arrivons pas, cependant nous travaillons systématiquement avec des représentants internes du client. Il faut savoir adapter XP à son contexte sans trahir les valeurs et les principes de la démarche.

Je remercie Christophe car il m'a donné certains augments pour défendre la pratique d'XP en milieu critique. Il m'a semblé que cet article a surtout été écrit par des vendeurs d'outils qui cherchent à promouvoir leur solution dans un milieu prometteur qui n'y porte que peu d'attention. Un logiciel critique doit s'exécuter de manière sûr. je crois que je préfère porter l'effort de vérification lors de son exécution plutôt que sur une démonstration statique.

Working software is the primary measure of progress.

LE CHANGEMENT ET LES CONFLITS

IRRÉDUCTIBLES GAULOIS

Je travaille dans une grande organisation dont le modèle de fonctionnement n'est pas agile. Le modèle est assez classique des grandes structures françaises qu'elles soient industrielles, administratives, militaires, scolaires ou universitaires. Il s'agit de structures pyramidales, hiérarchisées, descendantes et élitistes. Le changement y est freiné par l'inertie des grandes organisations. On y pratique la séparation de penser et de faire, tout comme dans le paradigme de la production de masse et le cycle en vie en V. Une élite pense des procédures que les d'autres doivent appliquer pour faire.

Pourtant, il existe un appétit de changement. Différentes initiatives locales cohabitent comme la mise en place de la démarche Lean et l'adoption du développement logiciel Agile. Soutenues par la hiérarchie proche, plusieurs équipes agiles y développent des produits, tels des villages d'irréductibles gaulois.

HOUSTON, NOUS AVONS UN PROBLÈME

En ce moment, l'équipe dont je fais partie est en train de traverser une zone de turbulences. Nous sommes confrontés à des conflits à répétition avec les intervenants en périphérie de l'équipe.
Au sein même de notre équipe et avec le Product-Owner, l'ambiance est mouvementée mais dynamique, constructive et réconfortée par des résultats. Par contre, les relations se dégradent avec les acteurs qui ne sont pas directement et quotidiennement impliqués dans la construction du logiciel.

EST-CE UN CAS PARTICULIER?

Curieusement, dans les conférences auxquelles nous assistons et participons (XP Days, Agile Tour), il y a une part importante des sessions qui traitent de la gestion du conflit et de la conduite du changement. Ce que nous vivons n'est donc pas un cas isolé:

Le travail en mode agile déclenche tôt des conflits dans les organisations qui les mettent en place.

POURQUOI? A CAUSE DU CHANGEMENT!

Ces conflits naissent car les équipes auto-organisées conduisent des changements pour lesquels certaines personnes hors de l'équipe ne sont pas préparées. Les équipes agiles adaptent les standards et les meilleures pratiques du moment, elles s'organisent d'elles-même sans chef directif, elles développent des compétences nées du vrai travail d'équipe qui déstabilisent certains experts, elles sont soudées et acceptent les contraintes si elles sont comprises et non imposées par l'extérieur.

Les équipes agiles ne font pas conformément aux procédures pensées par une élite. Elle n'appliquent pas la séparation de pensée et de faire. Elles pensent ET font.

Tout changement déstabilise, mais ce changement particulier a un effet accentué dans une structure élitiste, pyramidale, hiérarchisée et descendante. Ainsi naissent les conflits entre les équipes agiles et leur entourage.

POURQUOI? PAR MALADRESSE!

Nous sommes pris par l'élan de l'équipe. Nous consacrons plus d'énergie à avancer qu'à communiquer sur notre manière de travailler. Certains se sentent exclus de cette dynamique, de cette solidarité d'équipe et ne se sentent plus respectés.
Nous sommes des techniciens passionnés, plus habiles en amélioration continue de nos pratiques de développement qu'en communication et qu'en conduite du changement.
Ainsi, il me semble qu'une organisation qui souhaite mettre en place des démarches agiles se doit d'investir dans la conduite du changement: communication, formation, sensibilisation ...

POURQUOI? PARCE QU'ON LIVRE TÔT!

Des conflits arrivent si tôt dans un projet agile qu'on entend même dire que les démarches agiles sont plus génératrices de conflits que les démarches descendantes. Est-ce vrai?

Pour analyser ce problème, faisons (encore une fois) le parallèle entre l'équipe et son produit.

Sur un projet précédant, nous avons travaillé en mode eXtreme-Programming au sein d'un programme plus large avançant en cycle en V. A l'époque, on nous a reproché de générer plus de défauts que le reste du programme. Pourquoi? Parce que nous levions les défauts plus tôt! C'est le propre des démarches agiles qui testent tôt et livrent tôt du logiciel opérationnel pour obtenir tôt des retours d'informations sur la satisfaction du client.

Pourquoi dit-on qu'une équipe agile génère plus de conflits qu'une équipe descendante? Parce qu'une équipe agile lève les conflits plus tôt!

A partir du moment où plusieurs personnes partagent un même objectif, des conflits apparaissent. Les points de vue se confrontent, tout simplement. Les conflits accompagnent les équipes.
Dans un groupe travaillant en cycle en V, il n'y a pas de vrai travail d'équipe jusqu'à la tardive phase d'intégration. D'ailleurs, l'objectif de la phase d'intégration est de réunir les travaux menés en parallèle. A partir de l'intégration, les crises apparaissent avec le travail d'équipe. Avez-vous vécu des projets en cycle en V qui ne sont pas devenus des poudrières à partir de la phase d'intégration? Et bien les projets agiles travaillent dès le début en équipe. Les conflits sont donc levés bien plus tôt.

Un conflit est à l'équipe ce qu'un défaut est au produit. Plus il est identifié tôt, plus son impact sera limité.

Pour contenir les défauts, les développeurs utilisent les tests. Si on poursuit le parallèle entre conflit et défaut, comment maitriser les conflits dans les équipes?
Les rétrospectives d'itération sont un moment où l'équipe identifie ses dysfonctionnements et se réorganise pour les corriger.

Si le conflit est à l'équipe ce que le défaut est au produit, alors la rétrospective et l'amélioration continue des pratiques est à l'équipe ce que les tests et le remaniement sont au produit.

Bref, il me semble que:

Il n'y a pas plus de défauts dans un produit développé par une équipe agile que dans un produit développé par une équipe travaillant en cycle en V. Par contre, l'équipe agile lève les défauts plus tôt.
De même, il n'y a pas plus de conflits dans une équipe agile que dans une équipe travaillant en cycle en V. Par contre, l'équipe agile lève les conflits plus tôt.

AGILE TOUR 2008 - VALENCE

Ce qui devait être un petit évènement pour tout au plus une cinquantaine de personnes est en voie de devenir une grande date avec 120 inscrits pour le moment!

Le programme de l'Agile Tour est désormais établi et consultable ici. Conférences, ateliers, débats et échanges autour d'un buffet sont au programme de cette demi-journée.

De grands conférenciers nationaux nous font l'honneur de nous présenter des sujets, tels que Régis Médina, Gery Derbier et Alexandre Boutin.

Vu le nombre d'inscris, il semble que l'Agile Tour réponde bien à un besoin. Par contre, je ne sais affirmer de quel besoin il s'agit.

• Est-ce un besoin de recherche d'information sur les méthodes Agiles?
• Est-ce un besoin de lever le nez du guidon et d'assister à des conférences pour élargir son horizon?
• Est-ce un besoin de se rencontrer et d'échanger entre professionnels du développement logiciel?
• Y aurait-il eu autant d'inscriptions avec un autre thème?

Nous tâcherons de répondre à ces questions ce 23 octobre à l'ESISAR. A très bientôt!