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 !

Communautés et paradigmes

Différents paradigmes (contradictoires) peuvent être présent pour un même contexte :

• Méthodes agiles. Customiser le mode de fonctionnement pour chaque projet. Notion de cône d’incertitude pour expliquer que les estimations initiales sont très aléatoires. L’idée d’abaque de chiffrage est impensable
• CMMI. Formaliser les pratiques, donc les uniformiser pour tous les projets, jusqu’à faire des statistiques (des charges, mais aussi des taux de defauts, …)
• Software craftsmanship. Emphase mise sur les pratiques d’artisanat (parfois par opposition à l’ingéniérie).

On les oppose, mais dans un contexte réel, il faut plutôt chercher à la articuler, à les faire coexister.

En effet, les méthodes agiles me semblent parfois être le rêve fou de développeurs qui ont pris le pouvoir. Software craftsmanship de vieux développeurs expérimentés, pour les “techniques” par opposition aux gestionnaires, pour la créativité individuelle par rapport à l’uniformité et à la norme. CMMI de chefs de projet (et encore il y a PMBOK), PMO et ingénieurs qualité. Tous ces profils ont leur place dans un ecosysteme.

Chaque contexte se fait sa sauce. A quand un paradigme chapeau ? Voire un guide avec pour chaque aspect des alternatives avec chacune ses conditions d’application ? Et une cross-fertilization (enrichissement mutuel d’approches différentes) ?

Mécanique de la compréhension d’une nouvelle techno

IMHO, la compréhension d’un sujet n’est pas une activité continue mais une succession d’instants de compréhensions, de révélations plus ou moins profondes.

D’abord un peu (on est exposé par hasard au sujet, ou indirectement), ensuite beaucoup (on est confronté à une doc riche sur le sujet, qui s’entrechoque avec les éléments que l’on avait) ensuite cela s’épuise.

Puis on pratique le sujet professionnèlement, en confrontant le modèle mental que l’on a à l’expérience. De nombreux instants de compréhension, puis cela rallentir.

En parallèle on échange (beacoup d’impact au début de la discussion avec chaque interlocuteur, puis moins) puis de moins en moins.

Puis on s’exprime sur le sujet. L’effort de rédaction, la confrontation des sources, dans un but précis (auditoire (experts ? novices ?), format (présentation ? formation ?), tout cela bouillone et affine la maturation, sans parler des questions de l’auditoire.

Enfin, la confrontation du sujet avec d’autres problématiques d’autres domaines, la cross-fertilization, apporte les quelques dernières gouttes.

Et puis on passe à autre chose !

Scénarii

Peut-être est-ce du à notre enfance bercée par les histoires racontées avant de s’endormir, toujours est-il que nous appréhendons la réalité à l’aide d’histoires, de scénarii.

Quand on spécifie un système informatique, il s’agit des “use cases”, histoires racontant ce qui se passe concrètement quand l’utilisateur fait telle ou telle action. La liste des uses cases permet d’avoir une vision d’ensemble, macro, des fonctionnalités que doit remplir le système. C’est là que ça se gâte. D’abord parce qu’on est réduit à avoir recours à un formalisme abscons (extension, héritage, inclusion,…) parce que l’utilisateur peut vouloir parcourir le système en suivant des voies diverses. Les décrire toutes est impossible. S’en tenir aux use cases identifiés est réducteur. Ensuite, on se rend bien compte que cette description, bien pratique sous l’angle contractuel ou de la rédaction des tests, pêche dès qu’il s’agit de rendre la complexité du métier. On ajoute alors des “business rules”, des renvois sans fin et le document devient illisible.

Quand on gère un projet, on cherche à gérer les risques. Les identifier, les anticiper, prendre des actions préventives. Pour gérer les risques, il faut les identifier. On se fait donc une image mentale du système, on essaie de dérouler tout ce qui peut se passer (utilisation normale, intrusion, crash système, incident d’exploitation, …). On affecte ensuite une probabilité à l’incident (celle que la salle machine soit détruite par une explosion nucléaire est faible par exemple). Si l’incident est jugé probable, on construit un nouveau scénario incluant le fruit d’actions préventives. La difficulté de cet exercice, c’est de savoir jusqu’où allé, ce que l’on gère et ce sur quoi on fait l’impasse. L’autre difficulté c’est l’exhaustivité. Penser à tout. C’est un réel travail de créativité, qui gagnera beaucoup à être réalisé en groupe. Malheureusement, la mise en situation étant relative, nous avons tendance à “découvrir” des problèmes au dernier moment, alors qu’il est trop tard…

Modèles mentaux et idoles

Je suis en train de finir “Death March: The Complete Software Developer’s Guide to Surviving “Mission Impossible” Projects ” de Edward Yourdon qui parle d’un peu tout sur les projets “plan loose”, et, pour ce qui m’intéresse ici, des modèles mentaux.

Comment s’organise l’expérience “soft” que l’on acquiert en général et en gestion de projet en particulier ?

J’ai tendance à retenir ce qui a pu marcher, sous forme de règles (non écrites) du genre : si tel évènement se produit, alors ca veut dire que tel fait est vrai et dans ce cas il faut prendre telle action. On reproduit ce qui a fonctionné par le passé.

Le problème étant dans ce cas que les choses ne sont pas forcément identiques. Il ne s’agit pas des mêmes personnes, de la même culture d’entreprise, du même contexte, du même historique. Même l’auteur de ces lignes à changé. Et donc une fois l’action prise, les conséquences ne seront pas les mêmes.

J’ai une autre tendance, qui consiste à idéaliser les gens avec qui j’ai pu tavailler. Vous n’avez pas connu Jacques R. ou Philippe R. ou Henri P. ou Georges H. . Moi si. Ils ont représenté à un moment donné l’idéal, même perfectible, le modèle, l’idole. Et donc même après avoir travaillé avec eux, ils reste un écho de nos échanges, de leur propos, un fantôme qui peut vouloir me guider.

Le problème c’est que dans la situation présente, ils n’auraient pas forcément réagi comme ils ont réagi par le passé. Et quand bien même ils auraient eu une réaction simillaire, ma mémoire défaillante ne m’aurait pas restitué tous les détails. Et même si j’avais tous les détails, je n’ai pas forcément les qualités pour faire les choses comme ils l’auraient fait.

Conclusion : conserver l’esprit du débutant pour rester vigilant et adapter son comportement à ce qui se passe, ici et maintenant, avec les personnes présentes.