L'idée principale du framework Scrum est d'organiser le processus de développement pour une exécution plus rapide du travail à différentes étapes du cycle de vie du projet. Mais cette approche pousse-t-elle toujours les développeurs vers les bons comportements? De nombreux utilisateurs qui ont rejoint la discussion sur la question ci-dessussur Stack Overflow, ont vécu des choses similaires lorsque les développeurs coupent les coins ronds, accordent trop d'importance aux scores élevés attribués à leurs tickets, ou même prétendent être des employés très performants devant les managers. Comment éviter ces dangers? La question en question est passée du lieu de travail.stackexchange.com à softwareengineering.stackexchange.com . Cela suggère que les programmeurs considèrent les considérations entourant Scrum et son efficacité comme quelque chose d'assez sérieux pour aller au-delà de la gestion du cycle de développement logiciel. Ils ressentent l'impact de cette méthode de gestion de projet sur l'environnement de travail global.
Scrum est-il la cause de mauvaises pratiques de développement ou est-ce juste une excuse pour ce problème?
De nombreuses controverses ont suscité des spéculations sur l'impact de Scrum sur les équipes et les développeurs individuels, et sur les limites que le framework impose à ceux qui l'utilisent. Alors que beaucoup blâment Scrum pour les échecs d'équipe, d'autres pensent qu'il s'agit d' une erreur d'attribution et que les racines des problèmes dans les équipes de développement vont beaucoup plus loin.
Les défenseurs de Scrum voient la mauvaise gestion comme la racine du problème. Voici ce que dit l'utilisateur Llewellyn, résumant: «La direction ignore essentiellement les développeurs. Il y a des délais fixes à respecter pour obtenir des résultats prédéterminés. Le travail n'est pas effectué par une équipe centrée sur la réalisation du même objectif, mais par un groupe de personnes dans lequel chacun ne se soucie que de lui-même. Il est déconseillé de planifier à l'avance et de sortir des sentiers battus. Dans de telles conditions, le programmeur, de ce fait, succombe aux circonstances et trouve le salut dans la simple exécution des tâches qui lui sont assignées. J'ai travaillé dans de telles conditions. Mais ne blâmez pas Scrum pour cela. "
L'utilisateur DJClayworth a exprimé le sentiment de nombreux commentaires, affirmant que les programmeurs qui pensent être sous pression fonctionneront mal avec toute méthodologie de gestion du développement.
L'opinion opposée sur cette question a été mieux exprimée par l'utilisateur Martin Maat , qui a attiré l'attention du public sur le fait que le fait même que tant de personnes ressentent le besoin de s'exprimer sur cette question témoigne de la frustration que Scrum leur cause.
Quels sont les problèmes courants liés à l'utilisation de Scrum?
Certains écueils courants de Scrum sont apparus dans les commentaires, qui apparaissent soit en raison d'une mauvaise utilisation du framework, soit parce qu'ils sont, en fait, des problèmes Scrum inhérents. Voici près d'une dizaine de problèmes de ce type qui ont retenu notre attention.
▍1. Les réunions quotidiennes sont réservées aux gestionnaires
La première critique de Scrum est liée au fait que lors des réunions quotidiennes (stand-ups) des tendances indésirables apparaissent. Un des arguments en faveur de cette idée est que les stand-ups peuvent se dégrader en état d'événements, dont les participants ne font que ce qu'ils disent de leur productivité. Surtout si les managers sont présents à de tels événements. Par conséquent, l'utilisateur Matthew Gaiser (il a déjà écrit pour nous, mais nous sommes tombés sur son commentaire) a appelé des événements stand-ups qui visent à informer les gestionnaires de la situation actuelle ( gestion des mises à jour). Il estime que les présentations des développeurs lors de tels événements n'encouragent que les managers à observer ce sur quoi ils travaillent, mais cela n'apporte aucun avantage. Cela est encore plus vrai pour les équipes distribuées, lorsque chacun des membres de l'équipe travaille dans son propre mode.
▍2. L'achèvement des tâches joue un rôle majeur
Une autre idée qui est ressortie des commentaires est que toute méthodologie de développement qui divise les grandes tâches en tâches plus petites et surveille l'avancement de ces tâches conduit, intentionnellement ou non, à de nouvelles approches pour évaluer le travail. Si vous commencez simplement à appliquer certaines mesures, cela affectera le comportement des personnes dont les performances sont évaluées conformément à ces mesures.
De nombreux commentateurs disent que cela signifie que les développeurs peuvent «couper les coins ronds» pour terminer ce qui devait être fait dans le sprint actuel. Le problème signalé par l'utilisateur Gaiseret d'autres utilisateurs, est qu'un ticket séparé sur lequel on travaille, et qui, lors du sprint, est transféré dans la catégorie «prêt», c'est une «boîte noire». Tout ce qui se trouve à l'intérieur de cette "boîte noire", cela n'affectera pas le résultat de l'évaluation de la vitesse de travail. L'utilisateur Gaiser écrit que l'implémentation de mauvaise qualité qui est passée par le département QA et l'implémentation parfaitement testée et conçue ne sont pas différentes les unes des autres. En conséquence, il s'avère que la comptabilisation du nombre de tickets fermés n'est pas un indicateur fiable de la productivité du travail.
▍3. Développeurs extrêmement productifs qui ne travaillent pas en équipe
Un autre fil parlait de la tension entre les grands programmeurs solo et les grandes équipes. Lorsque tout le monde suit la méthodologie Scrum, certains développeurs peuvent être extrêmement productifs, mais alors «l'équipe» peut être oubliée. L'utilisateur Gaiser déclare que sans les bonnes incitations, l'auto-organisation est un objectif inatteignable: «Les membres de l'équipe résoudront les problèmes comme ils l'entendent ou selon les instructions. S'il ne construit pas l'équipe, il en restera beaucoup et les membres de l'équipe avanceront tout simplement dans le désarroi. "
Il poursuit: "De plus, permettre à chaque développeur de choisir ses propres méthodes pour résoudre les problèmes, cela signifie plus difficile de déboguer le code."
▍4. Les tâches difficiles sont reportées à plus tard
Gaiser, dans le même esprit, continue de critiquer l'illusion de la productivité. Il dit que lors de l'application de Scrum, l'objectif principal est de faire passer le ticket à l'état "Prêt". Penser profondément à la tâche en même temps ne semble pas particulièrement productif. Par conséquent, les développeurs peuvent avoir tendance à assumer des tâches faciles et à éviter les tâches plus complexes. Ici encore, les mots de l'utilisateur Gaiser: «Scrum encourage les développeurs à entreprendre des tâches faciles qui prennent un peu de temps à résoudre, ce qui permet aux développeurs de montrer constamment des performances élevées. En conséquence, il s'avère que les choix de tâches quotidiennes et les rapports de travail quotidiens poussent le choix des tâches qui prennent une journée à accomplir.
▍5. Les fonctionnalités du produit sont plus importantes que la qualité du code
Néanmoins, Gaiser estime que l'utilisation du framework Scrum entraîne une baisse de la qualité du produit: «La qualité d'un développeur est généralement déterminée par sa capacité à développer un code fiable. Scrum, à moins que le propriétaire du produit ne comprenne la programmation et ne révise le code, dévalorise sérieusement cette caractéristique des projets. " Il souligne ici que la "disponibilité" d'un ticket est souvent déterminée non pas après avoir vérifié la qualité du code, mais seulement après la mise en œuvre de la fonctionnalité correspondante.
▍6. Manque de temps pour discuter des problèmes de travail avec des collègues
Si la vitesse de développement est le seul indicateur de l'efficacité de l'équipe, cela signifie que les membres de l'équipe n'ont plus le temps de discuter de certains problèmes entre eux, d'obtenir l'opinion des autres, ou de tester leurs idées, quelqu'un parler d'eux. Et c'est exactement ce qui fait d'une équipe une équipe. Ici encore, les mots de l'utilisateur Gaiser: «Les grands développeurs consultent souvent d'autres développeurs et recherchent des alternatives à leurs opinions. Mais ces classes prennent le temps nécessaire pour fermer les tickets, ce qui ralentit la vitesse de développement. "
▍7. Les bugs récemment identifiés doivent attendre leur tour
Un autre mauvais comportement de Scrum est que "les bogues sont trouvés après le sprint et sont considérés comme de nouvelles tâches". Cela peut pousser les développeurs à publier du code de mauvaise qualité, car des tâches supplémentaires ne peuvent pas être incluses dans le sprint actuel.
▍8. Architecture pilotée par les billets
Le système de tickets n'est pas uniquement basé sur les tâches que les développeurs choisissent pour eux-mêmes. L'utilisateur Gaiser dit également que l'utilisation de Scrum, par inadvertance, conduit à une architecture confuse des projets, car les développeurs travaillent sur les tickets dans l'ordre dans lequel ils apparaissent et indépendamment les uns des autres. En conséquence, «l'architecture devient rapidement le reflet des billets».
▍9. Une méthodologie de gestion du développement qui touche absolument tout
En lisant la discussion, vous pouvez faire attention aux commentaires, dont les auteurs notent que la racine de tous les problèmes réside dans le manque de strict respect des règles Scrum. Cependant, la revendication anti-Scrum la plus forte de l'utilisateur Gaiser est peut-être qu'elle domine tout le reste. Cela peut détruire une équipe solide. "[Scrum] déforme et brise tout autre mécanisme de gestion du développement, ce cadre devient un phénomène omniprésent dans lequel rien d'autre que des rituels ne se fait de manière uniforme, et l'exécution de ces rituels crée l'illusion du succès."
Nous avons discuté d'une liste assez longue de problèmes qui peuvent être causés par l'utilisation de Scrum et, peut-être, ne deviennent que plus visibles grâce à l'utilisation de ce framework. Mais dans la discussion que nous recherchons, vous pouvez trouver autant d'idées sur la façon dont les développeurs peuvent vivre en paix et en harmonie en suivant les règles Scrum .
Comment tirer le meilleur parti de Scrum?
Beaucoup de réponses aux commentaires de Gaiser, qui ont reçu de nombreuses évaluations positives, étaient que ce dont il parlait n'était pas de Scrum. Voici ce que l'utilisateur Stephen Byrne a écrit à ce sujet: «Je pense que c'est une bonne réponse avec quelques informations précieuses, mais je suis d'accord avec de nombreux autres commentateurs sur le fait que ce qui est décrit ici n'est certainement pas Scrum, bien que et est vu sous le couvert de Scrum. " Mais beaucoup détestaient ouvertement Scrum, ou étaient d'accord avec l'utilisateur de Gaiser que si quelque chose ne va pas lors de l'utilisation de Scrum, cela signifie que ce cadre n'est tout simplement pas utilisé correctement.
Comment utiliser correctement Scrum?
▍1. Les réunions quotidiennes ne sont pas la même chose que la collecte de nouveaux billets chaque jour
De nombreuses personnes ont expliqué comment les réunions quotidiennes obligent les développeurs à fermer des tickets chaque jour. Mais, comme l'a noté DJClayworth , vous ne pouvez pas vous passer de hiérarchiser les tâches. Et si les priorités ne sont pas définies naturellement, alors cette tâche devrait être prise en charge par le Scrum Master: «Nous devons prioriser les tâches dans les sprints, les tâches plus importantes doivent être plus prioritaires, donc quelqu'un doit assumer des tâches difficiles le premier jour du sprint. Dans tous les cas, si le deuxième jour personne n'a pris en charge une tâche importante et complexe, le Scrum Master devrait dire quelque chose comme: «Je vois que personne n'a pris la tâche de compresser la base de données. Et c'est une tâche énorme. Si nous voulons terminer le sprint, le travail sur cette tâche devrait commencer maintenant. "
▍2. ,
Toutes les tâches résolues dans le sprint doivent être décomposées en petites parties. C'est indéniable. Mais le framework Scrum ne dit pas que les développeurs devraient être obsédés par les métriques qui indiquent des résultats. Scrum ne suggère pas de confronter les développeurs les uns aux autres. L'utilisateur Gaiser propose d' abandonner complètement la prise en compte des points des programmeurs individuels. Il souligne également que de nombreux managers peuvent avoir besoin de réapprendre les règles de Scrum: «Dites aux managers que le moment où ils félicitent les développeurs ou leur donnent une promotion basée sur des tickets fermés devient le moment où ils changent radicalement le comportement de l'équipe. ".
Utilisateur DJClayworthconvient que le fait d'ignorer délibérément les métriques associées aux tickets individuels devrait faire partie de la tâche d'un bon Scrum Master: «L'attention doit être concentrée sur le fait que l'équipe atteint ses objectifs en tant qu'équipe. Le Scrum Master doit s'en tenir à cette ligne de comportement et éviter toute discussion ou notation basée sur le nombre de user stories que chaque membre de l'équipe a promues. "
▍3. Vous devez faire de petits pas vers de grands objectifs, mais avec cette approche, vous ne devez pas oublier ces objectifs.
Voici une autre idée pour briser de gros problèmes en petits morceaux: "Si vous travaillez sur une petite pièce d'un puzzle, cela ne signifie pas que vous devez oublier le puzzle entier."
L'utilisateur Llewellyn souligne que l'utilisation de Scrum n'est pas une excuse pour ignorer complètement les principes du développement logiciel de qualité: «Il faut avoir une bonne idée de la direction du projet. Ces connaissances peuvent être utilisées pour planifier l'architecture du projet, s'engageant dans la planification même dans le sprint actuel. "
Scrum ne libère pas les programmeurs de la nécessité de faire leur travail en y investissant toutes leurs connaissances et toute leur expérience. Par conséquent, l'appel de Llewellyn s'adresse aux programmeurs qui sont parmi les lecteurs des commentaires: «Vous étiez à la réunion, vous pouvez regarder le backlog, vous savez quelle est la vision globale du projet dans l'organisation. Vous vous efforcez d'éviter d'avoir à passer de longues périodes de temps sur quelque chose d'un futur lointain. Mais il n'y a rien de mal à jeter les bases d'un système extensible et modulaire qui convient à la fois pour résoudre les problèmes actuels et vous permettra de créer des opportunités supplémentaires déjà planifiées sans problèmes à l'avenir. "
▍4. Il est nécessaire de décider de ce que signifie «Terminé»
L'un des sujets soulevés dans la discussion dont nous avons discuté concernait les critères de définition du fait (DoD), et comment la définition de ces critères aide les programmeurs individuels à adhérer à certaines normes de qualité et à être conscients de ce que l'on attend d'eux. La question la plus urgente ici était de savoir qui et quand élabore ces critères. Quand il s'agit de « quand », il s'agissait généralement soit de développer des critères le plus rapidement possible, soit de savoir comment ils devraient être développés pendant la planification du sprint.
La réponse à la question de savoir qui produit DoD a été écrite par l'utilisateur SpoonerNZ sous la forme d'une réponse à une autre questionsur le site Web de génie logiciel. «Les critères de préparation sont créés par l'équipe, mais ce processus peut nécessiter la présence d'un Scrum Master. Cela est nécessaire afin de fixer des restrictions de qualité, dans le cas où l'équipe n'aurait pas de normes de développement claires. Par exemple, une équipe peut ne pas vouloir jouer avec les revues de code ou les tests unitaires, ce qui entraînera l'ajout de tous au DoD par le ScrumMaster afin d'assurer un développement de haute qualité. Dans une situation idéale, l'équipe, ayant compris les forces de ce qui est proposé, l'acceptera volontiers, mais le monde réel n'est pas toujours idéal. "
Qui devrait travailler en adhérant au DoD? Un objectif naturel (et stimulant) est de s'assurer que les dispositions décrites dans le DoD sont appliquées dans une seule équipe et qu'elles sont soutenues par tous les membres de cette équipe. Mais il y a de bonnes raisons d'étendre l'influence du DoD à plusieurs équipes. Ou même toute l'organisation. Voici ce que l'utilisateur Alan Larimer en écrit: «L'absence d'une définition DoD universellement reconnue pour un produit a un impact négatif sur la qualité et la transparence des résultats du travail. Le niveau organisationnel du DoD doit être minimal, technique et parfois propre à l'organisation, ce qui peut fournir une application universelle des critères de préparation. L'organisation peut proposer des normes de codage. Une organisation peut exiger la création d'assemblages automatisée, donnant les ressources nécessaires pour créer et gérer des assemblages pour chaque produit. Toute partie du DoD, qu'elle soit créée par une organisation ou par un développeur individuel, devrait apporter quelque chose de valeur aux critères de préparation. "
▍5. Les managers doivent jouer le rôle d'observateurs silencieux
Alors que ce qui est dans l'en-tête de cette section est déjà inscrit dans le manuel officiel Scrum, l'analyse de la discussion montre que cette règle est malheureusement souvent violée dans les réunions quotidiennes auxquelles participent les managers. Pour cette raison, les programmeurs ressentent le besoin d'expliquer pourquoi le travail des tickets prend plus de temps que prévu. Si seuls des programmeurs assistent à la réunion, ces explications ne sont guère nécessaires. Voici ce que le manuel Scrum en dit: «Daily Scrum est une réunion interne de l'équipe de développement. Si quelqu'un d'autre est présent, le Scrum Master s'assure qu'il n'interfère pas avec la réunion. "
▍6. Les personnes devraient être plus importantes que les processus
Si vous avez besoin de conseils sur la façon d'appliquer les règles Scrum, lisez les mots écrits par l'utilisateur Frank Hopkins pour vous rappeler un principe classique: «Les gens sont plus importants que les processus». Ici, il a ajouté ce qui suit: "Une bonne équipe doit définir ses processus, des processus définis de manière rigide ne contribuent pas à la formation d'une bonne équipe."
Un autre utilisateur, Meriton , a souligné que l'utilisation de Scrum dépend des programmeurs individuels: «Scrum ne stipule pas que les développeurs travaillent indépendamment les uns des autres. Scrum prévoit que l'équipe de développement s'auto-organise, c'est-à-dire que l'équipe prend des décisions sur la manière dont ses membres interagissent. "
Nvoigt utilisateur notesque les équipes de Scrum s'auto-organisent du fait qu'elles arrivent au projet avec une mission définie: «Le framework Scrum est basé sur le fait que vous êtes une équipe. Peu importe dans l'équipe si le ticket a été fermé hier par un programmeur spécifique. Quiconque travaille en équipe comprend l'objectif (c'est-à-dire le DoD) et s'efforce de l'atteindre avec le reste de l'équipe. "
▍7. Construisez des équipes pour qu'elles fonctionnent comme Scrum, mais ne vous attendez pas à ce que Scrum crée une équipe
Utilisateur nvoigta appliqué une métaphore sportive: «Imaginez que 11 personnes reçoivent un manuel de football imprimé. On leur a dit qu'ils devaient s'entraîner dans la salle de conférence n ° 5 tous les jours vers 10 heures pendant 15 minutes. Pensez-vous que le résultat sera une bonne équipe de football? Et si ces 11 personnes étaient de bons footballeurs professionnels? La commande ne fonctionnerait-elle pas de toute façon? Oui, ce ne serait pas le cas. C'est juste que les équipes de football ne sont pas créées de cette façon. Comme tout sport d'équipe, Scrum a besoin de ceux qui utilisent ce cadre pour être une équipe. S'il ne s'agit que d'un groupe de personnes, dont chacun veut juste gagner des points pour lui-même en montrant combien de points dans la user story ils ont couvert, ou combien d'objectifs ils ont atteint, alors ce groupe perdra toujours au profit d'une équipe dont les membres jouent ensemble, et non les uns à côté des autres. ami,ou les uns contre les autres. "
Résultat
L'utilisateur de nvoigt est prêt à admettre que Scrum "ne convient pas à tout le monde ou à toutes les équipes". Et, comme l'intérêt de la communauté pour le problème dont nous discutons ici l'a montré, l'application d'un ensemble de règles que Scrum pourrait pousser à développer peut conduire à un environnement de travail qui est loin de ce qu'elle aimerait construire.
Nous aimerions résumer le résultat de ce matériel avec les mots de l'utilisateur Seth R... Il dit qu'il n'est pas nécessaire d'attendre des miracles des rituels des méthodologies agiles. Trop est demandé par ceux qui cherchent avec leur aide, comme par magie, pour corriger les lacunes de l'équipe de développement. Voici comment il voit la situation: «Il s'agit d'accélérer le feedback. En conséquence, l'équipe a la possibilité de s'auto-évaluer et de prendre des décisions sur la façon de travailler pour obtenir les meilleurs résultats. Scrum ne vous aidera pas à créer un meilleur produit, mais si vous prenez au sérieux les auto-tests, cela peut vous aider à construire une meilleure équipe. Ceci, à son tour, conduit au développement d'un meilleur produit. "
Beaucoup de gens comparent ce cadre à la démocratie. Alors peut-être que Scrum est la pire forme de gestion du développement, à part tout le monde?
Ou peut-être s'agit-il, comme le dit le guide officiel , d'un cadre facile à comprendre mais difficile à maîtriser parfaitement.
Comment répondriez-vous à la question dans le titre de cet article?
