Scrum - Méthodes agiles

Non, Jef t'es pas tout seul

Lire la suite -->

Et pas seulement parce que j'en fais partie !

Lire la suite -->

Les équipes agiles sont plus efficaces avec des généralistes ou des spécialistes qui se généralisent

Lire la suite -->

Mais j'hallucine pas

Lire la suite -->

Darkness

Lire la suite -->

Par mes amis canadiens de la Communauté agile de Québec, je viens de consulter la présentation de Grigori Melnik, de Microsoft. Sa présentation s'appelle Empirical Evidence of Agile Methods. Elle est bizarrement sous-titrée ce que nous savons, ce que nous pensons savoir et ce que nous voulons savoir, car ce sont les seuls mots en français.

Pour ceux qui cherchent à avoir des chiffres qui prouvent que les méthodes agiles sont largement diffusées et qu'elles apportent des résultats, sa présentation est une mine d'informations. Il a compilé les différentes études disponibles sur le sujet.

A noter qu'il repose encore la lancinante question : Have Agile Methods Crossed the Chasm Yet? alors que je pensais que c'était fait il y a 2 ans et confirmé l'année dernière.

Ajout du 19 mai : Finalement j'apprends qu'il n'y a pas de chasm, ça règle ce (lancinant) problème

Emmanuel Chenu a publié des illustrations sur les principales pratiques de Scrum et de l'Agilité. Les dessins sont en anglais et les commentaires qui les accompagnent sont en français.
C'est sympa, mais pourquoi sont-ils tous chauves ? Dans un genre différent, j'utilise maintenant les icônes de IceScrum pour illustrer les rôles Scrum dans mes formations et mes présentations :

Vous avez reconnu les différents rôles ?

Pour apprendre Scrum, la façon la plus efficace est probablement de suivre une formation^[1] et d'appliquer aussitôt. D'autres choisiront l'apprentissage individuel avec les quelques livres et les nombreux articles disponibles sur Internet. Les livres imposent une approche séquentielle et les articles ne forment pas un tout cohérent, ce qui n'est pas l'idéal pour accéder à un processus, même simple comme Scrum.

La présentation d'un processus sous forme de site Web est une bonne solution pour pallier ces inconvénients. Le plugin Scrum que j'ai réalisé avec EPF Composer en est un exemple. Le résultat est visible ici. La structure relativement complexe est due aux choix faits dans EPF et au méta-modèle sous-jacent (Software Process Engineering Metamodel).

Dans la même veine, Mishkin Berteig annonce la sortie de Scrum Study Guide. Il le vend 500$ ! J'ai regardé la version de démo, gratuite.

J'ai tout de suite identifié l'outil avec lequel il l'a fabriqué : c'est Tiddlywiki. Il s'agit d'un wiki personnel que j'utilise quotidiennement depuis 2 ans^[2]. L'intérêt de TiddlyWiki est sa légèreté -tout est dans un seul fichier html- et la simplicité du wiki. La structure dépend des choix de l'auteur pour créer les pages wiki, ça peut vite devenir difficile de s'y retrouver.

Tiens, ça pourrait être un exercice amusant de porter ce que j'ai écrit dans le plugin Scrum EPF sur un TiddlyWiki. Et après, je le vends ?

Trouvé via le blog de Karl, un article publié dans le très sérieux magazine IEEE Software qui fait l'hypothèse d'une équivalence entre les tests et les exigences. L'article Tests and Requirements, Requirements and Tests: A Möbius strip, est signé de Grigori Melnik et de Robert C. Martin, le célèbre Uncle Bob.

La référence au ruban de Möbius illustre comment les 2 disciplines (exigences et tests) en deviennent une seule lorsque le formalisme augmente.

Dans l'article, les exemples sont en FIT qui propose une représentation tabulaire des tests exigences. FIT est bien adapté aux tests sur les données ^[1].

Je suis convaincu de cette hypothèse d'équivalence. L'écriture de tests d'acceptation est une technique de spécification, d'autant plus pertinente que les tests sont associés à des histoires d'utilisateur. Je l'applique maintenant sur tous les projets auxquels je participe, mais en utilisant le formalisme BDD plutôt que FIT. J'en ai déjà parlé ici et là.

Par Infoq, je viens de lire un article Well Formed Teams and Agile: An Opportunity to Thrive qui définit 3+2 attracteurs pour penser efficacement et constituer des équipes hyper-productives, comme dit Jeff Sutherland.

Etre guidé par le produit, travailler sur une chose à la fois en cycles courts (timeboxed) et garder le travail visible, ça fait partie de la base de Scrum. Le +2 est également favorisé par Scrum qui offre des canaux (la structure) pour favoriser les conversations.

L'article donne ensuite les caractéristiques communes des équipes qui sont considérées comme bien formées. La première est que l'équipe soit regroupée géographiquement dans un seul endroit (colocation). Je confirme absolument. Dans toutes les expériences récentes de mises en oeuvre de Scrum auxquelles j'ai participé ou qui me sont racontées, les difficultés les plus importantes sont venues d'équipes distribuées entre plusieurs locaux. Evidemment les problèmes sont décuplés si la distribution se fait sur plusieurs pays dans des continents différents, avec des horaires différents et des cultures différentes.

Ces organisations avec des équipes distribuées cherchent des palliatifs pour appliquer Scrum quand même, plutôt que de remettre en question la répartition des membres de l'équipe. Dommage que ce ne soit pas ceux qui connaissent Scrum qui décident...

Que faire des bugs relatifs à une user story et découverts dans un sprint postérieur à la réalisation de cette story ?

Lire la suite -->

Sex Pistols Driven Agile Development ?

Lire la suite -->