Le contenu suivant est tiré du livre blanc populaire "Agile Project Management : Quelle est l'histoire ?" écrit par Jerry Manas. Il est si bon que nous avons voulu le rendre gratuit pour nos lecteurs et lui donner une vie éternelle sur notre blog pour votre plaisir.
Depuis le début du mouvement Agile, les défenseurs des méthodes traditionnelles sont sceptiques. Certaines de leurs préoccupations sont valables, tandis que d'autres sont ancrées dans l'ignorance des véritables méthodes Agile.
Voici dix craintes courantes en matière de gestion :
- Cela ne fonctionnera pas pour les grands projets complexes.
- C'est trop ouvert. Nous ne pouvons pas prévoir les coûts. C'est du "scope creep sanctionné".
- Cela ressemble à une conception et une planification "au dos de la serviette".
- Il est trop axé sur la "technologie".
- Les développeurs de logiciels ne parlent pas le même langage que les clients.
- Les clients n'ont pas le temps de s'impliquer dans la planification.
- Nous ne voulons pas que nos clients voient notre linge sale.
- Cette approche de "travail en équipe" ne semble pas pratique.
- Des réunions quotidiennes ? Nos employés auront l'impression d'être sous un microscope.
- Il est trop rigide et inhibe la créativité individuelle.
La vérité est que Agile implique plus de planification qu'ils ne le réalisent- à chaque itération en fait. De plus, l'implication des clients et des entreprises est plus importante, et la communication est élevée, de sorte que l'accent n'est pas strictement mis sur la technologie. Mais d'autres préoccupations sont tout à fait légitimes.
Dans l'ensemble, les dix stratégies suivantes peuvent répondre aux préoccupations typiques :
- Adaptez la stratégie à la situation - utilisez la bonne méthodologie pour le bon travail ; Agile est la meilleure solution pour une équipe soudée travaillant sur un travail de connaissance avec un certain niveau d'incertitude.
- Réduisez les risques en vous concentrant sur les symptômes commerciaux plutôt que sur les solutions - ne perdez pas de vue le problème commercial à résoudre.
- Adoptez une politique du "voyez par vous-même" pour évaluer l'expérience utilisateur - avant et après.
- Favorisez une approche systémique - pensez au-delà du logiciel ; pensez également aux processus, aux systèmes en amont et en aval, à l'impact sur les parties prenantes, etc.
- Engagez un analyste commercial pour vous assurer que les détails ne sont pas négligés - les développeurs ne comprennent souvent pas les détails commerciaux.
- Combler le fossé culturel entre les techniciens et les clients - cela peut se faire en formant les développeurs à l'interaction avec les clients ou en engageant d'autres personnes pour interpréter et traduire afin de combler le fossé entre les développeurs et les clients.
- Acceptez le changement mais gérez-le - supposez que les fonctionnalités changeront en fonction des apprentissages, mais discutez de la portée globale, et gérez et consignez les modifications de la portée.
- Concentrez-vous sur l'évolution du produit, et non sur l'évolution du projet ; gérez les fonctionnalités et les versions par ordre de priorité ; fixez des objectifs pour les versions - la plupart des sprints n'aboutissent pas à un produit livrable au client, mais fournissent un certain niveau de valeur ; les versions aboutissent à des produits livrables au client ; veillez également à hiérarchiser les fonctionnalités et à fixer des jalons liés aux versions.
- Obtenez l'engagement de la direction à assister aux rétrospectives et aux démonstrations ouvertes - sans l'implication de la direction et du client, la méthodologie Agile perd de sa puissance ; obtenir l'engagement est essentiel.
- Concentrez-vous sur les résultats et la valeur, et non sur les activités ou les heures - ne donnez pas aux gens l'impression d'être sous un microscope - concentrez-vous sur ce qui est nécessaire, et non sur la manière de le faire ; autorisez la flexibilité et la créativité individuelle, et concentrez-vous uniquement sur les résultats et la valeur convenus pour chaque sprint - la liberté en matière d'heures et de créativité peut équilibrer l'accent mis sur les réalisations, et l'accord sur ce qui est réalisable peut réduire la pression.
Une façon supplémentaire de réduire les autres défauts d'Agile est d'adopter une approche intégrée pour mettre l'accent sur ce qui est généralement en dehors de la méthodologie Agile. Pour y remédier, utilisez une approche en quatre phases qui peut s'ajouter à votre méthodologie actuelle. L'acronyme s'écrit UP-IT:
- Understand - acquérir les connaissances nécessaires pour réussir le projet ; faire des recherches ; examiner l'expérience utilisateur actuelle et souhaitée.
- Prepare - acquérir les capacités nécessaires pour exécuter le projet avec succès, comme la formation, les bons outils, obtenir l'engagement des parties prenantes, etc.
- Iterate - planifiez et exécutez les itérations/sprints pour fournir de la valeur par le biais des versions planifiées.
- Transform - mettez l'accent sur le soutien continu et l'autonomie du client ; veillez à informer l'équipe des leçons apprises à appliquer aux versions futures.
Enfin, il existe certaines situations où Agile n'est probablement PAS la meilleure approche.
Voici huit exemples de situations où il faut éviter les méthodes Agile :
- Les initiatives de grandes entreprises qui ont besoin de définir les exigences dès le départ, et qui nécessitent généralement une documentation importante.
- Lorsque des spécifications formelles sont nécessaires pour l'auditabilité, la sécurité ou la précision.
- Lorsque la portée et les exigences sont connues, qu'elles peuvent être définies et qu'il est peu probable qu'elles changent beaucoup.
- Lorsque de nombreuses approbations sont nécessaires de la part de multiples parties
- Lorsque la culture de l'organisation ou de l'équipe est incompatible avec une approche Agile
- Si les clients/utilisateurs ne sont pas généralement disponibles pour participer
- Si l'équipe manque de compétences interpersonnelles ou de connaissances techniques lourdes (c'est-à-dire qu'elle ne peut pas être responsabilisée)
- Si l'équipe est trop grande pour être efficace en matière de communication croisée (c'est-à-dire plus de 100 personnes, bien que ce nombre puisse varier en fonction de la culture et de la technologie concernées)
Équipes virtuelles et Agile
Selon Gartner, d'ici 2015, les trois quarts des projets basés sur la connaissance dans le monde 2000 seront réalisés par des équipes virtuelles distribuées. Cela présente de nouveaux défis en matière de collaboration, qui est un principe central d'Agile. Dans cette optique, la compréhension des nouveaux médias et des outils de collaboration en ligne deviendra de plus en plus importante.
Les équipes Agile devront employer des méthodes pour rester en communication régulière, que ce soit par téléconférence, webinaires, outils de type Twitter tels que Yammer, sites web de collaboration ou autres médias. Certaines organisations ont même adopté l'utilisation de Wikis pour capturer, organiser et partager les connaissances.
Cela s'applique également aux organisations qui ne peuvent ou ne veulent actuellement pas colocaliser leurs équipes de développement. La plupart des experts Agile s'accordent à dire que la colocation est la meilleure solution, mais avec la bonne technologie et les bons principes, les équipes distribuées peuvent encore être efficaces.
Découvrez si la méthode Agile est faite pour vous et votre organisation en vous inscrivant dès aujourd'hui à une démonstration gratuite sur ! Pour en savoir plus, consultez le site https://www.planview.com/lean-agile-delivery/. Nous espérons que vous avez apprécié cette série et que vous en avez tiré de nombreux enseignements. Restez à l'écoute du blog de Planview pour plus de contenu Lean et Agile.
