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 !

Continuer à lire « En finir avec les User Stories ? »

Note de lecture : Conception orientée objet, par Peter Coad & Edward Yourdon

Note 3 ; Les principes embryonnaires de la conception objet

Il y a « l’avant » Design Patterns, et « l’après ». Cet ouvrage est dans la catégorie « avant ». Il fait aussi suit à « l’Analyse orientée objet » des mêmes auteurs. Et son âge respectable le classe parmi les livres qui ont servi de fondation à l’orienté objet. Bien sûr, depuis on a construit pas mal d’étages, et seul les férus d’histoire informatique auront à cœur de se replonger dans ces textes !

Le problème avec « l’avant » Design Patterns, c’est que l’on parle bien d’analyse et de conception (ici séparés en 2 livres) et que l’on prétend faire la différence clairement, mais en fait ce n’est pas le cas ! Au long des 160 pages du texte principal, les auteurs peinent à exposer des aspects clairement différents entre l’analyse et la conception. Voyons cela.

En plus du texte principal découpé en 10 chapitres, l’ouvrage  compte 24 pages d’annexes, elles-mêmes séparées en 3. Passé la quinzaine de pages d’avant-propos, ce sont les 10 pages du premier chapitre « améliorer la conception » qui ouvrent le bal. Bien que cela ne soit pas avoué ouvertement, la conception y est présenté comme quelque chose d’ajoutée « après coup » pour améliorer la qualité et la maintenance ! On y évoque aussi les principes d’encapsulation et l’organisation fonctionnelle.

Continuer à lire « Note de lecture : Conception orientée objet, par Peter Coad & Edward Yourdon »

ScrumDay 2015 : Reinventing organizations, avec M. Sahota et O. Lewitz

Cette session, co-animée par Olaf Lewitz et Michael Sahota se voulait un workshop. Moins workshop que je ne m’y attendais toutefois, cat on était plutôt dans le 80% « lecture » et le 20% « workshop »… dans le meilleurs des cas !

Qu’importe, il me tardait de participer à une session menée par deux personnes qui je suis par leurs publications depuis quelque temps. Ici toutefois, la session ne s’articulait pas autour des écrits de l’un des deux conférenciers, mais autour du texte de Frédéric Laloux : Reinventing Organizations.

image

Continuer à lire « ScrumDay 2015 : Reinventing organizations, avec M. Sahota et O. Lewitz »

Note de lecture : Service Design Patterns, par Robert Daigneau

Note : 5 ; Des patterns qui sont plutôt des exemples d’implémentation…

Ce texte, ce devrait être en principe le complément des Enterprise Integration Patterns de Gregor Hope. Dans la pratique, il n’est pas à la hauteur de son ainé, même s’il nous permet d’apprendre certaines choses sur les web services, qu’ils soient SOAP ou REST.

En pratique, ce texte de 270 pages est découpé en 7 chapitres. Il faut aussi compter les annexes qui ajoutent une trentaine de pages de glossaire et référence de patterns. Les 10 pages du premier chapitre servant d’introduction ne nous apprennent pas grand chose, passons ! Le second chapitre est plus conséquent, en nombre de pages d’abord car on en compte 40, mais surtout par le contenu. C’est de « style de web services » dont il est question, de 3 styles plus précisément : RPC, orienté messages et orienté ressources. Ce chapitre focalise sur les considérations d’architecture liées à ces 3 styles, c’est donc en fait la véritable introduction au reste du livre ! En tout cas, le contenu est digne de Martin Fowler.

Continuer à lire « Note de lecture : Service Design Patterns, par Robert Daigneau »

12 leçons (durement) apprises de transition agile : le live !

Ça a marché pour moi, mais je ne pas garantir que cela marchera pour vous … peut-être la 13ème leçon à garder en mémoire en visionnant mon intervention lors du Printemps Agile 2015.

J’avais posté ici-même le support de présentation il y a peu. Si vous acceptez d’en prendre pour 50 minutes, le propos vous éclairera encore d’avantage. Si j’ai le courage, je convertirais même le tout en article comme je l’ai fait pour la plupart de mes présentations. Mais il faudra être patient.

Si l’éclairage est loin d’être parfait, c’est difficile à nier (et difficile à gérer avec une projection), le CEMU a fait un remarquable travail de montage avec le support. C’est une excellente surprise, qui va bien plus loin qu’une simple synchronisation. Merci et bravo à eux.

Note de lecture : Growing Object-Oriented Software Guided by Tests, par Steve Freeman & Nat Pryce

Note : 8 ; Craftmanship en grandeur réelle

Quand on évoque le craftmanship, on montre des exemples de code, sinon cela n’a pas de sens ! Généralement, il s’agit de 2 ou 3 classes qui se battent en duel que l’on refactore afin d’améliorer les abstractions, éviter les duplications de code et tout et tout… Ce livre-là est différent, car il va faire du design émergent en TDD une réalité en l’appliquant sur la construction d’un logiciel complet, le tout suivi pas à pas ! Pour mener à bien sa mission, le texte compte un peu moins de 330 pages hors annexes, le tout découper en 5 parties très inégales. Je ne vais pas vous compter par le menu les 27 chapitres de l’ouvrage, mais plutôt les 5 parties.

La première partie est introductive (comme on peut s’en douter). Elle ne compte que 3 chapitres sur 25 pages. Il s’agit avant tout de considérations générales, mais non dénuées d’intérêt. On y évoque des principes nouveaux ou anciens comme le cycle ATDD imbriqué dans le cycle TDD, les cartes CRC ou le « tell, don’t ask ».

Continuer à lire « Note de lecture : Growing Object-Oriented Software Guided by Tests, par Steve Freeman & Nat Pryce »

How do you know that your product works ?

Ai-je vraiment « terminé » ?

C’est sur cette notion sur laquelle Kniberg nous invite à nous pencher en premier. Quand est-on « done » ?

  • Quand le code est commité ?
  • Quand le produit est testé ?
  • Quand il est déployé en production ?

Dans ce cheminement, c’est l’utilisateur qui est perdu de vue. Même le déploiement en production ne suffit pas, ni même son utilisation par de véritables utilisateurs ? Car à ce niveau qu’est-il vraiment advenu ? Comment le savons-nous ? Le 0% defect peut-être plus qu’une douce illusion : un manque de feedback ! Ce qu’il nous faut, c’est mesurer la pertinence de notre solution.

Où l’on reparle de valeur

La valeur de la solution que nous fournissons à nos utilisateurs n’est pas une mesure absolue, mais la différence par rapport à l’ancienne solution. La valeur n’est d’ailleurs pas la seule valeur, la souffrance soulagée en est une tout assi pertinente. Et Kniberg nous propose de rapprocher ce niveau de souffrance au niveau de gain : est-il positif ? C’est l’ensemble du tableau qu’il faut regarder.

Pour le prouver, nous avons aussi besoin de mesures. Par exemple, les recommandations, qui montrent que le produit est désirable et non que l’on est coincé avec.

Continuer à lire « How do you know that your product works ? »