SigmaT8

Le SigmaT 8ème du nom fut un bel évènement et a accueilli une cinquantaine de personnes.
Au programme :

Planification

La première présentation illustre bien la nécessité du plan de release, trop souvent négligé ou mal compris.
A travers un exemple précis et compréhensible de tous, Claude nous montre (entre autres) l'importance de la priorisation des éléments du backlog. A ce sujet, j'aimerais précisé que souvent, le client exprime le besoin d'une certaine "transversalité" des stories: autrement dit, il est souvent nécessaire de détailler quelques éléments des features globalement moins prioritaires pour obtenir dès les premières versions un produit illustrant "horizontalement" le produit final.
Exemple : initialement on détaille les features "Annonce", "Inscription" et "Comptes-rendus", on détaille moins "Programme", "Communauté", et encore moins "News", "Video & podcasts". Par contre, on isole certaines stories "clefs" parmi les features moins détaillées, on les détaille et on les sélectionne pour les 1ères livraisons.

Concernant les estimations, Claude rappelle la technique d'estimations en points, relatives par rapport à un étalon.
Pour ma part, je pense que dans la pratique, il est difficile de n'avoir qu'un étalon pour comparer certaines stories de nature très différentes et on en choisit donc souvent plusieurs.

Modélisation

La présentation de Pascal reprend point par point les bonnes pratiques de modélisation agile énoncées par Scott Ambler. Beaucoup de bon sens... y compris si on génère du code !
On fait toujours du whiteboard avant tout chose, on élabore les modèles en groupes, on choisit les bons diagrammes pour chaque problème, on sait se limiter dans les complexité des modèles, on applique des standard etc

Nous avons pris les mêmes références que Scott Ambler : l'articulation valeurs / principes / pratiques d'eXtreme Programming et montrons que globalement, rien ne s'y oppose à conditions de mettre en place l'environnement adéquat, tout comme il est nécessaire de mettre en place un environnement adéquate pour faire du XP sans génération. La différence essentielle, et certes pas des moindres, et la compétence spécifique à acquérir pour mettre en place un générateur. Nous avons déjà introduit tout cela dans nos précédents billets.

Nous réagissons particulièrement à l'analogie qu'à fait Pascal entre "Surmodélisation" et "Model Driven Engineering (MDE)". Une fois de plus, nous avons là un détracteur de la génération de code, dégouté par des années de tentatives infructueuses avec les solutions standards du marché.

Pour nous, le Model Driven n'est pas de la "surmodélisation" mais un savant équilibre entre ce qui doit être modélisé-généré, le travail que doit prendre en charge le générateur, et le travail des développeurs en charge du code "manuel". L'objectif du MDSD n'est pas de générer 100% du code et ne l'a jamais été. Nous le voyons davantage comme une alternative puissante de production logicielle qui, entre autres, affranchit les développeurs des tâches à faible valeur ajoutée. Le génie logiciel évolue en permanence et de nouvelles solutions intelligentes émergent avant de devenir matures à leur tour. Restons ouverts et objectifs sur les bénéfices potentiels de celles-ci.

Encore une fois, nous sommes prêt à la plus grande transparence concernant les éventuels manquements que présenterait notre vision vis-à-vis de l'agilité, mais nous demeurons convaincu de leur compatibilité !
Nous en reparlerons d'un SigmaT exclusivement sur le thème de la modélisation qui devrait avoir lieu début 2009.

Retour d'expérience

Olivier nous a montré, une fois de plus, le succès de Scrum dans des environnements où le logiciel est critique et comme tout retour d'expérience, qu'on peut être agile sans appliquer toutes les pratiques agiles.
J'abonde dans son sens quand il précise (oralement) que pour faciliter la mise en place de la technique des estimations, on peut avoir recours à des rapprochement au temporel. Je renvois le lecteur à son très utile billet sur le sujet.
Les estimations reviennent souvent dans les sondages comme les pratiques les moins évidentes.
Elles requièrent un accompagnement particulièrement proche.