Distinguer, regrouper, articuler

Quand on est plongé dans un contexte, avec ses particularités (et ses concessions dues à l’organigramme), on perd un peu le nord, la vision claire, les concepts et les rôles se mélangent ou se scindent artificiellement

Distinguer

• Exemple 1 : le product owner doit gèrer le « quoi », l’équipe (animée par le scrum master) doit gérer le « comment ». Le product owner exprime des besoins, des histoires utilisateurs, l’équipe fait des maquettes et des suggestions. On se laisse par exemple facilement embarquer dans des situations où c’est le product owner qui fait des maquettes (ne serait-ce que pour échanger avec les utilisateurs), avec les implications que cela peut avoir en terme de faisabilité et de coût.
• Exemple 2 : dans le cadre d’un contrat, l’estimation « vendue » qui correspond plus à une évaluation du prix que le client est prêt à payer pour la fonctionnalité et l’estimation par l’équipe, qui vient souvent plus tard et qui correspond au coût de réalisation objectif, à la complexité réelle.

Regrouper

• Exemple 3 : les tests. Quand on implémente une fonctionnalité à base de flux, on est bien obligé de la tester sur des fichiers de données, dans le cadre même des tests unitaires ou d’assemblage des différentes couches. A quoi bon séparer dans ce cas les tests dits « fonctionnels » ou d’intégration et les tests unitaires ? Une approche à base de fitnesse réconcilie les deux, en fournissant à l’équipe les données avec lesquelles tester. Mais cela suppose que l’on admette qu’il y a une étape de test unitaire et une étape de test d’intégration.

Articuler
Exemple 4 :  On entend tout et n’importe quo sur XP, Scrum et Lean Software Development, sans parler de Software Craftmanship.

• Scrum est venu après XP, ceux qui l’appliquent s’inspirent souvent de XP pour les sujets que Scrum ne couvre pas.
  Scrum ne couvre pas tout (en particulier par les activités d’ingéniérie), pour lesquelles certaines pratiques xp restent pertinentes. Il faut aussi considérer les pratiques plus modernes (TDD, TDR), voire Software Craftmanship.
• Scrum est un processus de développement, ce que XP faisait de manière plus diffuse, moins formelle.
• Scrum et XP viennent en partie du Toyota Way, repris de manière peut-être plus directe par Lean Software Development.
• Scrum est plus adapté pour les developments (orienté quantité de valeur métier que l’on arrive à faire rentrer dans un plan de charge), Lean (en particulier l’approche Kanban (pull) ) pour la maintenance (orienté délai de prise en compte des demandes métier).
• Certains débats sur Software Craftsmanship le voient comme un mouvement post-agile. D’autres comme une approche hyper-rétrograde. Selon moi, le Software Craftsmanship est dans la continuité de XP : une réflexion innovante sur les pratiques d’ingéniérie. Le débat avec l’agilité consiste « juste » à trouver un équilibre (enfin) entre livrer de l’utile au plus vite et maîtriser la capacité à livrer de l’utile par la suite.
• Etc..

Chers lecteurs, à vos claviers !