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

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?

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.

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.

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.

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é.

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.