A key tenet of agile estimating and planning is that we estimate size but derive duration.
Mike Cohn
Mois : juin 2015
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.
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.
Le secret pour prendre de l’avance est de démarrer. Le secret du démarrage est de décomposer vos écrasantes tâches complexes en tâches plus petites qui soient gérables, puis de commencer par la première.
Mark Twain
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 ».
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.
Software Freethinker 