By: Peter Boileau, analyste principal de gestion
Cette méthode permet aux équipes de créer des logiciels sur demande plus vite qu'avec les processus traditionnels de développement, plus rigides. Mais pour certaines entreprises, le développement agile ne se limite pas à l'adoption de principes fondamentaux. Certaines ont une première version complexe de leur produit minimum viable (PMV) qui s'applique à quelques unités opérationnelles, d'autres y vont massivement.
Votre entreprise rencontre un défi qui, vous le craignez, ne cadrera pas harmonieusement avec Agile ? Le développement agile est, comme son nom l'indique : agile. Vous pouvez adapter ses processus à de nombreuses caractéristiques de votre firme.
Toujours pas convaincu ? Examinons quelques scénarios non traditionnels qui prouvent qu'Agile peut convenir à votre équipe.
Parfois avec Agile, une entreprise sort un produit nouveau en lançant un PMV et en ajoutant progressivement les fonctionnalités qui répondent le mieux aux besoins des clients. Dans le cas de CWB National Leasing, nous avons remplacé deux systèmes de base que plusieurs services opérationnels utilisent pour chaque crédit-bail ou prêt que nous accordons. Notre PMV avait donc une portée massive. Nous avons réalisé qu'il prendrait des années à développer, et que nous avions besoin d'adapter Agile au projet. Notre solution : fusionner les pratiques d'Agile et la méthode en cascade.
Notre hybride a pris les aspects avantageux d'Agile – mêlées, embouteillages, sprints - et a adapté la méthode aux trois rôles définis de notre équipe de développement qui reflètent une approche en cascade plus traditionnelle. Voici comment cela a fonctionné : nous avons pris notre PMV massif et l'avons divisé en différents sprints. Pour chaque sprint, un analyste de gestion a rencontré les utilisateurs afin de créer des récits d'utilisateurs. L'analyste a envoyé chaque récit à un développeur pour la programmation. Enfin, l'équipe a envoyé le logiciel pour les essais, durant lesquels les utilisateurs ont suggéré des améliorations et identifié des bogues. Pendant ce temps, les équipes ont fait des mêlées régulièrement pour suivre l'avancement du projet.
Ne limitez pas votre projet pour l'adapter à une structure de développement si cela ne répond pas à vos besoins. Agile repose sur un ensemble de principes - dont je parle ici - et non sur un processus rigide. Même si nous avons emprunté une partie de la méthode en cascade au cours de notre projet, nous avons quand même fait des mêlées régulièrement, travaillé en faisant des sprints et surtout écouté nos responsables opérationnels pour livrer les logiciels dont ils avaient besoin.
En 2011, Brian Harry, vice-président à Microsoft, a annoncé le passage de l'entreprise à Développement Agile et à Scrum. Elle a réparti les 4 000 membres de sa division Développeurs dans des centaines d'équipes de 10 à 12 personnes, chacune s'occupant de fonctionnalités particulières de l'univers des produits de l'entreprise. Travaillant normalement à coups de trois semaines de sprints, Microsoft a raccourci le délai de livraison, augmenté la satisfaction des clients et modernisé ses produits. Comment le géant du logiciel a-t-il réussi un changement si radical à une aussi grande échelle ? L'entreprise décrit l'ensemble de son processus ici, mais en voici des aspects importants :
Par suite du fractionnement de sa division Développement, certaines équipes de l'entreprise travaillent à différentes fonctionnalités du même projet. Plutôt que d'avoir des équipes en silo pour les sprints et d'espérer tout intégrer à la fin, les équipes concernées travaillent ensemble quotidiennement. Elles règlent les problèmes d'intégration de la programmation au fur et à mesure et économisent à long terme du temps sur les essais.
Pour que le nombre de bogues du logiciel ne submerge pas les équipes et n'affecte pas le développement, Microsoft a créé la notion de « limite de bogues » (bug cap). Si à un moment donné durant le projet, il y a quatre fois plus de bogues que de techniciens, l'équipe suspens le projet et corrige les bogues jusqu'à ce que ce nombre retombe sous ce seuil. Par exemple, si une équipe a cinq techniciens, le projet ne doit jamais compter plus de 20 bogues en même temps. Cette règle générale permet d'éviter qu'un projet n'occasionne des montagnes de dette technique qui retarderont sa date de sortie.
Comment aligner les développeurs avec les objectifs produits de votre entreprise sans tomber dans la microgestion ? Microsoft charge ses gestionnaires d'orienter les développeurs dans la bonne direction puis confie l'exécution aux équipes - de la planification à la livraison. Cela contribue à créer l'appropriation au sein des équipes de développement et allège la surveillance par la direction - tant que les équipes respectent la limite de bogues mentionnée ci-dessus.
Même les grandes entreprises qui ont appliqué des méthodes de développement plus traditionnelles peuvent utiliser Agile efficacement, avec le plan d'exécution et le soutien descendant (top-down) qui conviennent. Dans de grands projets, permettez aux équipes de collaborer, gérez votre dette technique régulièrement afin que les bogues ne soient pas trop nombreux et donnez aux employés la possibilité de se développer de manière autonome.
Salesforce est l'une des plus importantes sociétés de gestion des relations avec la clientèle (GRC) dans le monde. Avec des milliers d'entreprises qui utilisent le logiciel et des millions de dossiers de clients, l'entreprise gère des tonnes de données. Comme de nombreuses sociétés qui utilisent Agile, la philosophie de Salesforce est de procéder à des mêlées (scrums). L'entreprise utilise des équipes de développement aussi petites que possible et habilite les employés du bas de l'échelle à prendre des décisions pour que ces équipes soient autosuffisantes.
Comme la plupart des entreprises avisées qui utilisent Agile, Salesforce a retenu les principes de base de la méthode et les a adaptés à ses besoins. La société forme chaque nouveau technicien durant un camp d'entraînement de deux jours pour lui montrer comment Salesforce déploie Agile et s'assurer que tous les développeurs parlent la même langue. De la gestion minimaliste (lean) aux principes de programmation extrêmes, les développeurs apprennent exactement la meilleure façon de créer des produits dans l'environnement, dynamique et guidé par les données, de Salesforce.
Comme Microsoft, Salesforce privilégie l'adaptation de sa méthode de développement pour sa croissance opérationnelle. Afin de conserver sa culture de partage des idées, les gestionnaires encouragent les développeurs à soumettre de nouvelles idées et à s'approprier le projet. Les développeurs peuvent ensuite présenter leurs idées aux intervenants internes, et si l'idée recueille de l'appui, ils présentent l'idée à la haute direction en vue d'obtenir le feu vert à l'échelle de l'entreprise.
Chaque membre de votre équipe de développement est précieux. Favorisez la génération des idées et laissez la communication circuler afin que votre équipe suggère de nouveaux produits et se manifeste lorsqu'elle constate un problème de programmation.
Les trois sociétés ci-dessus ont toutes pris des chemins différents pour appliquer Agile, mais elles ont une chose en commun : elles ont adapté la méthode de développement à leur structure. Alors ne laissez pas les spécificités de votre entreprise vous dissuader d'adopter le développement agile. Façonnez la méthode pour combler les lacunes dans vos processus courants, votre entreprise cernera mieux ses objectifs et elle réalisera ses projets plus vite.
Mis en ligne Conseils généraux en affaires ,
Contactez-nous et nous vous appellerons tout de suite.
