Scrum crée-t-il des frais généraux supplémentaires pour les projets où les exigences ne changent pas?
Je lis le Scrum - Un guide de poche par Gunther Verheyen et il dit:
Le rapport Chaos de 2011 du Standish Group marque un tournant. Des recherches approfondies ont été effectuées pour comparer des projets traditionnels avec des projets utilisant des méthodes Agiles. Le rapport montre qu'une approche Agile du développement de logiciels se traduit par un rendement beaucoup plus élevé, même contre les anciennes attentes selon lesquelles les logiciels doivent être livrés à temps, dans les limites du budget et avec toute la portée promise. Le rapport montre que les projets Agile ont été trois fois plus réussis, et il y avait trois fois moins de projets Agile ayant échoué par rapport aux projets traditionnels.
J'ai donc un argument avec un de mes collègues qui dit que pour certains projets (comme la médecine/militaire où les exigences ne changent pas), Agile (et, en particulier, Scrum) est au-dessus de toutes les réunions, etc. et c'est plus logique d'utiliser la cascade, par exemple.
Mon point de vue est que Scrum devrait être adopté dans de tels projets car cela rendra le processus plus transparent et augmentera la productivité d'une équipe. Je pense également que les événements Scrum ne prendront pas beaucoup de temps si ce n'est pas nécessaire, car nous n'avons pas besoin de passer les 8 heures entières dans Sprint Planning pendant 1 mois de sprint. Nous pouvons consacrer 5 minutes juste pour être sûrs que nous sommes tous sur la même longueur d'onde et commencer à travailler.
Alors, Scrum créera-t-il des frais généraux supplémentaires pour un projet où les exigences ne changent pas?
Je pense que c'est une hypothèse erronée de dire qu'il y a des projets où les exigences ne changent pas. Ayant travaillé à la fois dans l'industrie de la défense et dans l'industrie pharmaceutique pour la fabrication de logiciels, je peux vous dire qu'une fois que les logiciels se retrouvent entre les mains d'experts en la matière (internes ou externes), il y a du feedback. Parfois, ces commentaires portent sur la façon dont l'exigence a été satisfaite et dans d'autres cas, ils sont en fait sur les exigences elles-mêmes erronées ou incomplètes.
L'agilité consiste à réduire ce cycle de rétroaction et à mettre plus rapidement un logiciel fonctionnel entre les mains de quelqu'un, à obtenir cette rétroaction et à décider de la prochaine étape pour s'assurer que ce qui est livré ajoute de la valeur lorsque le client décide d'accepter le logiciel. Même dans des domaines tels que les systèmes embarqués avec du matériel personnalisé (comme vous pouvez le trouver dans des domaines tels que l'aérospatiale, l'automobile ou les appareils médicaux), la fourniture rapide de minces tranches de fonctionnalités à intégrer et à prototyper peut vous aider à vous assurer que le système logiciel et matériel va fonctionner comme prévu et d'une manière qui aidera l'utilisateur final.
La réduction de la durée du cycle de rétroaction est un facteur énorme de réduction des risques. Du point de vue de la gestion de projet, si vous financez un projet pendant 2 à 4 semaines et obtenez une visibilité régulière sur l'avancement, cela vous assure que vous êtes sur la bonne voie. En étant en mesure de fournir de fines tranches de fonctionnalités, vous travaillez progressivement vers l'état cible et pouvez commencer à prévoir quand vous y arriverez. Si le temps devient une contrainte, vous pouvez réduire les fonctions de valeur inférieure, car le travail effectué en premier doit être soit une fonction de valeur élevée, soit un catalyseur pour une fonction de valeur élevée. À tout moment, vous pouvez décider s'il vaut la peine de continuer à financer l'effort ou aller dans une direction différente et arrêter un projet avant qu'il ne soit trop tard.
La réponse très courte est que oui, Scrum est par conception une approche plus coûteuse, mais si vous l'appelez un projet, cela n'a certainement pas d'importance et au final, il en résultera presque toujours un meilleur retour sur investissement.
La réponse la plus complète est la suivante:
De manière générale, il existe trois formes de contrôle de processus: le contrôle de processus défini, le contrôle de processus statistique et le contrôle de processus empirique. Le contrôle de processus défini est de loin le moins cher. Cela est possible avec un travail fréquemment répétable qui a été affiné au fil du temps pour trouver la "meilleure" façon de faire le travail. CI/CD dans le développement de logiciels tombe dans cette catégorie. Vous ne voulez pas de variation dans votre processus de construction, vous standardisez donc le processus, ajustez-le jusqu'à ce que vous en soyez satisfait, puis automatisez-le. Ce processus automatisé est évidemment beaucoup moins coûteux à exécuter que de se battre manuellement à travers un déploiement.
Le contrôle statistique des processus est le deuxième moins cher, mais il tient compte des variations d'un processus connu. Les procédures médicales qui se déroulent selon le plan entrent dans cette catégorie. Je ne veux pas réinventer un pontage à chaque fois. Je suis le processus de base et je m'adapte aux variations. Cela a une charge cognitive relativement faible et un taux de réussite assez élevé.
Vient ensuite le contrôle de processus empirique, qui est de loin le plus cher car vous devez découvrir le processus au fur et à mesure. L'apprentissage est incroyablement élevé, mais au prix de la productivité et de l'efficacité. Cependant, presque tout le travail de projet l'exige car peu de projets ont été réalisés auparavant. Il y a, bien sûr, des exceptions. La configuration d'un grand environnement Active Directory est plus statistique car vous travaillez à partir d'instructions éprouvées que vous déviez légèrement en fonction des circonstances. Mais à moins que votre projet ne fasse exactement le travail qui a été fait auparavant, cela nécessite presque certainement un contrôle de processus impérial.
Pour le ramener à Scrum, Scrum est conçu pour résoudre les problèmes avec le contrôle du processus impérial. À cet effet, oui, il a plus de frais généraux que d'autres approches. Cependant, comme la plupart des projets nécessitent cette approche, c'est un argument théorique.
Au contrepoint de la médecine et des projets militaires, cela ressemble à une logique défectueuse. Si vous exécutez une commande de 500 avions, alors oui, vous recréez quelque chose exactement et Scrum n'est probablement pas bénéfique. Si vous construisez un nouvel avion et que vos besoins ne changent jamais, je ne piloterais pas cet avion.
Bien sûr, si vous avez un projet pour lequel vous avez des exigences limpides à l'avance, vous pouvez les déposer en cascade devant les développeurs et revenir deux ans plus tard pour rencontrer le logiciel de vos rêves.
Mais la grande majorité des projets logiciels n'est pas comme ça.
Habituellement, le client ne sait pas de quoi il a besoin. Ils ne sont pas en mesure de fournir des exigences complètes et spécifiques. Les approches itératives aident ici: construire une petite chose, puis demander des commentaires au client. Oui, cela "fait perdre" du temps sur les démos et la planification de la prochaine itération. Mais construire la mauvaise chose pour un sprint puis corriger rapidement les exigences est bien mieux que de construire la mauvaise chose pour l'ensemble du projet. C'est à dire. tandis que les exigences initiales peuvent permettre un développement plus efficace, les approches itératives seront plus efficaces.
Les développeurs doivent comprendre correctement les exigences s'ils veulent créer des logiciels utiles. Quelle est la bonne façon de découvrir les malentendus avant qu'il ne soit trop tard? Encore une fois, les approches itératives peuvent aider. Mais il est également important que les développeurs eux-mêmes collaborent avec le client au lieu d'obtenir uniquement des informations filtrées via un auteur de document d'exigences.
Enfin, le monde ne s'arrête pas pendant le projet. Les systèmes externes changent, les priorités changent, les gens changent. Prétendre que les exigences d'un projet logiciel ne changeront pas est une mauvaise idée, sauf pour les projets courts.
Tous ces avantages au niveau du processus manquent le gros avantage quotidien des approches agiles: si elles sont faites correctement, l'agile rend tout le monde plus heureux. Le plus important d'entre eux est que les techniques agiles se concentrent sur la fourniture d'une valeur réelle sur de courts délais. Cela donne de la visibilité au processus de développement, donne aux parties prenantes un niveau raisonnable de contrôle sur le projet et est beaucoup plus motivant que de travailler vers un objectif éloigné. À cela s'ajoute l'idée que les équipes agiles seront largement auto-organisées. Le sentiment de contrôle sur leur travail quotidien donne aux gens le sentiment d'être valorisés et donc plus susceptibles de donner le meilleur d'eux-mêmes.
Votre collègue n'a pas tort que les projets de style cascade puissent avoir leur place. Et vous ne vous trompez pas que certaines pratiques agiles peuvent être des rituels qui font perdre du temps. Mais il est complètement stupide d'ignorer les avantages des approches agiles et itératives, en particulier une meilleure gestion des risques et le respect des individus. Ce sont des choses que vous voulez dans chaque projet. Si nécessaire, une équipe peut essayer de mettre en œuvre une partie de cela en interne, mais les processus fonctionnent mieux lorsque tout le monde est à bord.
Je pense que cela pourrait bien paraphraser ce que dit @Cort Ammon, mais voici mon point de vue:
Les exigences externes (décrivant les "livrables") ne sont pas les seules exigences d'un projet. Même si les exigences externes ne changent pas, les exigences "internes" changeront ou devront être modifiées au fur et à mesure que vous travaillez. Les développeurs découvriront des obstacles ou des problèmes avec une approche, ce qui affectera le travail des autres personnes de l'équipe. Un stand-up quotidien tiendra tout le monde au courant de ces changements internes.
Considérez que:
Même avec des exigences fonctionnelles fixes, vous devez les traduire en exigences techniques. Et cela peut être mieux fait par itérations. Vous découvrirez peut-être de meilleures façons de résoudre le problème au milieu du projet.
Certaines exigences peuvent être trop génériques ou ambiguës: "être facile à utiliser", "être sécurisé". Il est difficile d'analyser la sécurité ou l'utilisabilité d'un système qu'il n'est pas terminé. Certains peuvent avoir des implications cachées ou peuvent ne pas être bien compris.
Certaines exigences peuvent être améliorées. Répondre en 200 ms peut être bon, mais 100 peut être meilleur. Vous pouvez viser le meilleur résultat possible mais le sacrifier si nécessaire pendant le projet.
Vous découvrirez peut-être des exigences cachées qui ne seront pas écrites sur le contrat mais qui peuvent faire passer le projet de l'échec au succès. Même si vous livrez le projet, le client peut ne pas être satisfait. Il se peut même qu'ils aient besoin de modifier le contrat pour ajouter (et facturer) de nouvelles fonctionnalités que vous pouvez concevoir dans le projet moins cher au début.
Vous découvrirez peut-être que vous ne pouvez pas répondre à vos besoins dans le délai imparti. Ce n'est pas comme si les projets logiciels n'étaient jamais en retard. Ainsi, offrir la meilleure valeur vous permettra de renégocier les fonctionnalités à supprimer.
Livrer quelque chose plus tôt facilitera l'intégration et montrera que ce projet peut produire des résultats.
On peut faire valoir que si toutes les exigences sont énoncées parfaitement, il existe une approche descendante qui atteint ces exigences le plus rapidement possible. Cependant, si ce sont de bonnes exigences, elles vous disent quoi faire, pas comment le faire. S'ils vous disent comment le faire, je choisirais de l'appeler "instructions de travail" au lieu d '"exigences" et nous discuterions d'un type de problème différent.
En conséquence, il existe toujours un processus d'élaboration du "comment" interne à l'entreprise ou à l'équipe mettant en œuvre les exigences. Empiriquement parlant, nous comptons fortement sur une approche hiérarchique où une équipe de concepteurs conçoit le système de haut niveau pour répondre à ces exigences, puis utilise les spécificités de ce système de haut niveau pour fournir des "exigences" aux petites équipes qui étoffent nos détails.
Dans le processus en cascade, cela peut être vu dans la flèche à sens unique entre la conception et la mise en œuvre. Cependant, ces exigences ne sont pas gravées dans la pierre, comme celles fournies par le client. Celles-ci sont définies en interne et ont de la place pour le processus itératif. Dans la pratique, nous constatons que les concepteurs mettent une marge considérable dans le processus pour tenir compte de ce manque d'itération ou recherchent un processus itératif.
SCRUM, et de nombreuses autres méthodes agiles connexes, fournissent simplement un cadre rigoureux dans lequel effectuer ce processus itératif. L'une des marques de commerce des approches agiles est qu'elles considèrent l'optimisation de ce modèle itératif comme étant le cœur du processus, plutôt que de se concentrer sur la couche externe des exigences strictes. Comme d'autres l'ont mentionné, réelles les exigences fixes sont rares, mais même en leur présence, SCRUM utilise l'approche itérative comme méthodologie pour contrôler l'approche contractuelle à laquelle il s'intègre.
La question de savoir s'il y parvient est un sujet de débat ouvert. D'autres ont fourni de nombreuses mesures à cette fin. Je noterai simplement qu'il appartient à la force de la direction de s'assurer que les itérations qui se produisent en dessous d'elles se rejoignent correctement dans le système contractuel ci-dessus. Cela est vrai avec n'importe quelle approche du développement, mais cela est plus visible dans les approches agiles parce que nous avons été amenés à supposer que l'approche la plus descendante est "normale" et les dirigeants formés en tant que tels.