Pourquoi cet article ?

Depuis mes débuts dans le développement logiciel j’entends parler de POC (Proof Of Concept). Et pendant un temps, je ne connaissais que ça. Ça suffisait pour faire ce qu’on avait besoin… c’est-à-dire prouver qu’un concept (fonctionnel ou technique), était exploitable pour une situation donnée.

Puis j’ai rencontré le framework SCRUM et la démarche agile, et on a commencé à me parler de Spike. Le but d’une (ou d’un, je ne sais jamais) spike étant de faire du quick & dirty au niveau code mais d’acquérir, entant que développeur, l’expérience nécessaire sur un sujet (technique ou fonctionnel encore une fois) afin de pouvoir se prononcer sur l’effort nécessaire à mettre en place des US dans ce domaine précis.

Etant principalement dans des équipes agiles, j’ai même été jusqu’à créer des POC (en fait des MVPs) de manière itérative et incrémentale tout en utilisant des spikes pour avancer.

Maintenant que j’ai la chance de pouvoir prendre du recul sur le travail des équipes, je rencontre assez régulièrement des situations dans lesquelles je vois des user stories embarquées dans un sprint qui représentent un POC… et donc je voulais explorer un peu le sujet POC et Spike dans cet article.

Une notion de livrable ?

De mon point de vue, l’objectif d’un POC et d’une Spike n’est pas le même. Une Spike a pour objectif d’aller acquérir de la connaissance sur un sujet, pour que l’équipe puisse se prononcer sur la difficulté de mise en œuvre. Un POC a pour objectif d’explorer un sujet pour prouver qu’il est utilisable et que nous pouvons produire une solution fonctionnelle et/ou technique adéquate.

Comme l’objectif n’est pas le même, ce qu’on attend en terme de production n’est forcément pas le même. Un POC doit produire quelque chose d’utilisable : un morceau de code lisible et propre pour tout le monde, une procédure claire et précise concernant le sujet exploré…  Une spike doit produire de la connaissance, elle n’est pas forcément génératrice de livrable spécifique mais doit proposer une aisance accrue de l’équipe sur une estimation de l’effort à déployer pour répondre aux besoins qui mettrons en œuvre cette nouvelle technologie ou fonctionnalité.

Et une notion de temps différente…

Comme l’objectif et le livrable ne sont pas les mêmes, la temporalité n’est pas non plus la même (dans mon esprit). Là où le POC se doit de produire quelque chose, une spike se doit d’être limitée dans le temps. Généralement, un POC embarqué dans une itération sera évalué en point par l’équipe (car elle possède déjà quelques connaissances lui permettant de traiter le POC) alors qu’une spike sera en fait une quantité de temps allouée à l’exploration.

Si, à la fin du temps imparti à la spike, la connaissance acquise n’est pas suffisante, dans tous les cas le sujet s’arrête pour ce sprint et l’équipe décidera (avec le PO) au moment du planning de la prochaine itération, si on continue à explorer ce sujet.

Si un POC est plus difficile à produire que ce que l’équipe avait projeté, bien sur il y aura discussion avec le PO mais ce qui arrive le plus souvent c’est que le sprint sera sans doute en échec (engagement global non tenu) à cause d’US non terminée(s).

Un livrable et un appétit.

Vous allez me dire que je joue sur les mots… oui et non. Certes la définition même de ce qu’on déploie comme pratique est importante mais c’est pour moi avant tout deux outils qui répondrons à des besoins différents. Le POC répond à un impératif de prouver une idée, un concept (comme son nom l’indique), et l’effort impliqué n’est pas en question (dans la limite du raisonnable). La spike répond à un appétit de l’équipe (et du PO) sur l’exploration… une fois cet appétit dépensé on se pose la question de savoir si nous sommes rassasiés ou si nous devons encore goûter au sujet.

Conclusion

Quel que soit le terme utilisé, je trouve que ces deux notions sont importantes à connaitre pour une équipe agile : soit on se focalise sur le rendu, soit on se focalise sur l’effort.

J’aime beaucoup la notion d’appétit et j’avoue que je l’ai exploré pour la première fois grâce à la démarche Shape Up, je vous conseille donc de lire leur livre blanc si vous ne l’avez pas encore fait…