Agile est-il le nouveau microgestion?

80

Cette question me trottait dans la tête depuis un moment donc je voulais demander à ceux qui suivent des pratiques agiles / scrum dans leurs environnements de développement.

Mon entreprise s'est finalement lancée dans l'incorporation de pratiques agiles et a démarré avec une équipe de quatre développeurs d'un groupe agile à titre expérimental. Cela fait 4 mois avec 3 itérations et ils continuent à le faire sans aller complètement agile pour le reste d'entre nous. Cela est dû au fait que la direction a confiance de pouvoir répondre aux exigences de l’entreprise avec une assez grande demande de type ad hoc émanant d’en haut.

Récemment, j'ai parlé aux développeurs qui participent à cette initiative. ils me disent que ce n'est pas amusant. Ils ne sont pas autorisés à parler à d'autres développeurs par leur maître Scrum et ne sont pas autorisés à prendre d'appels téléphoniques dans la zone de travail (ce qui est peut-être bien dans une certaine mesure). Par exemple, si je veux parler à mon ami pour les coups de pied qui fait partie de l'équipe agile, je ne suis pas autorisé sans l'autorisation du maître Scrum; qui est assis juste à côté de l'équipe agile.

L’idée de tout cela, ou de l’agile, est de fournir un vide complet aux développeurs agiles, à partir de toute interruption, et de leur faire passer plus de 6 heures productives. Eh bien, les gars, je ne suis pas un gourou agile, mais ce que j'ai lu dans le document de déploiement agile de Yahoo et similaire pour d'autres organisations, cela me donne le sentiment que l'agile n'est pas bon marché. Il faut des ressources et un budget pour insuffler de l'agilité aux équipes et corriger le problème à mesure qu'elles arrivent pour les remettre sur les rails.

Pour commencer, cela nécessite une formation pour les développeurs et un encadrement pour les gestionnaires, etc. Le maître Scrum actuel était un gestionnaire qui a suivi une formation agile de deux jours payée par la direction et dirige maintenant cette équipe agile. J'ai également entendu au cours de la réunion que le manifeste agile ne dit pas que l'agile n'est pas figé et qu'il est personnalisé différemment pour chaque entreprise. Eh bien, tout cela sonne bien et la raison.

En conclusion, j'ai toujours pensé que l'agile était censé apporter de l'harmonie dans les équipes de développement, ce qui rend les développeurs heureux. Cependant, je ressens un sentiment opposé lorsque je parle aux développeurs de l'équipe agile. Ils sont mécontents de ne pouvoir parler que de travailler, de rester assis tranquillement toute la journée à travailler, et ils estiment que c'est simplement un autre moyen pour la direction de les faire travailler davantage.

Dites-moi s'il vous plaît, si c'est l'un des exemples de bonnes pratiques utilisées dans le but de l'avantage égoïste pour plus de dollars? Ou peut-être que nous ne sommes que les développeurs comme moi et cette équipe agile a le sentiment qu'ils n'aiment pas travailler dans un environnement où ils ne respirent que parce qu'ils sont au travail.


C'est une entreprise dans le domaine de la santé qui a des bureaux à travers les États-Unis. Cela ressemble vraiment à un style de cow-boy agile, ce qui me donne vraiment envie de ne pas miser du tout sur l'agilité, surtout dans mon entreprise actuelle.

Tout cela a à voir avec la gestion étant complètement bon marché. Couper le café cher pour une version moins chère, mettre l'accent sur les économies et être productif tout en restant aussi mince que possible.

Mon sentiment est que quelqu'un de la direction derrière la porte a lancé cette idée, que l'agile vous permet de produire davantage afin que nous puissions montrer à nos chefs que nous produisons davantage avec le même effectif. Ou peut-être que cela nous permettra de réduire les effectifs si c'est le cas.

Ils ont leur réunion quotidienne de 5 minutes. Mais pas autorisé à discuter ou parler avec quelqu'un en dehors de leur équipe. Tout se concentre sur le travail.

Smith James
la source
71
J'ai vu plus d'abus au nom de l'agilité que ce que je tiens à commenter. Plusieurs fois, "nous faisons agiles" signifie "nous jetons tout semblant de processus et faisons ce que nous voulons, Yeehaw!" (pour la référence évidente de cow-boy). Un environnement calme aide certes, mais vous devez permettre aux développeurs de se parler et d’arranger des choses - sans l’ approbation de Scrum dictator .
Berin Loritsch
28
Eh bien, vous ne faites pas Agile ...
CaffGeek
13
C'est vraiment un discours. Pas une question.
JohnFx
8
Deux jours de cours sur le scrum master certifié ne font pas du manager un scrum master, tout comme 24 heures avec apprenez vous-même que c ++ en 24 heures ne vous rend pas capable de programmer en c ++. Ils font juste le mal.
Matt
9
lecture obligatoire: Manifeste semi-arse agile "Nous avons entendu parler de nouvelles méthodes de développement de logiciels en payant des consultants et en lisant les rapports Gartner ..."
gnat

Réponses:

89

Vous décrivez la dictature managériale, pas agile. Agile concerne le développement progressif dans un domaine où les exigences changent, et non pas de dicter aux gens la manière dont ils s’acquittent de leur travail.

Sami Lehtinen
la source
7
La seule chose que je pouvais trouver était un post "Joel on Software" parmi les 12 choses les plus importantes que chaque entreprise devrait offrir à ses programmeurs. L'un des 12 était un endroit tranquille pour travailler. Je doute que Joel Spolsky ait voulu dire cela cependant.
Berin Loritsch
5
Un lieu de travail calme serait un lieu où, si vous ne discutez pas, les choses sont généralement calmes et où vous pouvez avoir une conversation sans déranger les autres. Cela signifie qu’il n’ya aucune culture de recherche de personnes sur l’interphone et l’utilisation de générateurs de bruit blanc ou d’autres méthodes permettant de réduire le niveau sonore apparent dans les zones où travaillent de nombreuses personnes. Une règle interdisant de parler ne fait pas un lieu de travail calme.
Kevin Cathcart
5
@ Kevin Cathcart, nous sommes violemment en accord sur celui-là. Maintenant, j'ai été dans une entreprise où le contraire était vrai. Nous avions environ 40 personnes dans un enclos avec des tables ouvertes et aucun cube. La seule équipe qui pouvait faire quelque chose était celle qui faisait la majorité du bruit. C'est le type d'environnement contre lequel vous voulez vous protéger.
Berin Loritsch
8
@ Kevin - Mon département de développement est une ferme à compartiments ouverts, juste à côté d'un ensemble de trois cloches intitulées "Vente", "Grande vente" et "Grande vente". Quelques fois par jour, des vendeurs les appellent et crient "wooooo!". : - \
Dan Ray
2
@Dan J'ai eu une série d'interviews il y a quelques années, où trois startups m'ont dit qu'ils devaient éloigner les vendeurs des développeurs parce qu'ils étaient trop fort! @ # $ Ing.
Erik Reppen
46

Ils ne sont pas autorisés à parler à d'autres développeurs par leur maître Scrum et ne sont pas autorisés à prendre d'appels téléphoniques dans la zone de travail

Cela ne fait vraiment pas partie des pratiques Agiles - et une question distincte.

Une grande motivation des méthodologies Agiles est une communication accrue entre les développeurs. La restriction de la communication entre développeurs <-> est un problème distinct des pratiques Agiles. Je ne dis pas que cela ne se produit pas - c'est évident, et cela est considéré comme faisant partie du déploiement "agile" de votre organisation, mais il s'agit vraiment d'un problème distinct de l'agile (et quelque peu contraire à l'esprit du développement agile, OMI).

Reed Copsey
la source
29
Cela va tout à fait à l'encontre du tout premier principe du Manifeste Agile: "Les individus et les interactions par rapport aux processus et aux outils". Voir agilemanifesto.org pour plus d'informations.
Berin Loritsch
"Il est absolument contraire au tout premier principe du Manifeste <XXX>"; remplacez n'importe quoi pour XXX et vous aurez le choix du culte. ;-) Sérieusement, cela ne vous fait-il pas merveille?
CesarGon
5
@CesarGon, dans ce cas, nous parlons des principes de ce qui fait que le travail agile. Si vous ne pouvez pas vous conformer aux principes fondamentaux de l'agilité, alors vous ne voulez peut-être pas de l'agilité. Assez simple. Je ne dis pas "convertis à la foi", je dis "faites ce que vous dites croire". Sérieusement, ne pas que vous faire demander?
Berin Loritsch
1
@CesarGon, ce que le PO a décrit est à l'opposé de l'intention de cette ligne directrice, comme vous pouvez l'obtenir. À quel moment considérez-vous que votre ton moyen est suffisamment proche? La façon dont vous parlez semble indiquer qu’une différence de 95% entre les tonalités est suffisamment proche. Allons y. Et donnez-moi un peu de crédit. J'ai travaillé dans le monde réel et défini les processus dans les entreprises depuis longtemps. Je comprends très bien ce qui est assez proche - et ce que décrit le PO ne l’est pas.
Berin Loritsch
2
@Berin Loritsch: Je vous en donne le crédit; ce n'était pas mon intention de paraître autrement. Ma remarque initiale au sujet des sectes a en fait tenté de paraître partiellement plaisante. Ce que j'essaie de dire, c'est que nous n'avons pas besoin de quelques lignes sur un manifeste pour défendre quelque chose qui est flagrant contre le sens commun. L'OP décrit une situation qui fait sonner toutes les alarmes. J'espère que vous le prenez bien désolé si j'étais trop sévère. :-)
CesarGon
31

Cela ressemble à une implémentation assez perverse de l'agilité. L'agilité, si tant est que quelque chose, devrait réduire la microgestion, pas l'augmenter. L’équipe s’engage et fait partie du processus, c’est que la direction espère que l’équipe le réalisera. La mêlée quotidienne est un moyen pour les développeurs de communiquer entre eux et d’informer de ce qu’ils ont fait, et non pas de la façon dont ils ont passé leur temps (ce qui est une erreur que j’ai vue à quelques endroits). Même le processus d'estimation devrait supprimer la conservation du temps explicite des estimations, puisque vous devez estimer la complexité relative et non la durée d'une histoire (une autre erreur courante). Contrôler le temps passé par les développeurs est la marque de la microgestion, et la suppression du temps du processus est l’un des principes fondamentaux de l’agilité.

jjb
la source
24

L’environnement que vous décrivez ressemble à de la connerie pseudo-agile de variétés de jardin .

Je me suis impliqué avec Agile avant que ce soit Agile. Circa 2000 J'étais épuisé par le codage, j'ai entendu parler de la programmation extrême, je l'ai essayé et je l'ai aimé. En tant que développeur, cela m'a donné le contexte le plus important pour produire des logiciels performants, ainsi que des outils pour minimiser les conneries qui me rendaient dingue. Je l'ai aimé.

Le problème aujourd'hui, que j'explique en détail ailleurs , est que la plupart des personnes "adoptant Agile" ne sont pas intéressées à améliorer quoi que ce soit si cela les met mal à l'aise. Donc, pour eux, "Agile" est juste un nouveau bâton pour battre les développeurs de la même manière. Par opposition à, par exemple, un moyen d’accroître radicalement la productivité tout en supprimant toutes les conneries qui ralentissent le développement.

Maintenant. Je démarre une entreprise et je vais utiliser beaucoup d’EXP, ainsi que de nombreux autres trucs que j’ai appris dans le monde Agile. Mais justement à cause d’histoires telles que la vôtre, je tergiverse chaque fois que j’entends parler d’une adoption Agile de nos jours.

Donc, pour répondre directement à votre question: Agile ne devrait pas être la nouvelle microgestion. Il devrait s'agir de responsabiliser les personnes qui font le travail pour que ce soit fait. Mais dans votre cas, Agile ressemble au dernier mensonge qu’ils vous disent alors qu’ils se livrent à leur propre instinct. Pour lequel je suis vraiment désolé.

William Pietri
la source
4
+1 Agile / scrum / xp ou autre ne sont que des termes «mumbo jumbo» pour des boutiques informatiques qui ne sont pas de véritables éditeurs de logiciels. Comme vous l'avez dit, personne ne peut apporter de changements radicaux en se plongeant la tête dans le sable avec ces pratiques. Il suffit de lire cet excellent développement logiciel Lean: une boîte à outils agile et de mettre toutes les BS derrière. Ma conclusion est que ces pratiques ne sont pas pour les boutiques informatiques.
Smith James
23

Ce n'est pas agile.

Tout d'abord, Scrum n'est pas agile . Franchement, franchement, c'est des conneries. J'ai été élevé dans une maison de programmation extrême (littéralement - Kent Beck s'est assis sur le canapé de mon père et m'a parlé des tests), et je peux vous dire tout de suite que Scrum n'est pas ça. Scrum est un outil de gestion de projet - un rythme défini pour un projet de développement. Mais cela ne dit rien sur le développement lui-même et très peu sur les exigences, la planification et la relation avec le client. XP a beaucoup à dire sur tout cela; toute autre méthodologie qui se veut agile doit avoir quelque chose à ajouter à la conversation. Les partisans de Scrum l'ont décrit non pas comme un processus, mais comme un wrapper pour un processus. Un homme sage a un jour fait remarquer qu’une enveloppe est la chose que vous retirez et jetez pour obtenir les bonnes choses.

D'accord, mêlez-vous!

Deuxièmement, l'un des principes fondateurs de XP, qui est fondamental pour tout processus agile, est qu'il est centré sur le développeur . C'est une façon de donner aux développeurs le pouvoir de faire le travail dont ils savent qu'ils ont besoin et que l'on empêche souvent de le faire. Une équipe agile peut être structurée comme une démocratie ou une autocratie, mais les leaders sont des développeurs. Il y a des rôles pour les gestionnaires de projet et ainsi de suite - des rôles essentiels - mais ce n'est pas un rôle de chef d'équipe. Avoir un manager - désolé, 'Scrum Master' - rester assis à diriger des personnes est un signe certain que l'équipe ne fait pas preuve d'agilité.

Je pense qu'il devrait y en avoir une troisième. Il n'y a pas.

Tom Anderson
la source
-1, je ne suis pas d'accord. Le développement agile signifie également que vous purifiez et facilitez les processus, ainsi que la capacité d'adaptation aux changements. Ce qui se trouve être exactement ce dont parle Scrum. Scrum concerne également les exigences et la planification, mais différemment.
Falcon
6
Eh, allez, nous sommes en 2012. Citez l'écriture publique de Kent Beck ou laissez-la. Peu importe s'il se flatte sur votre canapé.
nes1983
6
@ nes1983: J'ai écrit cela en 2011. Les choses étaient alors différentes.
Tom Anderson
3
Je n'ai jamais entendu parler de «dette technique» jusqu'à ce que Scrum apparaisse sur mon radar. J'ai été à l'entraînement. Facilement vendue, Snake Oil était destinée à séduire la direction au détriment de la qualité à long terme du produit. 100% des conneries. Bien que je l'avale totalement si Scrum Masters devait porter une épée de style Conan pour frapper les personnes qui menaçaient l'intégrité du processus.
Erik Reppen
2
+1 pour le scrum. Je pense que Scrum est la méthodologie "Agile" pour ceux qui aiment tellement les cascades qu’ils veulent le faire toutes les deux semaines.
Kyralessa
16

Scrum est le bâtard de Agile. C’est la plus agressive des méthodes agiles, et c’est pourquoi elle est la plus populaire parmi les gestionnaires.

Toutes les méthodes agiles consistent à produire du code de travail sans merde. Lisez cela à nouveau. Et encore.

Tout ce qui contrarie cet objectif, quelles que soient les "règles agiles", est mauvais. Si les règles vous gênent, changez les règles f * * ! C'est la manière agile, c'est ce qui le rend pertinent et efficace.

Alistair Cockburn (l’un des auteurs du manifeste agile) en donne le meilleur exemple :

«Mettez 4 à 6 personnes dans une pièce avec des postes de travail et des tableaux blancs et donnez accès aux utilisateurs. Demandez-leur de fournir aux utilisateurs un logiciel en cours d'exécution et testé tous les mois ou tous les deux mois, sinon laissez-les tranquilles. "

Si cela fonctionne pour la qualité des gars que vous avez, c'est tout ce dont vous avez besoin. Vous n'avez pas besoin d'un scrum master ou d'une méthodologie "agile". Si vous êtes assis dans un point de presse quotidien fonctionne pour vous, alors f * * * le faire. Ce qui vous oblige à vous lever, ce n’est que l’abrogation pathétique de votre capacité de penser par vous-mêmes.

Il y a une réponse à votre agilité. C'est ça. Imprimez-le et épinglez-le quelque part lorsque personne n'est là et laissez-le découvrir par lui-même.

gbjbaanb
la source
Demandez-leur de fournir aux utilisateurs un logiciel en cours d’exécution, testé, tous les 2/3 semaines, vous voulez dire?
user272671
2
@ user272671 NO. Demandez-leur de fournir régulièrement des logiciels en cours d'utilisation et testés à l'utilisateur. Pas sur un calendrier bêtement arbitraire comme 2 ou 3 semaines. Si la complexité du logiciel ou des utilisateurs est telle qu’un cycle de travail de 6 semaines fonctionne, effectuez 6 semaines. Si cela peut être fait sur "une fois terminé", faites-le. Ne vous bloquez pas avec des contraintes artificielles. Ce n'est pas agile.
gbjbaanb
11

L’actuel Scrum Master était un manager qui a suivi une formation agile payée par la direction pendant quelques jours et dirige maintenant cette équipe agile.

C'est ton problème. Les directions veulent de l’agile, elles ne savent pas vraiment ce que c’est et elles l’imposent aux équipes. C’est à peu près ce que vous devez faire lorsque vous souhaitez réduire considérablement la productivité de vos développeurs;)

La nouvelle proposition de processus devrait venir des développeurs. Ou au moins être examiné et approuvé par eux si c'est une idée de la direction.

En tout cas, si les développeurs le refusent, ne l'implémentez pas ! Ou ce sera le désastre que vous décrivez.

utilisateur2567
la source
9

"Agile" et toutes les autres "méthodes de gestion" sont fréquemment utilisées pour forcer la microgestion sur des personnes. OTOH est aussi parfois maltraité pour défendre un travail médiocre.

"Nous sommes agiles" est l'excuse la plus fréquente que j'entends pour manque de planification, manque de réflexion sur la conception, les fonctionnalités, la qualité, les cycles de publication. Cela provient généralement des développeurs et des cadres inférieurs. C'est aussi l'excuse la plus fréquemment utilisée par les cadres moyens, les architectes, les vendeurs, etc. pour une microgestion, des délais en constante évolution et des listes de fonctionnalités, l'obligeant à faire des heures supplémentaires massives (bien sûr, les délais en constante évolution et les listes de fonctionnalités, etc.), etc. .

Les deux bien sûr sont souvent en contradiction directe et peuvent se produire sur le même projet.

jwenting
la source
D'après mon expérience, je n'ai jamais entendu parler que de l'agilité (toujours de la mêlée) pour expliquer la microgestion. Je ne nierai pas, c'est un style de microgestion différent et unique. Je n'ai jamais entendu un développeur dire qu'il est agile et expliquer une courte venue. Quel genre de gestion avez-vous expérimenté?
JM Becker
1
chaque fois que j'ai rencontré scrum, il était introduit parce qu'un responsable (généralement supérieur à un responsable de projet) en avait entendu parler comme étant "la chose".
Jwenting
7

Pour répondre à votre question initiale, Agile est-elle la nouvelle micro-gestion, je dirais non.

Commencez par lire ceci (manifeste Agile) et vous remarquerez que ne pas parler à vos co-développeurs ne figure pas dans la liste.

En fait, "individus et interactions" est exactement le contraire de ne pas parler à vos co-développeurs.

Ian
la source
"Individus et interactions" sont ce qu’ils font en ce moment au sein de leur équipe. Comment cela se passe-t-il contre le manifeste agile, si vous regardez du point de vue de Scrum Master? Le problème à l'heure actuelle, c'est qu'ils ne doivent pas interagir avec d'autres équipes afin de maintenir leur productivité, ce qui est la cause des plaintes du groupe agile.
Smith James
Ils n'interagissent pas. C'est le problème. Bien sûr, un développeur peut abuser de privilèges et parler de choses sans signification pendant des heures. Cependant, la plupart des bons développeurs veulent livrer un projet de qualité. C'est une question de fierté. Tout ce que le scrum master fait sape cela et en fait plutôt une question de répression. Ce n'est pas ce qu'est l'agile. Un scrum master doit permettre à l’équipe d’être productive, non de craquer, mais de lui dire d’être productive. Ils veulent déjà être productifs.
Berin Loritsch
2

Agile devrait être la nouvelle autogestion. Si la mise en pratique agile est correcte, de nombreuses décisions sont prises par un client et un développeur qui travaillent sur une histoire utilisateur relativement étendue qui est ajoutée à l'arriéré à mesure que les tâches sont identifiées.

Le point de presse quotidien concerne la communication, pas la gestion. Il y aura des discussions sur la priorité et l'équilibrage de la charge, mais la personne gérée à la mêlée est, espérons-le, le maître de mêlée. En tant que développeur, j'assiste, dit ce que j'ai fait, ce que je vais faire et l'aide dont j'ai besoin. Ensuite, le scrum master devrait passer à l’action pour éliminer les obstacles à mes progrès.

Les équipes agiles ne doivent pas avoir l’impression que le travail quotidien est géré de manière hiérarchique. Si les décisions sont prises à distance par une personne au sommet d'une organisation hiérarchique, l'heure est à la décentralisation de la prise de décision! Pour certaines personnes et certaines organisations, cela peut être un pont trop loin. Si ce qui suit n'est pas vrai pour votre organisation:

Vivez le Manifeste Agile

"Nous découvrons de meilleurs moyens de développer des logiciels en le faisant et en aidant les autres à le faire."

Évitez "Rencontrez le nouveau patron, Identique à l'ancien patron." Origine Agile autant que possible au sein de l'équipe. Parfois, cela se produit en choisissant une coalition de personnes désireuses de participer à un projet pilote utilisant Agile. Si vous pouvez former votre équipe Agile à partir de bénévoles ou de membres invités qui ont fait leurs preuves en matière de travail d'équipe, ils peuvent le résoudre. Faites appel à une petite équipe pour un projet de courte durée, par exemple pour un client interne ou hautement accessible.

Embrasser le changement. Vous pouvez peut-être suivre une formation, mais peut-être que votre budget est serré et que l'argent n'y est tout simplement pas. D'autres opportunités peuvent également apporter des améliorations. Faites des lectures, demandez aux membres de l'équipe d'apprendre tout ce qu'ils peuvent sur Agile et enseignez-vous les uns aux autres. Vous pourrez peut-être trouver du personnel nouveau ou existant qualifié pour modéliser et diriger l'adoption agile.

DeveloperDon
la source
1

Les équipes agiles sont comme des équipes de football travaillant vers un objectif commun. Je fais partie d’équipes agiles depuis quelques années et la clé est une communication efficace entre toutes les parties prenantes. Les gestionnaires / maîtres Scrum ne sont que des facilitateurs de l'équipe et la gestion traditionnelle / micro-gestion tue l'esprit de l'équipe.

Dans les équipes où j'ai travaillé, nous sommes encouragés à jouer à des jeux d'équipe après les heures de travail pour améliorer la camaraderie parmi les membres. J'ai rassemblé ces pensées ici .

Vinod R
la source
1
Développer des relations de travail après le travail, nous devrions développer nos relations souvent négligées entre amis et notre famille après le travail. Considérant que les collègues de travail sont rarement des amis et saisissent la plupart des occasions pour s'aider eux-mêmes aux dépens des autres. La société oui-hommes, copains et outils ne le réalisent tout simplement pas, car les opportunités sont rares. XP pourrait avoir une certaine valeur, je n'ai aucune expérience pour dire le contraire. Scrum est devenu une version différente de la microgestion, du moins chez les trois sociétés environ que je connais. .... Vous savez quoi, je déteste trop les entreprises américaines pour être un peu objectives.
JM Becker
0

Pour répondre à votre question: non. L'agilité n'est pas une forme de microgestion. Mais comme tout outil, les gens peuvent l’utiliser incorrectement. Agile est merveilleux lorsqu'il est correctement mis en œuvre et que les gens le respectent.

Mes pensées sur le sujet "Les développeurs ne parlent à personne, mais au Scrum Master":

J'ai travaillé dans un endroit où c'était une règle auparavant. CEPENDANT, la règle concernait davantage le fait de demander aux personnes d’achever leurs tâches. Par exemple, je ne peux pas aléatoirement faire appel à un testeur de développement et leur demander de faire des tests pour moi dans les prochaines heures. Je dois parler au chef de mêlée afin qu’ils puissent discuter avec leur membre de l’équipe de la façon dont ce travail s’intégrera dans le sprint en cas d’urgence (ou s’il doit être reporté à l’arriéré pour un prochain sprint).

Dans ce cas, j’ai compris le concept "les développeurs ne se parlent pas" parce que cela se traduisait vraiment par le fait de canaliser les tâches par un point de contrôle afin que les développeurs ne soient pas surchargés ou soient si occupés par des tâches urgentes qu’ils ne puissent pas obtenir leur planification. travail effectué.

Sinon, les développeurs DEVRAIENT être en train de se parler. Toujours. Il vous aide à résoudre les problèmes plus rapidement, à vous rapprocher en équipe et à livrer plus rapidement.

Juste pour offrir un autre point de vue: j'ai également été dans un environnement où les gens pensaient que les développeurs "parlaient trop". Après une séance, nous avons découvert qu’en réalité, "les développeurs ne sont pas assez indépendants pour faire leur propre travail. Comme tout est fragmenté, les développeurs doivent aller voir trois autres personnes pour s’acquitter de petites tâches".

Ainsi, lorsque les responsables ont décidé de passer à l'agile, ils espéraient que cela contribuerait à amener les informations aux bons endroits et à mettre un terme à la fragmentation au sein de l'organisation. Certaines personnes ont été un peu déçues qu'après la mise en œuvre d'Agile, les développeurs fussent toujours en train de se faire la navette. Mais, ce qu’ils ne réalisaient pas, c’était de moins en moins ce qui se passait. Cela a pris du temps cependant. Donc, peut-être que si c'est ce qui se passe dans votre organisation, il se peut que les gens s'attendent à être agiles pour régler les problèmes du jour au lendemain. Ce n'est pas comme ça que ça marche.

JustBlossom
la source
-1

L'auteur original Smith Janes aurait pu donner de l'expérience. Mais ce sont les problèmes typiques que j'ai trouvés dans le projet Agile.

  1. La plupart des organisations, les développeurs sont supposés travailler dans plusieurs projets, en agile / scrum. Les sprints ne sont jamais pris en compte. votre Scrum Master suppose que vous devriez avoir fini vos histoires à la fin du sprint. Votre Scrum Master pourrait être dédié à un seul projet, mais pas aux développeurs. CECI EST LA DISTRACTION - il ne suffit pas de prendre un appel téléphonique ou permettant un appel téléphonique.
  2. J'ai vu des projets Agile où Sprint est planifié, des histoires incluses dans Sprint, sans être blotties..à mi-chemin ou au milieu des sprints .. les développeurs trouvant des dépendances non résolues, des exigences ou une histoire non complétées est l'un des abus dans la plupart des projets agiles.
  3. Testing: TTD .. oui, c'est très bien .. mais j'ai vu la plupart des projets Agile s'appuyant totalement sur TTD ... aucune portée ou temps imparti pour les tests fonctionnels ou humains .. Un autre abus ... Beaucoup de Scrum Masters également ne sais pas ou ne comprend pas l'importance des tests fonctionnels. Votre code pourrait fonctionner parfaitement, s'il ne répond pas aux besoins de l'entreprise. Il ne sert à rien. Cela se produit lorsque les entreprises ne participent pas suffisamment à l'avance ... ou la participation est là ... mais ne reflète pas la prise de décision. .. À la fin, les développeurs sont blâmés, vous n’avez pas fourni la fonctionnalité..ou cela se terminera par un changement de dernière minute ... de très longues heures parce que votre maître Scrum ne veut pas s’en prendre à une histoire non terminée.

Abuser ici ... soit une faible participation des entreprises, soit un participant qui n'est pas parfaitement informé, ou un homme d’affaires qui abandonne au milieu du sprint.

  1. Tous les projets ne conviennent pas à Agile ... La plupart des gestionnaires ou des maîtres de scrum ne le savent pas. Projets de maintenance .. Un défaut peut être supposé au départ, mais peut être effectué en 8 heures, et accepté dans le sprint. Après avoir passé 4 heures, il s’est avéré qu’il s’agissait d’un autre produit Java / ... le financement, la nouvelle version ou la mise à niveau doivent être approuvés par le service d'ingénierie interne, etc. 5. Rétrospection: seule une poignée de projets Agiles réalise cette étape. Si jamais terminée..Gestion, Scrum Master n'a jamais pris aucune responsabilité pour les histoires ratées.
  2. Jumelage .. Beaucoup de développeurs considèrent le jumelage comme un lieu d'abus pour les collègues de travail. Critiquent d'autres conceptions, pratiques de codage.

Agile est définitivement une bonne méthodologie. À moins que votre organisation ne suive pas complètement ou n’ait pas été formée…. Elle est malmenée…. Effets secondaires… plus de 60 heures de travail / semaine, jeu de blâme, moral bas.

Mukunda
la source
voir ce lien .. pourquoi les projets Agile échouent .. brighthubpm.com/agile/55778-why-do-agile-projects-fail
mukunda
Je suis également d’accord avec les informations présentées dans cet article. Je comprends que certains pensent qu'Agile est infaillible, mais la réalité est que Agile laisse peu ou pas de place à l'introduction d'idées nouvelles et plus efficaces. is..brighthubpm.com / agile / 55778-pourquoi-faire-agile-projets-échec
utilisateur272671
-3

Agile est une microgestion déguisée. Il n'y a pas de place pour l'initiative ou la créativité dans Agile, cela a permis de supprimer le plaisir de la programmation pour permettre aux gestionnaires incompétents de garder le contrôle, même sans avoir la moindre idée du point de vue technique.

géo
la source
2
Vous ne pouvez pas avoir plus tort. En mode agile, les équipes doivent avoir un très grand contrôle créatif. Agile nécessite beaucoup d'initiatives, car c'est l'équipe qui décide comment mettre en œuvre chaque histoire. La direction a en fait très peu de contrôle sur le processus agile. Personnellement, les trois différentes équipes agiles auxquelles j'ai participé sont extrêmement amusantes. On dirait que vous avez vécu une grave incompétence qui s’est identifiée comme agile sans être proche de l’agile.
Bryan Oakley
ajoutez un raisonnement à l'appui de votre affirmation (ce qui a un sens pour moi, mais cela n'a pas d'importance), et je retirerai le vote négatif
gnat
1
Je suis d'accord avec @Geo. Jusqu'à présent, c'est l'impression que j'ai de ce qu'est "Agile" dans le monde réel. Lorsque vous avez un tel paramètre dans l’usine, c’est simplement une forme de microgestion. Maintenant, le Manifeste tente de nous dire que ce n’est pas le cas. Mais projet après projet, je suis amené à croire encore plus qu’il s’agit simplement d’un autre nom pour "Micromanagement". Et cela tue la créativité.
user272671