La véritable autonomie, c’est l’auto-organisation.
Jean-François Zobrist
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 ? »
Dave Snowden au Scrumday 2015 : Making Sense through Action
Faire une bonne transcription de la keynote de l’auteur du modèle Cynefin n’est pas chose facile. Je ne pense pas y parvenir. Son accent n’est pas évident, pour commencer. Ensuite, suivre son propos s’est souvent avéré pour moi difficile. Je vais donc plutôt passer en mode « morceaux choisis ».
Adopter l’approche scientifique
Dave Snowden nous met en garde contre l’approche par l’exemple: on ne saurait proclamer une réussite basée sur un nombre limité de succès. En fait, la théorie s’avère alors un meilleur fondement que la technique.
Des entreprises montrent des succès spectaculaires en faisant des choses différentes, mais il est illusoire de chercher à les copier
Continuer à lire « Dave Snowden au Scrumday 2015 : Making Sense through Action »
Rendez-vous à l’Agile Vendée !
C’est toujours un grand plaisir d’assister à la naissance d’un mouvement local de notre communauté agile. En ce mois de Juin, c’est la vendée qui va poser la première pierre de sa communauté.
J’y serais, avec un plaisir d’autant plus grand que l’équipe organisatrice compte des personnes que j’apprécie vraiment beaucoup !
Pour vous inscrire ou vous régaler du programme, c’est ici !
Si tu vois un éléphant avaler une noix de coco, c’est qu’il a confiance en son derrière.
Proverbe Africain
Note de lecture : Essential Business Process Modeling, par Michael Havey
Note : 7 ; Un titre trompeur, mais sinon un excellent tour d’horizon des langages de processware…
Commençons par clarifier un point important : ce livre ne traite pas de « business processes », pas plus qu’il n’aborde la modélisation métier. Hélas, ce terme a été kidnappé et est devenu depuis consacré, par les éditeurs d’infrastructures d’échanges et d’orchestration. Ce point traité, nous allons voir que ce livre, divisé en 3 parties, recèle beaucoup de bonnes surprises.
La première partie est consacrée aux fondamentaux du « BPM », historique et fondements théoriques. En effet, les standards du BPM s’appuient globalement sur 3 principes théoriques (au choix ou de façon complémentaire) : les réseaux de Pétri, le Pi-calcul (je vous garanti que celui-ci n’est pas facile à capter) et les diagrammes d’état-transition. Si les fondements théoriques permettent de comprendre les paradigmes développés par les moteurs de processware, les process patterns permettent de comprendre les briques de base de l’orchestration et aussi de classifier les normes d’orchestration de process en fonction de leur support des 24 process patterns présentés.
Continuer à lire « Note de lecture : Essential Business Process Modeling, par Michael Havey »
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 ?
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… »
It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change.
Charles Darwin
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 !
