Étiquette : Cockburn

Note de lecture : Patterns for Effective Use Cases, par Steve Adolph & Paul Bramble, with Alistair Cockburn & Andy Pols

Le par addinquydans Notes de lectureLaisser un commentaire

Note: 7 ; Un (excellent) complément au « Writting Effective Use Cases » d’Alistair Cockburn.

Les cas d’utilisation sont un peu passés de mode depuis la grande époque UML, jusqu’au début des années 2000. C’est bien de cette époque que date cet ouvrage dont on peut pourtant dire qu’il serait injuste de le considérer comme passé de mode ! Il s’inscrit dans la lignée du « writting effective Use Cases » d’Alistair Cockburn qui promeut une écriture intentionnelle, courte et efficace par rapport aux Cas d’Utilisation « interactionnels » qui noircissent beaucoup de pages et ont donné une image si déplorable de cette pratique.

L’ouvrage a adopté le forme « Pattern Language ». Elle n’est pas toujours appropriée pour un livre d’environ 200 pages, mais on doit bien constater qu’ici cela ne pose guère de problème. Ceux-ci sont partitionnés sur 7 chapitres (auxquels il faut ajouter le chapitre introductif). Chaque pattern occupant environ 6 à 8 pages, donc assez pour être développé et pas trop pour ne pas devenir indigeste. Le premier chapitre investigue ce qu’est réellement un cas d’utilisation de qualité. C’est du moins la promesse faite par ce chapitre dont le titre est un peu trompeur. Si les auteurs nous montrent effectivement ce qu’est un bon Cas d’utilisation par rapport aux mauvais cas d’utilisation (toute ressemblance avec les bons et les mauvais chasseurs…), le chapitre sert surtout de table de matière et au langage de patterns et d’introduction à la forme pattern. Cela dit, il n’y a rien de mal à cela et c’est même nécessaire.

Le chapitre 2 nous prend un peu par surprise : « The Team » évoque les aspects collaboration et coopération gravitant autour de l’écriture des cas d’utilisation ! Ainsi, ParticipatingAudience met l’accent sur l’implication des utilisateurs et des parties prenantes, tandis que BalancedTeam détaille la pertinence de former des groupes d’écriture diversifiant les points de vue. En réalité, les éléments évoqués sont un peu des nouvelles d’hier, mais les expliciter ne peut pas faire de mal. Le chapitre 3 « The Process » s’inscrit dans la continuité. Le chapitre est assez riche et ne commet pas l’erreur de proposer un workflow de rédaction. BreathBeforeDepth est sans doute l’un des patterns cruciaux de ce chapitre. Les auteurs y référencent de très nombreux autres patterns, sans doute trop. Mais le propos est crucial pour la réussite d’une démarche « cas d’utilisation ». Je suis plus surpris d’y trouver TwoTierReview qui aurait d’avantage eu sa place dans le chapitre précédent, à mon avis. Le QuittingTime est une bonne idée : il rappelle que « pas trop n’en faut » et qu’ajouter du détail peut être contre-productif. C’est une mise en garde dont j’ai eu à faire bon usage, car je dois avouer avoir été coupable de ce travers !

Lire la suite →
Publicité

Carnet de route : Agile France 2014 (4/4)

Le par addinquydans Compte-renduLaisser un commentaire

Nous voici arrivés au bout de notre périple. Les épisodes précédents sont disponibles ici et ici pour la journée du Jeudi, et ici pour le vendredi matin.

Au programme de cette dernière après-midi : des demi-sessions (dont la mienne) et une clôture de l’évènement toute particulière !

Matti Schneider : Petit board deviendra grand

Je ne connaissais pas Matti. Je dois dire qu’il m’a bluffé par son niveau de maturité en agilité et la qualité de ses analyses. Peut-être est-ce lié au fait qu’en plus d’être ingénieur, il est également étudiant en anthropologie ?

image

Matti évoque pour nous l’amélioration continue, avec une approche qui sort des très classiques rétrospective et est d’avantage « centrée artéfacts ».

Façonner nos outils

Le point essentiel de la présentation est l’utilisation d’un outil (oui !), en fait un tableau, qui va guider l’équipe d’une façon particulière : faire entrer en résonance le descriptif et le prescriptif par le biais de cet outil !

Quand un changement de workflow est pressenti : le tableau change et devient prescriptif. Et comme l’équipe suit ce tableau, il devient alors prescriptif. Le tableau évolue par le biais de l’équipe de production qui est elle-même une partie de l’outil de production ainsi décrit.

Le passage d’une étape à une autre fait l’objet d’un « point fixe » : un état que l’on sait parfaitement définir par lequel passe obligatoirement les items. En dehors de ces points fixes, la façon dont évoluent ces items peut varier !

Voilà qui rappelle une citation de McLuhan : nous façonnons nos outils et eux-même à leur tour nous façonnent ! Et la façon dont nous les façonnons passe au travers de nos interactions.

Reflection workshop

Cette approche, à la base une variante des classiques rétrospectives agiles, est issu de Crystal Clear d’Alistair Cockburn. L’incarnation qu’en fait Matti est au travers d’un board synthétisant les décisions prises au long des itérations ! On a donc une vue d’ensemble de la chose. Les règles sont d’abord simples (dans les premiers sprints) et deviennent de plus en plus pointues. Elles peuvent aussi être changées / abandonnées, on leur superposent alors un post-it bleu avec le numéro de l’itération à l’origine de ce changement.

Les tickets agissent comme des « reminders » évitant de réitérer une discussion sur laquelle il y a déjà eu un accord. Certains guides focalisent sur l’usage du board lui-même, une sorte de niveau méta…

Ce que j’en ai pensé

Une présentation remarquable qui traduit une maturité tout aussi remarquable. Ce fut ma présentation préférée de cette après-midi là.

Géry Derbier : Les jeux de langage de Ludwig Wittgenstein

Ce n’est pas souvent que Géry nous gratifie d’une session qui n’est pas un atelier. En fait, c’est la première fois que j’y assiste ! Géry avait envie de partager depuis longtemps ce qui l’attire sur la pensée de Ludwig Wittgenstein. Une session pas très facile à suivre et encore moins facile à retranscrire !

image

Le plus simple est problement de ne pas faire de retranscription. Je vais simplement relever certains éléments que j’ai noté au fur et à mesure de la présentation de Géry.

  • La primauté de l’acte sur la pensée.
  • La théorisation est vaine. Il est préférable de voir et décrire ou « déconstruire » précisément.
  • Comprendre n’est pas l’intellectualisation de quelque chose, mais l’aptitude à le faire.
  • Nous utilisons un langage : regardons comment il fonctionne.

Cette façon de pensée amène Géry, en tant que coach, à demander au coaché de « déconstruire » les constats par une question : comment le savez-vous ?

C’est aussi ce mode de pensée qui a amené Gery vers le solution focus qu’il voit comme une incarnation de la pensée de Wittgenstein.

Ce que j’en ai pensé

Une session difficile à suivre qui nous amène vers les sentiers d’une philosophie à contre-courant. Je ne suis certainement pas rompu à cet exercice (je n’ai même pas d’épreuve de philo dans mon bac technique !). Bref, je passe pour l’instant…

Pierre Hervouet : Manipulé à l’insu de mon plein gré

Hélas, j’ai assez peu suivi la session de Pierre. Il faut dire qu’elle précédait juste la mienne. Au minimum pour commencer, je peux vous en livrer le teaser.

Pourtant cette session s’articule autour d’un de mes sujets préférés : les biais cognitifs ! Pierre évoque ainsi quelques mécanismes :

L’ancrage

Le cerveau humain juge souvent en relatif. Si on fournit une référence, elle biaise les résultats obtenus, par le haut ou par le bas, suivant que le référence d’origine est haute ou basse respectivement !

Le planning poker, en exigeant que les cartes soient montrées en même temps cherchent à éradiquer ce biais.

image

L’identification

S’identifier à une personne est plus fort que s’adosser à des statistiques ! Le mécanisme des persona s’appuie sur cela (en lieu et place des rôles, plus abstraits).

Ce que j’en ai pensé

Essentiellement que je suis frustré de n’avoir pas mieux suivi cette session. Damnation ! Car le sujet m’intéresse au plus haut point. Mais je ne peux en vouloir qu’à moi-même. J’espère que le support ou mieux l’enregistrement sera bientôt disponible…

Christophe Addinquy : User Stories, what else ?

C’est mon tour ! Au programme une version plus dense, en partie raccourcie et en partie modifiée de ma présentation faite à Agile Grenoble 2013. J’ai dans ma liste de tâches, la rédaction de cette présentation sous forme d’article, comme je l’ai fait pour Scrum Shu Ha Ri.

Je publierai aussi sous peu la nouvelle version correspondante du support.

Les 10 buzzwords du hipster agile

Cette dernière demi-session ne fut pas ma préférée de l’après-midi, bien au contraire. Le but était en principe de démystifier certains de ces buzzwords, de les dégonfler. En fait, je me suis trouvé en désaccord avec nombre des assertions de Christopher et Hervé !

image
  • Lean Startup = XP + Product Management ! Bien sûr, Eric Rie est un ancien de XP. Un peu léger pour affirmer que Lean Startup est un réhabillage d’XP avec les idées de Steve Blank ! Il ya mieux et plus à dire d’autant que l’inspiration initiale est beaucoup plus « lean ». Dehors !
  • Le MVP n’est pas la réalisation minimale de mon produit. Je suis d’accord !
  • Le devops n’est pas un process ou un outil, mais la collaboration entre ops et dev : d’accord aussi !
  • Continuous deployment, ce n’est pas mettre en production des bug fixes tous les jours. Certainement, mais d’ou vient cette idée ?
  • Le Kanban, il doit suivre la définition d’Anderson ! Ce n’est pas lui qui a inventé le Kanban, et on peut aussi faire des proto-Kanban sans mettre en place de WIP initialement !
  • Le Proxy PO : Bon, nous sommes d’accord sur l’absurdité du concept !
  • La transformation agile d’entreprise. Une foutaise pour les orateurs. Certainement, si on mène cela comme un nouveau process et non comme un changement culturel et organisationnel !
  • La feature team : Désolé, je ne suis pas prêt à considérer comme un « nouveau buzz » quelque chose décrit par Ken Schwaber en 2004…
  • Le Design Thinking. Bien, là aussi je doute que les orateurs ait fait l’effort de rentrer dans le concept…
  • Agile. Oui c’est vrai le « on fait ça depuis longtemps mais on appelait pas ça comme ça », on l’entend réellement tous les jours.

Bref, pas enthousiasmé par cette session. Mais alors, pas du tout…

Fresque Finale

Le scribing était notre grand fil rouge de la conférence. Pour clore en beauté celui-ci, Romain nous a invité à élaborer en commun une grande fresque faisant le tour de la salle Belvédère. Un bel exercice !

image

Keynote de clôture ?

L’organisation d’Agile France nous réservait une petite surprise pour clore ces deux jours : une fausse session proposée avec talent par la compagnie des Z’Humbles.

image

Drôle et bien enlevé. C’est une façon originale de terminer cet Agile France !

Alors, cet Agile France 2014…

image

Une formule en grand changement pour cette nouvelle édition, avec deux après-midi à caractère spécifique, sans oublier le fil rouge de Romain. Toujours une grande qualité dans les sessions et la magie du Chalet de Porte Jaune ! Les organisateurs ont réellement redoublé d’efforts pour réussir cette nouvelle édition.

Carnet de route : Le ScrumDay 2014 (1/4)

Le par addinquydans Compte-renduLaisser un commentaire

Bienvenue au ScrumDay 2014 !

Cette édition sera particulière pour moi : c’est la première où je ne fais pas partie du comité d’organisation ! Certes, j’y aurais ma session, mais je vais faire mon possible pour profiter pleinement de ces deux jours, et vous en faire bénéficier maintenant !

Pour tout dire, ça commence par un peu de galère : Xavier Warzee voulait depuis longtemps organiser l’évènement chez Disney. C’est loin et cher (le prix de la conférence triple donc au passage), mais mon statut de conférencier me donne accès à la conférence « full package », celui qui vaut 290 € ! Reste l’accès. Venir en voiture s’avère plus galère que si nous avions été en plein Paris, j’opte pour le RER.

L’accès est un rien compliqué, mais le SUG a tout prévu : Pascal est là pour nous accueillir dès la sortie de la gare !

image

N’oublions pas que chez Mickey on est presque aux états-unis, le délit de sale gueule existe encore. Pour moi, c’est fouille minutieuse à chaque contrôle de sécurité. Même avec une certaine habitude de la chose, ça ne me met pas spécialement de bonne humeur. C’est dommage d’autant que le French SUG n’y est pour rien. Mais si c’est au même endroit l’an prochain, ce sera probablement sans moi.

Je découvre le centre de conférence en arrivant : vraiment très spacieux (et même un chouia labyrinthique), quand au hall principal…

image

Le temps de prendre un café et d’échanger avec les amis, nouveaux ou anciens, l’heure est vite passée et nous sommes attendus dans la salle où se dérouleront discours d’ouverture et keynote.

Ouverture du Scrum Day

Rameuter Presque 500 personnes, ça prend du temps, on va donc débuter avec un peu de retard. Que du classique pourrait-on dire.

image

Comme il est de coutume, le président du SUG ouvre ce ScrumDay ou ScrumDays, devrai-je plutôt dire.

image

On retrace un peu d’histoire, quelques chiffres et surtout on présente le déroulement de ces deux jours, le maître de cérémonie de la seconde journée sera Laurent Bossavit, épaulé de Raphael Pierquin pour un grand open-space, à l’image de ce qui se fait à Grenoble.

image

On termine cette ouverture par le mot des sponsors. Les sponsors ! Il y en a 17 ! C’est certainement un record, en tout cas c’est un marathon de les écouter tour à tour.

image

Laurent Delvaux ouvre le tir pour Zenika, et j’ai vite perdu le compte. Mention spéciale pour le représentant de HP France qui nous a gratifié d’une introduction au style humoristique bien enlevé !
Heureusement, on va maintenant enchainer sur la keynote.

Alistair Cockburn : What’s new with agile ?

J’étais curieux de voir ce dont Alistair allait parler. Après tout, j’ai l’habitude de l’entendre parler d’agilité, ou comme dirait Géry Derbier de jeu de coopération et collaboration. En fait, il commence par évoquer les personnes … et les difficultés que nous avons face aux problèmes et à nos décisions. C’est un préambule au manifeste agile dont il est l’un des signataires.

image

Mais pour parler de Scrum, Alistair évoque le Shu Ha Ri ! Curieusement, c’était le sujet de ma présentation à Caen il y a 3 semaines, je suis tout ouï. Si vous l’ignorez, il s’agit des 3 niveaux de maturité en agile, emprunté par Alistair aux arts martiaux, à l’Aikido pour être plus précis.

  • Le Shu est le niveau initiatique. Le Shu c’est copier la technique sans en dévier. Hélas, nombre de personnes tombent amoureux du Shu et ne le quitte jamais…
  • Le Ha est le perfectionnement, il signifie « cassure ». Dans le Ha, on collectera nombre de techniques utiles.
  • Le Ri est le niveau de la maîtrise, c’est littéralement l’abandon. On invente, mixte ses propres techniques.

Core Scrum

Scrum n’est pas fondamentalement du niveau Shu, il est du niveau Ri. Et au niveau Ri, le « core Scrum » se définit ainsi :

  • Délivrer à chaque Sprint (plutôt que démontrer)
  • Laisser l’équipe décider (en assignant une tâche)
  • Inspecter et adapter à chaque Sprint

Ca c’est l’esprit du Scrum. Autour de cela, gravitent des rumeurs ou des freins (Alistair parle de balanes).

Les « balanes » sont tous ces éléments de Scrum, des éléments « Shu » sur lesquels on se focalise alors qu’ils n’ont qu’une importance secondaire :

  • Le burndown chart : il n’est pas essentiel, faites-le si vous en avez envie, d’ailleurs il ne fait plus même plus partie des éléments « obligatoires du Scrum Guide !
  • Le Scrum Board : Doit-on en faire un ? A quoi doit-il ressembler ? L’équipe décidera.
  • Le Scrum Master est-il un chef de projet ? Un tech Lead ? Cela dépendra du contexte.
  • Le Product Owner doit-il assister au stand-up ? Laissez l’équipe décider !
  • Les 3 questions du stand-up : ce peut être une aide, mais pas un dogme !

Rumeurs et ouïe dire, ou les « lutins » comme dirait Laurent Bossavit:

  • Les User Stories : Elles ne font pas partie de Scrum, elles ont été créées avec XP. Scrum n’oblige pas à utiliser les stories.
  • Le Planning Poker : Cette pratique vient également d’XP ; si elle convient, alors utilisez-la !
  • La suite de Fibonacci / les story points : Ce ne sont pas non plus des pratiques spécifiquement liées à Scrum. Tirez-en parti si vous aimez.

Le « big agile »

Alistair évoque pour commencer le framework SAFe. J’avoue y avoir porté peu d’intérêt, bien que ce soit un sujet dont on parle en ce moment. Je m’attendais à voir Alistair le démonter, mais non ?!?

Quand on parle d’agile en grand en ce moment, on évoque souvent Spotify autour duquel Henrik Kniberg communique beaucoup en ce moment. Ce qu’il appelle l’organisation 3D semble aussi une référence pour Alistair. Et qui dit grande organisation dit dépendances : l’architecture du système doit prendre en compte cet aspect afin de rendre le déploiement asynchrone.

image

Disciplined learning

Le dernier point évoquer par notre keynote speaker est l’un de ceux qui lui tiennent beaucoup à coeur : l’apprentissage. Alistair oppose le « big bang » synonyme d’apprentissage tardif d’un apprentissage au plus tôt (ou réduction des risques, mais l’emphase sur l’apprentissage n’est-il pas préférable ?). Cette courbe n’est d’ailleurs pas une courbe, mais une espèce d’escalier, car tous les progrès ne se valent pas et certaines expérimentations d’avèrent stériles. Géry Derbier évoque souvent la chose quand il anime le Carpaccio Game : il y a 4 dimensions d’apprentissage sur un projet :

  • Business (ce volet pouvant lui-même avoir différents axes, et pas seulement le ROI).
  • Social (la formation de l’équipe).
  • Technique
  • Coût / délais (découverte de la vélocité, par exemple).

Cette façon d’appréhender le projet permet de le borner (trim the tail), soit par la date, soit par la valeur.

Ce que j’en ai pensé

Peut-être Alistair Cockburn n’était pas aussi percutant qu’il nous en a donné l’habitude, mais s’agissant du Scrum Day il nous a livré une keynote s’articulant autour du Scrum, du vrai Scrum ! Je ne peux qu’apprécier le propos faisant écho à ma propre présentation du Printemps Agile, bien sûr, mais surtout je trouve important de mettre en exergue les aspects importants de Scrum (le Scrum Core), par rapport aux choses secondaires qui sont celles sur lesquelles se focalisent souvent les détracteurs de Scrum !

Romain couturier nous a aussi gratifié d’un « scribing » de la session d’Alistair. Il a bien voulu le partager avec nous, et je m’incline devant son talent !

image

Nous avons déjà pris un peu de retard sur le timing, le changement de salle est un tout petit peu serré. Pour moi, le choix de la session suivante était déjà fait.

Coaching Teams Through Change, par Rachel Davies

Rachel Davis est l’auteur d’un des quelques ouvrages disponibles en rayonage sur le coaching agile. Un ouvrage que j’avais trouvé correct sans être fantastique. Le sujet de cette session lui, me fait plutôt penser au Fearless Change !

image

D’abord, quel est le plus grand obstacle au changement ? Bien entendu : la résistance ! Alors certes, on voit beaucoup de choses à faire … tellement à faire et si peu de temps ! Mais la première précaution est justement de ne pas se précipiter !

Communiquer

Choisir ses mots avec soin (en fonction du canal de votre interlocuteur, comme dirait Véronique Messager). N’oublions pas de nous mettre à la place de notre interlocuteur : ce que nous voulons dire correspond rarement à ce que nos interlocuteurs veulent entendre !

La communication, c’est aussi un processus bidirectionnel. N’oublions pas l’écoute, en fait, commençons par cela. Une bonne écoute c’est :

  • Absorber de l’information
  • Rester calme et attendre.
  • Encourager l’interlocuteur.

Voilà qui me rappelle la session de Florence Chabanois à l’Agile France 2013.

Leadership

Et ceci me rappelle à nouveau le Fearless Change. On y trouve plusieurs idées:

Aller parler aux sceptiques : comprendre ce qui les retiens est le premier pas vers la compréhension des faiblesses de notre message. De plus les sceptiques ne sont pas des opposants, du moins pas nécessairement. Ils peuvent même s’avérer être à terme vos plus ardents défenseurs.

Plusieurs facteurs peuvent influencer le refus de suivre :

  • La difficulté
  • La permission
  • Le (mauvais) timing
  • Ce n’est de toute manière pas mon idée !

L’exemplarité: Pour inciter les autres à suivre, commencer par faire vous-même. Vous voulez mettre en place un Kanban ? Utilisez déjà un « personal Kanban ».

Traiter les problèmes

Les rétrospective sont là pour les mettre en évidence et dresser des plans d’action. Mais plus encore, rendons les problèmes visibles tous les jours en les affichant !

Ce que j’en ai pensé

Pour être franc, j’ai eu du mal à m’enthousiasmer pour cette session un peu fourre-tout, avec un fil conducteur un peu difficile à saisir ! Bref, un peu déçu, je l’avoue…

Sébastien Ferron a publié un excellent post sur cette session sur le blog de SOAT.

Pollénisation croisée avec la communauté des designers ?

Pierre Hervouet et Joumana Mattar nous proposaient cette session. Si l’audience était nettement plus réduite qu’avec Rachel Davies, le contenu… eh bien j’ai préféré cette session, voilà !

Pourtant je suis venu sans trop savoir à quoi m’attendre. Mais j’avais aimé la session que Pierre avait animé avec Pascal Van Cauwenberghe à Agile France 2013. Je l’ai donc suivi ici.

Pierre vient ici avec une étiquette « Agile Lebanon », et il venait nous parler du Global Service JAM !

image

Le Global Service JAM, c’est une sorte de Startup Week-end pour les designers : une unité de lieu et d’action pour 48 heures, et pour sortir avec un produit ! Le JAM s’organise sur 3 jours.

1ère journée : Open minder

Au programme : ice-breaker, brainstorming et agile games !
On explore l’espace, on répartit des idées sur une table (cela offre une meilleure circulation qu’un mur) et on met l’utilisateur au centre en utilisant des personas.

A ce stade, on ne sait pas encore ce que l’on va construire !
Une première journée jugée très positive par Pierre et Joumana. Avec un outil atypique : l’unstuck jarre, remplie de questions perturbantes quand on est en panne…

2nd journée

Beaucoup de choses dans cette seconde journée ! En fait tellement d’outils que Pierre et Joumana nous ont distribué un jeu de cartes les rassemblant tous ! Voilà, vous n’aviez qu’à être à cette session !

image

On va donc y trouver pêle-mêle :

  • Get out of the building : à l’image du Lean Startup Machine, pour aller valider son concept dans la rue !
  • Des energizers
  • Le bottleneck game de Pascal Van Cauwenberghe et Portia Tung, pour introduire l’amélioration continue
  • 5 focus steps !
  • La carte d’empathie pour explorer les personas. A l’image de ce que l’on fait en Lean Startup.
  • Le User Journey map pour explorer l’expérience utilisateur via du story telling.
  • Le PoP (prototyping on paper).

3ème journée : stress et deadline

A la fin de cette journée, il faut livrer !

Ce que j’en ai pensé

Beaucoup de choses dans cette session, j’ai la sensation d’en avoir raté la moitié. Au moins ! Cela m’a permis d’explorer un concept que je ne connaissais pas et je repars donc avec pas mal de pointeurs à investiguer !

Si l’aventure du Global Service JAM Libanais vous a intéressé ou intrigué, vous pouvez les retrouver sur leur Blog Tumblr.

Il est bientôt l’heure du déjeuner. En passant, je vois Romain qui termine sa session.

image

Déjeuner

Disons-le tout net : ce ScrumDay est de loin celui qui m’aura laissé la meilleure impression sur cet aspect : on a de la place et plusieurs buffet sont disposés de manière à ce que l’on ait jamais besoin d’attendre très longtemps. Les plats sont diversifiés et de qualité, et l’on peut s’assoir pour converser en même temps que l’on se restaure. Bravo !

image

Profiter de la pause déjeuner pour converser avec les nombreuses brillantes personnes que je peux croiser ici est un luxe que je n’ai jamais eu jusqu’à présent au ScrumDay ! C’est avec Jean-Laurent de Morlhon que je passerais la plus grande partie de cette pause. Le développement (le vrai) est la passion de Jean-Laurent. Aujourd’hui il partage son temps entre les missions de dev orientées « craftmanship », Serpodile la société créé par sa femme et le partage au sein des communautés qui lui tiennent à coeur. Nous retrouverons Jean-Laurent au cours de l’après-midi pour sa session.

image

Je clos ici le premier volet de mon retour sur ce ScrumDay, il ne faudrait pas risquer l’indigestion !

Scrum Shu Ha Ri, la présentation

Le par addinquydans Presentation1 commentaire

« On a pas mal de nouveaux venus à l’agilité, et on n’a pas beaucoup de sessions pour eux ». C’est ce que Jean-Luc Lambert me disait à propos de ce Printemps Agile 2014. En fait, je fais peu de sessions d’initiation, ce n’est pas ce que je préfère. Puis j’ai repensé à mes expériences récentes et ma façon d’appréhender Scrum comme un framework à même de nous accompagner du débutant à l’agiliste expérimenté.

Ainsi est née cette présentation « Scrum Shu Ha Ri ». Il n’est pas certain que j’aurais l’occasion de la resservir, ce n’est en tout cas pas prévu pour l’instant.

Le thème est inspiré du « Shu Ha Ri » présenté par Alistair Cockburn. J’ai en quelque sorte « instancié » ses idées à l’image que je me fais de Scrum.

J’escompte aussi pouvoir vous proposer plus tard cette présentation sous forme d’article, comme je fais parfois. Il vous faudra quand même patienter un peu.

User Stories … What else ?

Le par addinquydans PresentationLaisser un commentaire

Voici le support de ma présentation, faite lors d’Agile Grenoble 2013. Elle aborde le sujet épineux de l’emprunt de techniques issues du monde non-agile dans nos projets agiles !

Le teaser

Les users stories sont rapidement devenus la formulation convenue du besoin. Mais est-ce la seule ? Est-ce toujours la meilleure ? On dit que quand on a un marteau, tout ressemble à un clou. Notre communauté agile tend à ignorer ce qui vient d’ailleurs. Pourtant ce qu’on appelle l’ingénierie des exigences est un domaine riche de plusieurs décennies de connaissances et de techniques. Certaines peuvent être utilisées directement, d’autres doivent être adaptées ou peuvent servir d’inspiration.

Cette présentation va nous permettre d’étudier ensemble plusieurs techniques et concepts du recueil des besoins et les regarder par le prisme de nos pratiques agiles. A l’aide d’exemples, nous verrons comment elles peuvent renforcer nos pratiques actuelles.

Ce que vous allez en retirer

Découvrir l’ingénierie des exigences, prendre conscience de la profondeur de ce domaine de connaissance. A la fin de cette session les participants auront des clés pour enrichir leur maitrise de la capture du besoin en s’alimentant hors du champs de l’agilité, et j’espère le goût de le faire !

Si j’ai assez de courage, je produirais cette présentation sous forme d’article. Mais alors pas avant Janvier !

Note de lecture : Surviving Object-Oriented Projects, a manager’s guide, par Alistair Cockburn

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 7 ; Beaucoup de clairvoyance et de clarté dans l’illustration de cas réels, une pertinence du texte qui résiste mais s’est érodée avec le temps.

Ce livre est rédigé de façon pragmatique, c’est probablement pourquoi il ne compte que 200 pages, volume au delà duquel il faut planifier du temps pour lire entièrement l’ouvrage. L’auteur s’est attaché à décrire comment une organisation pouvait basculer vers l’objet, les stratégies possibles et comment mettre le maximum d’atouts de son coté. Les cas de figure sont abondamment illustrés de cas de figure réels, aussi bien en succès qu’en échecs. Mais voyons plus avant son contenu. Les 200 pages de son contenu sont réparties sur 8 chapitres, mais il faut aussi évoquer les 40 pages d’annexes.

Le premier chapitre est un rappel des concepts de base de l’objet : encapsulation, polymorphisme, etc.. Rien de vraiment original, surtout en 98 où l’objet est quand même un acquis. Mais le propos a le mérite d’être clair.

Le second chapitre est plus original, car il reprend de manière très succincte 11 projets avec leurs facteurs clés de succès, d’échecs ou simplement de difficultés. Chaque cas est exposé sur moins d’une page avec un cartouche caractérisant le projet. En synthèse de ce chapitre l’auteur expose les avantages et les coûts liés aux projets objet. Le contenu est original et reste intéressant, même maintenant.

Les 40 pages du chapitre 3 sont dédiées aux choix et au setup du projet. Quel type de projet doit-on choisir pour faire son premier projet objet ? Avec quelles personnes et surtout avec quel langage ? Certains des points évoqués font largement sourire aujourd’hui. Comme par exemple la question d’un nouveau venu « périphérique » : Java. Aujourd’hui c’est surtout avec ce regard historique que l’on lira ce chapitre dont le propos a perdu de sa pertinence au fil du temps.

Au chapitre 4, on discute méthodologie et plus exactement ce que l’auteur appelle « big-M » versus « little-m » methodologies. Le big-M, ce sont les vrais processus, alors que les little-m ce sont les notations dérivant vers des méthodes/processus d’usage de ces notations. L’auteur exhorte d’abandonner le little-m et de se consacrer au big-M en statuant sur le choix d’un « big shop » ou « small shop » methodologies. Ce qui deviendra plus tard sa « cristal family of methods ». Même si l’auteur conseille de ne pas faire trop lourd, on reste quand même dans la logique rôles / activités / outils, sans compter le plan, les milestones, etc.. On reste assez loin de l’agilité quand même.

Justement, le très long chapitre 5 (près de 50 pages) est exclusivement consacré aux aspects itératifs et incrémentaux des projets. L’auteur y explique par le menu la différence entre les deux et l’avantage des les combiner et compare l’utilisation de ce mode à une « correction de trajectoire ». Cette lecture reste pertinente, même aujourd’hui.

Par comparaison, le chapitre 6 est très court, car il ne compte que 10 pages. L’auteur y évoque les phrases qu’il aurait souhaité de ne jamais entendre. Ce que j’appelle de mon côté les tartes à la crème. Certaines de ces idées reçues sont passées de mode (du moins je crois) mais d’autres ont la vie dure… On passe un bon moment à passer cela en revue !

Le chapitre 7 traite le cas des gros projets et se focalise spécifiquement sur les facteurs de réduction de risque. Là encore, il s’agit d’une lecture qui ne se démode pas.

Le dernier chapitre revisite l’un des cas exposé au premier chapitre et montre comment un échec aurait pu être évité à la lumière des éléments exposés dans le livre.

N’oublions pas non plus l’annexe A, la plus importante qui reprend sous forme de patterns, les stratégies de réduction de risques. Pas mal.

Le livre mérite sans contestation possibles son titre. Il accuse par pas mal de facettes le poids des ans. Il devient difficile de le conseiller, surtout quand de l’excellente littérature agile peut vous montrer la voie. Quelques chapitres méritent le détour, même aujourd’hui. Mais on en est plus à considérer les projets orientés objet comme de la technologie d’avant-garde…

surviving-oo-projects

Référence complète : Surviving Object-Oriented Projects, a manager’s guide – Alistair Cockburn – Addison Wesley / Object Technology Series 1998 – ISBN: 0-201-49834-0

Surviving Object-Oriented Projects


http://www.goodreads.com/book/add_to_books_widget_frame/0201498340?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Writing Effective Use Cases, par Alistair Cockburn

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 7 ; D’excellents conseils rédactionnels et une bonne approche “adaptative” de la modélisation des systèmes.

Ce livre se focalise entièrement sur la rédaction textuelle des cas d’utilisation. A ce titre, il relativise la description graphique comme étant une vue synthétique du périmètre fonctionnel. Alistair prêche une approche par décomposition fonctionnelle dans laquelle on part des business cases pour descendre jusqu’à des uses cases de type sous routines. A chaque niveau (représenté par une icône) on détermine l’objectif de l’acteur principal comme étant la force essentielle dans la détermination du cas d’utilisation.

Le livre est excellent pour ce qui est de décrire des Use Cases optimaux et clairs, donc suffisamment courts et concis pour être lus et compris. Qui plus est, des mémentos permettent de se rappeler quelles sont les règles à suivre dans l’écriture des Use Cases. Ce livre est d’avantage dédié aux personnes pratiquant déjà les cas d’utilisation et désireuses de progresser qu’aux nouveaux venus qui risquent de se retrouver quelque peu noyés. Enfin certains aspects tels que la décomposition fonctionnelle utilisant abondamment les relations d’inclusion sont critiquables voire dangereuses lorsque utilisées à mauvais escient.

writing-effective-use-cases

Référence complète : Writing Effective Use Cases – Alistair Cockburn – Addison Wesley / Crystal Collection for Software professionals 2001 – ISBN: 0-201-70225-8; EAN: 978-0-201-70225-5

Writing Effective Use Cases


http://www.goodreads.com/book/add_to_books_widget_frame/0201702258?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on