L’approche agile est-elle une excuse trop commode pour les cow-boys?

Je crois qu'une approche agile est préférable pour les projets où les exigences sont floues et où de nombreuses interactions sont nécessaires pour aider à définir les idées de l'utilisateur final.

Cependant ... Dans mon travail professionnel, je me retrouve souvent dans des entreprises où une approche "agile" est utilisée comme prétexte pour expliquer pourquoi aucun effort n'a été déployé dans une conception initiale; quand les exigences sont bien comprises.

Je ne peux pas m'empêcher de penser que si l'approche agile n'existait pas, je serais assis ici avec une spécification de haut niveau agréable et je n'aurais pas à revisiter le même écran et les mêmes fonctionnalités tous les deux jours lorsque quelque chose d'autre se présente. et donc je n'avais pas pensé à cela.

Les avantages des méthodes agiles sont-ils vraiment suffisants pour compenser l'excuse d'être boiteux qu'elle donne aux pistes techniques des cow-boys?

Mise à jour: Ironiquement, je suis maintenant un Scrum Master certifié. L'un des documents présentés sur le cours Scrum a observé que le meilleur processus de développement était celui où un seul expert ou un seul gourou prenait les décisions de conception, mais qui présentait des faiblesses évidentes. Scrum confie la responsabilité de la production de logiciels de qualité à "l'équipe", ce qui signifie qu'une équipe médiocre peut se permettre de produire des spaghettis qui, je suppose, ne sont pas différents des autres processus de développement agiles et non agiles.

Je crois que si vous utilisez le développement Agile comme excuse pour une programmation de style cow-boy, vous ne suivez pas vraiment le développement Agile. Les cow-boys seront toujours des cow-boys, quel que soit le processus que vous leur proposez.

L’agilité n’est pas plus à blâmer pour les mauvaises pratiques de développement que la BDUF. Le problème réside dans la discipline, ou son absence, dans l'application des pratiques. Les pratiques de BDUF ont pour but de déterminer l’orientation du projet et de déterminer les risques au préalable. Le but des pratiques agiles est de garder l’état du développement suffisamment souple pour pouvoir changer rapidement de direction. Un projet agile pourrait préparer des user stories très détaillées pour que l'équipe soit au courant des orientations futures et ne sélectionne que 2 ou 3 par itération à mettre en œuvre. Le problème reste le même quelle que soit la méthodologie utilisée: la direction laisse les cow-boys se perdre.

[BDUF: Big Design Up Front]

Agile, comme n'importe quoi , peut être utilisé pour couvrir un mauvais comportement ou pour tenter de résoudre un problème dont l'équipe pense ne pas être responsable.

Cependant, la magie de certaines méthodologies Agiles telles que Scrum est qu’elles offrent une visibilité considérable sur les problèmes de l’organisation. Y compris les problèmes au sein de l'équipe!

Vous aurez ensuite la possibilité de les résoudre au fur et à mesure qu'ils se présentent.

Si le problème se pose pour les cow-boys, ce sera très visible après la première itération. Si le problème est ailleurs, vous le verrez très bientôt aussi.

Curieusement, parmi les projets «agiles» auxquels je participe, cela ressemble plus à une excuse de la direction pour ignorer la phase de collecte des exigences qu’à un désir de cow-boy de simplement commencer à coder. Mes projets ont été extrêmement frustrant parce que nous n'avons des utilisateurs finaux d'interagir avec. Au lieu de cela, nous avons un directeur qui s’adresse aux commerciaux pour savoir ce qu’ils pensent que les clients veulent, puis convoque une réunion et la décrit aux gestionnaires, qui commencent ensuite à attribuer des tâches aux développeurs. Sur un "bon" projet, nous pourrions faire référence à une présentation PP, mais nous finissons généralement par passer nos réunions de mêlée quotidiennes à demander comment certaines fonctionnalités sont censées fonctionner, et le responsable écrit les questions et demande au directeur. C'est une énorme perte de temps - mais c'est "agile"!

Je ne dirai pas que je suis un fan de Waterfall, car je suis moi aussi confronté à un glissement de champ toujours plus frustrant, mais j'ai toujours vu Agile comme une concession au problème, pas un moyen efficace de le combattre. Une bonne conception, avec des tests itératifs précoces et de nombreux prototypes en papier, semble être beaucoup plus efficace.

Je vois des défenses du développement agile affirmant qu'il n'est pas responsable des échecs causés par les cow-boys. Réussir avec Agile requiert diligence et intelligence.

Cela semble une position raisonnable, tant que vous appliquez la même concession à d'autres méthodologies. Si vous ne pouvez pas reprocher à Agile les échecs de projets causés par les cow-boys, vous ne pouvez pas imputer aux méthodologies non-Agiles les échecs de projets causés par les cow-boys.

On peut alors se demander s’il existe une corrélation (et non une causalité!) Entre Agile et les cow-boys. Avec seulement des preuves anecdotiques, je crois qu’il en existe. Est-ce perçu comme un bon moyen de se débrouiller avec les pratiques de cow-boy sans être détecté par la direction?

Bien sûr, si nous acceptons que les cow-boys peuvent ne pas être répartis équitablement entre les méthodologies, et nous acceptons que les cow-boys compromettent l’utilisation réussie d’un processus, nous avons rendu très difficile la vérification du succès d’un processus. L'affirmation selon laquelle un processus est meilleur (dans un contexte) devient presque infalsifiable. C’est l’un des problèmes qui me rend honteux au sujet de mon métier: le manque de fondement scientifique de nombreuses revendications.

(Au fait, je déteste appeler la (les) alternative (s) alternative (s) à "chute d'eau" Agile, parce que le processus de chute d'eau semble être un homme de paille que tout le monde attaque, mais très peu de gens l'ont jamais utilisé sans itération.)

Agile va bien tant que cela fonctionne pour votre équipe.

Beaucoup trop de gens le vendent pour transformer une mauvaise équipe en une bonne équipe, et cela ne fonctionne tout simplement pas de cette façon. Vous ne pouvez pas prendre les mauvaises personnes et appliquer un processus pour les rendre soudainement utiles.

J'aime beaucoup des idées qui sous-tendent l'agile, mais l'échec que je constate à maintes reprises, c'est que les gestionnaires préconisent un ensemble strict de "processus agiles", ce qui va à l'encontre du concept entier d'agile, selon lequel les équipes doivent être autonomes. -organiser.

En ce qui concerne les "cow-boys", je trouve que, pour toutes les équipes agiles que j'ai côtoyées, les processus les ralentissent plus qu'elles ne les lâchent. Je ne l' ai jamais vécu une situation où agile servi pour permettre un « codeur de cow - boy ».

Pour les bonnes équipes, cela semble bien fonctionner (là encore, la plupart des processus semblent bien fonctionner quand vous avez une bonne équipe, drôle comment ça marche, n'est-ce pas?).

Selon mon expérience, cela n’aide jamais les mauvais à faire mieux, mais cela sert parfois à embêter les personnes productives.

Globalement, je pense que l’important est de former une bonne équipe, de leur dire de quoi vous avez besoin, puis de vous en sortir. Je ne pense pas que l'application d'une chaîne de mots à la mode puisse résoudre le problème de la mauvaise équipe.

(Si vous n'avez pas compris ce qui précède, je ne suis pas un fan de "Capitol-A Agile". En revanche, je ne pense pas que cela encourage les cow-boys non plus.)

Agile, une fois correctement effectué, devrait avoir pour effet de limiter les fils techniques "cow-boys" et les programmeurs "héros". Si vous n'observez pas cet effet, cela peut indiquer que quelque chose d'important manque dans votre implémentation agile.

Je veux ajouter que "Agile" est vraiment une interface (j'utilise une métaphore orientée objet ici) et vous ne pouvez pas l'instancier. Si votre implémentation concrète est XP , alors vous devez suivre un ensemble de pratiques techniques avec beaucoup de discipline, ce qui laisse peu de place à la programmation de cow-boys. Une autre possibilité est que le travail d'équipe d'une équipe Scrum bien organisée maintiendra le contrôle.

Les codeurs Cowboy ont aussi tendance à écrire du code qui n’est pas très testable, et ils ont tendance à ne pas aimer écrire des tests. Je pense que le fait que tout le monde fasse le TDD peut aider à régner sur l’attitude des cow-boys et amener les développeurs à penser un peu plus à l’architecture. Aucune méthodologie n'est parfaite, bien sûr.

Je travaille actuellement dans un magasin où c'est le cas, sauf que cela a plus à voir avec la culture organisationnelle qu'avec des cow-boys particuliers.

L'organisation a toujours opéré selon une approche relativement souple, "informelle Agile". Je ne dirais pas que c'est vraiment agile, c'est plus "de nom agile", mais tout simplement une méthodologie inexistante dans la pratique. Différentes équipes fonctionnent différemment, mais étant donné que la culture organisationnelle globale n’a pas de méthodologie en place autre que le processus très lâche "Agile au nom uniquement" - il est relativement cow-boy et chaotique dans l’ensemble - en particulier dans l’intégration (et il y en a beaucoup ).

La morale de l'histoire est la suivante: oui, cela se produit. Si j'étais à la recherche d'un emploi pour le moment, je ferais très attention à cela. Si un magasin prétend être agile - je poserai des questions assez difficiles lors de l'entrevue pour m'assurer que l'on suit bien plus qu'un abus d'appellation Agile.

J'ai constaté que les utilisateurs ne peuvent nous faire part de leurs commentaires que lorsqu'ils disposent d'une application qu'ils peuvent utiliser, d'écrans sur lesquels ils peuvent entrer des données. Ensuite seulement, ils comprennent vraiment ce que nous essayons de dire dans les documents d’exigences (les clients signent mais tout le monde a sa propre version de la signification). S'il ne s'agit pas d'un développement agile, le budget du projet en cascade sera dépassé, mais l'application changera une fois que vous l'aurez livré. Votre première version n'est plus qu'un prototype permettant aux utilisateurs de définir les conditions requises. Je préfère donc appeler cela agile plutôt que hors budget.

Je pense que c'est vrai, dans certains environnements, Agile est utilisé comme une excuse pour aucune discipline. Le vrai problème est que nous avons perdu de vue pourquoi nous avons une méthodologie. Personnellement, j’estime que la méthodologie est un problème d’architecture en ce sens que l’architecture du système est censée prendre en compte les attributs de qualité non fonctionnels. Elle devrait traiter de certains de ces mêmes attributs (maintenabilité, productivité du développement, transfert de et al.)

Considérer la méthodologie comme un contrôle des attributs de processus implique deux choses: 1) sans métriques, nous ne pouvons pas comparer l'efficacité d'une méthodologie à une autre, 2) une décision active doit être prise concernant les attributs importants (délai de livraison par rapport au code). qualité vs transfert de connaissances).

Sans avoir à la fois les métriques et un objectif concret, nous choisissons simplement une méthodologie comme notre "plume magique" qui, si nous nous en tenons à nous-mêmes, nous pourrons livrer des logiciels.

Maintenant, les opposants de Agile, XP, Scrum, etc. parlent de la fragilité de cette catégorie particulière de méthodologies. L'argument étant: pourquoi utiliser une méthodologie qui peut être sabotée par un individu sans discipline pour suivre toutes les règles? La question est valide. Cependant, c'est le symptôme, pas la cause. Si un ensemble de métriques de processus précises et significatives (c'est la partie difficile) sont définies, testées et que les retours d'information sont donnés rapidement, je pense que nous découvrirons que la méthodologie en question a peu à voir avec le succès. (De manière anecdotique, j'ai vu des projets couronnés de succès utilisant une myriade de méthodologies et deux fois plus échouant avec les mêmes méthodologies)

Alors, quelles sont les métriques? Ils varient d'un projet à l'autre, d'une équipe à l'autre et de temps en temps. Utile lorsque le calendrier de livraison est important, celui que j'ai personnellement utilisé est la compétence et la qualité de l'estimation. La plupart des développeurs peuvent estimer avec précision les tâches d'une semaine ou moins. Une approche consiste donc à diviser le projet en tâches d’une semaine par développeur et à déterminer qui a effectué l’estimation. Au fil du projet, ils peuvent modifier leurs estimations. Une fois la tâche terminée, si nous la désactivons de plus de 10% (une demi-journée), nous la traitons comme un bogue - nous identifions la raison pour laquelle l’estimation était désactivée action corrective (c'est-à-dire associer l'administrateur de base de données à l'estimation), puis passer à autre chose. En utilisant ces informations, nous pouvons créer des mesures telles que le nombre de bugs d'estimation par semaine, le nombre de bugs par développeur,

Et alors? C'est à ce moment que les méthodologies entrent en jeu - si vous avez un modèle prédictif qui ne répond pas aux qualités du processus, vous pouvez choisir d'ajouter ou de supprimer un aspect de la méthodologie et voir comment cela affecte votre modèle. Certes, personne ne veut jouer avec un processus de développement par peur des échecs, mais nous échouons déjà à un rythme constamment élevé et prévisible. En apportant des modifications individuelles et en mesurant le résultat, vous constaterez peut-être qu'Agile est la méthodologie idéale pour votre équipe, mais vous pouvez tout aussi bien trouver que RUP, une cascade ou tout simplement un fouillis de meilleures pratiques est idéal.

Je suggère donc de cesser de nous inquiéter de ce que nous appelons le processus, de mettre en place des contrôles pertinents pour nos objectifs de processus de développement et d'expérimenter différentes techniques pour améliorer ce processus.

Je serais assis ici avec une spécification de haut niveau agréable et je n'aurais pas à revisiter le même écran et les mêmes fonctionnalités tous les deux jours, car quelque chose de plus surgit ou à peu près et je n'avais donc pas pensé à cela.

Cela semble correspondre à l'expérience de mon collègue du projet "agile" auquel il participe (je ne l'ai jamais fait moi-même): on lui demande d'écrire un morceau de code selon certaines spécifications, puis juste au moment où il a fini de le tester et est prêt à passer à une nouvelle exigence qui l’oblige à la modifier et à la tester à nouveau. Il trouve ça frustrant.

Je ne crains pas l'agilité, je suppose que l'équipe ne fait pas l'agile correctement - mais comme vous le dites, le terme "agile" peut parfois être utilisé par les cow-boys pour convaincre les dirigeants pointeux que la conception à moitié cuite est un élément positif plutôt qu'un élément négatif. .

C'est drôle comme personne ne se considère comme un codeur cow-boy. Je parie que beaucoup des affiches sont ou ont été une;)

Les codeurs Cowboy sont bons parce qu’ils aiment faire les choses rapidement. Ils ne sont souvent pas aussi préoccupés par les problèmes généraux ou par la qualité du code, raison pour laquelle le "codeur cow-boy" est souvent une épithète. Leurs méthodes atténuent les risques liés aux coûts d'opportunité d'une livraison tardive du projet.

Les codeurs autres que les cow-boys aiment faire leur travail de manière sûre, disciplinée et ordonnée. Ils aiment bien le construire et le construire une fois. Ils sont connus pour collecter des informations à tout jamais, envisager des hypothèses, produire des documents volumineux que personne ne lit, et fournir des systèmes tard ou très tard. Leurs méthodes tentent d'atténuer les risques d'un logiciel de mauvaise qualité.

L’intérêt des méthodologies Agiles réside dans le fait qu’elles exploitent les atouts des deux types de codeurs en imposant de brèves itérations de travail limitées dans le temps qui leur demandent de produire rapidement de petits travaux de haute qualité. Et chaque itération atténue à la fois les risques de retard liés aux coûts d’opportunité et les risques liés à la mauvaise qualité des logiciels.

La raison, bien qu'agile, de mettre très peu l'accent sur la conception / les spécifications initiales n'est pas simplement parce que les exigences peuvent changer. La raison la plus profonde est que même lorsque les exigences sont stables, les spécifications ont tendance à être:

• incorrect - ne parvient pas à capturer les exigences.

• incohérent - criblé de contradictions parce qu'elles contiennent suffisamment d'informations pour empêcher l'écrivain / lecteur de les saisir.

• détachés - ils n'intègrent pas les retours précieux d'un système en cours d'exécution (bien que dégénéré).