« Fusées, voitures et jardins : visualiser le modèle en cascade, le processus Agile et la méthode du passage de portes » : différence entre les versions

Traduction : <br/>

<br/>

<br/>

Plus je creuse dans les pratiques de développement de nouveaux produits, plus j’ai envie de trouver une manière simple d’aider les gens qui tentent d’en visualiser rapidement les concepts. Dans cet esprit, je vous ai organisé un petit voyage illustré à travers les paysages fascinants du modèle en cascade, du processus agile, du modèle de gestion de portefeuille et de la méthode du passage de portes. Pour se faire plaisir, il y a aussi une description de la façon dont vous pouvez appliquer des techniques de gestion de portefeuille à des projets agiles, notamment pour réduire les risques de conception.<br/>

'''Développement de logiciels sous la forme de travaux pratiques'''<br/>

<br/>

* '''La connaissance est essentielle pour réussir''' : un grand nombre de projets logiciels échouent parce que nous construisons du logiciel qui a en fait peu de valeur métier. Si vous cherchez les raisons profondes, même les équipes ayant de fortes compétences de production, clament haut et fort qu’elles se concentrent sur de fausses problématiques et qu’elles ne comprennent pas du tout ce que le client souhaite réellement. Lorsque vous construisez le mauvais logiciel, vous vous retrouvez avec du code inutile, un certain manque de soutien politique et des cycles de développement sans fin. Si l’équipe a une connaissance claire et fiable de ce qu’il faut construire, elle peut offrir de la valeur très tôt.

* '''La plupart des équipes de production démarrent avec une piètre connaissance pratique''' : c’est très bien d’avoir la connaissance, mais généralement nous lançons les projets sans en avoir beaucoup. Nous ne savons pas exactement ce que veulent nos clients. Nous ne savons pas comment notre conception va fonctionner une fois propulsée dans la complexité du monde réel. Nous ne savons pas quelles nouvelles opportunités et quelles contraintes vont apparaître dans l’avenir. Même si nous sommes experts dans un domaine précis, le meilleur que nous pouvons tirer de cette expertise ce sont généralement des théorèmes, des conjectures et des opinions.

Dans la plupart des modèles en cascade traditionnels, les équipes recueillent le besoin, développent le produit puis le testent afin de voir si elles ont correctement implémenté les spécifications. C’est seulement après avoir livré que ces équipes obtiennent des indications plus précises sur ce que le client souhaite réellement. La métaphore qui est souvent utilisée est celle du lancement d’une fusée vers une destination. Vous ne pouvez viser l’objectif qu’une seule fois, vous tirez et ensuite vous priez pour avoir touché la cible. Tout va bien, sauf que A) c’est une fusée qui brûle beaucoup d’argent pour le carburant et B) quand elle n’atteint pas son objectif, l’équipe entière (et parfois l’entreprise) est virée.<br/>

<br/>

<br/>

Cependant, tout n’est pas perdu. Si votre entreprise a assez d’argent à brûler, elle peut de nouveau essayer. Il y a de bonnes chances que l’équipe ait appris beaucoup de choses sur ce que leurs clients souhaitent effectivement adresser sur son marché, de sorte que le prochain tir a de meilleures chances d’atterrir au plus près des besoins réels du client.<br/>

<br/>

<br/>

Maintenant, la bonne blague c’est que « Si vous voulez correctement construire une partie du logiciel, vous devrez la réécrire quatre ou cinq fois. » Finalement, si vous continuez à essayer assez longtemps, vous aurez atteint le marché cible concerné par votre produit. Certaines grosses entreprises ont investi une énorme quantité d’argent dans cette poursuite obstiné du succès. Elles échouent encore, encore et encore, mais les quelques succès qu’elles obtiennent leur permettent de poursuivre de nouveaux objectifs métiers et de croître. L’apprentissage se révèle assez cher, mais précieux au final.<br/>

<br/>

<br/>

'''Place à l’amélioration'''<br/>

Si le modèle en cascade c’est comme tirer une fusée sur une cible, le modèle de gestion de portefeuille c’est comme tirer une volée de fusées en espérant qu’une d’elles touchera la cible. L’entreprise donne son feu vert à un grand nombre de projets, les finance entièrement et espère que l’un d’eux se transformera en succès. Vous dépensez de l’argent, mais en contrepartie, vous aurez rarement besoin d’attendre la version 3.0 pour constater le succès.<br/>

<br/>

<br/>

Ce modèle est très utile lorsque le marché cible est mal compris ou, par nature, éphémère. Par exemple, dans l’industrie de la musique, lorsque les goûts de l’utilisateur changent tous les mois, cela n’a pas de sens de passer trois ans à tenter de faire évoluer un album pour s’adapter au marché. Cela se révèle aussi utile lorsque le coût de développement est faible et que les gains potentiels sont élevés. Le coût supplémentaire d’un feu vert pour un autre projet peut être facilement compensée par la quantité incroyable d’argent générée par un disque qui a cartonné.<br/>

Les petites équipes ont appris à maximiser leurs possibilités d’apprentissage en se donnant un maximum de chances d’obtenir des retours rapides dans leur processus. Je mets ici en avant le développement agile de logiciels, mais on tire les mêmes leçons avec le lean manufacturing, le kaizen et d’autres pratiques efficaces utilisées par un large éventail de sociétés de développement de produits.<br/>

<br/>

<br/>

La métaphore courante est celle de conduire une voiture au lieu de lancer une fusée. Chaque fois que c’est possible, vous regardez la route et vous ajustez la trajectoire de l’équipe afin de l’orienter. Chaque changement peut sembler subtil, mais grâce à tous ces ajustements rapides et cumulés, l’équipe répond efficacement aux objectifs.<br/>

<br/>

<br/>

L’équipe commet bien sûr quelques erreurs. Si elle dévie un peu vers la gauche, c’est très bien. Elle apprend rapidement qu’il s’agissait d’une mauvaise idée et elle corrige ses actions. Les cycles rapides de feedback garantissent ainsi que les grosses erreurs arrivent beaucoup moins souvent.<br/>

<br/>

<br/>

Au lieu de prendre 12 à 18 mois pour créer et évaluer un nouveau concept, les équipes construisent et livrent leur nouvelle version aux utilisateurs toutes les 2 à 4 semaines. Elles travaillent également dans des environnements très communicants où tous les membres de l’équipe sont proches et proches du client. Les membres de l’équipe vont dans la même direction et en se mettant d’accord sur de bonnes idées en quelques heures, et non pas en quelques mois. Les équipes deviennent expertes dans la résolution de problèmes et dans les tests. Cela finit par construire des produits qui sont susceptibles de beaucoup mieux répondre aux besoins réels des clients plutôt que ceux imaginés dans les spécifications platoniciennes rédigées par des experts dans leurs tours d’ivoire.<br/>

Un projet agile est très ciblé. Dans la course effrénée pour obtenir uniquement les fonctionnalités les plus prioritaires, de nombreux autres concepts n’ont pas la chance d’être explorés. Chez le client, on demande à un groupe, qui a l’habitude de s’exprimer de façon vague ou sans réel consensus, de parler d’une seule voix pour réduire le bruit et le gaspillage dans l’équipe. Pour de nombreuses équipes qui se battent pour sortir des logiciels en temps et en heure, c’est une bénédiction. L’inconvénient, c’est qu’il reste peu de place pour une gestion de portefeuille stratégique.<br/>

<br/>

<br/>

Les projets agiles se comportent un peu comme un algorithme d’optimisation combinatoire$$NdT : hill-climbing algorithm = méthodes de descente. A chaque pas de la recherche, cette méthode progresse vers une solution voisine de meilleure qualité. La descente s’arrête quand tous les voisins candidats sont moins bons que la solution courante ; c’est-à-dire lorsqu’un optimum local est atteint.$$. Ils vous guideront vers le succès le plus proche du client, mais passeront peut-être à côté d’une solution plus prometteuse, mais qui se situe plus loin.<br/>

Nous pouvons faire mieux que le développement agile pur ou le développement par gestion de portefeuille pur. Le processus par passage de portes emprunte aux techniques à la fois de l’itératif et du modèle de gestion de portefeuille. Vous lancez toujours plusieurs produits, mais vous utilisez des techniques de développement itératif pour guider chaque projet vers le succès. Vous "tuez" les projets qui ne parviennent pas à atteindre vos objectifs.<br/>

<br/>

<br/>

Imaginez que nous sommes des jardiniers. Nous semons un portefeuille diversifié de projets, certains à haut risque, d’autres à faible risque. Puisque nous gérons maintenant les retours de l’équipe et des clients, les projets commencent à s’épanouir, en progressant vers la plateforme de lancement ensoleillée. Les pratiques de développement de l’équipe peuvent être agiles puisque nous voulons encourager des cycles courts avec des feedbacks rapides. Les meilleurs d’entre eux commencent à fleurir et mûrir en produisant une valeur client évidente. Néanmoins, certains projets sont maladifs et semblent peu susceptibles de produire quoi que ce soit.<br/>

* '''Banques de concepts''' : le troisième point sont les banques de concepts où les anciennes idées sont conservées pour un éventuel recyclage. Vous ne savez jamais quand les restes d’une vieille idée iront nourrir un nouveau projet prometteur.<br/>

<br/>

<br/>

Vous pouvez commencer avec des dizaines de projets, mais à la fin vous en lancerez seulement quelques-uns sur le marché. La combinaison qui consiste à tenter diverses directions avec de très petites équipes agiles à faible coût augmente considérablement vos chances d’apprendre par rapport à la technique agile pure ou à la technique de gestion de portefeuille pure.<br/>

Un produit unique peut grandement bénéficier des idées générées par le modèle de passages de portes. Un produit est composé d’une variété de fonctionnalités distinctes, de scénarios et d’utilisateurs. Nous pouvons considérer chaque quantité de valeur pour le client comme un projet distinct et cette quantité de projets de grande valeur en tant qu’un produit. Le modèle de base est le même que le processus de passages de portes décrit ci-dessus. Cependant, au lieu de gérer de multiples produits, vos équipes vont se concentrer sur les processus critiques ou les scénarios d’utilisation pour un seul produit.<br/>

<br/>

<br/>

Pour revenir à la métaphore du jardin, pendant que vous entretenez ces zones de grande valeur, vous devriez toujours avoir des projets qui sont mûrs pour être livrés. Cela doit être aussi simple que de générer une version publique qui désactive tous les projets expérimentaux en ne laissant que vos meilleures fonctionnalités pour les montrer au client. Pensez-y comme s’il s’agissait de récolter vos meilleurs fruits pour vos clients préférés.<br/>