Avantages de Scrum pour les développeurs eux-mêmes? [fermé]

Scrum étant une méthodologie de gestion de projet, comment la «vendriez-vous» aux développeurs d'une équipe raisonnablement satisfaite de sa situation actuelle?

Il me semble facile d'expliquer à notre chef de produit comment Scrum lui permettra d'obtenir des versions régulières, de modifier les exigences et de faire en sorte que l'équipe se concentre d'abord sur les histoires prioritaires. J'ai trouvé facile d'expliquer ce que le TDD ou l'intégration continue apportent à la vie quotidienne d'un développeur.

Mais comment convaincre les développeurs d'embrasser Scrum? Comment Scrum pourrait-il leur faciliter la vie?

Scrum fournira beaucoup plus de visibilité sur ce qui se passe . Mauvaise gestion, changements de dernière minute, pressions et toutes sortes de choses auxquelles un développeur est généralement confronté.

Cependant, cela apportera également beaucoup de visibilité sur les procrastinateurs, les développeurs de mauvaise foi, les individualistes fous, ... en d'autres termes, les mauvais développeurs.

Scrum est une épée à double tranchant

Scrum vous apportera des opportunités pour résoudre ces problèmes. C'est pourquoi c'est si puissant.

Briser le grand objectif («faire faire le logiciel») en plus petits morceaux - des histoires - et décider lequel d'entre eux faire au sprint actuel améliore la productivité et réduit le stress. Lorsque vous savez précisément ce que vous êtes censé faire maintenant , il n'y a pas grand-chose à souligner et vous pouvez vous concentrer sur le petit morceau au lieu de vous sentir dépassé par le grand tout.

Stack Ranks / Backlog empêche les jalons de se terminer par des marches de la mort

En tant que développeur, le «schéma destructeur» que je vois le plus dans le développement de logiciels est lorsqu'un «contrôleur externe» (par exemple, la gestion de projet, la gestion exécutive) est très excité par le fait que la «fonctionnalité préférée» ne va pas continuer. calendrier »et ordonne une marche vers la mort.

Scrum, car il classe les «fonctionnalités importantes» dans une liste de backlog, aide les développeurs à gérer cette tension de manière proactive de deux manières. Premièrement, vous pouvez classer la «fonction préférée» en haut de l'arriéré afin qu'il soit le plus susceptible d'être heureux. Deuxièmement, cela donne une réponse très visuelle et concrète à "puisque nous avons déplacé les" widgets clignotants "au rang 1, il est très probable que nous n'allons pas arriver aux" lapins rebondissants "dans ce sprint car il est maintenant au rang 7. Sont vous êtes à l'aise avec ce compromis? "

J'ai également constaté qu'avec des sprints courts, les «contrôleurs externes» sont moins contrariés par le report du travail. Si les «widgets clignotants» ne se transforment pas en «jalon 1» et que le «jalon 2» ne se termine pas avant 9 mois, le sponsor des «widgets clignotants» est très contrarié. Mais si `` widgets clignotants '' est classé 7 au lieu de 1 car il y a vraiment 6 choses plus importantes à faire en premier, cela signifie que nous y arriverons probablement en sprint + 1 ou au pire sprint + 2, ce qui signifie il apparaîtra dans 12 ou 18 semaines (en utilisant des sprints de 6 semaines). D'après mon expérience, attendre 3 mois est «acceptable» pour les impatients - en outre, de retour dans le modèle «cascade» des jalons de 3 mois et plus,

Enfin, si nous arrivons à la fin du sprint et que les choses ont pris plus de temps que prévu, il est très agréable de pouvoir reporter les éléments 5-6-7 du backlog au prochain sprint et de nous assurer que nous avons terminé 1-2-3. -4 de haute qualité et sans semaines de 70 heures. Après tout, nous serons sûrs d'arriver au 5-6-7 prochain sprint. Encore une fois, étant donné les délais plus courts impliqués dans le report, les `` contrôleurs externes '' sont généralement plus à l'aise avec cela et n'insistons pas pour que nous passions le jalon deux semaines et commandions des dîners chaque nuit `` juste pour le franchir ''.

Les membres d'une équipe Scrum décident de beaucoup de choses par eux-mêmes: ce qui sera fait lors du prochain sprint, comment décomposer cette histoire en tâches, qui travaille sur quoi, etc. -la gestion.

Le fait que les exigences vont changer est pris en compte dès le début. Les développeurs n'ont pas besoin de créer des spécifications détaillées avec des estimations précises, puis de passer des semaines à développer une fonctionnalité pour se rendre compte que le client change d'avis dès qu'il voit le résultat ...

Pour moi, vous pouvez vous attribuer des tâches à partir du backlog, c'est le plus gros argument de vente du point de vue du développeur. En outre, l'intimité avec le client / propriétaire du produit permet de comprendre le plus grand schéma des choses.

Un certain nombre de choses:

• S'appuyant sur l'argument de Xavier sur les exigences changeant dès le début - une atmosphère moins politique se développe lorsque tout le monde accepte dès le départ que certaines choses ne seront pas comme le client l'attend. Une livraison et un examen rapides signifieront que le coût des erreurs de communication est faible, et au lieu de jouer le jeu du blâme, les développeurs peuvent simplement changer les choses afin qu'elles fonctionnent comme prévu par le client.

• Points d'histoire! Quel développeur n'aime pas obtenir des points pour faire des choses !!?! Sérieusement, c'est mieux que d'obtenir des badges dans SC2 ou Stack Overflow.

En tant que développeur, il y a plusieurs choses que j'aime dans Scrum.

Les développeurs ont tendance à recevoir plus d'informations à l'avance. Le propriétaire du produit doit expliquer tout le travail qui sera effectué lors du prochain sprint de manière suffisamment détaillée pour permettre de bonnes estimations.

L'estimation juste à temps signifie que ces estimations sont raisonnablement précises. Tout le monde a généralement une assez bonne idée de ce qui sera terminé dans un sprint. Cela donne aux programmeurs et aux chefs de projet les outils pour repousser les demandes déraisonnables.

Il est agréable de prendre du recul toutes les trois à quatre semaines et de reprendre son souffle et au moins de changer de rythme.

Les équipes auto-organisées semblent donner un peu plus de variété dans le travail.

En théorie du moins, pendant le sprint, il y a moins d'interruptions et d'urgences.

La réunion quotidienne de stand up force les programmeurs à dire plusieurs mots chaque jour.

Il est plus facile de voir les progrès réalisés car les histoires sont explicitement terminées et examinées à la fin de chaque sprint.

Les tableaux de gravure sont un moyen léger et assez efficace de suivre les progrès.

L'avantage pour le développeur est une rétroaction précoce (du client, du testeur, du propriétaire du produit, etc.).

En tant que développeur, je suis toujours intéressé à faire les choses pas à pas sans distraction. Scrum fournit cela.

PS: Scrum n'est pas une méthodologie, c'est un cadre.