Je viens de regarder la conférence d’Allan Kelly sur sa vision des projets.
Le moins qu’on puisse dire, c’est qu’il déménage.
Je connaissais déjà Allan pour ses Dialogue Sheets que j’avais déjà utilisées.
Il part du principe qu’un logiciel n’est jamais fini. Ou alors, lorsqu’il est terminé, c’est qu’il est mort. Il cite les exemples de MS Office ou bien de certains logiciels bancaires qui tournent depuis les années 70.
A l’inverse, dans toutes les méthodes, on nous dit qu’un projet possède une durée limitée dans le temps, une date de fin. Mais qui a fixé cette limite ? Est-ce la charge estimée ?
Comme nous l’enseigne l’agilité, un logiciel doit d’abord et avant tout apporter de la valeur. Et la date peut faire partie de cette valeur !
Cela me rappelle mon expérience professionnelle. Pour un produit, il nous fallait livrer pour juin. C’est à cette période que les acheteurs des grandes surfaces achètent sur étagère pour Noël un produit qu’ils ont vu fonctionner. Le logiciel devrait donc être prêt à cette date. Il ne devait rester ensuite que la production électronique et l’acheminement. Dans cet exemple, on mesure bien la valeur de la date. Si on n’est pas capable de livrer à temps, ce n’est même pas la peine de faire le produit !
Allan cite le modèle de Tuckman qui décrit les 5 étapes de la construction d’une équipe. Mais pourquoi donc faut-il dissoudre une équipe qu’on a mis tant de temps à bâtir ? Comment rentabiliser tout cet investissement ? Simplement, en maintenant l’équipe ! On peut très bien la mettre sur une autre activité pendant quelle assurera les évolutions (la maintenance ?) du produit précédent. Une même équipe peut très bien s’occuper de différents produits, surtout s’ils sont similaires.
Contrairement à beaucoup d’autres aspects économiques, le monde du logiciel ne supporte vraiment pas bien les effets d’échelle. Plus le projet est gros, plus il demande de spécifications, de lignes de code et de tests. Et donc, plus il est risqué !
Contrairement aux autres produits qui coûtent plus chers lorsqu’ils sont vendus en petits emballages, le logiciel, lui, coûte moins cher quand il est petit. Il faut arrêter de voir grand, mais plutôt, il faut penser petit, même si ce n’est pas sexy.
Un très gros projet induit un maximum de risques, mettons 30%. Le découper en deux projets permet d’avoir un risque lui aussi découpé par deux, soit 15% sur chaque projet et donc 15% au total pour les deux projets. Et si on le découpe en 6 projets avec un risque de 6%, la somme des risques des 6 projets reste à 6%.
Allan recommande d’arrêter de mentir aux gens : il ne faut plus appeler projet avec une date de fin ce qui n’est que du travail continu, le développement d’un produit logiciel. Il continue de provoquer en proposant un nouveau modèle : reprendre le terme de cascade ! Oui, la cascade est un flux continue d’eau qui tombe verticalement, c’est-à-dire que le temps passé entre le début de la cascade et la fin est extrèmement court.
En conclusion, il insiste sur des petits travaux, de devenir bons en les faisant bien, d’aller vite, de rechercher de la valeur et de ré-itérer, pas de s’arrêter.
Il transforme le moto traditionnel Agile en « fail fast, fail cheap », à la manière des sociétés de capital risques qui s’engagent peu pour éviter de perdre beaucoup.
Oublier les projets et considérer le « business as usual ».