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.

image

Des entreprises montrent des succès spectaculaires en faisant des choses différentes, mais il est illusoire de chercher à les copier

Lire la suite

Publicité

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 !

Rendez-vous à l’Agile Vendée !

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.

Lire la suite

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.

Lire la suite

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.

Lire la suite