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.

Continuer à lire « Quand les users stories deviennent techniques… »

Note de lecture : Convergent Architecture, par Richard Hubert

Note: 1 ; Pas convaincant et ennuyeux!

Mais pourquoi donc ai-je acheté ce bouquin? Tout simplement parce que l’excellent « enterprise patterns and MDA » y fait référence. Mais force est de constater que c’est l’échec complet. Voyons donc comment les 260 pages et les 8 chapitres de cet ouvrage pourtant estampillé « OMG press » ont pu nous amener là.

Le chapitre 1 « IT Architectural style » couvre 30 pages. Il s’agit, du moins pour les 15 premières pages d’une discussion philosophique sur la nature d’une architecture, son caractère évolutif, ses niveaux d’expression et l’équilibre entre innovation et couverture du risque. Rien de bien concret. Je ne me retrouve guère non plus dans les 4 propriétés énoncées concernant cette architecture, sujet des 15 pages suivantes :

  • Le métamodèle architectural, bref la nécessité de suivre un style prédéfinit.
  • Le cycle de vie du développement du modèle.
  • Une suite d’outils complète.
  • Une « projection technologique » formalisée.

On va même jusqu’à évoquer le template IEEE 1471-2000 pour documenter cette architecture. Bref, un chapitre qui n’a guère de sens pour moi.

Continuer à lire « Note de lecture : Convergent Architecture, par Richard Hubert »

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 !

Une transition agile en 12 leçons apprises

J’avais évoqué il y a peu le Printemps Agile 2015. J’y ai présenté un retour d’expérience sur le projet Linky en 12 « patterns » pratiques pour accompagner cette transition. Voici le support de ma présentation, en attendant la mise en ligne de la vidéo et une hypothétique version rédigée.

Linky, c’est le grand projet ERDF de mise en place du « compteur intelligent ». Une grande aventure qui a amené le plateau de développement Parisien (12 équipes de développement) à basculer vers un fonctionnement agile. Cette présentation ne raconte pas l’histoire du projet : Jean-Hugues Hamelin et Nadim Elbaba qui la vive de l’intérieur depuis un bout de temps l’ont raconté avec plus de pertinence et d’intérêt que je n’aurais pu le faire lors du ScrumDay 2015. Non, ici c’est de mon point de vue de coach accompagnant ces équipes que je parle.

Note de lecture : Making Sense of NoSQL, par Dan McCreary & Ann Kelly

Note 4 ; NoSQL plus ou moins décrypté pour le manager

Voici un ouvrage « à priori » destiné aux managers. En tout cas son objectif est de donner une image du paysage NoSQL sans nécessité de voir une ligne de code. Dans le principe, le livre atteint son objectif : il couvre les différents types de bases NoSQL, avec toutefois un biais marqué vers les bases XML (qui ne sont généralement pas considérées comme des bases NoSQL), ces dernières ayant droit à leur propre chapitre contrairement aux autres ! Mais le texte me laisse quand même un sentiment d’inachevé, il ne permet pas vraiment de comprendre les patterns d’usage des différentes bases par manque de parti pris.

L’ouvrage est assez conséquent pour une introduction. Il compte 275 pages réparties sur 12 chapitres. Ceux-ci sont eux-mêmes regroupés en 4 parties. La première d’entre-elle est une introduction, courte d’un peu plus de 30 pages et de deux chapitres. Le premier répond au « pourquoi » en exposant succinctement quelques cas d’études des grands du Web, c’est hélas très superficiel. Le second s’attaque aux concepts : documents, sharding, théorème de CAP, cache, etc… C’est un peu brouillon et j’aurais préféré y voir une bonne exposition des typologies de bases.

Continuer à lire « Note de lecture : Making Sense of NoSQL, par Dan McCreary & Ann Kelly »

Water – Scrum – Fall … la réalité d’aujourd’hui ?

Le constat

Oui, l’agilité gagne en popularité dans les organisations ! Du moins, apparemment. Les idées qui en sont à la base comme le « people centric » génèrent un réel intérêt. Aujourd’hui plus encore qu’hier, « agile » rime avec « Scrum ». Cet article met en exergue ce qui était déjà un soupçon fort, ce que j’appelle le Scrum « Canada Dry » dans mon article Scrum Shu Ha Ri :

  • La MOA rebaptisée « Product Owner ».
  • L’organisation matricielle, avec les développeurs devant partager leur temps sur plusieurs projets (je l’avait raté celle-ci)
  • Des itérations qui ne couvrent que partiellement le cycle logiciel
  • La « culture projet » où les équipes se font et se défont régulièrement au grée des projets.

Les organisations elle-même créent un carcan dans lequel inscrire un projet agile devient compliqué, à moins d’en pervertir la logique : logique budgétaire, silotage des activités, prédominance de la « logique document » et des releases parcimonieuses pour d’apparentes raisons économiques et culturelles.

Pourquoi ?

Ce constat met en relief un aspect quasi schizophrénique de l’adoption de l’agilité (d’où le titre de l’article). Celui-ci s’explique du fait de l’adoption des processus agiles par les praticiens qui tend à cloisonner l’agilité dans les équipes de développement, les équipes connexes restant attachées à leurs anciens processus. La réalité du « water-scrum-fall » se traduit par :

Continuer à lire « Water – Scrum – Fall … la réalité d’aujourd’hui ? »