Scrum Guide 2016

En mettant un peu d’ordre dans mes anciens posts, je me suis aperçu que j’avais bien mis en ligne et commenté la version 2013 du Scrum Guide, mais que je n’avais pas dit un mot de la version 2016. Il faut dire que cela fait un bon moment que je n’ai plus publié autre chose que des notes de lecture…

Les valeurs de Scrum

La version 2016 compte 1 page supplémentaire. On arrive assez vite à la section qui a été rajoutée: les valeurs de Scrum ! Les 5 valeurs d’ailleurs évoquées depuis longtemps prennent enfin place dans le guide officiel, signe que Scrum se focalise de plus en place sur son essence et moins sur le folklore.

Et quoi d’autre ?

En fait, la surprise est que pour le reste, le texte reste mot pour mot celui de l’édition 2013 ! Il faut un peu chercher pour comprendre la réelle nouveauté de cette édition : le copyright figurant au bas de chaque page ! Certes, c’est un « creative commons », mais quand même…
Je pense que les auteurs auraient pu faire un peu plus d’effort que cela…

Publicité

Agile France 2017 j’y serais et vous ?

Absent du chalet de la porte jaune l’an dernier, je serais là de nouveau mi-juin pour une session que je présenterais conjointement avec deux collègues : la spécification par l’exemple, par l’exemple !

Nous avons voulu cette session originale : ce sera donc plutôt une représentation qu’une présentation. C’est aussi pour cela que nous serons trois !
En attendant de nous rencontrer le 15 Juin, voici le teaser de cette session.

Le teaser

Le BDD, maintenant tout le monde connait. Comme l’a popularisé Gojko Adzik avec le « workshop des 3 amis », l’élément clé est la co-écriture d’exemples qui fait de cette activité tout autant un travail de spécification que d’écriture de tests.
Mais comment se déroule cet atelier ? Comment procéder ? Quelle stratégie adopter pour rendre cet atelier le plus efficace ?

L’approche que nous allons vous proposer permet de structurer les conversations de ce workshop en suivant 3 étapes s’enchainant logiquement.

Plutôt qu’une présentation, il s’agit d’une représentation du workshop. Chaque séquence étant brièvement commentée pour souligner les enseignements.

Destinée en premier lieu aux Product Owners et aux testeurs ayant si possible une connaissance de base des tests d’acceptation, cette session vous donnera une idée claire sur la manière d’animer le workshop des 3 amis pour maximiser la qualité des interactions et obtenir des cas de test de qualité.

Lire la suite

De retour aux affaires…

Lecteur fidèle et émérite, tu t’en ai certainement aperçu: il y a eu un grand vide dans les publications sur mon blog. Quelques explications s’imposent…

Depuis 2011 j’utilise Tumblr comme plateforme de blog. Ca va vraiment très vite pour mettre en oeuvre son blog. On peut aussi personnaliser un peu ce que l’on a, mais la personnalisation est assez limitée, il n’y a pas non plus de « plugins ». Bref, quand on veut améliorer un peu le truc, on arrive vite à devoir insérer des choses dans le HTML du thème. Ce que j’ai fait.

Hélas, ce n’est pas tout.

L’enfer de l’édition

Tumblr, c’est un truc de jeunes. Tu insert des images, des vidéo, des citations, etc… Le tout très simplement, en quantité et dans le cadre défini par Tumblr. Pour en sortir, retour au HTML (dans le post, cette fois). C’est ce que j’ai fait pour insérer des présentations Slideshare, des documents stockés dans Issuu et des images en provenance de Flickr. Hélas au fil du temps et des nouvelles releases de Tumblr, cela est devenu plus difficile et mes intégrations se sont même trouvées « cassées ». Sans parler des éditions HTML qui supprimaient mes ajouts (ça c’était sur la fin).

Bref, j’ai vu que la plateforme n’évoluait pas dans un sens qui m’était favorable, il était temps de faire mes valises.

Je n’ai pas été très créatif en ce qui concerne ma destination : WordPress, le super standard des blogs. Le setup est peut-être moins direct qu’avec Tumblr, mais on arrive à ce que l’on veut en une paire d’heures. Plus ou moins. Last but non least, un import Tumblr ! Lui aussi marche très correctement dans les grandes lignes.

Franchir le dernier mètre

Tout aurait été très simple sans le nom de domaine. Le transfert de celui-ci a été quelque peu compliqué avec mon fournisseur. Ca a pris du temps, probablement aussi parce que j’ai manqué de pugnacité sur ce coup.

Petit effet de bord de ce long délai: j’ai perdu mon élan !

Lire la suite

En finir avec le stand-up ?

Le stand-up, ou scrum meeting, quelque soit le nom que vous lui donniez, est un élément prépondérant du framework Scrum (et d’autres approches agiles également). C’est lui qui permet de maintenir le cap de l’itération et de s’assurer que tout reste dans les clous de ce qui a été prévu en début de Sprint et de faire des choix ou des actions correctrices le cas échéant.

Vous connaissez sans doute le principe : à heure fixe chaque jour, les membres de l’équipe se rassemblent, souvent devant leur Scrum Board. C’est un rendez-vous court d’une dizaine de minutes (c’est pourquoi tout le monde reste debout) et chacun répond à 3 questions :

  • Qu’ai-je fait hier ?
  • Qu’ai-je l’intention de faire aujord’hui ?
  • Quelle problème ai-je rencontré ?

Tout est dans l’efficacité. Qu’est-ce qui pourrait mal tourner ?

Lire la suite

En finir avec les User Stories ?

Aujourd’hui je vous propose d’investiguer l’un des outils les plus emblématiques des approches agile : la User Story. Par son « focus » et la légèreté de son expression elle symbolise une part importante de ce que nous voulons faire en agile.

Créées avec l’Extreme Programming, elles ont été adoptées largement par la communauté Scrum (Scrum n’évoque qu’une notion plus générique de « product backlog item » ou PBI). Ces User Stories peuvent-elles nuire aux projets agiles ? En quoi leur usage peut-il être néfaste ?

3 mots sur un bout de carton !

…Ou sur un post-it, pour rester dans la tradition agile. Voilà qui nous change des documents de spécification tellement épuisants à compléter ! Sans compter que ces derniers sont vraiment ennuyeux : traquer la précision, chasser l’ambiguité, devoir tout justifier… Un vrai travail de romain !

Lire la suite

Quand les users stories deviennent techniques…

Je ne suis pas un intégriste de la User Story. Il ne m’importe pas tellement qu’elles suivent le fameux template de Mike Cohn « en tant que… je veux… afin de… ». Même si ce template n’a rien de mauvais et peut guider vers l’écriture de meilleurs histoires, c’est aussi un bon moyen de devenir un « template zombie ». Je préfère les 3 questions de Jeff Patton : Qui ? Quoi ? Pourquoi ?

image

En fait, peu m’importe que vous parliez de User Story, d’item de backlog ou d’un autre terme inventé de toute pièce. Ce qui va m’importer, c’est que votre story ait un sens d’un point de vue externe au système que l’on construit. C’est là qu’intervient le « qui », un acteur externe aus système. Ce n’est pas par dogmatisme que j’y suis sensible, mais au contraire par pragmatisme. Une petite explication s’impose.

Lire la suite

SysML, l’UML de l’analyse système

Voici un court papier écrit en 2005. Les reflexions qu’il soulève restent pertinentes. Je me suis bien éloigné de ces considérations depuis une dizaine d’années. Si les efforts pour structurer les exigences paraissent louables, je ne peux m’empêcher de les trouver vains. Ou tout au moins aurait-il falu les compléter par une structuration des tests (via des stéréotypes ?) à différents niveaux…

Je ferais certainement l’effort d’une note de lecture sur l’ouvrage de Pascal Roques un de ces jours. En attendant : enjoy !

Des applications et des patches

Le saviez-vous ?

Tout comme les bugs font référence aux insectes envahissant les premiers ordinateurs, occasionnant des erreurs, le mot « patch » fait référence à l’origine à des éléments bel et bien physiques. Il s’agit en l’occurence de pièces de papiers apposées sur les rubans perforés du Mark I, qui fut en service durant la première moitié des années 40 ! Conçu par Howard Aiken et construit par IBM, Grace Hopper en fut le premier programmeur.

Taylorisme et travailleurs du savoir

Durant les formations, je me retrouve souvent en situation de devoir expliquer pourquoi (et en quoi) l’agilité est différente des processus classiques, mais pas seulement. Bien sûr on pense au bon vieux « cycle en V », la tarte à la crème des processus non-agiles, mais nous pouvons aussi évoquer les processus itératifs tels qu’Unified Process !

Unified Process est un cas intéressant, voir embarrassant. Certains le classent dans la limite basse des méthodes agiles [4] (après tout, on est loin du cycle en V), d’autres considèrent qu’il ne s’agit définitivement pas d’une approche agile. C’est mon cas. Je trouve par ailleurs intéressant de voir que Ken Schwaber lors de sa première présentation de Scrum en 1995 classait déjà ces approches (pourtant plutôt novatrices à l’époque) en dehors de ce que l’on appelait pas encore les « approches agiles » [1] !

Pour débuter notre reflexion, je vous propose de nous intéresser au modèle Cynefin.

Le modèle Cynefin

Le modèle Cynefin permet de classifier la complexité des contextes en fonction de la nature des relations de causalité entre problème et solution. Je simplifie un peu, pourtant cela doit sembler obscure. Ne vous en faites pas, cela deviendra plus clair lorsque nous expliquerons le modèle. Le voici.

image

Lire la suite

En Finir avec le Planning meeting ?

Je vous avais laissé sur la remise en cause des estimations. Natrellement, le sujet suivant ce dvait être le planning meeting. Nous allons nous y attaquer aujourd’hui !

Autopsie du planning meeting

Le planning meeting de Scrum, c’est une composante importante de la démarche, du moins dans le Scrum Su (). De là découle tout ce qui sera fait durant le sprint. Aussi intéressons-nous à ce qui le constitue.
Tel que décrit initialement, le planing meeting comporte 2 parties, c’est donc en fait 2 meetings en un seul [1] :

  • Une présentation des fonctionnalités souhaitées pour le prochain sprint
  • Une planification de l’execution de ces fonctionnalités pour la durée du sprint

Les textes ultérieurs ont ajouté un peu de détail, comme la présentation de l’objectif de sprint et la détermination de la capacité de travail [2]

image

Lire la suite