« Changez votre façon de construire » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
|||
| (5 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 1 : | Ligne 1 : | ||
[[Category: Marty Cagan]] | [[Category: Marty Cagan]] | ||
[[Category: | [[Category: Accelerate]] | ||
[[Catégorie:Portail Product Owner]] | |||
Auteurs : Jon Moore et Marty Cagan<br /> | |||
Source : [https://www.svpg.com/changing-how-you-build/ Changing How You Build]<br /> | Source : [https://www.svpg.com/changing-how-you-build/ Changing How You Build]<br /> | ||
Date : 16/09/2022<br /> | Date : 16/09/2022<br /> | ||
| Ligne 52 : | Ligne 53 : | ||
Ce n'est pas un secret dans notre domaine que de nombreuses entreprises ont un bilan terrible en termes de respect de ce type de promesses. Mais les entreprises de produits fortes savent combien cela est important pour établir et maintenir la confiance avec nos clients. | Ce n'est pas un secret dans notre domaine que de nombreuses entreprises ont un bilan terrible en termes de respect de ce type de promesses. Mais les entreprises de produits fortes savent combien cela est important pour établir et maintenir la confiance avec nos clients. | ||
==PETITES VERSIONS, FRÉQUENTES, FIABLES== | ===PETITES VERSIONS, FRÉQUENTES, FIABLES=== | ||
La technique de base utilisée pour répondre à chacun de ces principes est la notion de versions petites, fréquentes et fiables. | La technique de base utilisée pour répondre à chacun de ces principes est la notion de versions petites, fréquentes et fiables. | ||
| Ligne 78 : | Ligne 79 : | ||
Comme vous commencez, je l'espère, à le comprendre, c'est la raison pour laquelle les grandes versions comme celle-ci (connues sous le nom de "big bang") sont connues pour leurs retards de plusieurs semaines, voire de plusieurs mois, pour essayer de tout remettre dans un état fiable et publiable. | Comme vous commencez, je l'espère, à le comprendre, c'est la raison pour laquelle les grandes versions comme celle-ci (connues sous le nom de "big bang") sont connues pour leurs retards de plusieurs semaines, voire de plusieurs mois, pour essayer de tout remettre dans un état fiable et publiable. | ||
En fait, de nombreux produits construits de cette manière n'atteignent jamais un niveau de qualité élevé, et le client est obligé de faire face à un flux constant de défauts et de problèmes, ou bien de chercher un autre fournisseur de solutions. | |||
De plus, même si la nouvelle version fonctionne comme prévu (ce qui est loin d'être le cas), le client est contraint d'absorber des centaines, voire des milliers de changements de produit qui le frappent d'un seul coup, nécessitant probablement une nouvelle formation, une recertification, une réintégration et une interruption importante de son travail pour s'adapter à tous les changements que l'entreprise lui a imposés. | |||
Dans ce cas, il arrive trop souvent que le client fasse pression sur votre entreprise pour qu'elle publie moins souvent, car il n'a tout simplement pas le temps de faire face à un tel degré de changement. Comme vous pouvez le voir maintenant, bien qu'il soit tout à fait compréhensible que le client demande cela, agir ainsi serait bien pire pour le client et pour votre entreprise. | |||
Si l'on ajoute à cela l'incapacité de l'entreprise à répondre rapidement et de manière compétente aux problèmes critiques, on comprendra que les clients perdent confiance dans votre capacité à leur fournir le service dont ils ont besoin. | |||
===UNE REMARQUE SUR LES MÉTHODES AGILES=== | |||
Vous avez presque certainement entendu parler des méthodes agiles. La raison principale pour laquelle tant d'entreprises ont adopté les méthodes agiles au cours des vingt dernières années est que ces méthodes peuvent fournir la force nécessaire pour amener les équipes de produits à réaliser ces petites versions régulières et fréquentes. | |||
Il est vrai que le passage à des versions petites et fréquentes peut nécessiter un investissement important, principalement dans l'automatisation des tests et du déploiement. Mais pour les entreprises qui ont utilisé les méthodes Agile pour parvenir à des versions au moins toutes les deux semaines, cela leur a apporté, ainsi qu'à leurs clients, une réelle valeur ajoutée. | |||
Cela dit, il est important de comprendre qu'il n'est pas nécessaire de recourir aux méthodes agiles pour obtenir des versions régulières, petites et fréquentes. | |||
En fait, beaucoup des meilleures équipes produits du monde ont maîtrisé la capacité de déployer systématiquement ces petites versions (appelées intégration continue et déploiement continue ou "CICD"), sans pour autant suivre un processus ou des méthodes agiles formels. | |||
Comparez cela aux organisations qui investissent tant de temps et d'argent dans l'adoption de rituels, de rôles, de méthodes et de processus Agile, mais qui, au bout du compte, continuent de publier des versions trimestrielles et de pénaliser leurs clients. | |||
De même, [https://www.svpg.com/revenge-of-the-pmo/ une maladie se propage] dans le monde de la technologie, où des processus lourds [https://www.forbes.com/sites/stevedenning/2019/05/23/understanding-fake-agile/ se font passer pour Agile], mais ne sortent une version qu'une fois par trimestre. | |||
Et pour être parfaitement clair sur ce point très critique : si votre entreprise continue à publier des versions annuelles, trimestrielles ou même mensuelles, peu importe le nombre de rituels agiles que vous suivez ou le nombre de soi-disant coachs agiles que vous employez, la vérité est que vous n'êtes pas Agile au sens propre, vous n'obtenez pas les bénéfices nécessaires et vous ne serez pas en mesure de servir vos clients ou votre entreprise comme il se doit. | |||
