Comment faire fonctionner Scrum pour une équipe avec des rôles définis?

13

Quelques informations de base

Je fais partie d'une équipe de développement logiciel en interne. Cela consiste en

  • 5 développeurs (avec des expériences allant de 2 à 5 ans, j'en fais partie)
  • 3 personnels d'implémentation (ils assurent le déploiement et la formation des logiciels)
  • et 1 chef de projet.

Nous développons de nombreux projets de petite à moyenne taille, et leurs délais se chevauchent généralement. Le développement se déroule comme suit:

  1. "Client" nous donne un ensemble d'exigences initiales
  2. Nous développons le système selon cette spécification
  3. Présenter ledit système au "client"
  4. "Client" nous donne des exigences supplémentaires basées sur ladite présentation
  5. Répétez 2-4 jusqu'à ce que le «client» soit à court de nouvelles exigences ou que la date cible de déploiement soit proche
  6. Configurer et déployer le système

Ceci, avec le fait que c'est le "client" qui gère les délais la plupart du temps (qui est un drapeau rouge, d'après ce que je vois ici dans Programmers et PM.SE) et nous ne suivons pas de pistes de méthodologie de développement définies au codage cowboy, au code quasiment impossible à maintenir et aux bogues qui traversent la production, entre autres. C'est pourquoi nous avons choisi d'adopter une méthodologie basée sur Agile comme Scrum.

Pourquoi Scrum?

C'était l'initiative de notre manager, et tout le monde semble être d'accord, vu notre situation actuelle.

Le problème avec Scrum

Certains des éléments de Scrum ont des conflits avec notre configuration actuelle que nous ne pouvons pas facilement résoudre, en particulier la nature "jack-of-all-trades" des développeurs Agile. L'équipe de déploiement ne sait pas programmer et les développeurs ont des compétences de communication et de formation inférieures à la moyenne. Et cette programmation ne changera pas vraiment de si tôt.

La question

Cela affecterait-il l'efficacité de Scrum en tant que méthodologie? D'autres modifications devraient-elles être apportées pour compenser? Ou serait-il préférable d'abandonner complètement la pensée et de réfléchir à une méthodologie différente?

agile scrum methodology Revenant
la source
17
Votre "Pourquoi Scrum?" paragraphe est assez important, et il est essentiellement vide en ce moment. Il semble que votre manager n'aime pas ce que vous faites actuellement, et a donc décidé au hasard Scrum parce que Scrum.
RemcoGerlich
4
il y a un rôle / une place précis pour les spécialistes dans un environnement agile (scrum ou autre). Ne vous méprenez pas sur le fait que les gens sont censés sauter sur des choses qui ne sont pas leur spécialité pour une «interdiction» des spécialistes. En plus de cela, pourriez-vous expliquer pourquoi vous avez choisi la mêlée et non le kanban? cela me semble comme, étant donné la réitération constante des exigences, un meilleur ajustement que celui avec des sprints prédéfinis qui fonctionnent le mieux avec des exigences fixes ...
Elias Van Ootegem
12
5 développeurs mais pas un seul testeur?
Apfelsaft
8
@Revenant vous confondez la prise de tous les métiers (individuels) avec interfonctionnelle (équipe).
guillaume31
6
Popularité. Toujours la meilleure façon de choisir quoi que ce soit.
Robert Harvey

Réponses:

17

En fait, votre façon de travailler actuelle n'est pas si éloignée de Scrum que vous le pensez.

Dans Scrum, vous obtenez également un ensemble initial d'exigences, implémentez-les et démontrez le résultat.En fonction de la démonstration, de nouvelles exigences peuvent vous être données ou les parties prenantes peuvent décider que le produit est suffisamment bon pour qu'aucun développement supplémentaire ne soit nécessaire.
Dans votre situation, le "client" dont vous avez parlé pourrait se voir attribuer le rôle de Product Owner dans Scrum (il semble déjà remplir ce rôle en définissant les priorités dans un projet et en décidant quand il est prêt à être déployé).
Un grand changement pourrait être la longueur d'une itération. Dans Scrum, une itération devrait durer entre 1 et 4 semaines.

En ce qui concerne la composition de l'équipe et la fausseté de tous les métiers: Scrum n'exige pas que tout le monde soit un cric de tous les métiers. Scrum exige simplement que l'équipe dans son ensemble possède toutes les compétences requises pour faire passer le produit d'une liste d'exigences à quelque chose qui a été / peut être déployé.
Dans votre situation, je pourrais facilement voir une équipe par projet composée d'un ou plusieurs développeurs (effectuant principalement le travail de mise en œuvre et de test) et un membre du "personnel de mise en œuvre" qui se concentre principalement sur la création des manuels et du matériel de formation pour les fonctionnalités qui les développeurs implémentent maintenant.

Une fois que le client / propriétaire du produit a donné son feu vert pour le déploiement, le travail de l'équipe scrum sera principalement effectué, afin que les développeurs puissent passer à un autre projet (et être disponibles uniquement sur demande pour résoudre les problèmes après le déploiement) et la mise en œuvre le personnel peut passer à l'exécution de la formation et au soutien du déploiement.

Le fait qu'il y ait des délais n'est pas un vrai problème, tant qu'il y a suffisamment de flexibilité dans les fonctionnalités qui doivent être dans cette version.

Bart van Ingen Schenau
la source
2
Un changement que Scrum et d'autres méthodologies Agile introduiraient est que le produit / toutes les fonctionnalités doivent être «effectués» - dans un état livrable - à la fin de chaque itération.
stannius
5

Vous demandez des alternatives, donc je vais dire eXtreme Programming (XP). Plus précisément, je pense que la programmation par paires pourrait vous aider ici.

En associant des personnes ayant des compétences différentes, peu importe la compétence: préparer du café, tester, former, etc., vous pouvez diffuser les compétences au sein de l'équipe.

Mais pour être honnête, il ne semble pas que SCRUM soit si loin pour vous. Une partie de SCRUM est d'être flexible et de trouver ce qui convient le mieux à votre équipe. Une partie de XP consiste à respecter votre équipe et à vous adapter. Peut-être que dans 100 ans, nous pourrions avoir une profession plus développée avec des règles dures et rapides (bien que j'en doute) mais pour l'instant, faire ce qui fonctionne pour vous est tout ce que nous avons. L'important est d'avoir des boucles de rétroaction. Si quelque chose ne fonctionne pas, l'équipe doit en discuter et essayer de nouvelles choses jusqu'à ce qu'elle trouve quelque chose qui fonctionne.

Encaitar
la source
3
+1 pour XP. La question indique que la principale raison de l'adoption de Scrum est que "nous ne suivons pas une méthodologie de développement définie conduit à un codage cowboy, un code presque impossible à maintenir et des bogues qui traversent la production" - Scrum fera peu ou rien pour cela, comme il ne prescrit aucune pratique technique, et seules les pratiques techniques vont résoudre ces problèmes. Il existe de nombreux autres cadres agiles qui le font, XP étant probablement le meilleur candidat car il est le plus proche des plus connus de Scrum dans sa structure.
Jules
3

Comment faire fonctionner Scrum pour une équipe avec des rôles définis?

Simplement fais-le. Selon le guide Scrum, tout le monde est développeur, mais de retour sur la planète Terre, différentes personnes apporteront différentes choses. J'ai failli être lynché quand j'ai suggéré que certaines personnes sont vraiment des testeurs tandis que d'autres écrivent le logiciel.

Certaines choses que vous voudrez peut-être aborder:

Sprints

Il semble que vous ayez une phase de développement initiale suivie d'une série de sprints ostensiblement. Pensez à rompre cela. Non seulement le client verra quelque chose tôt, mais vous aurez une meilleure idée des étapes de développement à mesure qu'elles se produisent.

Délais fixes

Cela revient encore et encore et est en effet une épine persistante du côté des développeurs où je travaille actuellement. Scrum établit des estimations pour le sprint - rien de plus. Oui, vous pourriez atteindre la cible après une série de sprints, mais une fois que le client a les yeux sur les premières versions, la portée est susceptible de se glisser considérablement. Ce n'est pas un problème en soi, mais le client doit être informé que des travaux supplémentaires auront lieu dans les sprints ultérieurs et dépasseront les exigences connues.

Robbie Dee
la source
Juste pour souligner ce qui semble être une horrible mauvaise caractérisation de Scrum: tout le monde n'est pas un développeur - vous pouvez et aurez des membres spécialisés, mais ils font partie de l'équipe de développement et sont responsables de la sortie des sprints de cette équipe. Dans notre configuration Scrum, les testeurs sont généralement derrière quelques sprints en termes de ce sur quoi ils travaillent par rapport aux développeurs car ils ne peuvent pas tester ce qui n'est pas fait, mais ils créent les plans de test et les données de test possibles dont ils auront besoin. Bien qu'ils traitent des principales fonctionnalités, nous entrons dans un ancien mode de correction de bogues et préparons le correctif à mesure qu'ils rattrapent la coupure de la version.
Duffy
3
En réalité, vous avez été "lynché" pour avoir suggéré que les testeurs soient traités comme des poulets, plutôt que comme des porcs (du moins c'est pourquoi j'ai dévalorisé cette réponse) ...
David Arno
@Duffy Je suis d'accord - il n'y a pas d'autres titres que développeur mais en réalité, les rôles sont souvent très bien organisés selon les lignes traditionnelles.
Robbie Dee
@DavidArno Dans notre boutique, ils sont. En fait, nous avons une configuration identique à ce que Duffy décrit. Nos testeurs font un sprint ou deux derrière. Le hic, c'est quels membres du personnel vous jugez être l'équipe de développement. Comme je l'ai souligné dans mon article , je n'accepte tout simplement pas que les administrateurs de base de données et les gestionnaires de build puissent être classés dans le temps de la même manière que les développeurs vanilla - YMMV.
Robbie Dee
Nous arrivons assez bien à la chronologie, il faut une pensée et un processus un peu différents pour les estimations des testeurs car ils sont plus axés sur les processus que sur les estimations de l'intestin, mais ils se retrouvent généralement avec des estimations de temps beaucoup plus fiables (une fois qu'ils peuvent les comparer pendant tests de premier passage) que les développeurs en raison de la nature de leur travail par rapport au nôtre. Je suis le développeur DBA / DB de l'équipe et je m'intègre parfaitement dans un sprint, donc je ne sais pas comment ils ne s'intègrent pas dans le flux de travail pour les autres.
Duffy
3

Votre situation pourrait être un meilleur match pour Kanban, car vous pouvez commencer avec vous avez et itérer à partir de là. Cela signifie que vous n'auriez pas une introduction de grande envergure qui perturbe vos projets actuels - commencez simplement par visualiser les tâches sur un tableau et adoptez certaines des pratiques telles que les rétrospectives et les réunions quotidiennes.

Vous devez être un peu plus prudent qu'avec Scrum car il n'est pas si prescriptif: il a donc tendance à revenir à tout ce qui s'est passé avant d'inculquer un état d'esprit agile approprié.

ndyer
la source
0

Scrum ne fonctionne pas bien avec des projets distincts qui se chevauchent, car vous n'avez pas un ensemble stable de personnes travaillant sur un projet pour le sprint complet. Par conséquent, des concepts tels que la verbosité, etc. sont susceptibles de vous déprimer.

Mais d'abord prendre l'histoire qui donne le meilleur rapport coût / bénéfice au client, et l'implémenter, y compris les tests entièrement automatisés, à une qualité suffisamment bonne pour être déployée, avant de travailler sur l'histoire suivante est un concept utile. De même, tout le code écrit pour une histoire doit être revu par un autre développeur avant que l'histoire soit considérée comme «terminée».

Je suppose que votre personnel de mise en œuvre doit rédiger des documents de formation et de référence, ils peuvent être écrits (première version) pour chaque histoire avant que le code ne soit écrit, devenant ainsi les tests d'acceptation.

J'espère que vous constaterez qu'au début de chaque projet où la contribution du personnel de mise en œuvre serait la plus utile pour les développeurs, ils sont 100% engagés dans le déploiement du projet précédent. Par conséquent, demandez-vous si le personnel d'implémentation peut travailler à l'écriture des histoires et de la documentation utilisateur pour le prochain projet, pendant que les développeurs écrivent le code du projet en cours.

Le «développement axé sur le comportement», le personnel de mise en œuvre écrivant l'exemple utilisé dans les tests pouvant fonctionner.

Il y a donc un peu de Scrum qui vous aidera, mais essayez de vous appuyer sur Scrum au lieu d'utiliser Scrum.

Ian
la source
"D'où des concepts comme la verbosité ..." - vouliez-vous dire vitesse?
Robbie Dee
Si c'était sur une application de grande entreprise avec plusieurs départements voulant des choses différentes à des moments différents, Scrum ne conviendrait-il pas aussi?
JeffO
@jeffO, pourrait fonctionner avec Scrum, à condition que UNE personne ait le pouvoir de décider entre les départements.
Ian
@Ian - c'est une bonne raison de n'avoir qu'un seul propriétaire de projet et les projets peuvent être tranchés et coupés en gros ou en petits comme bon vous semble.
JeffO