ScruML

[((/dotclear/public/photos/.HenrikKniberg_t.jpg|Henrik Kniberg|L|Henrik Kniberg))|/dotclear/public/photos/HenrikKniberg.jpg]Je vous ai traduit un billet intéressant écrit par Henrik Kniberg le 25 août 2007 sur son blog : ++[ScruML|http://blog.crisp.se/henrikkniberg/2007/08/25/1187995980000.html|en]++.%%% %%% Cet article permet de mieux comprendre l’évolution du modèle d’organisation Scrum décrit par Henrik dans un de ces autres articles que j’ai déjà traduit : ++[« Rôle des Managers En Scrum »|http://www.fabrice-aimetti.fr/dotclear/index.php?post/2009/06/01/Managers-Role-In-Scrum|fr]++. %%% > Le monde n’a-t-il pas besoin d’un autre langage de modélisation ? :)%%% > %%% > __ScruML__ signifie « __Scru__m __M__odelling __L__anguage ». 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 de terminé ? 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)%%% > %%% > ((/dotclear/public/traductions/ScruML1.jpg|Une seule équipe (ou Hello World)||Une seule équipe (ou Hello World)))%%% > %%% > Ce diagramme montre les choses suivantes :%%% > – Nous avons une équipe composée de 5 membres, avec ++[Reza Farhang|http://www.crisp.se/reza.farhang|en]++ (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 de terminé est « livré à l’utilisateur final ».%%% > – La longueur d’un sprint est de 2 semaines (~2weeks).%%% > %%% > %%% > __Exemple 2 : Plusieurs équipes__%%% > %%% > ((/dotclear/public/traductions/ScruML2.JPG|Plusieurs équipes||Plusieurs équipes))%%% > %%% > Ce diagramme montre les choses suivantes :%%% > %%% > – Nous avons deux équipes qui travaillent sur le même product backlog.%%% > – La définition de fait 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ée), 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__%%% > %%% > ((/dotclear/public/traductions/ScruML3.JPG|Plusieurs équipes & plusieurs product owners||Plusieurs équipes & plusieurs product owners))%%% > %%% > 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és par le product backlog de JM, et font toutes les deux des sprints de 3 semaines.%%% > – – > Leur définition de terminé 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 de terminé 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 :%%% > %%% > ((/dotclear/public/traductions/ScruML4.JPG|Utilisateurs finaux||Utilisateurs finaux))%%% > %%% > 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…%%%

3 réflexions au sujet de « ScruML »

  1. Michael BordeC’est suffisamment simple pour me plaire. Il est possible en un coup d’œil d’avoir une vue d’ensemble de l’organisation des développements. J’essaie de me faire une opinion sur le genre de configurations évoqué par le dernier schéma. Le côté rationnel rassure mon esprit cartésien par contre dans les faits cela fonctionne t-il réellement ? Je n’ai trouvé que bien peu de retours d’expérience sur le sujet. Agile Project Management With Scrum survole trop le sujet et me laisse vraiment sur ma faim.

  2. En premier lieu un grand merci pour ce blog, je vais être un peu hors sujet par rapport à l’article mais je cherche actuellement une solution pour stabiliser la vélocité de l’équipe dans laquelle j’officie.

    La vélocité sur les 5 premiers sprints :
    Sprint 1 : 31, Sprint 2 : 31, Sprint 3 : 23, Sprint 4 : 51, Sprint 5 : 16
    Pourquoi ?
    Prenons l’exemple du sprint 3 dans lequel une user story de 13 point a été commencé et non terminée. Au premier jour du sprint 4 on termine cette user story et donc 13 points sont comptabilisé dans le sprint 4 et 0 dans le sprint 3. Cette situation se reproduit au sprint 5 et 6, au premier jour du sprint 6 on cloture 16 points qui aurait pu être attribué au sprint 5).

    La première tentative pour résoudre ce problème avait été de limiter les user stories à 8 points, en plus cela permettait une meilleure estimation mais comme on le voit aux sprint 5 et 6 cela ne résoud pas le problème.

    Je vais désormais comptabiliser les story point des tâches (dont la valeur est de 2 maximum) terminées (une tâche étant une partie d’une user story) pour dessiner le burndown de sprint et non plus attendre que la user story soit terminée. Cependant cela semble considéré comme une moins bonne pratique Scrum (je pense notamment à la carte heuristique « Checklist Scrum » que l’on trouve sur ce blog et qui précise que le calcul de la vélocité « n’inclut que le calcul des stories ayant atteint l’état Fini »).

    Et vous comment faites vous ?

    En vous remerciant de vos réponses.
    Lume

  3. Merci pour votre réponse.
    Une lume est une lumière douce, les derniers rayons oranges d’un soleil automnale couchant pour prendre un exemple de saison. Mais pour tout dire c’est un pur néologisme personnel que je réutilise à chaque besoin de pseudo.

    Notre équipe n’est vraiment pas expérimentée en Scrum (5 sprints de 2 semaines chacun en tout et pour tout) et pour l’instant j’attendais de connaitre notre vélocité avant de dire au product owner « nous nous engageons sur la livraison de ces user stories car ils cumulent 30 story points que nous savons pouvoir produire en deux semaines ». Pour l’instant le backlog de sprint contient +-50 point de user story et on faisait ce que l’on pouvait en attendant d’établir notre vélocité.
    A la lumière de votre remarque je m’aperçois que nous sommes donc en train de prendre la mauvaise habitude de ne pas considérer le backlog sprint comme un contrat avec le product owner mais comme une todo list dans laquelle on pioche le travail quotidien. Le backlog produit n’est pas vide à la fin ? C’est la faute du scrum master (ma pomme en l’occurrence) qui en a trop mis.
    Par ailleurs, avec le Product Owner, nous mettons dans le backlog produit les spikes, bugs en sus des user story mais de nombreuses activités qui n’ajoutent aucune valeur au client nous perturbent en permanence (la base de recette est à réinstaller, les maquettes du service créa sont en retards, le service WebTracking de l’équipe SOA est bugué, etc.). C’est le cas pour toute les équipes et je ne me vois pas révolutionner le service informatique en entier donc on va faire avec, scrum m’a déjà permis d’améliorer considérablement ma visibilité sur ce projet et du coup de me concentrer sur des points importants.

    En conclusion je vais établir une vélocité moyenne qui sera notre vélocité de base et je vais tenter de redresser la barre à partir du sprint suivant pour que l’on considère le backlog de sprint comme un engagement plutôt que de partir dans mes errements.

    Merci de votre réponse et bon courage à tous les agilistes.
    Bon je vais de ce pas poser ma super question sur les rétrospectives de sprint à Claude Aubry :p

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *