ScruML

De Wiki Agile du @GroupeCESI
Aller à : navigation, rechercher

Auteur : Henrik Kniberg
Source : ScruML
Date : 25/08/2007


Traducteur : Fabrice Aimetti
Date : 04/11/2009


Traduction :

Le monde n'a-t-il pas besoin d'un autre langage de modélisation ? :)
ScruML signifie "Scrum Modelling Language". Comme UML, mais spécifique à un domaine et non pas aussi stricte et ... euh ...finalement peut être pas tant que ça comme UML, après tout.
ScruML est utilisé pour visualiser une organisation Scrum d'une manière si simple que même les managers vont comprendre. Il se concentre uniquement sur les éléments propres à Scrum (les Product Owners, les Équipes et qui fournit à qui), ce n'est donc pas une cartographie complète de l'organisation. C'est un outil qui peut aider une entreprise à essayer de comprendre comment mettre en œuvre Scrum dans son contexte particulier.
A quoi ressemble une organisation dans sa première étape ? Et à la deuxième étape ? Quelles sont les équipes existantes ? Quelles sont les équipes qui ont besoin de se synchroniser avec les autres ? Quelle partie prenante (~stakeholders) alimente quelle product backlog ? Quels product backlog alimentent quelles équipes? Si il y a plusieurs product owners, qui doit résoudre les conflits de priorité entre eux ? Quelle est la définition du fini ? Combien de temps durent les sprints? et ainsi de suite. Tout dans un seul dessin, simple et beau.
NOTE AUX LECTEURS SENSIBLES : Certains des diagrammes ci-dessous montrent des organisations Scrum qui ne sont pas optimales, y compris des choses terribles comme les transferts de responsabilités à l'équipe de recette (~QA). J'ai entendu dire que de telles organisations existaient réellement sur le terrain ;-)
Vous semblez être une personne intelligente et impatiente de sorte que, au lieu d'écrire de fastidieuses spécifications, je vais donner 3 exemples et vous laisser comprendre les détails vous-même.
Exemple 1 : Une seule équipe (ou Hello World)
ScruML1.jpg

Ce diagramme montre les choses suivantes :

  • Nous avons une équipe composée de 5 membres, avec Reza Farhang (RF) en tant que ScrumMaster.
  • Il n'y a qu'un seul product owner (bonhomme en fil de fer) et un seul product backlog.
  • Le product backlog est essentiellement alimenté par des demandes provenant directement des utilisateurs finaux.
  • La définition du fini est "livré à l'utilisateur final".
  • La longueur d'un sprint est de 2 semaines (~2weeks).


Exemple 2 : Plusieurs équipes
ScruML2.JPG

Ce diagramme montre les choses suivantes :

  • Nous avons deux équipes qui travaillent sur le même product backlog.
  • La définition du fini est "livré à l'exploitation" (qui à son tour peut déployer tout de suite ou plus tard).
  • L'équipe 1 fait des sprints de 2 semaines, L'équipe 2 fait des sprints de 4 semaines.
  • Les équipes ont besoin de synchroniser leurs travaux grâce à un Scrum de Scrums (la ligne en pointillé), mais ils livrent à l'Exploitation de façon indépendante. Il n'y a pas d'étape d'intégration.
  • Le product backlog est essentiellement alimenté par les commerciaux, les managers, les bêta testeurs et le support.


Exemple 3 : Plusieurs équipes & plusieurs product owners
ScruML3.JPG

Ce diagramme montre les choses suivantes :

  • Nous avons 2 product owners et 2 product backlogs (JM et LJ).
  • Le product backlog de LJ est alimenté par le support aux utilisateurs.
  • Le product backlog de JM est essentiellement alimenté par les responsables produits, mais les demandes des autres intervenants se retrouvent là aussi.
  • L'équipe 1 et l'équipe 2 sont alimentées par le product backlog de JM, et font toutes les deux des sprints de 3 semaines.
    • Leur définition du fini est "intégré et livré à la recette", c'est-à-dire que l'équipe 1 et l'équipe 2 intègrent leurs travaux en une seule release avant de la passer à l'équipe de recette.
  • L'équipe 3 est alimenté par le product backlog de LJ, elle fait des sprints de 1 semaine. Elle travaille essentiellement pour le support aux utilisateurs.
    • Sa définition du fini est "prêt à déployer". Elle n'a pas besoin de passer par une étape distincte de recette.
  • Les trois équipes ont des dépendances, et se synchronisent donc par le biais de scrum of scrums.
  • Si JM et LJ rencontrent des conflits de ressources (par exemple, qui reçoit les nouvelles recrues ou bénéficie d'une super plate-forme), le conflit est résolu par AS.


Le fait de passer par la recette n'est pas très agile, La version propre de ce schéma est la suivante :

ScruML4.JPG

N'hésitez pas à ajouter d'autres éléments dont vous auriez besoin. Rappelez-vous juste que l'ajout d'un trop grand nombre de nouveaux éléments rendra rapidement le diagramme illisible...