Fermer

mai 20, 2024

Comment créer une culture de développement agile réussie – et pourquoi votre entreprise en a besoin

Comment créer une culture de développement agile réussie – et pourquoi votre entreprise en a besoin



Pour suivre le rythme de la complexité croissante du développement logiciel, les organisations ont passé des années à travailler à la mise en œuvre de pratiques agiles dans leur expérience de développement. Les pratiques agiles sont un ensemble de méthodologies de développement logiciel centrées sur l’idée de développement itératif, où les exigences et les solutions évoluent grâce à la collaboration entre des équipes interfonctionnelles auto-organisées. Il permet aux équipes de créer de la valeur plus rapidement, avec une meilleure qualité et prévisibilité, et une plus grande aptitude à répondre au changement. La popularité d’Agile s’est accrue grâce à sa liste d’avantages, notamment une meilleure concentration sur les valeurs commerciales, les utilisateurs et la qualité. Mais de nombreuses organisations sont encore avoir du mal à atteindre l’agilité et déclarent que les progrès sont encore lents et que les projets sont au point mort.

Quelles sont les causes de l’échec agile

La plupart des pratiques agiles échouent en raison d’un nombre croissant d’idées fausses et de malentendus sur ce qu’est l’agilité et comment l’appliquer. Dans cet article, Mik explique les idées fausses courantes sur le développement agile et comment appliquer et développer correctement une culture agile.

Le développement agile est né du besoin de flexibilité et de rapidité du développement de logiciels modernes dans le but de promouvoir la collaboration, la communication et la réactivité afin de créer de meilleures façons de développer des logiciels. Les principes agiles permettent aux organisations de répondre aux commentaires et d’apporter les modifications nécessaires à tout moment du cycle de vie du développement logiciel agile.

Les responsables informatiques qui tentent d’introduire des méthodes de travail agiles dans des organisations qui n’ont pas pleinement adopté l’agilité peuvent être victimes d’anti-modèles agiles. Certaines des pratiques anti-modèles les plus courantes incluent une grande planification initiale, de longs sprints, une trop grande importance accordée aux points d’estimation précis et des rétrospectives inefficaces.

Deux anti-modèles Agile : exigences détaillées, cycles de publication longs

Il existe une croyance commune selon laquelle planifier longtemps à l’avance produit d’excellents logiciels. Dans certains cas, c’est vrai, mais pas dans la plupart des cas de développement d’applications. Concevoir et planifier un produit un an à l’avance peut en fait nuire au succès d’une entreprise. Lorsque les plans de développement sont élaborés dès le départ, cela ne laisse aucune place à l’agilité, car les exigences capturées lors de la planification ne peuvent pas refléter avec précision ce dont le flux de travail réel a besoin pour réussir.

L’une des connaissances les plus importantes sur le développement agile que nous avons apprises au cours des 25 dernières années chez Tanzu Labs est que très peu de personnes peuvent prédire quels sont ces flux de travail. Au lieu de cela, vous découvrez et perfectionnez les flux de travail en étudiant ce que les gens font avec votre logiciel au fur et à mesure que vous le publiez progressivement. Lorsque vous utilisez les bons outils et processus, les logiciels peuvent être modifiés rapidement (même quotidiennement !) – vous permettant de présenter de nouvelles fonctionnalités aux gens, d’observer comment ils les utilisent, puis de modifier à nouveau ces fonctionnalités d’application. En répétant ce processus, vous êtes en mesure d’utiliser des données validées pour découvrir puis perfectionner la manière dont votre logiciel résout les problèmes des utilisateurs.

Il y a deux signes avant-coureurs de cette mauvaise pratique. Tout d’abord, vérifiez si vous créez un grand nombre d’exigences logicielles, d’histoires ou tout ce que vous utilisez pour spécifier ce que fait le logiciel. Deuxièmement, avez-vous des cycles de publication longs, de l’ordre de six mois ou plus ? Nous avons travaillé avec de nombreuses organisations au fil des années qui n’avaient pas publié leur logiciel depuis un an ou plus et qui pensaient pourtant pratiquer l’agilité. Des cycles de publication longs indiquent que les exigences agiles (souvent appelées « histoires ») ne sont pas décomposées en éléments suffisamment petits et que les cycles de publication sont trop longs. Décomposer les versions en une série de petits changements fréquents est la voie à suivre.

Comment bien faire le développement agile

L’accélération des cycles de publication peut être étonnamment rapide. Selon nos estimations, au moins 50 %, voire 70 % des organisations n’ont pas encore entièrement automatisé leurs tests et créé des pipelines. Ce ne sont que des outils qui doivent être mis en place ou, dans certains cas, simplement utilisés de manière plus complète.

Il existe plusieurs autres principes agiles dont nous n’avons pas discuté ici et qui sont également fréquemment laissés de côté ou pas entièrement mis en œuvre. Par exemple, pour bénéficier des avantages de la gestion du développement agile, il faut rendre les équipes plus autonomes, leur donner la parole pour signaler les domaines à améliorer et leur faire confiance pour effectuer ces changements.

À Laboratoires des filiales VMware, notre approche agile est basée sur un ensemble de principes directeurs et de pratiques de base, issus de plus de 30 ans d’expérience de travail avec des organisations de toutes tailles et de tous secteurs. Ce qui rend notre playbook agile unique, ce sont nos quatre piliers :

(1) Équipes équilibrées – nous commençons avec une équipe logicielle qui possède un mélange de compétences et de perspectives. Selon les besoins de votre organisation, cela comprend généralement un chef de produit, un concepteur de produit et plusieurs ingénieurs. Cela signifie que chaque équipe dispose des principales capacités nécessaires pour créer des logiciels, réduisant ainsi le temps nécessaire à la coordination et au transfert entre les silos fonctionnels.

(2) Programmation extrême – les 12 principes de l’Extreme Programming fournir un ensemble éprouvé de pratiques prescriptives pour le développement de logiciels agiles. Des pratiques telles que le développement piloté par les tests, la refactorisation et la programmation en binôme vous donnent la recette exacte pour commencer. De nombreuses organisations ont l’idée de l’agilité mais sont laissées seules à comprendre les pratiques quotidiennes. Extreme Programming comble cette lacune.

(3) Pensée Lean – nous appliquons la philosophie Lean consistant à se concentrer sur l’apprentissage et l’amélioration continus, l’élimination des déchets dans le pipeline de bout en bout et l’autonomie des travailleurs au développement de logiciels.

(4) Conception centrée sur l’utilisateur – la conception centrée sur l’utilisateur place les besoins et les objectifs des utilisateurs au cœur du processus de conception. Traiter les utilisateurs comme des parties prenantes importantes du produit garantit que ce que les équipes construisent est pertinent, utile et agréable. Lors de la mise en œuvre de cela, il est important de demander des commentaires réguliers sur les conceptions, les prototypes et les premières versions afin que le résultat corresponde mieux à votre public cible.

S’abandonner au processus

Lorsqu’ils construisent une culture agile, les entreprises et les responsables informatiques doivent être prêts à accepter qu’il existe une incertitude dans tout projet logiciel. L’essentiel est d’être prêt à gérer cette incertitude de manière utile et d’apprendre à se sentir à l’aise avec l’inconfort. Le développement agile consiste simplement à être réaliste quant à la capacité de toute équipe à prévoir avec précision plus de quelques semaines à l’avance. Lorsque cela est fait correctement, les entreprises bénéficieront de nombreux avantages, notamment une meilleure résilience et la capacité de s’adapter en fonction des besoins du marché et des utilisateurs, un meilleur alignement entre les équipes de livraison et les besoins des utilisateurs, ainsi qu’un travail plus durable pour les équipes de développement.

Pour en savoir plus, visitez-nous ici.




Source link