Voir la source de Fusées, voitures et jardins : visualiser le modèle en cascade, le processus Agile et la méthode du passage de portes

[[Category: Portail Product Owner]]
[[Category: Portefeuille]]
Auteur : Happy Danc<br/>
Source : [http://www.lostgarden.com/2007/02/rockets-cars-and-gardens-visualizing.html Rockets, Cars and Gardens: Visualizing waterfall, agile and stage gate]<br/>
Date : 18/02/2007<br/>
----
Traducteur : Fabrice Aimetti<br/>
Date : 03/01/2011<br/>
----
Traduction : <br/>
<br/>
[[Fichier: Rocket-Car-Garden2-788212.jpg|500px|link=]]<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/>
<br/>
Les concepts illustrés ici sont facilement applicables à la plupart des projets logiciels, y compris des jeux, des sites web et bien sûr des applications client lourd.<br/>
<br/>
'''Développement de logiciels sous la forme de travaux pratiques'''<br/>
<br/>
Tous les schémas sont basées sur deux prémisses :<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.
<br/>
L’objectif du développement de produits est de produire rapidement des solutions ciblées qui génèrent un maximum de valeur pour le client. Pour le faire efficacement, nos équipes doivent être des équipes apprenantes qui ne cessent de collecter des connaissances concrètes sur les besoins des clients. Une équipe qui apprend à connaître les particularités de ses clients, du code et du métier, obtiendra souvent plus rapidement de meilleurs résultats que les équipes qui travaillent sans cette connaissance. En partant de ce concept, nous allons observer la manière dont certains scénarios de développement typiques peuvent être traités par une équipe apprenante.<br/>
<br/>
'''Développement typique d’un seul produit'''<br/>
<br/>
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/>
[[Fichier: Iteration-Diagrams-Waterfall1-756439.jpg|500px|link=]]<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/>
[[Fichier: Iteration-Diagrams-Waterfall2-740943.jpg|500px|link=]]<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/>
[[Fichier: Iteration-Diagrams-Waterfall3-715206.jpg|500px|link=]]<br/>
<br/>
'''Place à l’amélioration'''<br/>
<br/>
Cette démarche de succès, basée sur des échecs multiples, s’est bien mise en place dans les divers secteurs de l’industrie du logiciel. Quelques entreprises intelligentes ont mis en place deux stratégies de base pour identifier beaucoup plus rapidement de nouveaux marchés fructueux.<br/>
* '''Le modèle de gestion de portefeuille''' : échouer sur plusieurs choses à la fois. En essayant de nombreuses options différentes en même temps, on obtient un peu de réussite (NdT : que je retraduirais par "la quantité produit la qualité").
* '''Le modèle itératif''' : échouer plus tôt. On essaye quelque chose de simple, on le teste pour voir si ça marche et on recommence.
<br/>
'''Modèle de gestion de portefeuille'''<br/>
<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/>
[[Fichier: Iteration-Diagrams-StandardPortfolio-726829.jpg|500px|link=]]<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/>
<br/>
Le grand avantage du modèle de gestion de portefeuille, c’est qu’elle vous permet d’essayer des options totalement différentes simultanément. Les entreprises se retrouvent souvent dans des situations où plus d’une idée a du potentiel et elles manquent d’informations pour choisir lesquelles financer. Si elles étaient forcées d’en choisir une seul, elles louperaient souvent l’opportunité de créer plusieurs lignes de produits. Au lieu de mettre tous vos œufs dans le même panier, le modèle de gestion de portefeuille vous permet de répartir le risque et d’augmenter vos chances d’innover.<br/>
<br/>
Le talon d’Achille du modèle de gestion de portefeuille, c’est le coût. Les petites entreprises ont de la difficulté à financer un projet, donc encore moins dix ou vingt.<br/>
<br/>
'''Modèle itératif'''<br/>
<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/>
[[Fichier: Iteration-Diagrams-Agile1-782053.jpg|500px|link=]]<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/>
[[Fichier:Iteration-Diagrams-Agile2-752409.jpg|500px|link=]]<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/>
[[Fichier: Iteration-Diagrams-Agile3-765636.jpg|500px|link=]]<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/>
<br/>
Le développement Agile fonctionne mieux en démarrant avec de petites équipes, car cela réduit considérablement le risque de défaillance d’une équipe. Si vous avez seulement la possibilité de tirer un seul coup vers la cible, vous pouvez tout aussi bien vous consacrer à obtenir avec succès un maximum d’informations pertinentes au lieu de tirer à l’aveuglette vers l’inconnu (NdT : et l’au-delà !). À long terme, les processus agiles fournissent davantage de valeur, plus tôt et avec un risque global plus faible.<br/>
<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/>
[[Fichier: Iteration-Diagrams-Agile4-714391.jpg|500px|link=]]<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/>
<br/>
'''Méthode du passage de portes (NdT : Stage Gate) : modèles de reproduction croisée et développement itératif'''<br/>
<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/>
[[Fichier: Iteration-Diagrams-StageGatePortfolio-737228.jpg|500px|link=]]<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/>
<br/>
En tant que jardiniers, c’est aussi notre travail d’entretenir le jardin. Les projets faibles sont coupés et transformés en paillis qui aide à nourrir les projets ayant la plus grande chance de réussir, et à créer une couche permettant de faire germer les idées les plus prometteuses. Les meilleurs projets sont récoltés et envoyés aux clients, riches en fonctionnalités mures, débordant de valeur. Nous sommes constamment en train de semer de nouveaux projets pour garder notre portefeuille équilibré.<br/>
<br/>
Nous avons ajouté trois points au modèle agile traditionnel.<br/>
<br/>
* '''Plusieurs équipes essaimées (NdT : Seed Teams)''' : le premier point est le concept de plusieurs équipes orientées dans des directions différentes avec des objectifs différents. Il n’y a pas un seul client, mais plusieurs clients ayant plusieurs stratégies de succès potentiel.
* '''Des portes tueuses (NdT : Kill Gates)''' : le deuxième point est le concept de portes apparaissant au bout de quelques itérations et qui « tuent » les projets peu performants. Il est préférable de renvoyer ces ressources vers les projets existants plutôt que de continuer à investir. Vous pouvez considérer que les critères de succès représentent un ensemble de contraintes raisonnables pour les portes. L’équipe est autorisée à faire ce qu’elle veut tant qu’elle respecte les contraintes énoncées et réévalués à chaque porte.
* '''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/>
[[Fichier: StageGate-Gate-Diagram-795628.jpg|500px|link=]]<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/>
<br/>
Vous dépenserez beaucoup moins d’argent que dans un modèle de gestion portefeuille pur puisque vous n’avez pas la contrainte de coût élevé lié au fait de finir et déployer la majeure partie des explorations de marché en fait infructueuses. Tous ces déchets peuvent se transformer soit en exploration de nouvelles pistes soit dans la construction de projets qui confirment leur réussite.<br/>
<br/>
Vous avez un taux de réussite supérieur à celui d’un modèle purement itératif puisque vous explorez plusieurs pistes au lieu de n’en explorer qu’une seule avec le secret espoir que ce soit la meilleure. Nous affirmons donc ici que tous les succès ne sont pas créés égaux et qu’il peut être facile de rester coincé dans des niches. En gardant vos options ouvertes, vous pouvez toujours transférer vos ressources sur une véritable opportunité.<br/>
<br/>
L’inconvénient, c’est que le coût est un peu plus élevé que pour un modèle itératif pur. Vous aurez besoin de consacrer une partie de vos efforts à générer et explorer de nouvelles opportunités. C’est généralement largement compensé par un accès plus rapide à des produits fructueux. Un autre inconvénient, c’est que certains projets à long terme (par exemple ... un réacteur à fusion) sont tués avant qu’ils aient eu l’occasion de montrer qu’ils sont prometteurs. Cela peut être géré par l’adaptation soigneuse des portes afin que les innovations soient correctement pondérées.<br/>
<br/>
'''Le processus de récolte : appliquer le modèle de passages de portes sur un seul produit'''<br/>
<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/>
[[Fichier: Iteration-Diagrams-ProjectPortfolio-736600.jpg|500px|link=]]<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/>
<br/>
Le temps s’écoulant, les petites idées que vous avez semées plus tôt ont mûries et produisent une nouvelle récolte de fonctionnalités à forte valeur ajoutée. Le processus ne cesse de se répéter, saison après saison, version après version.<br/>
<br/>
Le cliché dans notre métier c’est que "les idées sont bon marché". Ce qui est honteux, c’est que quelques-unes des meilleures idées sont laissées à l’abandon parce qu’elles ne viennent pas des bonnes personnes et que le calendrier de production n’a pas laissé de place à la pensée créative. Le processus de récolte positionne l’innovation au plus bas niveau possible. Tout le monde est encouragé à trouver des idées et il y a un processus clair et officiel par lequel les idées peuvent devenir réalité.<br/>
<br/>
'''Pour que ça marche'''<br/>
<br/>
Pour que ça marche, vous avez besoin d’avoir quelques éléments en place. Il s’agit quand même d’une dépense importante pour gérer de multiples projets et constamment intégrer leurs efforts. Avec les bonnes personnes, les bons processus et les bonnes valeurs en place, cela devient un objectif atteignable.<br/>
<br/>
* '''Plusieurs petites équipes agiles''' : une seule équipe monolithique a du mal à piloter de multiples projets. Des équipes plus petites peuvent défendre leur périmètre plus facilement.
* '''Remanier facilement le code et tester facilement sa non-régression''' : vous devez être capable de changer un élément sans casser le reste des projets.
* '''Constamment innover''' : les équipes doivent être en mesure d’innover dans des directions intéressantes sans pour cela devoir se référer à un "comité de planification maître".
* '''Portes tueuses''' : si vous ne reconnaissez pas le succès et que vous ne tuez pas les projets qui n’ont pas le niveau, vous vous retrouverez avec une masse cancéreuse de projets bizarres, avec des fonctionnalités malsaines qui se seront développées dans des directions aléatoires. De bonnes portes tueuses qui tuent réellement les projets sont essentiels à la réussite.
* '''Conception partagée''' : vous devez toujours présenter un visage uniforme au client. Chaque équipe est soumise à des contraintes supplémentaires pour partager visuellement et minimiser la complexité conceptuelle du produit dans sa globalité. Ces contraintes sont intégrées dans les portes tueuses.
* '''Retours des clients''' : à chaque étape, vous devez tester vos produits avec de vrais clients. Vous devriez être capable de déployer rapidement, et tous les jours, un produit opérationnel à vos clients. Aucune de ces idées ne pourra réussir sans que des personnes utilisent des versions opérationnelles de votre logiciel et que l’équipe soit prête et capable d’apprendre à partir des réactions des clients.
<br/>
'''Conclusion'''<br/>
<br/>
En fin de compte, toutes les techniques décrites ci-dessus ont une chance de fonctionner. Vous avez besoin d’un groupe de personnes avec les bonnes conditions en place. Avec une bonne dose de chance et d’obstination, même un projet mené en cascade peut changer le monde. Pour ceux qui ont de l’argent et qui travaillent dans de grosses entreprises, cela suffit. Toutefois, si l’échec représente un coût personnel, vous aurez envie de loucher sur d’autres techniques, telles que l’agile, les passages de portes ou la récolte. À long terme, vous remarquerez que le risque du portefeuille diminue globalement et que vos clients commencent à profiter de vos produits conçus avec une meilleure qualité et de vos équipes qui le connaissent bien.<br/>
<br/>
Si vous ne devez retenir qu’une seule chose aujourd’hui, cela doit être que l’apprentissage est fondamental pour le développement de logiciels. Nous ne vivons pas dans un monde Newtonien où d’énormes cerveaux mécaniques peuvent prédire le futur. (NdT : on dirait du Thierry Cros dans le texte :-) C’est même le contraire, nous évoluons dans un univers en constante évolution des modes culturelles, des demandes urgentes des clients, des flux de trésorerie fluctuants et de sponsors sceptiques. Afin de fournir de très bons produits dans les temps, nous devons apprendre de notre environnement et construire une réponse rapidement et précisément. La technique du portefeuille favorise l’apprentissage en essayant d’autres options. Les techniques agiles augmentent l’apprentissage en raccourcissant le cycle de feedback. Mettez en œuvre ces deux concepts clés dans vos équipes et vous verrez qu’elles prennent de meilleures décisions et qu’elles fournissent plus de valeur à vos clients.<br/>
<br/>
Prenez soin de vous !<br/>
Danc.<br/>
<br/>
'''RÉFÉRENCES ET RESSOURCES'''<br/>
<br/>
'''Images'''<br/>
J’ai été inspiré par ces images de développement agile lorsque j’ai commencé à faire des schémas.<br/>
[http://www.gamesfromwithin.com/articles/0608/000110.html]<br/>
<br/>
Petites équipes au début ? Essayez une personne à 20%<br/>
Avec les techniques de la Récolte des des Passages de portes, les équipes peuvent être très petites au début. Par exemple, vous pourriez consacrer 20% du temps d’une personne pour l’étape de conception initiale. Cela ne semble pas beaucoup, mais si chaque personne de votre consacre 20% de son temps à de nouvelles idées, vous sèmerez l’équivalent de centaines de nouveaux projets chaque année sans effectifs supplémentaires. Google est l’enfant chéri de ce concept à l’heure actuelle, mais 3M l’a fait avec succès pendant des dizaines d’années.<br/>
<br/>
Mettez ces centaines d’idées dans une simple check-list à la recherche d’une potentielle valeur client. Essaimez les meilleures idées dans des équipes minuscules de quelques personnes et donner leur une itération ou deux pour arriver à quelque chose de cool (et testable). Répétez l’opération plusieurs fois et vous verrez sortir, rapidement et de façon surprenante, des produits innovants.<br/>
<br/>
'''Techniques itératives'''<br/>
Agile : [http://www.agilealliance.org/]<br/>
Scrum : [http://www.controlchaos.com/about/]<br/>
Kaizen : [http://en.wikipedia.org/wiki/Kaizen]<br/>
<br/>
'''Passage de portes'''<br/>
Winning at New Products: Accelerating the process from idea to launch, 3rd edition Robert G. Cooper, copyright 2001<br/>
<br/>
'''Rapport sur le projet "Fer à cheval" pour construire des jeux qui se vendent'''<br/>
Beaucoup d’idées de cet article ont été fortement influencées par la discussion au sein du groupe Play Dough du Projet "Fer à cheval" en 2006.<br/>[http://www.projecthorseshoe.com/ph06/ph06r5.htm]<br/>