Existe-t-il des études sur l'efficience / efficacité de Agile vs Waterfall [fermé]

Lors d'une réunion de l'autre jour, une affirmation a été faite selon laquelle l'agilité n'était que 60% aussi efficace en temps de développement que la cascade. Je ne cherche pas à valider ou à réfuter cette affirmation. Je suis intéressant de savoir s'il y a eu des études comparant les 2 méthodologies.

Existe-t-il des études comparant les deux?

Le livre "Making Software: What Really Works and Why we Believe It" contient quelques chapitres sur les méthodes Agiles, y compris XP, Scrum, Dynamic Software Development et Lean, avec un bon soutien scientifique. C'est de haute qualité, comme on peut s'y attendre de O'Reilly. L'un des éditeurs était l'excellent Greg Wilson , un auteur, éditeur et présentateur de confiance en informatique.

Le livre lui-même résume plusieurs études de recherche, dont beaucoup sur l'agilité. Une section résume les recherches, notamment: «Deux têtes valent-elles mieux qu'une? Sur l'efficacité de la programmation par paires » par Dybå, T .; Arisholm, E.; Sjøberg, DIK; Hannay, JE; Shull, F .; et " Études empiriques sur le développement de logiciels agiles: une revue systématique " par Tore Dybå et Torgeir Dingsøyr.

Le sentiment général est que la plupart des pratiques agiles sont bénéfiques, mais que les effets de la programmation par paires et du TDD et d'autres locataires agiles ne sont pas aussi forts qu'on pourrait l'espérer. Il y a même une note de bas de page inquiétante selon laquelle le TDD peut en fait être quelque peu addictif *.

Le livre est un excellent moyen d'accéder à de nombreuses recherches qui ont été faites, le tout dans un ensemble cohérent. Il existe quelques blogs et autres sites sur le Web qui examinent le livre.

* Ce n'est pas nécessairement mon avis!

Même si je n'aime pas le titre, je pense que Balancing Agility and Discipline: A Guide for the Perplexed peut contenir des informations qui vous concernent. Ce livre a été rédigé par deux experts en processus de génie logiciel et en gestion de projets logiciels - Barry Boehm et Richard Turner. Ce livre examine divers aspects des méthodologies agiles et axées sur les plans, les compare et les contraste, et discute également de leur intégration pour parvenir à une situation «le meilleur des deux mondes».

L'annexe E de Équilibrer l'agilité et la discipline contient une mine d'informations empiriques concernant les coûts et les avantages de diverses méthodes agiles et axées sur les plans. Cependant, il ne semble pas y avoir de données concernant l'efficacité du temps. Mais en parcourant les données, il semble (comme je le soupçonnais) que ce n'est pas un choix ni l'un ni l'autre - certains projets ont connu des efforts réduits, des calendriers plus rapides et des défauts inférieurs lors de l'application de méthodes agiles. Cependant, d'autres projets qui ont utilisé. La section traite d'un certain nombre de projets différents dans différentes industries, du type de processus qu'ils ont utilisé et de ce qu'ils ont vécu au cours du projet.

De nombreuses études de cas citées à l'annexe E fournissent ces données. Il y en a beaucoup trop pour que je puisse commencer à nommer au hasard, car beaucoup se concentrent sur une industrie particulière ou même au sein d'une organisation particulière. Si vous voulez examiner des cas, je suggérerais de trouver ceux qui sont de nature similaire à votre équipe, projet, organisation et industrie pour tirer des conclusions raisonnablement valables.

Dans Rapid Development: Taming Wild Software Schedules , Steve McConnell identifie un certain nombre de facteurs à prendre en compte lors du choix d'une méthodologie de cycle de vie: niveau de compréhension des exigences, niveau de compréhension de l'architecture, fiabilité souhaitée, gestion des risques, contraintes de calendrier, quantité de processus les frais généraux, les «corrections de cap» à mi-projet, la capacité de fournir au client une visibilité, la capacité de fournir une visibilité à la direction et la sophistication de l'équipe de développement et de la gestion. Il y en a aussi d'autres, comme la culture organisationnelle, il n'y a donc probablement pas de liste exhaustive nulle part.

Même pour le même projet, il y a aussi le facteur équipe. Si vous prenez une équipe qui a constamment livré des logiciels en utilisant la méthodologie en spirale basée sur un plan et les jetez dans Scrum, ils vont connaître une baisse de productivité, une augmentation du thrashing et devront surmonter un nouveau modèle de processus avant de pouvoir venir autour de réussir. Même si une autre méthodologie pourrait être plus adaptée, il y a toujours le besoin commercial de fournir réellement le logiciel. C'est pourquoi les efforts d'amélioration des processus sont souvent des efforts à long terme et non du jour au lendemain - des changements majeurs choquent une équipe et (même si la méthodologie peut être mieux adaptée sur le papier) peuvent entraîner une diminution de la productivité.

Il y a bien plus que l'efficience ou l'efficacité du processus, et vous ne pouvez pas simplement regarder un instantané de la même équipe travaillant dans un environnement piloté par plan et un environnement agile. Vous devez prendre en compte le contexte industriel et organisationnel, les attributs du projet, l'équipe, le client, etc. lors de la prise de décision.

Sur la base de ce que j'ai lu, je vais devoir être en désaccord avec votre évaluation des collègues. Je suis sûr que vous pouvez trouver une étude de cas quelque part où un projet agile était 60% moins efficace en ce qui concerne certaines mesures de performance qu'un projet basé sur un plan similaire. Cependant, il existe également des études qui montrent que l'agilité génère 80% d'efforts en moins, 50% de temps en moins et une satisfaction élevée des clients avec le produit.

Je n'ai pas d'étude mais j'aimerais partager mon expérience.

L'efficacité de l'une des méthodologies mentionnées dépend fortement des analystes.

Lorsque vous avez un grand propriétaire de produit, SCRUM par exemple est certainement plus rapide qu'une approche en cascade avec une mauvaise spécification.

Agile avec un mauvais propriétaire de produit est certainement plus lent que la cascade avec une grande spécification.

Cependant, le plus souvent, nous ne connaissons pas les exigences exactes suffisamment tôt et les méthodologies agiles ont des cycles de rétroaction plus rapides. Cela signifie que, dans un terrain incertain, l'agilité est une meilleure méthode pour fournir un produit de haute qualité à des coûts raisonnables. Il existe de nombreux autres avantages, par exemple, les projets agiles sont plus faciles à annuler lorsqu'ils ne fonctionnent pas et peuvent ainsi réduire les pertes au minimum.

On pourrait dire que les méthodologies agiles réduisent le risque, tandis que la cascade, même si elle peut parfois être plus rapide, peut être un pari assez monétaire.

agile était seulement 60% aussi efficace en temps de développement

Vrai.

Mais, c'est une mesure boiteuse.

Les méthodes agiles fournissent généralement une valeur réelle plus tôt.

La cascade respecte simplement un calendrier indépendamment de ce qui est livré et n'apporte souvent rien de valable jusqu'à ce qu'une énorme période de temps soit écoulée.

Plus loin.

Vous pouvez mesurer le «temps de développement» séparément du «temps de développement et de test».

Agile comprend généralement des tests. Cela semble donc plus lent.

Le développement de la cascade peut être clairement séparé des tests. Le code est donc "prêt à tester" plus tôt. Mais ce n'est "fait" que bien plus tard.

Alors. Ils ont tout à fait raison. Pour ce qu'ils ont mesuré.