Scrum transforme-t-il les développeurs actifs en développeurs passifs?


103

Je suis un développeur Web travaillant dans une équipe de trois développeurs et un concepteur. Cela fait maintenant environ cinq mois que nous avons implémenté la méthodologie de développement logiciel agile Scrum. Mais j'ai un sentiment étrange que je voulais juste partager sur ce site.

Le processus de prise de décision est un facteur important dans la vie humaine. Cependant, il y a une grande différence dans les décisions que vous prenez. Certaines décisions ne sont que le résultat d'une force interne ou externe, tandis que d'autres sont entièrement basées sur votre libre arbitre, et certaines décisions sont simplement quelque chose entre les deux. Plus vous êtes libre de prendre des décisions, plus votre travail sera autonome. Cela semble être une règle. Parce que nous avons tendance à façonner nous-mêmes nos vies.

Il y a une grande différence entre décider quoi faire ou se faire dire quoi faire .

Avant Scrum, j'avais plus de liberté pour prendre des décisions liées au développement, à l'analyse, à la hiérarchisation des priorités de mise en œuvre, etc. J'avais plus l'impression de décider de ce que je fais .

Cependant, en raison de la méthodologie Scrum, de nombreuses décisions sont maintenant prises par le propriétaire du produit. Il priorise les PBI , il analyse comment le logiciel devrait fonctionner, même parfois comment implémenter l'interface utilisateur et les fonctionnalités. Je sais que cela fait partie de la méthodologie Scrum et je sais aussi que cela pourrait entraîner de meilleures ventes de produits à l'avenir. Cependant, j'ai maintenant l'impression qu'on me dit toujours de faire quelque chose, au lieu de décider de faire quelque chose . Ce syndrome m'a maintenant rendu plus passif envers le travail.

  1. J'ai tendance à chercher moins pour trouver une meilleure solution, approche ou technique
  2. Je ne me lève pas le matin en espérant avoir un travail agréable. Au contraire, je me sens comme obligé de travailler pour vivre
  3. J'ai plus faim de travailler sur mes projets de passe-temps après le travail
  4. Je ne pousserai plus l'équipe à atteindre les plus hauts niveaux technologiques
  5. Je passe plus de temps maintenant à dîner ou à prendre le thé et j'ai moins d'enthousiasme pour retourner au travail
  6. Je suis maintenant prêt à ce que le travail se termine plus tôt pour pouvoir rentrer chez moi

Le gros problème est que je vois et diagnostique ce comportement chez mes collègues aussi. Est-ce le résultat de la mêlée? Scrum donne-t-il vraiment à l'équipe de développement le sentiment de ne pas participer à la formation du logiciel dans son ensemble, rendant ainsi le projet passif? Comment puis-je surmonter ce sentiment?


4
Êtes-vous sûr de ne pas vous engager beaucoup de manière dysfonctionnelle auparavant?
Donal Fellows

27
Beau post de blog.
Robert S.

20
ce que vous décrivez n'est pas SCRUM

4
@Chad. Ce que j'ai discuté ici n'est pas une plainte de ma situation de travail. Je me demande juste si cette humeur est le résultat de la mêlée? Et si d'autres développeurs connaissent également la même chose ou non?
Saeed Neamati

5
@Saeed - Désolé d'être franc, mais votre humeur est le résultat de votre décision de gérer votre environnement de travail. Cela peut également être affecté par les opinions et les attitudes des autres, mais vous pouvez également choisir d’adhérer à cette méthode. Cela vous dispense de la nécessité d'être responsable des décisions de conception et vous permet simplement de résoudre des problèmes spécifiques. Il ne sape pas toute votre énergie et vous permet de travailler sur plusieurs de vos projets domestiques. Vous avez plus de temps pour vous développer. Ce ne sont pas de mauvaises choses. Ce n'est pas votre travail d'employeur de vous rendre heureux. Vous pouvez trouver un autre emploi ou l'accepter.
SoylentGray

Réponses:


51

Cependant, j'ai maintenant l'impression qu'on me dit toujours de faire quelque chose, au lieu de décider de faire quelque chose.

Ceci est un indicateur sérieux que quelque chose a dérapé. Un projet agile ne devrait pas se sentir comme ça. La rhétorique "sur le processus des personnes" devrait inclure "nous ne forçons pas notre peuple à faire des choses qui sont nulles". Voici quelques idées:

Est-ce que tu fais "scrum but"? C’est-à-dire, partie scrum, partie autre chose. (C'est-à-dire: "Nous faisons de la mêlée, mais toutes nos histoires doivent provenir de notre bureau du premier ministre, et non d'un propriétaire de produit.") Beaucoup de merde folle s'appelle Scrum ces jours-ci.

Êtes-vous personnellement impliqué dans le processus où vous devriez être? J'ai connu un certain nombre de personnes contrariées par le contenu des articles, et il s'avère qu'elles ne sont impliquées que lorsque l'histoire est dans l'arriéré des sprints. Parlez au propriétaire du produit dès le début de l’élaboration de l’histoire et obtenez-lui vos commentaires.

Dans Scrum, l'équipe est censée être propriétaire du processus et il est prévu que le processus change avec le temps pour répondre aux besoins de l'équipe. Présentez vos préoccupations lors de la rétrospective. Si vous pouvez suggérer un ajustement du processus, cela facilitera la vente de certaines équipes.


10
+1 Scrum (comme toutes les méthodologies Agiles) donne plus d'importance à la conversation qu'à la direction. Le bon de commande doit décrire ce que le résultat final doit pouvoir accomplir, puis engager les concepteurs et les développeurs sur les moyens d’y parvenir.
StevenV

5
"personnes sur processus": drôle, alors pourquoi imposer le processus SCRUM au lieu de laisser les gens utiliser le leur? Et pourquoi toutes ces mesures (programmation en binôme, bilans de progrès fréquents) qui, au nom de la transparence, permettent de suivre de plus près le travail des développeurs?
Giorgio

3
@Giorgio: Parce que le développement structuré permet aux équipes de travailler ensemble sans se marcher sur les pieds les unes des autres. Nous n'avons tout simplement pas encore trouvé comment le faire parfaitement.
Phoshi

2
@Giogio, c'est un problème avec l'agile en général. Bien que l'objectif soit de faire en sorte que les gens passent outre au processus, Agile devient en réalité une religion respectée, ce qui confère encore une fois le processus à l'homme. Personnellement, j'estime que lean fait mieux que l'agile, bien qu'il ne tente pas de mettre en place une structure strictement horizontale de l'équipe - cela permet aux développeurs de mieux choisir leurs tâches. En supposant que votre équipe ne change pas, un conseil d'administration kanban, en plus de ce que vous faites maintenant, pourrait rendre la direction heureuse, et vous aussi, en vous laissant la liberté de choisir vos histoires / tâches.
jQwierdy

62

Votre problème n’est pas Scrum (et comme Jarrod Roberson l’a mentionné dans des commentaires, ce n’est pas ce que vous décrivez): c’est la microgestion du Product Owner et votre manque d’assurance (et de votre équipe) .

"Cependant, en raison de la méthodologie Scrum, de nombreuses décisions sont maintenant prises par le propriétaire du produit. Il priorise les PBI, il analyse le fonctionnement des logiciels, voire parfois la mise en œuvre de l'interface utilisateur et des fonctionnalités. Je sais que cela fait partie de la méthodologie Scrum."

Vous vous trompez. Il suffit de regarder brièvement la page wikipedia pour Scrum : "l’Équipe, un groupe interfonctionnel qui effectue l’analyse, la conception, la mise en oeuvre, les tests, etc." Voir? Product Owner vous dit quoi faire, mais c'est à l'équipe de décider comment faire.

Vous êtes la personne responsable de la mise en œuvre. Vous devez donc décider du mode de mise en œuvre de l'application. Écoutez l'opinion du responsable du produit, mais la décision finale appartient à vous (ou à l'équipe).

BTW microgestion ne tourne développeurs actifs dans les développeurs passifs.


38
Amen à cette dernière ligne
Wivani

6
"Product Owner vous dit quoi faire, mais c'est à l'équipe de décider comment faire." C’est exactement ce qui peut poser problème à la motivation des développeurs: le manque d’innovation. La plupart du temps, le client voudra des chevaux plus rapides, pas des voitures. Mais je suis tout à fait d’accord avec la microgestion.
MaR

1
+1 @Lukas, à cause de la différenciation entre quoi et comment . Merci mon pote.
Saeed Neamati

5
"Le responsable du produit vous dit quoi faire" - je ne suis pas tout à fait d'accord avec cela. Ils devraient vous dire ce dont ils ont besoin . Une différence légère mais importante. En d'autres termes: ils décrivent le problème / problème, vous apportez la solution.
DanMan

2
@MaR C'est pourquoi les développeurs ne parlent pas aux clients. Les clients parlent au responsable de produit et demandent des chevaux plus rapides, le bon de commande est celui qui voit tous les problèmes des clients, les combine et les hiérarchise, et dans le processus détermine que les voitures sont meilleures que les chevaux plus rapides
Izkata

29

Ce que vous décrivez n'est PAS SCRUM

Votre propriétaire de produit dépasse ses limites s’il vous dit comment faire votre travail techniquement, ce n’est pas du tout ce dont SCRUM est capable.

SCRUM vise à permettre aux développeurs de se concentrer sur les problèmes de développement et de les responsabiliser, ce qui leur permet de déterminer la durée et la manière de procéder.

SCRUM, c’est la collaboration, c’est le but des réunions de planification de Sprint, de promouvoir la collaboration entre toutes les parties prenantes; propriétaire du produit, les développeurs et les tests.

Oui, le propriétaire du produit doit hiérarchiser les fonctionnalités, ce qui doit être livré en premier en fonction des besoins du client, mais les développeurs doivent effectuer l'ingénierie et la conception, et non le propriétaire du produit.

Je ne suis pas d'accord pour dire que les développeurs devraient concevoir des interfaces utilisateur graphiques et des flux de travail, à moins qu'ils ne soient spécialement chargés de la tâche et formés à travailler avec les clients et à en traiter directement les fonctionnalités. Programmeur construit des interfaces graphiques réalisées en vase clos rarement répondre aux besoins des clients.

SCRUM consiste à mettre en place un processus léger, prévisible et reproductible sur le manifeste agile.

Cela me rend triste d'entendre des histoires selon lesquelles de très bonnes choses sont perverties de la sorte.


3
La nature humaine trouvera toujours un moyen d’arracher la défaite aux griffes de la victoire.
Warren P

2
Il y a ce que SCRUM est censé être, et ce qu'il finit par être , du moins dans la plupart des entreprises. SCRUM n’est pas un mal en soi, mais c’est un outil très facilement utilisable par le management.
AresAvatar

11

J'imagine qu'avant Scrum, tout le monde faisait ce qu'il voulait: yippee ki-yay mf'er . Vos utilisateurs sont vos bienfaiteurs et ils dirigent l’histoire et paient les factures. Le responsable du produit s'assure que l'histoire se termine. Certains comment, votre groupe est arrivé à la conclusion que le Product Owner devrait vous dire comment programmer.

Vous voulez écrire du code ou créer de petites applications ordonnées que vous jugez cool? "Je veux faire les fonctionnalités A d'abord et non B, afin de pouvoir conserver ma liberté de choix." Trouvez un bienfaiteur différent et non une nouvelle méthodologie de développement.

Vous êtes pris dans le titre du propriétaire du projet ou quelque chose. Si vous avez une raison valable de ne pas être d'accord avec l'histoire, dites quelque chose, argumentez. Vous ne pouvez pas toujours gagner. C'est leur travail de retourner aux utilisateurs et de leur faire savoir que leur demande pose problème. Regardons les choses en face, si l’histoire vous demande d’abandonner une base de données de manière aléatoire tout au long de la journée, sans sauvegarde, sans perte de données ni temps d’immobilisation, vous avez un problème et vous devez le mettre au clair.


10

On dirait que vos aventures dans Agile ont été corrompues par Scrum. Je trouve que parmi toutes les méthodologies agiles, Scrum est la moins agile. Cela ressemble plus à des cascades miniatures et à une gestion de projet supplémentaire. Bien sûr, cela en fait le plus apprécié par la direction qui a le sentiment de reprendre le contrôle de ces développeurs ennuyeux, mais vous voyez bien sûr la réalité de la situation.

Agile ne consiste pas à suivre un chemin prescrit, il est conçu pour vous rendre plus productif et motivé. Les gens ne traitent pas, dit le manifeste (paraphrasé), et c'est perdu dans le système que vous utilisez.

Alors change-le. Parlez-en à la direction et dites que c'est une étape rétrograde, que votre productivité est inférieure à ce qu'elle était auparavant et que vous êtes tous mécontents de la façon dont cela fonctionne. Montrez le Manifeste Agile (et son jumeau diabolique ) et montrez que vous avez non seulement tiré les leçons de cette expérience, mais que vous souhaitez en transformer les avantages en un système plus performant (un système semblable à celui que vous utilisiez auparavant, qui semble bien fonctionner). pour vous).


6
moi? oui - nous travaillions bien avant, puis la direction a décidé qu'Agile était l'avenir et a imposé Scrum, ce qui nous a énormément restreints. Ce que nous faisions auparavant s'est enlisé dans le processus et la bureaucratie. Une fois, j'ai pris 3 cartes du tableau de mêlée !! Les lumières ont clignoté et les sirènes ont gémi pour cette brèche de 'la voie de la mêlée', et une fois, j'ai ramené la carte à mon bureau . Les flics de gestion de projet sont venus pour moi. Et je l' habitude de s'asseoir dans les points de presse quotidiens, qui ne m'a pas du bien non plus . Toutes les banalités IMHO, mais ont été faites en montagnes.
gbjbaanb

2
Ne pensez-vous pas que, dans votre cas, c'est une mauvaise implémentation de Scrum qui a entraîné une perte de productivité? Vous dites que vous vous êtes "enlisé dans le processus et la bureaucratie", ce qui est étrange parce que Scrum est la méthodologie la moins simple et la moins bureaucratique au monde ... En fait, tout le cadre de Scrum tient dans une feuille ou deux. ne fait pas partie du cadre. Dans le cas de Saeed, je pense cependant que le problème réside dans le décalage entre le type d’organisation dans laquelle il a travaillé (avec une grande liberté et le pouvoir de décision des développeurs) et le type d’organisation auquel Scrum s’applique.
guillaume31

3
@ ian31: oui, ce projet était particulièrement mauvais, mais Scrum s'adresse à ce type de gestionnaires. On ne les voit jamais choisir Kanban ou Crystal après tout. Scrum se transforme trop facilement en "scrum mais" lorsque ces gars-là s'en emparent. pitié.
gbjbaanb

1
Je pense qu’il est hilarant que toute entreprise transforme Scrum en une cérémonie religieuse. Hey! Tenez-vous pendant cette cérémonie où nous prétendons être agiles! Hey! Souriez en faisant semblant de vous écouter, puis continuez joyeusement à faire ce que nous voulions faire quand même!
Warren P

2
Je suis totalement en désaccord avec le sens de cette réponse. Je pense qu'une sorte de "mini-cascade" peut être très bénéfique, en particulier pour les développeurs inexpérimentés mais intelligents, qui sont susceptibles de faire 5 choses différentes à la fois et de ne pas en finir. En fait, la personne qui m'a formé à Scrum a déclaré que vous pouvez toujours faire des "mini-cascades" dans Scrum si vous le souhaitez, mais que, dans l'idéal, elles devraient durer plusieurs jours voire plusieurs heures . Je pensais que les heures étaient trop courtes. Vous ne pouvez pas toujours concevoir-> mettre en œuvre-> tester une histoire en quelques heures. Et partager des histoires de manière à ce que vous puissiez ne soit pas toujours optimal non plus.
Robin Green

8

Je pense que vous êtes simplement habitués à avoir plus de propriétaires - et tout le monde, je pense, préfère cela, sa nature humaine.

Malheureusement, je pense qu'un grand nombre de logiciels est inférieur à ce qu'il pourrait être, car souvent des parties sont écrites pour le dev et non pour le client. Votre nouvelle approche devrait réduire cela, mais au détriment de votre sentiment de propriété.

Je ne sais pas comment vous suggérer de rendre les choses meilleures ou plus amusantes, mais c'est une excellente question et un très bon aperçu.


100% d'accord. Vous êtes maintenant plus en phase avec le propriétaire du produit, mais cela signifie que vous avez moins de liberté pour faire ce que vous pensez être juste. J'en ai fait l'expérience aussi et ça m'a fait chier et rendu mon travail beaucoup moins agréable. Mais cela signifiait que j'étais beaucoup mieux aligné sur les objectifs de l'entreprise et du chef de produit. Les entreprises paient les factures - y compris mon salaire - alors oui, elles ont la possibilité de dire ce qu'elles veulent au niveau des détails. Je ne pense pas qu'ils vous disent réellement comment coder. S'ils savaient comment ils pourraient le faire eux-mêmes.
Michael Durrant

L'entreprise ne paie pas les développeurs pour faire ce qu'ils veulent. Ils paient les développeurs pour la productivité que leur procure un bon environnement logiciel. Si vous laissez l’entreprise vous dire quoi faire «au niveau des détails», pensez-vous vraiment qu’elle obtiendra le bon environnement logiciel qu’elle recherche?
Andomar

@Andomar - C'est un équilibre. Chaque camp a ses idéaux, ses hypothèses et ses défauts. Ignorer l'un de ces risques est dangereux.
Jonno

5

Recevez-vous des récits d'utilisateurs sous la forme "En tant que - rôle -, je veux - objectif / désir - pour que - avantage -"? Il semble que votre responsable de produit souhaite effectuer le travail de conception, et il / elle peut ne pas être la meilleure personne pour le faire. L'utilisation du modèle de scénario utilisateur peut aider à garantir que le responsable du produit respecte les intérêts de l'entreprise et que les développeurs du logiciel sont en train de développer les logiciels.


4
En tant que développeur, je ne veux plus jamais revoir ce type de scénario utilisateur, afin de ne jamais avoir à gémir intérieurement à cause de son inanité.
Warren P

@WarrenP Oui, le passe-partout peut être pénible, que ce soit sous forme de code ou d'exigences. Je pense que l’essentiel est que chacun de ces 3 éléments soit énoncé ou compris, mais plus important encore, il doit être clair pour tout le monde ce qui est vraiment souhaité, et les exigences optimisées peuvent en fait gêner. Surtout si les développeurs commencent à penser que l'insertion de quelques mots courts dans ce modèle est toujours suffisante.
Robin Green

4

Dans Scrum, les développeurs ont amplement la possibilité de contribuer et de donner leurs conseils sur les nouvelles fonctionnalités, l'interface utilisateur, la convivialité ... La collaboration et la conversation entre les professionnels et les développeurs sont nécessaires dans Scrum et cela le permet. Cependant, au bout du compte, le propriétaire du produit aura toujours le dernier mot, car il est responsable de la maximisation de la valeur commerciale des incréments logiciels générés sprint après sprint (en d’autres termes, le retour sur investissement).

Du Manifeste Agile:

Notre priorité absolue est de satisfaire le client par la livraison rapide et continue de logiciels de valeur.

Le propriétaire du produit qui vous explique comment l'interface utilisateur et les fonctionnalités doivent être implémentées n'est pas acceptable. Dans ce cas, vous devriez avoir le dernier mot, puisque vous êtes responsable de la qualité interne du logiciel que vous produisez.

Vous travaillez peut-être dans une entreprise créée par des développeurs où les programmeurs étaient libres d’implémenter les fonctionnalités qu’ils souhaitaient. Cependant, la plupart des méthodologies Agiles établissent une séparation claire entre les personnes du domaine métier et l'équipe chargée de la production des logiciels (développeurs, testeurs, etc.), qui est la division de travail la plus courante dans la plupart des endroits. Si mes hypothèses sont correctes, je peux comprendre le sentiment que vous avez que vous n'êtes plus en mesure "d'influencer la situation dans son ensemble" mais avec la croissance de l'entreprise, je suppose que cela aurait été le cas de toute façon, Scrum ou pas.

En ce qui concerne l’analyse, la conception et les autres activités de méta-développement que vous avez mentionnées (qui ne sont pas supposées être réalisées par le Product Owner), les équipes Agiles sont censées être interfonctionnelles et ne comporter aucun silo. Personne n’est censé posséder toutes les connaissances relatives à une activité de développement spécifique. Vous avez donc peut-être l’occasion de vous diversifier par rapport à un simple "code monkey".


3

Au contraire, j'ai constaté que le fait qu'un propriétaire de produit prenne des décisions concernant les fonctionnalités me permet de consacrer plus de temps à la production de code de qualité. De plus, s'il y a des préoccupations valides, je peux toujours remettre en question les décisions des propriétaires de produits, ce qui donne généralement lieu à des discussions fructueuses.


3

Nous pratiquons Scrum ici. Nous avons une réunion de planification bimensuelle où nous prenons en compte les priorités commerciales actuelles, les succès et les échecs du sprint précédent, et nous décidons, en équipe , de ce que nous voulons aborder pour le prochain sprint.

Pour ce faire, l’un des moyens consiste à classer l’arriéré sur un tableau par complexité verticale et priorité commerciale horizontalement. Après cela, le responsable produit a eu son mot à dire, il appartient donc à l’équipe de choisir ce que nous voulons faire. Évidemment, choisir une tâche hautement complexe et peu prioritaire est mal vu, mais nous décidons de le faire en équipe. Cela allonge la durée des sessions de planification, mais cela en vaut la peine et constitue une partie essentielle du processus Agile.

Et nous avons parfois de la micro-gestion, mais le problème est différent.


3

Le vrai problème que vous décrivez est une pathologie courante lorsque les équipes adoptent une méthodologie: elles désactivent leur cerveau. Ceci est aussi vrai avec un système agile de nouvelle école qu’il l’était avec des systèmes lourds d’ancienne école.

Q: La méthodologie prescrit x, mais x ne fonctionne pas bien. Que devrions nous faire?

A: Affinez votre implémentation de x. Peut-être arrêter de le faire tout à fait. La Méthodologie n'est pas votre patron!

Dans ce cas précis, il semble que le responsable du produit en fasse trop. Êtes-vous à l'aise de lui parler de ça? Seriez-vous à l'aise d'avoir cette conversation si vous n'étiez pas "faire de la mêlée?" Si le propriétaire du produit n'est pas sensible aux commentaires constructifs, il ne s'agit pas d'un problème de méthodologie, mais d'un problème avec le propriétaire du produit.


2

Je ne suis pas vraiment au courant de tout le problème de la mêlée, qui a été plus de cascade pendant un moment

Mais pour être honnête, cela ressemble plus à un problème de personnel de gestion qu’à un problème de technique de gestion de projet. Comme dans plus de personnes que de technique.


Non @temptar, notre relation est vraiment bonne. Aucune infraction, aucune haine, rien du tout. Tout va bien, tout sauf ce que nous ressentons pour le travail.
Saeed Neamati

2

Le rôle des leaders dans une équipe auto-organisée serait un article de blog sur quelque chose qui semble manquer à votre article. Où l'équipe décide-t-elle du travail à effectuer dans un sprint? Où l'équipe est-elle en possession du processus et du travail? Avez-vous quelqu'un qui connaît assez Scrum pour le faire et pas une version perverse de celui-ci?


2

J'ai eu la même expérience avec Scrum et j'aime l'appeler "la tyrannie de l'histoire".

D'après mon expérience, les développeurs, du côté des créateurs / concepteurs / frontaux, semblent en souffrir plus que les personnes impliquées dans le backend.

Jusqu'à présent, la seule solution que j'ai trouvée consistait à abandonner Scrum - ce qui est souvent impossible et / ou inapproprié, car après tout, il présente des avantages - ou à introduire quelque chose comme le temps de 20% de Google pour donner aux développeurs un débouché créatif en dehors du "vous". Vous êtes libre de choisir comment mettre en oeuvre la page de connexion ", car en réalité, votre code et votre architecture système ne vous contraignent pas à la mettre en oeuvre - c’est-à-dire, à moins que vous ne considériez la liberté de choisir entre" une boucle for et une boucle while "a liberté.


1

Il y a une grande différence entre décider quoi faire ou se faire dire quoi faire .

D'après mon expérience, il y a encore un long chemin à parcourir avant de savoir quoi faire pour décider quoi faire.

Au bout du compte, il s’avère généralement que nous avons été instruits non pas parce qu’ils aiment le pouvoir et non parce qu’ils n’ont rien de mieux à faire. Au contraire, au bout de ce chemin, quand ils ont suffisamment confiance en notre équipe, ils semblent être soulagés et nous transmettent volontiers le plus de contrôle possible (et si leur confiance est vraiment ferme, ils essaient même de passer plus que ça)

Oh, et selon mon expérience, cela n’a fondamentalement rien à voir avec Scrum / agile. Arrivé avec mêlée, itérative, cascade, peu importe. Il semble que la question de la confiance soit agnostique


1

Dans notre équipe, le propriétaire du produit nous dit quoi faire et nous décidons comment nous le faisons. Il est vraiment important d’avoir cette séparation sinon vous vous retrouverez dans la situation que vous avez décrite.


1

D'après mon expérience, Scrum doit vous regarder profondément ce que vous faites. Il suffit de s'asseoir sur votre épaule et de regarder ce que vous faites. Même si cela présente un avantage, je déteste la méthodologie Scrum. Il attend le compte, pas la qualité. La qualité est compromise avec la méthodologie Scrum.


"La qualité est en train d'être compromise avec la méthodologie Scrum.": Peut-être qu'il est un peu extrême de dire que la qualité est compromise, mais que, effectivement, la contrôlabilité du projet est prioritaire sur la qualité.
Giorgio

Incroyable que peu de gens connaissent Scrum ou Agile, et pourtant, ils affichent comme les autorités. On a l’impression qu’une personne a travaillé pendant quelques semaines sur un groupe dysfonctionnel où elle a dit qu’elle «faisait de la mêlée» et en a conclu que c’était ainsi que devrait être la mêlée. Dans ce cas, il s'agit d'un gars complètement anonyme avec un seul post ou un commentaire en 4 ans et aucune preuve d'expertise sur le sujet. C'est pourquoi nous ne pouvons pas prendre beaucoup de ces commentaires très au sérieux.
Curtis Reed
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.