Les méthodologies de développement en cascade sont rapidement remplacées par les idéologies Agile. Les programmeurs et les équipes de programmation se demandent ce que cela veut dire en ce qui concerne le développement de leurs ensembles de compétences et la façon d’aborder efficacement la multitude de projets qui pointent à l’horizon en raison des méthodologies Agile. Les entreprises se demandent si elles devraient constituer des équipes Agile pour faire face aux défis de l’avenir.

Jusqu’à tout récemment, la méthodologie de développement et de déploiement en cascade s’est imposée comme stratégie au sein de la plupart des entreprises. Les entreprises ont migré vers le monde d’Agile, là où divers concepts servent d’appui et où les processus de développement sont abordés de manière totalement différente. Les idéologies de développement Agile s’avèrent meilleures pour faire face aux objectifs en changements rapides, pour raccourcir le temps d’accès au marché pour les applications d’affaires, les services et les autres types d’offres destinées aux clients (internes et externes). Les idées derrière Agile couvrent bien au-delà du développement de base des applications et peuvent bénéficier à de nombreux projets en améliorant le processus de réalisation des livrables et en assurant la rétention de l’accroissement de productivité.

L’avènement d’Agile.

Agile a été créé en février 2001 alors que 17 développeurs de logiciels se réunissaient dans l’Utah pour discuter de méthodes de développement.¹ Ces développeurs se trouvaient enlisés dans des processus de développement de logiciels s’appuyant sur la documentation et sur les silos créés par ces méthodes. Ils voulaient encourager la collaboration et le partage d’idées. Le résultat de cette réunion a été le Manifeste Agile.

Manifeste pour le développement Agile de logiciels

Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire. Ces expériences nous ont amenés à valoriser :

• Les individus et leurs interactions plus que les processus et les outils.
• Des logiciels opérationnels plus qu’une documentation exhaustive.
• La collaboration avec les clients plus que la négociation contractuelle.
• L’adaptation au changement plus que le suivi d’un plan.

Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.² Pour préciser davantage le Manifeste :

• Individus et interactions : L’auto-organisation et la motivation sont importantes, de même que les interactions comme le regroupement des services et la programmation en binôme.
• Logiciel opérationnel : Un logiciel opérationnel est plus utile et mieux reçu que la seule présentation de documents aux clients lors de réunions.
• Collaboration du client : Les exigences ne peuvent pas être toutes recueillies au début du cycle de développement d’un logiciel. Conséquemment, l’implication continue du client ou de la partie prenante est importante.
• Réagir au changement : Les méthodes Agile sont centrées sur des réactions rapides au changement et sur le développement en continu.

Définition approfondie d’Agile grâce aux methodologies.

En l’absence de processus définis, de méthodologies et d’étapes, Agile devint difficile à mettre en oeuvre. C’est ce qui mena à la création de méthodes plus spécifiques au sein du mouvement Agile. La méthodologie de la mêlée de presse (Scrum) est celle le plus fréquemment adoptée et utilisée pour la mise en oeuvre du développement de projets Agile. La mêlée met l’accent sur la collaboration, le logiciel opérationnel, l’autogestion d’équipe, ainsi que sur la flexibilité d’adaptation aux réalités émergentes de l’entreprise.4 Dans un tel cadre de gestion visant le développement progressif du produit, les équipes de mêlée créent des incréments de produit au cours d’itérations de durée limitée, appelées Sprints, d’une durée typique d’une à deux semaines.⁵ Ces incréments et ces itérations permettent aux rétroactions de s’incorporer plus rapidement qu’elles ne pourraient le faire dans le cadre d’un développement en cascade.

Parmi les autres méthodologies Agile, on retrouve :

• La méthode XP (Extreme Programming) : Elle favorise un flux de travail selon lequel le client travaille en étroite collaboration avec l’équipe de développement dans le but de prioriser les besoins (récits utilisateur). Un travail en étroite collaboration est nécessaire de la part de l’équipe, ainsi que des tests continus dans le but de livrer le logiciel à intervalles fréquents, typiquement à chaque période de une à trois semaines.
• Kanban : Méthodologie qui promeut la collaboration continue en mettant l’accent sur la livraison continue sans surcharger l’équipe de développement. Cette méthodologie met l’accent sur l’utilisation du flux de travail optimal de l’équipe, en faisant appel à la visualisation pour y arriver.
• Scrumban : Il s’agit de la combinaison de Scrum et de Kanban qui fait appel aux processus d’itération de Scrum et de Kanban.
• Lean : Il s’agit d’une concentration des efforts sur la livraison de valeur auprès du client, ainsi que sur l’efficience du flux de valeur (mécanisme assurant la livraison de valeur). Méthodologie qui minimise la quantité de travail inutile en mettant l’accent sur la rétroaction de petites équipes plutôt que sur celle de la hiérarchie, et sur la livraison par petits lots de caractéristiques priorisées.
• Feature Driven Development (FDD) : (Centré sur la mission) : Modèle centré sur la mission dont le processus est constitué de courtes itérations de deux semaines destinées à concevoir chaque caractéristique.
• Dynamic Systems Development Method (DSDM) : Fonctionne à partir des demandes et de la priorisation. Les demandes sont planifiées tôt au cours du projet et sont livrées selon de courtes itérations. La réfection constitue une considération standard et tous les changements au développement doivent être réversibles.⁵

Il existe plusieurs méthodologies Agile différentes, y compris : Scrum, XP, Kanban, Crystal et quelques autres, Scrum étant la plus utilisée sur le marché.³

Cascade c. Agile

Le modèle de développement en cascade fait appel à une approche qui s’appuie sur une séquence définie de réalisations pour en arriver à un point déterminé. Comme son nom l’indique, un cycle de vie de développement de produit évolue de façon constante vers l’achèvement, tout comme l’eau qui coule dans une cascade.

The waterfall development method has its roots in industries, ranging from construction to assembly lines, in which sequential processes are the key to success. Waterfall methodologies also took hold in the early days of programming, where changes during development projects were costly or impractical. Applying a waterfall methodology to a programming project meant that all the requirements gathering and design work was done before any coding took place.

La méthode de développement en cascade a ses racines dans des entreprises qui vont de celles de la construction jusqu’à celles des lignes d’assemblage, là où les processus séquentiels sont la clé de la réussite. Les méthodologies du développement en cascade ont aussi marqué les débuts de l’ère de la programmation, alors que les changements en cours de développement de projets étaient coûteux, voire impossibles. Bien que l’idéologie derrière le développement en cascade ne soit pas très âgée, elle a été d’abord décrite dans le domaine du développement logiciel par Winston Walker Royce qui a rédigé un article en 1970 expliquant la méthodologie appliquée aux projets de développement de logiciels. Le développement en cascade a été la méthodologie prédominante des projets de développement de logiciels depuis son introduction et dans la plupart des cas, respecte les sept étapes des processus décrits dans la publication de Royce en 1970.

La méthodologie de développement d’Agile évite une approche linéaire basée sur les séquences, et fait plutôt appel à une approche incrémentielle itérative. Les projets basés sur Agile ne débutent pas par une planification et une conception exhaustives ; ce qui veut dire que les demandes de changement peuvent être incorporées au processus de développement.

Les équipes interfonctionnelles deviennent une pièce importante du casse-tête que constitue la méthode Agile. Elles accueillent des planificateurs, des concepteurs, des développeurs et des testeurs qui travaillent de concert à la création d’itérations réussies du produit. Ces itérations s’achèvent au cours de périodes fixes (auxquelles on réfère comme blocs temporels) dont l’objectif est la création d’un produit fonctionnel, qu’on peut montrer aux parties prenantes dans le but d’obtenir leur rétroaction, leurs commentaires et leurs demandes de changements à inclure aux itérations futures.

Pourquoi les méthodologies Agile fonctionnent.

Pour comparer les différences entre les méthodologies du développement en cascade et celles d’Agile, il est très important de savoir comment leurs caractéristiques peuvent être interprétées selon le point de vue de la personne. Par exemple, un développeur de logiciel pourrait percevoir l’idée de flexibilité et de réduction des tests comme un point avantageux, alors qu’un gestionnaire de projet pourrait considérer ces deux éléments comme désavantageux.

Les points le plus souvent contraignants des méthodologies de développement en cascade sont : les longs délais pour les publications, l’impossibilité de faire des changements au cours du processus de développement, et devoir recommencer complètement le processus de développement en raison de changements des besoins. Heureusement, ces inconvénients peuvent être éliminés avec les méthodologies Agile.

Les forces motrices de l’adoption de la méthodologie Agile.

Les méthodologies Agile sont en voie de devenir l’idéologie par excellence pour prendre en compte la productivité et permettre aux entreprises de réagir aux changements, aux exigences du marché ainsi qu’aux priorités changeantes.

Les méthodes Agile offrent davantage de flexibilité que les projets qui misent sur le développement en cascade. Agile implique aussi la présence du client, permettant que les demandes de ce dernier puissent être mises en oeuvre sur-le-champ, ainsi que la réalisation d’un logiciel qui s’adapte selon le besoin et qui peut être modifié à chaque itération dans le but de faire face à de nouveaux défis. Par exemple, si une entreprise qui fait appel aux méthodologies de développement en cascade est en cours de développement d’un logiciel avec un arrière-plan vert, et si elle décide qu’un arrière-plan bleu conviendrait mieux, un délai important s’impose alors. En faisant appel à la méthodologie Agile, il s’agirait cependant d’une modification mineure s’intégrant harmonieusement au processus de développement.

La méthodologie Agile offre plusieurs avantages perceptibles, ce qui en accroît l’adoption comme pratique de développement. Parmi ces avantages, on retrouve :

• Réduction de la perte de temps : L’amélioration continue s’avère un processus plus rapide, qui réduit la perte en temps passé à la conception et à la modification du concept, tout en prenant en compte le changement.
• Rapidité accrue : La capacité d’Agile à procéder rapidement aux changements, spécialement en ce qui concerne les corrections de trajectoire, permet que les livrables soient réalisés plus rapidement.
• Productivité accrue : Agile constitue une façon plus efficace pour les équipes de travailler ensemble, ce qui veut dire que la productivité s’accroîtra en raison des améliorations de la communication, de même que la perspicacité acquise lors de l’établissement des objectifs de l’entreprise.
• Confiance en soi améliorée : Grâce à de meilleures décisions et à une approche proactive, Agile améliore la confiance en soi au sein d’une entreprise. Il devient plus facile d’ajuster un produit, et partant, pour l’entreprise de mieux réagir aux conditions changeantes du marché.
• Fiabilité et sécurité accrues : Agile favorise une approche différente à l’erreur : Agile met l’accent sur l’apprentissage découlant des erreurs et s’appuie sur un post-mortem sans blâmes, ce qui améliore l’attitude face aux erreurs. Ultimement, apprendre des erreurs et éliminer les blâmes mènent à l’amélioration de la fiabilité réciproque au sein de l’équipe.

Un sondage en ligne effectué par HP auprès de 601 professionnels des TI et du développement montre que 51 % des répondants favorisent Agile, alors qu’un autre 16 % d’entre eux font déjà appel à Agile comme unique méthode de développement. Seulement 2 % des personnes sondées utilisaient exclusivement le développement en cascade, alors que seulement 7 % d’entre elles favorisaient ce dernier.⁷ C’est là une indication claire de l’implantation d’Agile comme nouvelle normalité.

Le sentier d’accès à Agile.

L’adoption d’une idéologie Agile ne se résume pas à déclarer que ses équipes en sont adeptes. Les gestionnaires et les décideurs doivent comprendre les constituants de l’idéologie Agile, particulièrement lorsque l’idéologie cible est la mêlée – le Scrum. L’une des embûches principales dès lors que les entreprises optent pour Agile est le changement de culture. Bien que la présence d’un évangéliste Agile constitue une première étape efficace, l’imprégnation de la culture exige plusieurs réorientations majeures.

• Réorientation des objectifs – faire de l’argent vers la satisfaction du client.
• Réorientation de la structure – supervision de la part de la gestion vers favoriser l’auto-organisation des équipes en vue d’une contribution à tout ce dont elles sont capables.
• Réorientation des flux de travail – flux marqué par la bureaucratie vers un cycle incorporant la rétroaction directe du client.
• Réorientation des valeurs – efficacité et prévisibilité vers transparence et amélioration continue.
• Réorientation des communications –hiérarchique vers latérale.⁸

Glossaire et idéologies Agile

Carnet de produit : Un document actif qui contient les caractéristiques recherchées pour un produit, de même que les bogues, les travaux techniques et les connaissances acquises. Le carnet de produit est géré par le propriétaire du produit et est continuellement mis à jour et priorisé.

Sprint : L’équipe des développeurs travaille selon des sprints, une classification utilisée pour décrire l’ensemble des tâches d’une itération. Au début du sprint, les développeurs et le propriétaire du produit conviennent des items contenus au carnet de produit qu’ils achèveront durant le sprint. Le sous-ensemble d’items du carnet de produit devient le carnet du sprint. Au cours du sprint, le propriétaire du produit n’est pas autorisé à changer les items dans le carnet du sprint.

Mêlée quotidienne : Au cours d’un sprint, l’équipe de développeurs se réunit pour coordonner le travail du carnet du sprint lié aux items devant être achevés. Idéalement, l’équipe discutera à savoir qui travaille sur quoi et si quelque problème de contrainte a été découvert. Simplicité et courte durée des réunions sont la norme, les rencontres sont centrées sur ce que quelqu’un a accompli depuis la dernière réunion, ce qui est prévu pour aujourd’hui et s’il existe quelque entrave. L’idée consiste à partager la connaissance directement liée au projet.

Récits utilisateur et tâches : L’on réfère aux items du carnet de produit ou du carnet du sprint comme récits de l’utilisateur. Les récits utilisateur sont créés par le propriétaire du produit et représentent les besoins particuliers de l’entreprise. Les récits utilisateur sont souvent morcelés en tâches distinctes afin que leur degré de réalisation puisse être mesuré. Sans définitions des tâches, les récits utilisateur deviennent d’interminables histoires du simple fait qu’elles ne comportent aucun jalon mesurable d’exécution. Les récits utilisateur sont la propriété du propriétaire du produit et tous concernent les valeurs de l’entreprise, alors que les tâches relèvent de l’équipe des développeurs et toutes concernent la mise en oeuvre des détails. Un récit utilisateur peut exiger plusieurs jours ou semaines à rédiger, alors qu’une tâche est quelque chose qu’un développeur peut réaliser en moins d’une journée.

Graphique d’avancement : Dans la mêlée, le graphique d’avancement sert à représenter le travail qui reste à réaliser pour un projet. Un graphique d’avancement de publication s’effectue à partir du calcul du nombre restant de points de récits utilisateur non réalisés chaque jour, alors que le graphique d’avancement du sprint sert à préciser le travail restant pour un sprint particulier.

Histoires de réussites Agile.

HealthFitness

Dans son milieu de travail, l’entreprise de soins de santé a mis en oeuvre les méthodologies Agile pour créer un nouveau portail. HealthFitness perdait des clients actifs et des clients potentiels en raison d’un outil désuet de son portail. Sa technologie se devait d’être rapidement mise à niveau en plus d’avoir la possibilité de l’optimiser constamment au besoin. En 2012, l’entreprise a réuni des équipes de mêlée dans le but de développer un nouveau portail. Le portail est maintenant lancé et, à la fin de l’année 2015, retenait 50 des clients de l’entreprise.⁹

Spotify

Le service de musique en diffusion continue a fait appel à la méthodologie Agile pour mettre à niveau ses équipes de développement. Dès son lancement, Spotify a adopté Agile. L’entreprise en est revenue à l’esprit de flexibilité et d’expérimentation à la source d’Agile et a créé sa propre méthodologie Agile pour combler les besoins de son imposante équipe de développement. Les équipes de Spotify s’appellent des « escadrons » et chacun jouit de l’autonomie nécessaire pour assumer ses responsabilités, du début à la fin, de la conception jusqu’au déploiement et aux améliorations continues.¹⁰ L’entreprise a étendu la méthodologie Agile aux 30 équipes de ses installations partout au monde, lesquelles assurent le soutien à 75 millions d’usagers et pour 1,5 milliard de « playlists » dans 58 marchés.¹¹

Cerner

L’entreprise d’information en technologies de la santé a migré vers les technologies Agile dans le but d’accélérer l’accès au marché. Il a fallu typiquement 30 mois aux équipes de développement de Cerner pour introduire les innovations de produit. Dans le domaine de la réforme rapide des soins de santé, l’entreprise a pris conscience du besoin d’améliorer la rapidité d’accès au marché pour demeurer concurrentielle. La transition vers Agile a résulté en une réduction de 75 % du temps d’accès au marché, en une augmentation de 24 % de la productivité, en une diminution des frais de développement de 14 %, et en une réduction de 50 % des temps alloués à la résolution des défauts critiques.¹²

FBI

Après presque une décennie de mauvaise gestion et de pertes au sein du FBI, son dirigeant principal de la technologie (DPT) a transformé en projet Agile la mise en oeuvre de la gestion de cas discréditée de l’agence.¹³ Lorsqu’est survenue la tragédie du 9/11 aux États Unis, le seul moyen sécuritaire pour le FBI de transmettre des photos des pirates de l’air était le télécopieur et l’envoi rapide de disques CD ROM. Le besoin de la numérisation s’est douloureusement imposé comme évident, uniquement pour le bureau, mais non pas pour l’ensemble de la nation. Il en est résulté que le projet de dossier de cas virtuel (VCF – Virtual Case File) était lancé en 2000 dans le but de faire entrer le bureau dans une nouvelle ère de gestion de cas. Après avoir pataugé péniblement pendant cinq ans et après des coûts de presque 170 millions de dollars pour le gouvernement, le projet était mis à la poubelle pour des raisons d’inefficacité. Parmi les raisons avancées pour justifier l’échec du projet, on citait la piètre architecture technique, des changements répétés aux spécifications, et la microgestion.¹⁴

En 2006, le FBI ravivait ses efforts avec le projet Sentinel qui faisait appel à la méthodologie de développement en cascade pour la gestion du projet. En 2010, on n’avait achevé que deux des phases du projet à quatre phases et dépensé 405 millions de dollars du budget prévu de 451 millions de dollars. Le DPT a fait migrer le style de gestion de projet du modèle de développement en cascade vers Agile, après avoir été breffé sur la performance du projet en 2010. Après la transition, le projet était achevé dans les 12 mois pour un déboursé de 30 millions de dollars – des économies de plus de 90 %.¹⁵

Il est temps pour vous d’emprunter le sentier d’accès à Agile.

Il est temps d’amorcer votre transition vers la prochaine étape de mise en oeuvre d’Agile. Chez Modis, nous vous aidons à établir les contacts exceptionnels pour dénicher les talents versés en méthodologies Agile dont vous avez besoin. Pour obtenir plus d’information au sujet d’Agile, ou pour trouver le talent technologique par excellence pour votre entreprise, communiquez avec le représentant Modis de votre localité dès aujourd’hui.

Sources

• Agile Manifesto. History: The Agile Manifesto. http://Agilemanifesto.org/history.html
• Manifesto for Agile Software Development. http://Agilemanifesto.org/
• Version One. The 10th Annual State of Agile™ Report. https://versionone.com/pdf/VersionOne-10th-Annual-State-of-Agile-Report.pdf
• Scrum Methodology. http://scrummethodology.com/
• Version One. Agile Methodologies. https://www.versionone.com/Agile-101/Agile-methodologies/
• SolutionsIQ. What is Scrumban? http://www.solutionsiq.com/what-is-scrumban/
• Hewlett-Packard. Agile is the new normal: Adopting Agile project management. http://www8.hp.com/h20195/v2/getpdf.aspx/4AA5-7619ENW.pdf?ver=1.0
• Forbes. How To Make The Whole Organization Agile. http://www.forbes.com/sites/stevedenning/2015/07/22/how-to-make-the-whole-organization-agile/#55e4d665135b
• ReQtest. How Spotify does agile – A look at the Spotify engineering culture. http://reqtest.com/blog/how-spotify-does-agile-a-look-at-the-spotify-engineering-culture/
• Harvard Business School. The Spotify ‘Squad’: How to successfully lead a global organization WITHOUT an operations team. https://rctom.hbs.org/submission/the-spotify-squad-how-to-successfully-lead-a-global-organization-without-an-operations-team/
• Version One. Cerner Case Study. https://www.versionone.com/our-customers/case-studies/cerner/
• CIO. How the FBI Proves Agile Works for Government Agencies. http://www.cio.com/article/2392970/Agile-development/how-the-fbi-proves-Agile-works-for-government-agencies.html
• Congressional Testimony, US DOJ Inspector General Glenn A. Fine. https://oig.justice.gov/testimony/0502/final.pdf
• Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, And Leave Competitors In the Dust. Case Study: The FBI’s Sentinel Project. http://my.safaribooksonline.com/9781118240908/navpoint-10?link=106b6df7-7b31-425e-a539-e02c3ec13fb4&cid=shareLink

Téléchargez le livre blanc maintenant