Is Agile more effective than the waterfall method?
L'un des Scrum Masters que nous coachons régulièrement nous appelle souvent pour des problèmes auxquels il est confronté. Il a plaisanté en disant que nous devrions répondre au téléphone par « Hotline Agile, comment pouvons-nous vous aider ? ». Nous avons trouvé que c'était une excellente idée et c'est pourquoi nous lançons maintenant une série d'articles de blog intitulée Agile Hotline. Vous y trouverez nos réponses aux questions que nous recevons sur Agile ou Scrum. Nous espérons que vous pourrez également en tirer des enseignements.
Récemment, on m'a demandé conseil concernant une discussion que quelqu'un avait eue avec un collègue. Il s'agissait de savoir si Agile et Scrum peuvent fonctionner dans tous les scénarios de développement logiciel. Le collègue affirmait que non.
Le scénario
Imaginons qu'un produit logiciel doive être développé pour permettre aux utilisateurs de donner des évaluations lorsqu'ils lisent un e-book. Il doit y avoir au moins deux types différents d'évaluations.
Avec Agile ou Scrum, on essaierait de livrer un produit fonctionnel et de valeur le plus tôt possible – l'objectif est donc de ne livrer qu'une seule des possibilités d'évaluation, mais utilisable rapidement par les utilisateurs. Ce serait alors la v1.0. Quelques Sprints plus tard, on essaierait d'implémenter la deuxième possibilité d'évaluation en v2.0.
Avec le modèle en cascade, on prendrait tout le temps nécessaire pour livrer les deux types d'évaluations dans la première version.
Dans ce cas, le collègue argumentait que la cascade serait plus judicieuse, car le risque serait sinon très élevé de devoir refactoriser tout le code pour pouvoir supporter la deuxième possibilité d'évaluation en v2.0. Avec la cascade, les deux types d'évaluations seraient développés ensemble. Même si la livraison de la première version fonctionnelle prendrait plus de temps, il y aurait moins de retouches à faire.
Il pense que la méthode en cascade fait gagner du temps et est plus efficace, car on a moins besoin de refactoriser quand on commence le développement avec les exigences actuelles et futures en même temps. Avec Agile, notre focus est sur le « maintenant » et sur un seul type d'évaluation.
Qu'en pensez-vous ? Comment géreriez-vous un groupe de développeurs qui pensent qu'avec Agile, ils devront beaucoup retravailler plus tard parce qu'ils « n'ont pas eu le droit de planifier trop loin à l'avance » ?
Ce que nous pensons
Il y a trois points essentiels à comprendre pour répondre à cette question :
Premièrement : Agile et Waterfall ont chacun leur domaine d'application. Agile est conçu pour les systèmes compliqués/complexes, par exemple quand il existe un certain degré d'incertitude concernant les exigences et/ou la technologie. Waterfall convient mieux aux projets simples, par exemple quand les exigences et la technologie sont bien comprises et ne changent pas. Nous utilisons la Stacey Matrix pour déterminer quand utiliser quelle approche. Le truc, c'est que Waterfall échoue complètement dans un environnement complexe, alors qu'Agile dans un environnement simple demande certes plus d'efforts mais fonctionne quand même. Notre exemple préféré est l'organisation d'une conférence. On peut utiliser Agile, même si cela peut sembler être un effort superflu.
Deuxièmement : Agile n'est PAS plus efficient que Waterfall. Il est plus efficace. Cela signifie qu'on a peut-être besoin de plus d'heures-personnes pour livrer quelque chose avec Agile, mais le produit peut très probablement être mis sur le marché plus tôt (parce qu'il devrait y avoir une release à la fin de chaque Sprint et non pas seulement à la fin du projet). De plus, le coût total de possession est probablement plus bas (parce que la qualité et la conception sont meilleures et que les connaissances sont partagées, ce qui facilite la maintenance).
Troisièmement : Agile ne consiste pas à développer quelque chose de précis plus vite. Il s'agit de l'art de maximiser la quantité de travail non fait. L'étude Chaos indique que 65 % d'un logiciel n'est jamais ou rarement utilisé. Avec Agile, on essaie d'identifier et de développer les 35 % restants qui seront le plus probablement utilisés ; ensuite on s'arrête. Donc même si le développement des premiers 35 % prend peut-être un peu plus de temps, on s'est épargné le développement des 65 % restants que personne n'utilisera.
À quoi cela ressemble-t-il avec notre exemple ? Eh bien, tout d'abord, on ne terminerait pas entièrement la première évaluation avant de passer à la seconde. On identifierait la partie la plus précieuse de l'évaluation. Cela peut être un certain type de question (par exemple une question à choix multiples). On n'intégrerait donc qu'une seule question dans l'évaluation, on la ferait tester par des utilisateurs et on vérifierait si elle fonctionne. On pourrait même livrer la première possibilité d'évaluation uniquement avec des questions à choix multiples. Ensuite, on intégrerait le type de question suivant par ordre d'importance. Ou bien on décide que c'est suffisant et on commence un nouveau projet.
Si le périmètre des évaluations est vraiment défini, qu'on sait en plus que cela fonctionne réellement pour les utilisateurs, et qu'il n'y a aucune incertitude concernant la technologie, Waterfall peut être le meilleur choix pour ce projet. Agile fonctionnerait aussi, mais ne ferait pas nécessairement gagner du temps. D'expérience, je peux dire que la plupart des gens pensent connaître et avoir compris toutes les exigences – mais ce n'est généralement pas le cas. L'effort supplémentaire avec Agile en vaut donc généralement la peine.
Ce texte provient du blog de Growing Agile et a été traduit par nos soins en français.
