Autour des méthodologies de développement logiciel

Un article posté sur Hacker News m’a entraîné dans une suite de développement sur les méthodologies de développement logiciel.

La problématique est la suivante : comment peut-on industrialiser le développement logiciel – c’est à dire faire en sorte d’obtenir des résultats prédictibles en terme de temps et de qualité ?

Et son corollaire : parmi les multiples méthodes de développement logiciel qui n’ont pas manqué d’être proposées depuis quarante ans, pourquoi est-ce qu’aucune ne semble atteindre ce but ?

Le point de départ est un article de Ian Miell, My 20-Year Experience of Software Development Methodologies.

Sa thèse est que toutes les méthodes de développement qu’il a rencontré dans sa vie professionnelle (Waterfall, Flow, Agile, ou n’importe quoi de vaguement indéfini) sont des fictions collectives. Ces méthodes ne sont pas bonnes ou mauvaises en soi – mais permettent de s’organiser en grands groupes suivant différents principes partagés par tous.

Lean, Agile, Waterfall, whatever, the fact is we need some kind of common ideology to co-operate in large numbers. None of them are evil, so it’s not like you’re picking racism over socialism or something. Whichever one you pick is not going to reflect the reality, but if you expect perfection you will be disappointed.

Au passage, un lien pointe vers cet autre article d’il y a quelques années, Why don’t software development methodologies work?. En résumé, l’article dit ceci :

Once a programming team has adopted a methodology it’s almost inevitable that a few members of the team, or maybe just one bully, will demand strict adherence and turn it into a religion. The resulting passive-aggression kills productivity faster than any methodology or technology decision.

Si pour lui par essence aucune méthodologie de développement logiciel ne fonctionne, par sédimentation des rituels, il voit quand même un critère qui permet de prédire le degré de succès d’une équipe de développement :

My own experience, validated by Cockburn’s thesis and Frederick Brooks in No Silver Bullet, is that software development projects succeed when the key people on the team share a common vision, what Brooks calls “conceptual integrity.” This doesn’t arise from any particular methodology, and can happen in the absence of anything resembling a process. I know the feeling working on a team where everyone clicks and things just get done.

Ce qui me mène vers des recherches effectuées par des employés de Google, sur d’autres critères qui influencent la performance d’une équipe de développement.

Leur prémisse est que le succès d’un projet dépend plus de l’équipe que de la méthodologie employée. Et d’après l’expérience des auteurs, cinq critères semblent être prédominants :

1. Psychological safety: Can we take risks on this team without feeling insecure or embarrassed?
2. Dependability: Can we count on each other to do high quality work on time?
3. Structure & clarity: Are goals, roles, and execution plans on our team clear?
4. Meaning of work: Are we working on something that is personally important for each of us?
5. Impact of work: Do we fundamentally believe that the work we’re doing matters?

Je ne peux parler que pour moi, mais j’ai effectivement retrouvé tous ces critères dans les boulots où je me suis vraiment plu. Et inversement, dans les endroits ou les moments plus disfonctionnels, je retrouve bien ce qui manquait dans les éléments de cette liste. Comme quoi…

🚀 Partager les succès

Si vous travaillez sur un projet dans une petite équipe, il est sans doute facile de suivre ce qui se passe en ce moment. Qui fait quoi, quels sont les sujets du moment, quels sont les dernières modifications visibles et les dernières étapes effectués.

Mais au fur et à mesure que l’équipe grandit, ce sens de « qu’est-ce qui se passe en ce moment » devient plus difficile à appréhender. Et on découvre un jour qu’on n’était pas au courant de telle nouveauté, de tel changement dans l’équipe d’à côté, ou de tel recrutement. Ça a été annoncé, sûrement – mais peut-être pas aux bonnes personnes, ou au bon moment.

Chez Capitaine Train, on avait mis au point une petite convention simple pour rendre les succès plus visible.

“There are things that can give you wings, but I’ll give you a rocket!”

Pour partager les succès, pas besoin d’en faire des caisses. Ce qu’on faisait, c’est simplement de poster un message dans un canal public sur le chat interne (Slack, en l’occurrence).

Une seule règle : mettre un emoji :rocket: 🚀 au début du message.

C’est tout.

Pas besoin d’être bien long ; il s’agit juste de communiquer aux autres une nouveauté dont vous êtes heureux ou fier :

• 🚀 Les utilisateurs du site peuvent enfin modifier leur adresse email de contact.
• 🚀 Le bogue pénible d’envoi des notifications a été corrigé
• 🚀 Nos affiches sont visibles dans le métro depuis ce matin !
• 🚀 C’est confirmé, Eva nous rejoindra en mars comme data-scientist

Comme c’est très léger, ça ne prend pas beaucoup de temps à écrire.
Comme c’est rapide, on hésite pas à annoncer la petite nouveauté dont on est fier, même si ce n’est qu’un petit détail.
Comme c’est juste une convention, ça ne rajoute pas un processus de plus.
Et comme c’est sur Slack, ça permet de recueillir les félicitations et les applaudissements (et c’est important, les applaudissements).

Composer les outils pour aller plus loin

La beauté des conventions, c’est que ça active plein de possibilités. On peut s’en servir pour faire plein de belles choses en plus.

Par exemple, pour les changements qui s’y prêtent, on peut ajouter une image à son annonce : une capture d’écran, la photo de la personne recrutée, ou un gif animé qui présente une nouvelle fonctionnalité.

Pour être notifié de ces annonces spécifiquement, il est possible de rajouter :rocket: à la liste des mots-clefs qui déclenchent une notification. Ça peut permettre de mieux filtrer le bruit, et de n’être notifié que de ce qui est important.

Enfin, il est assez simple de générer une newsletter interne, mensuelle ou bimensuelle, à partir de ces annonces. Une simple recherche sur 🚀 renverra tous les messages à inclure dans la newsletter. Il est même possible d’automatiser le processus : coder un petit bot pour Slack qui recopie les :rockets: dans une planche Trello ; et un autre bot qui, une fois les annonces mises au propre, envoie automatiquement une newsletter avec le contenu de la planche.