Less is more avec Craig Larman

En préambule d’une formation LESS (j’y reviendrais bientôt), Greg Hutchings nous a permis d’assister à une présentation dans le cadre du Scrum User Group. Une présentation autour de LESS, bien entendu. De mon point de vue, une présentation de Craig Larman, ça vaut toujours le détour: ses talents d’orateur ne sont plus à démontrer et même si vous n’adhérez pas à la totalité de son propos, vous êtes sûr de repartir avec de nouvelles connaissances, des idées et surtout de quoi reflechir !

Pour commencer

Avant même d’aborder le thème même de la présentation et après la traditionnelle histoire drôle qui ouvre toujours ses présentations, Craig campe l’ambiance : je ne suis pas intéressé par vos opinions ! Je ne suis d’ailleurs pas non plus intéressé par MES opinions. Ce qui compte, ce sont les faits. Même les études de cas sont insuffisantes. Ce qui compte, ce sont les études menées de manière scientifiques sont des échantillons statistiquement signifiants et publiés dans des journaux à comités de lecture. Une approche scientifique sur laquelle l’orateur se revendique de Thomas Kuhn.

image

Lire la suite

Note de lecture : Stand Back and Deliver, par Pollyanna Pixton & al.

Note : 7 ; Du modèle de valeur au modèle de leadership.

Pas facile de classer ce livre de prime abord. Finalement, c’est du côté du « Product management » qu’il a le plus sa place. La première chose qui surprend dans ce livre, c’est le titre ! Les auteurs s’en expliquent dans la préface : le point clé du « process », c’est de mettre ensemble les acteurs clés, puis de se tenir en retrait ! La seconde chose qui surprend un peu, c’est la taille de l’ouvrage : seulement 150 pages, qui ne nécessitent guère plus de 7 chapitres.

Le premier chapitre ne compte que 9 pages. C’est une introduction au reste du texte, on y présente dans les grandes lignes les 4 éléments du framework qui feront l’objet des chapitres suivants. Justement le chapitre 2, avec ses 30 pages a trait au premier élément : le « purpose alignment model ». Celui-ci permet de qualifier les éléments d’un portefeuille de projets par rapport aux axes différentiateurs de l’entreprise. Bref, un bel exemple de discrimination par la valeur. Mais surtout un modèle pleinement utilisable tous les jours. Certainement le plus utile du livre !

Le chapitre 3 a trait à la collaboration, c’est l’aspect « stand back » du titre. Ici les auteurs, au long des 25 pages de ce chapitre, nous proposent 3 outils :

Lire la suite

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.

Rendez-vous au Scrumday 2015 !

Le grand rendez-vous de la communauté Agile / Scrum

Que ce soit comme organisateur ou comme orateur, je n’ai encore jamais raté une édition du Scrumday ! Il en sera de même cette année. Mais c’est plutôt aux nouveaux venus que je m’adresserais cette fois-ci avec ma session Scrum Shu Ha Ri. J’avais donné celle-ci une première fois au Printemps Agile à Caen () il y a un an. Je l’ai produite une seconde fois en Anglais à Beyrouth au mois de novembre. Ce sera donc la 3ème fois que je produirais cette présentation. Non seulement ce sera probablement la dernière, mais pour ne pas trop me répéter, je ferais quelques retouches au contenu. Je devrais donc aussi faire évoluer l’article ( en conséquence…

En attendant, voici le teasing de cette session.

Scrum Shu Ha Ri
Passer à l’agilité ce n’est pas “faire de l’agile”, c’est être agile, devenir agile. Ce n’est pas une destination, mais un voyage. Scrum nous accompagne remarquablement sur les trois grandes étapes de ce voyage : le Shu, le Ha et le Ri.
Le Shu est apprentissage : appliquer correctement Scrum.
Le Ha est perfectionnement : Adopter des pratiques pour s’améliorer.
Le Ri est maîtrise : créer sa façon d’être agile en se guidant sur les valeurs de l’agilité.
Pour les nouveaux venus, cette session fera découvrir Scrum sous des jours différents au long des étapes qui constituent ce voyage.

Agile en grand !

C’est avec grand plaisir que je vois la session « Agile en grand » figurer au programme. Il s’agit d’un retour d’expérience sur le passage à l’agile du programme Linky ! Encore un REX allez-vous me dire ? Mais j’ai toutes les raisons de penser que la session que nous proposeront Jean-Hugues Hamelin et Nadim Elbaba sera bien autre chose que « encore un autre REX » !

J’accompagne aujourd’hui encore très activement ERDF sur l’agilification de ce projet sur le site Parisien. Ce sera donc un plaisir tout particulier pour moi d’y assister. Et dès maintenant je vous recommande de l’inscrire à votre programme de la journée.

Ah, une dernière chose !

N’oubliez pas que la seconde journée est consacrée à un open-space. J’ai l’idée d’y poursuivre l’aventure « en finir avec.. » à cete occasion. Mais je ne vais pas en dire plus !

Rendez-vous au Scrumday 2015 !

What is an agile tester ?

Rôle, quel rôle ?

Oui, le tester agile n’a plus la même place qu’avant. Tout d’abord, il n’y a plus d’équipe de test, mais un testeur intégré dans une équipe pluridisciplinaire ! Ce qui signifie aussi par voie de conséquence qu’il n’y a plus de phase de test. En fait, pour aller plus loin, il n’y a plus non plus de rôle de testeur !

La qualité est désormais l’affaire de tous, on passe de la notion d’assurance qualité à celle d’assistance qualité. C’est pourquoi ce n’est plus le rôle de testeur qui primer mais la compétence qu’il véhicule et injecte dans l’équipe. Kniberg nous débarque le concept de « T shape compétences », que personnellement je n’aime pas trop.

S’assurer que le produit marche

L’assistance qualité, dans une équipe agile recouvre un certain nombre d’activité que l’auteur nous énumère. Mais surtout, le testeur agile doit travailler en interaction avec les développeurs et les utilisateurs afin de toujours raccourcir la boucle de feedback, une idée qui s’inscrit bien dans la philosophie du « continuous delivery ».

Lire la suite

Parlons outils pour Kanban !

Eh oui, malgré que le manifeste nous assène que « les hommes sont plus importants que les outils », cela ne nous empêche pas de faire le plein à une soirée exclusivement consacrée aux outils ! D’ailleurs j’en étais, mais je suis arrivé un peu en retard… Essayons de rattraper celui-ci !

Thomas Declercq, ou comment étendre TFS

Thomas est manager chez AXA, à Lille plus exactement. Ici, on utilise les outils Microsoft, donc TFS pour faire du développement en .NET ; rien que de très logique. Les grands comptes sont rarement sur les dernières versions des outils, on vient donc tout juste de passer de TFS 2010 à TFS 2013. Et l’outil montre ses limites pour suivre des métriques. Alors si l’on a pu fort logiquement commencer avec des exports de données puis du bricolage sous Excel, l’équipe a fini par se lasser de ce travail et a envisagé des outils se branchant sur les API de TFS. On parle ici de 3 outils internes.

Outil #1 : Le Kanban board

Il n’est pas beau, il a été développé entre la poire et le fromage, car l’équipe en avait besoin mais personne ne voulait payer pour … et il est très utilisé ! Ils en avaient besoin, car la solution initiale, c’était des extracts CSV de TFS injectés ensuite dans Excel. Un travail à la longue très fastidieux.

Lire la suite

Note de lecture : Use Cases : Requirements in Context, par Daryl Kulak & Eamonn Guiney

Note : 6 ; Bonne mise en pratique du cycle itératif et de bonnes idées, mais pas entièrement concluant.

Ce livre présente les cas d’utilisation dans le cadre d’un processus itératif, en fait celui d’Unfied Process. A ce titre, il propose une approche incrémentale pour la spécification des cas d’utilisation, basée sur celle de Craig Larman. Cet ouvrage taille aussi un short à la gestion des exigences, par rapport auxquels les auteurs préfèrent la spécification des règles métier, même si en fait c’est surtout la production de gros documents de spécification monoblocs qui est remise en cause. La description des spécifications incrémentale est réellement valable et concrète, et de plus desservie par des exemples concrets en annexe.

La construction du livre est un peu curieuse, car les annexes forment la moitié de l’ouvrage, le texte principal ne comptant que 170 pages structurées en 11 chapitres. Le premier d’entre-eux consacre ses 18 pages à l’identification des problèmes liés à l’approche classique. La prose manque un peu d’élan lyrique, mais s’efforce néanmoins de bien synthétiser ces points d’achoppement. Disons que le boulot est fait.

Le second chapitre s’étend sur 32 pages, il s’agit d’une introduction aux cas d’utilisation d’inspiration très « Gery Schneider ». On y aborde plutôt efficacement les basiques de la représentation des cas d’utilisation et les bonnes règles de conduite. Plus globalement on y traite aussi des cas d’utilisation dans l’environnement UML. Un chapitre rondement mené.

Lire la suite