SCRUM à partir de zéro, sans cadre de base établi?


11

Nous sommes un petit groupe de 5 personnes qui s'apprête à démarrer un nouveau projet. C'est le premier projet où nous allons faire tapis sur scrum.

Nous nous débattons un peu avec la façon dont nous allons établir une base pour le projet (cadres et similaires). De telles tâches ne sont pas quelque chose dont l'utilisateur bénéficiera directement, nous avons donc du mal à comprendre comment nous écrivons des user stories pour cela.

Donc, en général, comment utilisez-vous Scrum, lorsque vous démarrez un projet à partir de zéro, sans framework et sans bibliothèque de base en place?

Réponses:


7

Je ne pense pas que beaucoup de méthodes agiles gèrent bien les activités qui font généralement partie du démarrage d'un projet. De nombreux cadres communs (XP, Scrum, Kanban) ne répondent pas à cette préoccupation, mais certains des cadres évolués (Disciplined Agile Delivery, SAFe) le font dans une certaine mesure.

Certaines personnes préconisent un concept d'incrément initial (dans Scrum, un sprint) conçu pour mettre en place votre projet. Ceci est souvent appelé Increment Zero (ou, dans Scrum, Sprint 0). Cependant, ce n'est pas une partie formelle de Scrum et les puristes disent que le premier incrément devrait être potentiellement libérable.

Un tel incrément est utilisé pour configurer l'environnement de l'équipe - configurez vos environnements de développement, de test et de production, configurez vos outils et scripts de prise en charge et établissez vos environnements de travail avec des graphiques de burndown et des backlogs. Si un membre de l'équipe n'est pas familier avec les outils de développement utilisés, c'est là qu'il apprend les bases pour fonctionner et commence à produire des résultats dès la première itération.

Parallèlement à cela, vous commencerez souvent à écrire vos premières histoires d'utilisateurs et à hiérarchiser votre backlog de produit, car il n'y a pas de backlog de sprint à ce stade. Celui qui est le propriétaire du produit inventera des histoires. Si cette personne est nouvelle à Scrum, elle apprendra à écrire de bonnes histoires d'utilisateurs avec lesquelles l'équipe peut également travailler. N'insistez pas sur l'obtention de toutes les histoires, mais vous en aurez assez pour lancer la première itération de développement.

Différentes équipes gèrent le Sprint 0 différemment. Certains pourraient le chronométrer à la même durée que n'importe quel autre sprint. D'autres pourraient l'allonger un peu plus ou un peu plus court selon les besoins de l'équipe. Comme c'est votre première tentative de Scrum, je pourrais l'allonger, surtout si vous avez des itérations plus courtes dans le cadre de votre cycle de développement. Si vous prévoyez des itérations de deux semaines, faites-en 3 semaines.

En ce qui concerne la formulation des tâches, je ne les formulerais pas nécessairement comme des user stories. Vous pouvez, du point de vue des membres de l'équipe et des différents rôles (Product Owner, ScrumMaster, développeur, testeur, concepteur, rédacteur technique, etc.). Cependant, Sprint 0 est pour l'équipe, pas pour le client ou l'utilisateur. Une simple liste de tâches et d'activités suffirait.


3
Le sprint 0 est directement destiné à l'équipe mais profite indirectement au client car il jette les bases du travail de sprint à venir. Excellente réponse, vous le faites paraître simple et pas aussi chaotique que Sprint 0 le ressent habituellement.
maple_shaft

Tout lancement de projet est généralement chaotique dans une certaine mesure, selon l'équipe. Non seulement il y a généralement des problèmes techniques pour tout configurer, mais aussi des problèmes personnels entre les membres de l'équipe et des problèmes de processus pour trouver la meilleure façon de traiter les problèmes qui surviennent.
Thomas Owens

Un autre outil de la ceinture à outils Scrum est une série de "pointes" (histoires de recherche) dont le résultat est essentiellement de déterminer quelles options sont disponibles et ce que l'équipe a choisi comme solution préférée. C'est-à-dire quand aucun framework n'est utilisé, vous pouvez avoir un sprint pour déterminer quels frameworks (le cas échéant) vous aideraient à vous rapprocher d'un produit utile. Aucun cadre n'est toujours une option, en particulier pour les petits utilitaires ponctuels.
Berin Loritsch

1

Ce sont les pré-sites que nous avons établis avant d'implémenter SCRUM dans notre équipe. Une fois que vous avez terminé avec la liste, vous pouvez déployer le processus et les outils pour une mêlée réelle.

  1. Les membres de l'équipe sont hautement ou moyennement qualifiés.
  2. L'équipe est très soudée.
  3. L'échange d'informations entre les membres de l'équipe est rapide, cohérent et libre.
  4. L'équipe est colocalisée.
  5. Les affaires sont fortement impliquées avec l'équipe.
  6. L'architecture (commerciale, informationnelle et technique) est bien définie.
  7. L'infrastructure est opérationnelle - environnement Dev, test et UAT.
  8. Construction et publication automatisées.
  9. Haut niveau d'automatisation des tests.
  10. La dépendance de l'équipe vis-à-vis du monde extérieur est minimale (idéalement nulle).
  11. Le nombre de systèmes participants est minime.
  12. Les exigences sont stables à des niveaux supérieurs, de sorte que le backlog de produits a des changements minimum
  13. Les membres de l'équipe sont autonomes pour décider quelle histoire utilisateur doit faire partie du sprint / scrum ainsi que du nombre total de scrums / sprint nécessaires pour atteindre l'objectif déclaré.

Deux autres parties importantes:

  1. Sélectionnez les personnes pour les rôles (Scrum master, Product owner et l'équipe)
  2. Ayez votre tableau blanc, vos autocollants prêts.

Que voulez-vous dire avec # 11?
Matt Grande

3
D'après mon expérience, si l'application dépend de ou est connectée à des systèmes externes, SCRUM ne fonctionnait pas bien. La dépendance à l'égard d'autres équipes a réduit l'efficacité de notre processus. Peut-être que c'était juste notre projet ...
java_mouse

Oh, d'accord, vous vouliez donc dire des systèmes qui avaient besoin de modifications. Je pensais juste que c'était des systèmes qui étaient inclus, d'où la confusion. Dans le passé, nous avons réussi cela en ayant deux "niveaux" de mêlée. Un niveau inférieur pour chaque système et un niveau supérieur pour l'ensemble du projet pour inclure toutes les équipes.
Matt Grande
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.