5 astuces pour mettre à l’échelle l’agilité dans un environnement d’entreprise
L’Agilité peut être une excellente méthodologie pour développer et fournir de meilleurs logiciels. Mais si l’agilité fonctionne bien dans les petites organisations, la mise à l’échelle agile pour les entreprises ne va pas toujours bien. Les gens ont tendance à assumer beaucoup de choses sur les pratiques de développement agile, telles que:
+ Les membres de l’équipe ne changent pas
+ Chaque spécialiste est également généraliste
+ Tout le monde est engagé et motivé à travailler
+ Votre équipe est toujours dans le top 10 des artistes
+ Les équipes ont très peu de dépendances externes
+ Les clients sont pleinement engagés dans le processus
+ Tout le monde est situé au même endroit
Bien que ces hypothèses puissent être valides pour de nombreux petits environnements de démarrage, elles ne s’appliquent pas souvent lorsque des projets d’entreprise sont en cours. Par exemple, les user stories commencent à dépasser leurs délais, débordent sur les sprints suivants et les limites «work in progress» (WIP) sont dépassées, créant des goulots d’étranglement dans le développement et les tests.
Alors, comment empêcher cela? Les personnes ayant un état d’esprit technique (oui, développeurs, dev testeurs et autres) ont tendance à penser que la mise à l’échelle agile est comme écrire des programmes informatiques: « if (agile) then {do x; do y; do z}. » Mais ce n’est pas si simple. Bien que chaque organisation soit différente, il y a cinq principaux défis à relever lors de la mise à l’échelle des entreprises.
- Entrer dans un état d’esprit agile
Les grandes entreprises, en particulier celles qui gèrent des projets hérités, se sont habituées à leurs différentes équipes travaillant en silos. Le développement et l’assurance qualité étaient des organisations distinctes. Les développeurs ont « terminé » leurs tâches, puis les ont transmises à l’assurance qualité pour les tester. Il y avait une réelle disparité entre la définition de «fait» par l’équipe de développement et la définition de «fait» par l’équipe de QA.
Pour réussir à évoluer vers les entreprises, cet état d’esprit doit évoluer de «Je dois terminer mes user stories» à «Nous, (développement et assurance qualité) en tant qu’équipe, avons besoin de terminer nos user stories ensemble». En regardant le WIP comme un exemple, cela signifie que s’il y a 15 user stories dans le WIP, les développeurs n’ont pas terminé leur tâche tant que le QA n’a pas terminé le leur. Les développeurs doivent accepter que les user stories sur lesquelles ils travaillent ne soient pas « terminées » tant qu’ils n’ont pas été approuvés par le QA.
- Gestion des projets hérités avec des cycles de version longs
Les projets hérités peuvent avoir de longs délais entre chaque livraison, ce qui ne cadre pas bien avec l’esprit agile des sprints rapides et des versions. Le problème est que dans le travail hérité, il n’y a pas toujours un client en baisse d’activité dans l’entreprise, exigeant des livraisons rapides et fréquentes. Il est facile de mettre les choses en attente et d’ignorer l’arriéré croissant. Pour éviter cela, vous devez essayer de définir des jalons intermédiaires: des versions internes qui interrompent les longs cycles de publication pour empêcher les user stories de s’accumuler dans le backlog. Par exemple, si votre prochaine livraison n’est prévue que dans six mois, divisez ce long cycle et libérez une version alpha pour un groupe restreint d’utilisateurs internes dans un délai de deux mois, et une version bêta pour un groupe de clients externes amicaux deux mois après ça. Cela applique une tension constructive aux équipes et aide à garder tout le monde alerte et dans les délais d’une manière positive.
- Passer à des cycles de développement et de test plus courts
Les longs cycles de publication sont réconfortants dans les environnements d’entreprise qui se sont habitués à développer des solutions complètes avec de nombreuses fonctionnalités pour toutes les plates-formes et tous les navigateurs. Mais pour les équipes de développement et de livraison, les choses peuvent devenir très inconfortables lorsque les fonctionnalités qui ont passé des mois dans le développement sont rejetées par vos clients. Agile stipule des cycles de développement courts. Pour accomplir ces intervalles plus courts, vous devez déplacer votre approche vers le mode «produit minimal viable» (MVP). Essayez de créer le plus petit produit utile et fonctionnel et expédiez-le aux clients dans des cycles de version courts. Vous pouvez ensuite surveiller les réactions des clients et modifier le produit dans les versions ultérieures.
- Atteindre l’automatisation dès le premier jour (AD1)
AD1 est une quête noble. L’immense contribution que l’automatisation apporte à la stabilité et à la qualité globale de votre produit est indiscutable. Les tests d’automatisation sont déterministes, ce qui les rend efficaces pour détecter les bogues de régression dans votre produit entre les versions. Cependant, cela signifie également que si votre produit change, vos tests d’automatisation seront interrompus. Le développement de tests d’automatisation nécessite un effort considérable de la part d’un personnel formé et que le travail doit être fait dans les premières phases du développement, lorsqu’un produit est beaucoup plus susceptible de changer. Il peut être difficile de synchroniser les tests d’automatisation avec le développement du produit. La solution, bien sûr, est de viser AD2 (ou AD3 ou AD4 …). Reporter vos tests d’automatisation et les développer selon une stratégie soigneusement élaborée. Commencez avec des tests manuels jusqu’à ce que vous atteigniez un certain degré de stabilité et que vous passiez ensuite à l’automatisation. Décider exactement quand et comment commencer à écrire des tests d’automatisation peut être un peu un art. Il varie d’un projet à l’autre en fonction des différentes considérations à prendre en compte.
- Évaluer vos progrès
La mise à l’échelle agile pour les entreprises ne se fait pas d’un coup. Personne ne migre instantanément de la cascade à l’agile. C’est un processus qui prend du temps. Pour évaluer vos progrès, définissez des objectifs raisonnables en définissant des KPI agiles pour votre équipe. Un KPI très utile dans les environnements agiles est le « temps de cycle moyen« . C’est le temps que prend une histoire d’utilisateur pour passer à travers le WIP à partir du jour où le travail sur l’histoire de l’utilisateur a commencé jusqu’à ce qu’il soit cérémonieusement étiqueté «terminé». Il s’agit de l’un des indicateurs de performance clés les plus importants, car il mesure le temps nécessaire à la création d’une user story ou d’une fonctionnalité dans votre backlog et indique si vous êtes réellement en train de développer et de faire les choses assez rapidement. Idéalement, le temps de cycle moyen ne devrait pas dépasser un seul sprint, mais il peut y avoir une certaine variabilité entre les équipes. Tant que tous les membres de l’équipe peuvent convenir d’un temps de cycle moyen raisonnable, vous pouvez l’utiliser comme standard si les user stories commencent à glisser. Vous pouvez également éventuell ement ajuster votre temps de cycle moyen. Au fil du temps, à mesure que l’équipe acquiert de l’expérience en travaillant ensemble et devient plus efficace, vous constaterez que les histoires des utilisateurs sont complétées plus rapidement. Lorsque vous vous trouvez constamment battre votre temps de cycle moyen, ce pourrait être le temps de le raccourcir. Vous pouvez également utiliser « travail en cours dans le temps », qui est une mesure du nombre d’user stories actives à un moment donné. Cela vous indique si vous ouvrez trop de pistes de développement, à quel point votre équipe est ciblée et si vous avez le temps de commencer et de compléter des user stories supplémentaires avant la fin du sprint. Une autre mesure est « le temps moyen de résolution des défauts ». Cela représente le temps nécessaire pour corriger les défauts de fonctionnalité jusqu’à ce que le produit soit prêt à être livré en production. Connaître cette moyenne vous permet d’allouer du temps entre la poursuite du développement et la correction des défauts. Vous pouvez même aller un peu plus loin et décomposer en fonction de la gravité des défauts, pour rendre vos estimations plus précises.
Élevez-vous!
Le principal obstacle à la mise à l’échelle de l’agilité dans les environnements d’entreprise est l’état d’esprit des personnes impliquées dans le processus. En s’attaquant directement à cet état d’esprit, vous pouvez aider les membres de l’équipe à changer leurs sentiments et à agir dans le cadre de leurs tâches quotidiennes. Et vous êtes capable de mesurer les performances pour voir que l’équipe continue de progresser et de se développer plus efficacement. Agile est un voyage qui exige un engagement à long terme de la part de tous ceux qui sont impliqués, mais cela en vaut la peine quand vous commencez à ressentir les avantages que l’agilité apporte à votre groupe de développement à plus grande échelle.