« Changez votre façon de construire » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
|||
| (4 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 86 : | Ligne 87 : | ||
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. | 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. | |||
