L'approche agile est-elle trop une excuse pratique pour les cow-boys
Je crois qu'une approche agile est la meilleure pour les projets où les exigences sont floues et beaucoup d'interaction sont nécessaires pour aider à façonner les idées de l'utilisateur final.
Cependant ... Dans mon travail professionnel, je continue à me retrouver dans des entreprises où une approche "agile" est utilisée comme excuse pour pourquoi aucun effort n'a été mis dans une conception initiale; lorsque les exigences sont bien comprises.
Je ne peux pas m'empêcher de penser que si l'approche agile n'était pas là, je serais assis ici avec une spécification de haut niveau Nice et ne pas avoir à revoir le même écran et les mêmes fonctionnalités tous les deux jours quand quelque chose d'autre survient ou plus et donc n'y avait pas pensé.
Les avantages des méthodologies agiles sont-ils vraiment suffisants pour l'emporter sur 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 articles présentés sur le cours Scrum a observé que le meilleur processus de développement était celui où un seul expert ou gourou prenait les décisions de conception, mais qui présente des faiblesses évidentes. Scrum transfère la responsabilité de la production de logiciels de qualité à l '"équipe", ce qui signifie qu'une équipe de qualité inférieure peut s'en tirer avec des spaghettis qui, je suppose, ne sont pas différents des autres processus de développement Agile et non Agile.
Je crois que si vous utilisez le développement Agile comme excuse pour une programmation de style cowboy, alors vous ne suivez pas vraiment le développement Agile. Les Cowboys seront toujours des Cowboys, quel que soit le processus que vous leur donnerez.
Agile n'est pas plus responsable des mauvaises pratiques de développement que BDUF. Le problème réside dans la discipline, ou son absence, dans l'application des pratiques. Le but des pratiques BDUF est d'identifier la direction du projet et de déterminer au préalable les risques. Le but des pratiques agiles est de maintenir l'état du développement suffisamment flexible pour changer rapidement de direction. Un projet agile pourrait préparer des user stories très détaillées afin que l'équipe soit au courant des orientations futures et n'en sélectionne toujours que 2 ou 3 par itération pour une mise en œuvre complète. Quelle que soit la méthodologie utilisée, le problème reste le même: la direction laisse les cowboys se déchaîner.
[BDUF: Big Design Up Front]
Agile, comme n'importe quoi, peut être utilisé pour couvrir un mauvais comportement ou pour essayer de résoudre un problème dont l'équipe pense qu'elle n'est pas responsable.
Cependant, la magie de certaines méthodologies Agile comme Scrum est qu'elles fourniront beaucoup de visibilité sur les problèmes au sein de l'organisation. Y compris les problèmes au sein de l'équipe!
Vous aurez alors la possibilité de les résoudre au fur et à mesure de leur apparition.
Si le problème vient des cowboys, cela 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, d'après les projets "agiles" auxquels j'ai participé, cela ressemble plus à une excuse de gestion pour sauter la phase de collecte des exigences qu'à un désir de cow-boy de simplement commencer à coder. Mes projets ont été extrêmement frustrants car nous n'avons avons aucun utilisateur final avec lequel interagir. Au lieu de cela, nous avons un directeur qui parle aux ventes pour savoir ce qu'ils pensent que les clients veulent, puis appelle 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 avoir une PP présentation à laquelle nous référer, mais généralement nous finissons par passer nos réunions de mêlée quotidiennes pour demander comment certaines fonctionnalités sont censées fonctionner, et le gestionnaire écrit les questions et demande le réalisateur. C'est une énorme perte de temps - mais c'est "agile"!
Je ne dirai pas que je suis un fan de Waterfall, car moi aussi je fais face à un glissement de portée toujours 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 disant qu'il n'est pas responsable des échecs causés par les cowboys. Le succès avec Agile nécessite de la diligence et de l'intelligence.
Cela semble une position raisonnable, tant que vous appliquez la même concession à d'autres méthodologies. Si vous ne pouvez pas blâmer Agile pour les échecs de projet causés par des cowboys, vous ne pouvez pas blâmer les méthodologies non agiles pour les échecs de projet causés par des cowboys.
On peut alors se demander s'il existe une corrélation (pas une causalité!) Entre Agile et cowboys. Avec seulement des preuves anecdotiques, je crois que oui. Est-ce perçu comme un bon moyen de s'en sortir avec des pratiques de cow-boy sans être détecté par la direction?
Bien sûr, si nous acceptons que les cowboys ne soient pas répartis également entre les méthodologies, et nous acceptons que les cowboys sapent l'utilisation réussie d'un processus, nous avons rendu très difficile de tester si un processus est réussi. L'affirmation selon laquelle un processus est meilleur (dans un contexte) devient presque infalsifiable. C'est l'un des problèmes qui me font honte de ma profession de honte - le manque de fondement scientifique de nombreuses affirmations.
(Soit dit en passant, je déteste appeler la ou les alternatives à la "cascade" agile, car les processus en cascade semblent être un homme de paille que tout le monde attaque, mais très peu de gens ont jamais utilisé sans aucune itération.)
Agile, c'est bien tant qu'il travaille pour votre équipe.
Beaucoup trop le vendent comme un moyen de transformer une mauvaise équipe en une bonne équipe, et cela ne fonctionne tout simplement pas de cette façon. Vous ne pouvez pas prendre de mauvaises personnes et appliquer un processus pour les rendre soudainement utiles.
J'aime beaucoup d'idées derrière l'agile, mais l'échec que je vois maintes et maintes fois est que les managers poussent un ensemble strict de "processus agiles", qui va à l'encontre du concept entier d'agile, que les équipes devraient être autonomes -organiser.
En ce qui concerne les "cowboys", je trouve que pour toutes les équipes agiles sur lesquelles j'ai été, les processus servent à les ralentir plus qu'à les laisser se déchaîner. Je n'ai jamais connu de situation où l'agile servait à activer un "codeur cowboy".
Pour les bonnes équipes, cela semble bien fonctionner (là encore, la plupart des processus semblent bien fonctionner quand vous avez une bonne équipe, c'est drôle comment ça marche n'est-ce pas?).
Pour d'autres équipes, d'après mon expérience, cela n'aide jamais les mauvaises personnes à faire mieux, mais cela parfois sert à embourber les gens productifs.
Dans l'ensemble, je pense que l'important est de constituer une bonne équipe, de leur dire ce dont vous avez besoin, puis de vous éloigner. Je ne pense pas que l'application d'une chaîne de mots à la mode soit susceptible de résoudre le problème d'avoir une mauvaise équipe.
(Si vous n'avez pas compris ce qui précède, je ne suis pas du tout un fan de "Capitol-A Agile". D'un autre côté, je ne pense pas que cela encourage les cow-boys non plus.)
Agile lorsqu'il est fait correctement, il devrait avoir pour effet de maîtriser les pistes techniques "cowboy" et les programmeurs "héros". Si vous n'observez pas cet effet, cela peut être un signe que quelque chose d'important manque dans votre implémentation agile.
Je veux ajouter que "Agile" est vraiment une interface (j'utilise ici une métaphore orientée objet) et vous ne pouvez pas l'instancier. Si votre implémentation concrète est XP , alors vous devez suivre un tas de pratiques techniques avec beaucoup de discipline, ce qui laisse peu de place à la programmation cowboy. Une autre possibilité est que le travail d'équipe d'une équipe bien auto-organisée Scrum le maintienne en échec.
Les codeurs Cowboy ont également tendance à écrire du code qui n'est pas très testable, et ils n'aiment pas écrire des tests. Je pense que tout le monde fait du TDD peut aider à régner dans l'attitude cowboy et inciter les développeurs à réfléchir 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 qu'il s'agit plus de culture organisationnelle que de cowboys particuliers.
L'organisation a toujours fonctionné selon une approche relativement souple et "informelle Agile". Je ne dirais pas que c'est vraiment Agile, c'est plus "Agile de nom", mais simplement une méthodologie inexistante dans la pratique. Différentes équipes fonctionnent différemment, mais comme la culture organisationnelle globale n'a pas de méthodologie en place autre qu'un processus très agile de nom uniquement - c'est relativement cowboyish et chaotique dans l'ensemble - en particulier dans l'intégration (et il y en a beaucoup) ).
La morale de l'histoire est - Oui, cela arrive. Si je cherchais un emploi en ce moment, je serais très prudent avec cela. Si un magasin prétend être Agile - je poserais des questions assez difficiles dans l'interview pour m'assurer que plus qu'un mauvais terme d'Agile est réellement suivi.
J'ai constaté que les utilisateurs ne peuvent nous donner des commentaires qu'une fois qu'ils ont une application qu'ils peuvent utiliser, des écrans sur lesquels ils peuvent saisir des données. Alors seulement, ils comprennent vraiment ce que nous essayions de dire dans les documents d'exigences (que les clients signent mais tout le monde a sa propre version du sens). Si ce n'est pas un développement agile, ce sera un projet en cascade dépassant le budget mais l'application va changer une fois que vous l'avez livré. Votre première version n'est rien d'autre qu'un prototype permettant aux utilisateurs de discuter des exigences. Je préfère donc parler d'agilité plutôt que de dépassement de budget.
Je pense que c'est vrai, dans certains environnements Agile est utilisé comme excuse pour aucune discipline. Le vrai problème est que nous avons perdu de vue pourquoi nous avons une méthodologie. Personnellement, je pense que la méthodologie est un problème architectural dans le sens où l'architecture du système est censée répondre aux attributs de qualité non fonctionnels, la méthodologie devrait traiter certains de ces mêmes attributs (maintenabilité, productivité du développement, transfert de connaissances, et al.)
Voir la méthodologie comme un contrôle pour les attributs de processus implique deux choses: 1) sans métriques, nous ne pouvons pas comparer l'efficacité d'une méthodologie par rapport à une autre, 2) une décision active doit être prise sur les attributs importants (délai de livraison vs code qualité vs transfert de connaissances).
Sans avoir à la fois des métriques et un objectif tangible, nous choisissons simplement une méthodologie comme notre "plume magique" que si nous nous accrochons, nous serons en mesure de fournir des logiciels.
Maintenant, les détracteurs d'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 une personne n'ayant pas la discipline nécessaire pour suivre toutes les règles? La question est valable; cependant, c'est le symptôme, pas la cause. Si un ensemble précis et significatif (c'est la partie difficile) de métriques de processus est défini, testé et en temps opportun, je pense que nous découvrirons que la méthodologie particulière a peu à voir avec le succès. (Pour l'anecdote, j'ai vu des projets réussis utilisant une myriade de méthodologies et deux fois plus échouent en utilisant les mêmes méthodologies)
Alors, quelles sont les mesures? Ils varient d'un projet à l'autre, d'une équipe à l'autre et de temps à autre. 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. Ainsi, une approche consiste à diviser le projet en tâches d'une semaine par développeur et à suivre qui a fait l'estimation. Au fil du projet, ils peuvent modifier leurs estimations. Une fois la tâche terminée, si elle est désactivée de plus de 10% (1/2 par jour), nous la traitons de la même manière qu'un bogue - nous identifions pourquoi l'estimation est désactivée (c'est-à-dire qu'une table de base de données n'a pas été prise en compte), identifiez le action corrective (c.-à-d. impliquer le DBA dans l'estimation), puis continuer. En utilisant ces informations, nous pouvons créer des mesures telles que # de bogues d'estimation par semaine, # de bogues par développeur, # de bogues par KLOC, # de bogues par développeur-KLOC, etc. La publication de ces chiffres sur le wiki de l'équipe exerce une pression sociale importante et du point de vue managérial, après quelques semaines, vous pouvez générer un modèle prédictif des semaines de développement suivantes.
Et alors? C'est à ce moment-là 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 certains aspects de la méthodologie et voir comment cela affecte votre modèle. Certes, personne ne veut jouer avec un processus de développement de peur d'échouer, 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 parfaite pour votre équipe, mais vous pourriez tout aussi facilement trouver RUP, une cascade ou tout simplement un méli-mélo de meilleures pratiques pour être idéal.
Donc, ma suggestion est de ne plus vous soucier de ce que nous appelons le processus, de mettre en place des vérifications pertinentes pour nos objectifs de processus de développement et d'expérimenter différentes techniques pour améliorer ce processus.
Les codeurs Cowboy sont bons parce qu'ils aiment que les choses soient faites rapidement. Souvent, ils ne sont pas aussi préoccupés par les problèmes généraux ou la qualité du code, c'est pourquoi "codeur cowboy" est souvent une épithète. Leurs méthodes atténuent les risques de coûts d'opportunité liés à la livraison tardive du projet.
Les codeurs non-cowboy 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 moment, tenir compte des hypothèses, produire des documents volumineux que personne ne lit et livrer des systèmes tard ou très tard. Leurs méthodes tentent d'atténuer les risques de logiciels de mauvaise qualité.
L'éclat des méthodologies Agile est qu'elles exploitent les forces des deux types de codeurs en forçant des itérations de travail limitées dans le temps qui demandent aux codeurs de produire rapidement de petites pièces de haute qualité. Et chaque itération atténue à la fois les risques de coût d'opportunité d'une livraison tardive et les risques d'un logiciel de mauvaise qualité.
C'est drôle comme personne ne se considère comme un codeur de cow-boy. Je parie que la plupart des affiches sont ou ont été une;)
Je serais assis ici avec une belle spécification de haut niveau et je n'aurais pas à revoir le même écran et les mêmes fonctionnalités tous les deux jours, car quelque chose d'autre survient, et donc je n'y avais pas pensé.
Cela semble correspondre à l'expérience de mon collègue sur le projet "agile" sur lequel il est (je n'ai jamais été sur un projet 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 changer et à la tester à nouveau. Il trouve cela frustrant.
Je ne dénonce pas l'agile, je soupçonne que l'équipe ne fonctionne pas correctement - mais comme vous le dites, le terme "agile" peut parfois être utilisé par les cowboys pour convaincre la direction pointue que le design à moitié cuit est un positif plutôt qu'un négatif .
La raison pour laquelle Agile met très peu l'accent sur la conception/spécifications initiales n'est pas seulement 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 car elles contiennent suffisamment d'informations pour empêcher l'écrivain/lecteur de les saisir.
détachés - ils n'intègrent pas de rétroaction précieuse d'un système en marche (bien que dégénéré).