Less is more avec Craig Larman

En préambule d’une formation LESS (j’y reviendrais bientôt), Greg Hutchings nous a permis d’assister à une présentation dans le cadre du Scrum User Group. Une présentation autour de LESS, bien entendu. De mon point de vue, une présentation de Craig Larman, ça vaut toujours le détour: ses talents d’orateur ne sont plus à démontrer et même si vous n’adhérez pas à la totalité de son propos, vous êtes sûr de repartir avec de nouvelles connaissances, des idées et surtout de quoi reflechir !

Pour commencer

Avant même d’aborder le thème même de la présentation et après la traditionnelle histoire drôle qui ouvre toujours ses présentations, Craig campe l’ambiance : je ne suis pas intéressé par vos opinions ! Je ne suis d’ailleurs pas non plus intéressé par MES opinions. Ce qui compte, ce sont les faits. Même les études de cas sont insuffisantes. Ce qui compte, ce sont les études menées de manière scientifiques sont des échantillons statistiquement signifiants et publiés dans des journaux à comités de lecture. Une approche scientifique sur laquelle l’orateur se revendique de Thomas Kuhn.

image

Pour lui, nous sommes à l’âge de l’obscurantisme du management, où les croyances prédominent sur les faits. Où une plus grande attention aux recherches académiques devrait être portée, alors que 50 ans de recherche en management sont simplement ignorées. Alors, laissons tomber les opinions personnelles.

Le “Scrum fake” : à la recherche des causes racines (1ère partie)

Le constat premier de Craig Larman rejoint le mien : il y a de plus en plus de “Scrum Fake” dans les mises en place de Scrum aujourd’hui. Le co-auteur de LESS y voir 2 causes racines. Des causes racines qu’il faut activement adresser, car si notre transition agile ne les adressent pas, celle-ci pourrait faire plus de mal (la déstabilisation liée au changement) que de bien (la mise en place d’un véritable environnement agile).

Cette première cause racine a un nom : le “contract game”. C’est à dire le jeu autour du contrat auquel se livrent les équipes de développement d’une part et le client (au sens client interne) d’autre part. Oui, on parle bien d’un contrat “virtuel” interne et non d’un contrat légal avec un client externe. Pourtant le fond reste le même.

image

La première partie du projet, celle où se joue l’établissement de ce contrat, est le théâtre d’un duel où le business demande “plus, plus, plus” et où l’équipe de développement réponds “moins, moins, moins”. Il y a ce combat, car chacun sait qu’au moment où celui-ci sera ficelé, le jeu changera :

  • Le business n’a plus la main, elle passe au développement qui devient seul maitre.
  • Le business lui-même ne veut pas être inclus dans le jeu du développement.
  • Ce contrat est basé sur l’illusion de la faible variabilité. Une illusion dont on sait qu’elle est fausse depuis de nombreuses décennies.
  • On dit d’un d’un contrat qu’il est aboutit quand les deux parties sont mécontentes de manière équilibrée. Au fait, quel est son rôle au contrat ? Ce n’est pas de permettre la réussite du projet mais de permettre de blâmer l’autre partie en cas d’échec !

Donc on s’engage dans une longue phase de réalisation où le chef de projet fait le lien avec le business. Craig nous parle des outils du PMI (qu’il appelle le Project Magic Intitute) concernant la relation entre le chef de projet et le client :

  • Comment le chef de projet assure le client de la réussite : en déclarant « je m’engage ! » ; une approche dont on sait depuis longtemps qu’elle ne marche pas !
  • Comme dans toute magie, on utilise des symboles ésotériques : ici, on les appellent « diagrammes de Gantt » … en fait une illusion de contrôle !

Enfin les managers pilotant ces projets à plusieurs niveaux hiérarchiques de distance transmettent des rapports d’avancements faussement optimistes au grée des remontées d’information entre niveaux hiérarchiques ! Un phénomène appelé « greenshifting ».

Tout cela se paie à la fin du projet : les blâmes sont rejetés entre les acteurs du projet, le périmètre est bâclé en toute urgence pour se débarrasser du projet en sacrifiant la moindre parcelle de qualité. Enfin, le tout se conclut en « dette managériale » : les bons managers et les bons développeurs quittent la structure !

image

Larman explicite ces fonctionnements par ce qu’il appelle en toute modestie les « lois de Larman » !

1 – Les organisations sont sont implicitement optimisées pour maintenir le statut quo du pouvoir des managers de proximité et des spécialistes

2 – Corollaire de la première loi, toute initiative de changement sera réduite à des changements d’appellation maintenant ce statut quo.

3 – Second corollaire de la première loi, les initiatives de changement seront tournées en dérision, puis qualifiées de « puristes », « théoriques » ou « révolutionnaires », puis « nécessitant des adaptations pragmatiques pour customiser pour l’organisation », menant au statut quo managers / spécialistes.

4 – La culture se calque sur la structure : les plans de carrière favorisent la spécialisation. Changer la culture en tant que tel n’est pas possible.

La seconde cause : le découpage par fonction

Le découpage « orienté composants » présente de graves lacunes :

  • Du « code privé » : au contraire d’augmenter la qualité, ces groupes créent une complexité artificielle qu’ils ne sont plus capables de voir au bout d’un certain temps !
  • Les fonctionnalités à délivrer traversent les composants. Mais comme elles deviennent subordonnées aux planning locaux, elles mettent très longtemps à être livrées. Donc un cycle de feedback qui va de même.
  • Les fonctionnalités étant l’assemblage de fonctionnalités implémentées dans les divers composants, les tests de bout en bout ne peuvent avoir lieu qu’une fois l’ensemble complété. Notre cycle de développement est en fait séquentiel à ce stade. Il subit le syndrome du « hands of » typique du cycle en cascade.
  • Ce « hands of » n’est pas seulement en aval, il est aussi effectif en amont: chaque fonctionnalité demandée doit être ventilée en éléments de réalisation, il est donc nécessaire d’avoir des analystes effectuant ce découpage au préalable du développement !
  • Le staffing étant effectué par composant, l’occupation générée par ls demandes n’est pas nécessairement en ligne avec cette disposition de ressources. La priorisation des fonctionnalités finit donc par être dirigée par l’occupation des équipes, plutôt que par les priorités métier !

Hélas, le « découpage par composants » a des airs bien trop familiers pour moi. La démonstration de Craig est plutôt édifiante !

image

Mais alors…

Et LESS, dans tout ça ?

Le point de départ de la reflexion de LESS vient de l’expérience de RUP (j’y ai participé chez Valtech, à la fin des années 90). Les deux grands défauts de RUP, que je partage avec l’orateur, étaient :

  • Un niveau de détail bien trop grand. Personnellement, je traduis celà comme une rémanence d’une vision Tayloriste du travail .
  • Un manque de contextualisation.

Le framework LESS est guidé par plusieurs principes :

  • Celui des organisations apprenantes, en s’inspirant du Shu Ha Ri. Ainsi plutôt que le ras-de-marée de détails, LESS propose des principes et juste « un peu moins que nécessaire » d’éléments de processus. Il se revendique en cela dans la lignée de Scrum.
  • Une organisation en « feature teams » plutôt qu’en composants. Comme c’est le cas chez Spotify.
  • Une « serious change initiative » destinée à bouleverser l’organisation et les titres de postes ! LESS se revendique d’inspiration Lean ici : La préservation des emplois ne signifie pas la préservation des rôles !

Pour démarrer tout cela, Larman débute une réorganisation LESS avec 2 points de rencontre très importants :

  • L’informed consent meeting. C’est un meeting de 2 à 3 jours avec Craig, avec tous les exécutifs ! S’ils ne peuvent y consacrer ce temps, c’est qu’ils ne sont pas sérieux sur leur volonté de changement ! D’après l’orateur, la plupart des organisation n’en valent pas le coup ! Hum…
  • Une fois le changement décidé, il y a le « flip », qui dure 2 heures. C’est le Design Team Meeting. Il s’agit d’une grande place de marché où les équipes s’auto-forment en s’appuyant sur une « check list ». Cela nécessite parfois plusieurs tours. Une fois cela fait, les équipes embauchent… leur Scrum Master ! Puis… leurs managers !
image

Il y a de nombreux éléments spécifiques à LESS, comme la façon de gérer les planning meetings, les démos et les sprints synchronisés. Par ailleurs, pour donner de la cohérence à l’ensemble des travaux menés par des features teams indépendantes, il faut des communautés de pratiques: certaines sont requises, d’autres informelles.

En conclusion

Tout d’abord, Craig Larman est un orateur hors pair. Non seulement sa diction est claire, mais son jeu de scène est vivant, son propos est intéressant et souvent pertinent. L’approche de changement des organisations de Larman me semble par ailleurs brutale : le RAZ sans tenir compte de l’existant ou du contexte, avec le dogme que l’organisation LESS est de toute façon la bonne. Pour Olaf Levitz, cela démontre un manque de respect. Je le rejoins sur ce point.

Les pré-requis au passage à LESS sont très importants car Craig Larman n’accepte aucun compromis. De fait peu d’entreprises acceptent un tel changement, mais doit-on dire de fait que les autres ne « valent pas le coup » ? Je ne suis pas non plus l’auteur sur ce point.

image

LESS est résolument d’inspiration Scrum par sa légèreté. Au contraire de SAFe que je trouve sujet à caution, la fibre agile de ce process me semble réelle. Mais je reste dubitatif sur le concept même et sur la motivation du scaling, quel que soit la dose d’intelligence qui y est mise (ce qui est bien le cas ici). L’idée de « scaler » me semble une réminiscence d’un ancien mode de pensée qui vient infecter le nouveau. Je pense que l’enseignement de l’agilité est différent…

Vous pourrez retrouver quelques éléments de la prose de Craig dans l’interview suivant. Un livre sur le sujet est à venir cette année, mais on trouve déjà une majorité du matériel dans les deux livres co-écrits avec Bas Vodde, dont celui-ci.

Note de lecture : Stand Back and Deliver, par Pollyanna Pixton & al.

Note : 7 ; Du modèle de valeur au modèle de leadership.

Pas facile de classer ce livre de prime abord. Finalement, c’est du côté du « Product management » qu’il a le plus sa place. La première chose qui surprend dans ce livre, c’est le titre ! Les auteurs s’en expliquent dans la préface : le point clé du « process », c’est de mettre ensemble les acteurs clés, puis de se tenir en retrait ! La seconde chose qui surprend un peu, c’est la taille de l’ouvrage : seulement 150 pages, qui ne nécessitent guère plus de 7 chapitres.

Le premier chapitre ne compte que 9 pages. C’est une introduction au reste du texte, on y présente dans les grandes lignes les 4 éléments du framework qui feront l’objet des chapitres suivants. Justement le chapitre 2, avec ses 30 pages a trait au premier élément : le « purpose alignment model ». Celui-ci permet de qualifier les éléments d’un portefeuille de projets par rapport aux axes différentiateurs de l’entreprise. Bref, un bel exemple de discrimination par la valeur. Mais surtout un modèle pleinement utilisable tous les jours. Certainement le plus utile du livre !

Le chapitre 3 a trait à la collaboration, c’est l’aspect « stand back » du titre. Ici les auteurs, au long des 25 pages de ce chapitre, nous proposent 3 outils :

  • Collaboration steps : Comment créer le contexte qui va inviter les participants à réellement collaborer.
  • Collaboration process : Comment initier et maintenir une collaboration vers un but défini, où l’énergie est maintenue par les participants.
  • Leading Collaboration : En tant que leader, quel est votre rôle et quelle doit être votre posture pour permettre au projet d’avancer dans la bonne direction ?

Le chapitre 4 consacre ses 25 pages au delivery. Les auteurs y développent le « context leadership model », qui combine incertitudes et complexité pour former 4 quadrants. Un modèle simple mais que je trouve moins utile que le purpose alignment model. Chaque quadrant appelle un comportement adéquat du leader.

Le chapitre 5 développe aussi sur 25 pages la question de la décision. Et celle-ci est directement relative à la question de la valeur. C’est d’ailleurs le modèle de la construction de la valeur qui est au centre de cette partie.

Le chapitre 6, quand à lui, compte 20 pages et s’intitule « leadership tipping point ». C’est donc encore de leadership dont il est question ici, mais il s’agit de la posture du leader par rapport à l’équipe : à quel moment celui-ci doit prendre du recul pour laisser l’équipe opérer. A quel moment peut-il reprendre les manettes pour donner une impulsion nécessaire au projet ?

Finalement, ce sont moins de 10 pages qui sont consacrées au chapitre final faisant office de conclusion. Les auteurs s’y efforcent de mettre les éléments du puzzle ensemble pour en donner une vue aérienne.

Ce texte n’est ni réellement un ouvrage sur le product management, pas plus qu’il n’est consacré au project management. C’est un peu de tout cela à la fois. Je dirais qu’il s’agit d’une boite à outil orientée product management pour le leader de projet. Un projet qui serait, même si les auteurs s’en défendent, plutôt à connotation agile. Une très bonne lecture.

Référence complète : Stand Back and Deliver, Accelerating business agility – Pollyanna Pixton, Niel Nickolaisen, Todd Little & Kent McDonald – Addison Wesley 2009 – ISBN : 978 0 321 57288 2

Stand Back and Deliver: Accelerating Business Agility


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

Des applications et des patches

Le saviez-vous ?

Tout comme les bugs font référence aux insectes envahissant les premiers ordinateurs, occasionnant des erreurs, le mot « patch » fait référence à l’origine à des éléments bel et bien physiques. Il s’agit en l’occurence de pièces de papiers apposées sur les rubans perforés du Mark I, qui fut en service durant la première moitié des années 40 ! Conçu par Howard Aiken et construit par IBM, Grace Hopper en fut le premier programmeur.

Rendez-vous au Scrumday 2015 !

Le grand rendez-vous de la communauté Agile / Scrum

Que ce soit comme organisateur ou comme orateur, je n’ai encore jamais raté une édition du Scrumday ! Il en sera de même cette année. Mais c’est plutôt aux nouveaux venus que je m’adresserais cette fois-ci avec ma session Scrum Shu Ha Ri. J’avais donné celle-ci une première fois au Printemps Agile à Caen () il y a un an. Je l’ai produite une seconde fois en Anglais à Beyrouth au mois de novembre. Ce sera donc la 3ème fois que je produirais cette présentation. Non seulement ce sera probablement la dernière, mais pour ne pas trop me répéter, je ferais quelques retouches au contenu. Je devrais donc aussi faire évoluer l’article ( en conséquence…

En attendant, voici le teasing de cette session.

Scrum Shu Ha Ri
Passer à l’agilité ce n’est pas “faire de l’agile”, c’est être agile, devenir agile. Ce n’est pas une destination, mais un voyage. Scrum nous accompagne remarquablement sur les trois grandes étapes de ce voyage : le Shu, le Ha et le Ri.
Le Shu est apprentissage : appliquer correctement Scrum.
Le Ha est perfectionnement : Adopter des pratiques pour s’améliorer.
Le Ri est maîtrise : créer sa façon d’être agile en se guidant sur les valeurs de l’agilité.
Pour les nouveaux venus, cette session fera découvrir Scrum sous des jours différents au long des étapes qui constituent ce voyage.

Agile en grand !

C’est avec grand plaisir que je vois la session « Agile en grand » figurer au programme. Il s’agit d’un retour d’expérience sur le passage à l’agile du programme Linky ! Encore un REX allez-vous me dire ? Mais j’ai toutes les raisons de penser que la session que nous proposeront Jean-Hugues Hamelin et Nadim Elbaba sera bien autre chose que « encore un autre REX » !

J’accompagne aujourd’hui encore très activement ERDF sur l’agilification de ce projet sur le site Parisien. Ce sera donc un plaisir tout particulier pour moi d’y assister. Et dès maintenant je vous recommande de l’inscrire à votre programme de la journée.

Ah, une dernière chose !

N’oubliez pas que la seconde journée est consacrée à un open-space. J’ai l’idée d’y poursuivre l’aventure « en finir avec.. » à cete occasion. Mais je ne vais pas en dire plus !

Rendez-vous au Scrumday 2015 !

What is an agile tester ?

Rôle, quel rôle ?

Oui, le tester agile n’a plus la même place qu’avant. Tout d’abord, il n’y a plus d’équipe de test, mais un testeur intégré dans une équipe pluridisciplinaire ! Ce qui signifie aussi par voie de conséquence qu’il n’y a plus de phase de test. En fait, pour aller plus loin, il n’y a plus non plus de rôle de testeur !

La qualité est désormais l’affaire de tous, on passe de la notion d’assurance qualité à celle d’assistance qualité. C’est pourquoi ce n’est plus le rôle de testeur qui primer mais la compétence qu’il véhicule et injecte dans l’équipe. Kniberg nous débarque le concept de « T shape compétences », que personnellement je n’aime pas trop.

S’assurer que le produit marche

L’assistance qualité, dans une équipe agile recouvre un certain nombre d’activité que l’auteur nous énumère. Mais surtout, le testeur agile doit travailler en interaction avec les développeurs et les utilisateurs afin de toujours raccourcir la boucle de feedback, une idée qui s’inscrit bien dans la philosophie du « continuous delivery ».

Parlons tests

A un moment donné il faut bien parler tests. Mais de quel tests ? Petite leçon de vocabulaire de la part d’Henrik, et aussi de la nécessité des tests exploratoires… et d’inclure la dette technique dans la notion de qualité.

Kniberg nous propose aussi de maintenir un « tests automation backlog », et aussi un « tech backlog » qui s’injecte dans les sprints en fonction d’une bande passante réservée.

Pendant ce temps, chez Spotify…

Kniberg est aussi connu pour avoir popularisé le mode de fonctionnement chez Spotify. Je ne vais pas revenir dessus, cela a été largement exposé. La culture Spotify amène par ailleurs à privilégier le « failure recovery » au « failure avoidance », selon une approche que l’auteur appelle le « limited blast radius ».

Big government

Chez ces institutionnels, la structuration en phases est de mise, une approche que nous agilistes abborhons. A cette approche, Henrik Kniberg propose comme alternative une approche Kanban en « multi-swimlanes ». La présence de plusieurs équipes permet aux testeurs (et aux autres communautés aussi, d’ailleurs) de se synchroniser au sein de stand-up transverses.

Une autre pratique spécifique aux tests au sein de ce type de projet : le « ready for system tests », qui est un moyen d’intégrer les tests système au sein des itérations.

Un process spécifique de traitement des anomalies peut aussi s’avérer nécessaire. Piètre constat mais que j’ai moi-même fait à différentes occasions.

Parlons outils pour Kanban !

Eh oui, malgré que le manifeste nous assène que « les hommes sont plus importants que les outils », cela ne nous empêche pas de faire le plein à une soirée exclusivement consacrée aux outils ! D’ailleurs j’en étais, mais je suis arrivé un peu en retard… Essayons de rattraper celui-ci !

Thomas Declercq, ou comment étendre TFS

Thomas est manager chez AXA, à Lille plus exactement. Ici, on utilise les outils Microsoft, donc TFS pour faire du développement en .NET ; rien que de très logique. Les grands comptes sont rarement sur les dernières versions des outils, on vient donc tout juste de passer de TFS 2010 à TFS 2013. Et l’outil montre ses limites pour suivre des métriques. Alors si l’on a pu fort logiquement commencer avec des exports de données puis du bricolage sous Excel, l’équipe a fini par se lasser de ce travail et a envisagé des outils se branchant sur les API de TFS. On parle ici de 3 outils internes.

Outil #1 : Le Kanban board

Il n’est pas beau, il a été développé entre la poire et le fromage, car l’équipe en avait besoin mais personne ne voulait payer pour … et il est très utilisé ! Ils en avaient besoin, car la solution initiale, c’était des extracts CSV de TFS injectés ensuite dans Excel. Un travail à la longue très fastidieux.

Donc, cette application faisant grand usage d’AngularJS s’adosse directement à TFS sans même posséder son propre modèle de données. Elle montre simplement les données de TFS sous forme Kanban (chaque équipe a son Kanban) et permet de calculer les temps de cycle, d’afficher le CFD, etc…

Un outil beaucoup utilisé par les Scrum Masters et les PO (les PO sont à Paris alors que l’équipe est à Lille).

Outil #2 : Project Report

Oui, malgré que l’on soit en mode agile, le management continue à demander des reports comme au bon vieux temps. Là aussi la motivation est de permettre de générer cela en économisant l’énergie à produire ces rapports, car tout comme dans l’outil précédent, les données sont directement issues de TFS.

Pour l’essentiel il s’agit de données agrégées des projets pour permettre d’avoir un indicateur global du projet en un coup d’oeil. Cet appréciation va même jusqu’à l’aspect budgétaire !

Outil #3 : Quality Report

Comme pour le second outil, il s’agit là d’avoir des vues synthétiques d’information. Mais cette fois ce sont des informations sur le code et les builds ! Cet outil semble moins pertinent avec la dernière mouture de TFS, mais son architecture lui permettrait d’être frontal d’autres outils comme Jira, car il est agnostique par rapport au back-end.

Et par rapport aux boards physiques ?

La position prise dépend des équipes. Pour Thomas, la bonne position consiste à utiliser … le board physique autant que possible. Il permet un niveau d’appréhension et de personnalisation que ne permettent pas aujourd’hui les outils électroniques. La plus grande plus-value de ceux-cis se situe à deux niveaux :

  • La communication entre équipes distantes.
  • La génération automatique d’indicateurs.

Jira Agile, par Basile Le Plessis

Basile est très à l’aise avec Jira Agile, un outil qu’il déploie très régulièrement dans des équipes. A l’origine, cet outil s’appelait Greenhopper. L’outil permet d’accéder à deux types de boards (qui sont en fait des vues vers les tickets Jira) :

  • Un board Scrum
  • Un board Kanban

Ces deux boards ne présentent pas les mêmes fonctions, et c’est en fait le board Scrum qui est le plus riche des deux. Par défaut l’outil proposera un board avec 4 colonnes qui correspondent à autant d’état du workflow Jira. Mais ces colonnes sont évidemment configurables (3 grands types : A faire, en cours, terminé), chaque colonne pouvant d’ailleurs représenter une conjonction d’états ! La flexibilité de cette configuration a un revers : si on se rate, on peut créer des tickets qui ne sont pas visibles sur le board !

Il est également possible d’ajouter des swimlanes, ainsi qu’un ensemble d’ajouts tels que des « filtres rapides » des couleurs associées à des sous-requêtes, etc…

Tout est configurable dans Jira, c’est sa grande force. Mais cela demande une bonne prise en main, car l’ergonomie tourne souvent au cauchemar sur tout ce volet configuration… D’ailleurs si Jira Agile est le successeur de Greenhopper, l’ergonomie semble estimée en retrait par rapport à la première mouture !

En parlant de configuration, il y a quand même quelques contraintes, entre autre sur l’édition de workflow et la réversibilité des migrations (ok, j’en demande beaucoup).

Par contre, l’outil hérite des capacité d’extensibilité de comportements et de modules de Jira. Il est par exemple possible d’associer des comportements aux transitions d’état. Et les modules Jira sont déjà un écosystème très riche !

Agile Bee, par Laurène Vol

Bee, c’est essentiellement un tableau de bord pour les projets menés en Agile, un tableau de bord à même de montrer un portefeuille de projets et d’en donner une vue uniforme. Pourquoi ?

  • Pour le décideur, pour lui donner de la visibilité sur les livraisons en extrapolant le « quand » on livre.
  • Pour l’équipe, lui permettre de suivre les indicateurs opérationnels.

De mon point de vue, il semble s’adresser avant tout aux décideurs.

Maintenant, d’un point de vue pratique, comme cela marche-t-il ? Les données doivent être extraites de Jira ou de TFS, etc… en format CSV, puis intégrées dans Bee. C’est assez rustique. La connexion via des APIs devrait arriver dans une version ultérieure. La bête est hébergée sur Heroku, c’est donc avant tout un outil SAS, même s’il peut être déployé chez les clients (avec les difficultés de mise à jour que l’on connait).

L’outil rappelle un peu le « happy board » d’AXA, avec des indicateurs tels que :

  • Atterrissage du backlog (via des extrapolations calculées sur 3 itérations).
  • Suivi budgétaire on track / off track ; il permet également de déduire le coût moyen des stories. En pratique, ce suivi s’appuie simplement sur le nombre de stories réalisées dans l’itération et le « coût » d’une itération.
  • Les Bugs, dont le ratio de bugs et le suivi des bugs ouverts et fermés.
  • La Productivité (quand je vous disais que cela intéressait avant tout les managers…). Son suivi se base sur le flux et la cadence et son évolution au fil du temps.
  • Feature matrix : une fonctionnalité permettant l’agrégation de stories par MMF.
  • Calcul de la prédictibilité, en se basant sur une vision flux.

Le point réellement fort de cet outil est son ergonomie et la qualité de son rendu visuel. Tout est très bien fait jusque dans les moindres détails.

Kantree

C’est l’invité surprise de ce meetup ! Kantree est un  produit est développé par une petite société, le démarrage de ce projet étant surtout guidé par la passion ! L’outil s’inspire profondément de Trello, l’ergonomie respire de cette inspiration (si je puis dire). La grande différence est que Kantree permet une gestion de boards multi-niveaux : chaque carte peut elle-même devenir un board ! Chaque niveau de board peut par ailleurs avoir son propre workflow.

Au-delà des boards multi-niveaux, l’équipe travaille activement à des fonctions se différenciant de Trello : association d’une date à une tâche, synchronisation avec Github et personnalisation des attributs.

Cette sympathique équipe investit beaucoup sur le développement de cet outil dans le but de développer une activité d’éditeur autour. Cela me laisse dubitatif, car même s’il présente des particularités intéressantes, le marché est déjà bien occupé par des éditeurs avec une forte présence. De plus ce type d’outil est exposé à terme à une « comoditisation » et est destiné à perdre de la valeur. Du moins à mon avis.

Autour d’un verre

L’agenda de la soirée était plutôt riche et chargé, un style auquel le FKUG commence à être coutumier. Il est maintenant temps de tailler dans le saucisson et la canette de bière. J’en profite pour échanger avec Thomas Declercq à propos de la question « tableau physique versus tableau électronique ».

Thomas est un fervent du tableau physique : il permet une vue globale, d’embrasser l’ensemble du projet ou de se focaliser sur un point en particulier. On peut adapter l’affichage contextuellement pour attirer l’attention sur des points particuliers, etc. Le tout avec une souplesse que ne permettent pas les boards électroniques. Mais les boards électroniques sont pratiquement indispensables pour des équipes géographiquement dispersées et permettent la tenue à jour d’indicateurs, chose trop pénible en mode manuel. Des points de vue envers lesquels j’abonde.

Note de lecture : Use Cases : Requirements in Context, par Daryl Kulak & Eamonn Guiney

Note : 6 ; Bonne mise en pratique du cycle itératif et de bonnes idées, mais pas entièrement concluant.

Ce livre présente les cas d’utilisation dans le cadre d’un processus itératif, en fait celui d’Unfied Process. A ce titre, il propose une approche incrémentale pour la spécification des cas d’utilisation, basée sur celle de Craig Larman. Cet ouvrage taille aussi un short à la gestion des exigences, par rapport auxquels les auteurs préfèrent la spécification des règles métier, même si en fait c’est surtout la production de gros documents de spécification monoblocs qui est remise en cause. La description des spécifications incrémentale est réellement valable et concrète, et de plus desservie par des exemples concrets en annexe.

La construction du livre est un peu curieuse, car les annexes forment la moitié de l’ouvrage, le texte principal ne comptant que 170 pages structurées en 11 chapitres. Le premier d’entre-eux consacre ses 18 pages à l’identification des problèmes liés à l’approche classique. La prose manque un peu d’élan lyrique, mais s’efforce néanmoins de bien synthétiser ces points d’achoppement. Disons que le boulot est fait.

Le second chapitre s’étend sur 32 pages, il s’agit d’une introduction aux cas d’utilisation d’inspiration très « Gery Schneider ». On y aborde plutôt efficacement les basiques de la représentation des cas d’utilisation et les bonnes règles de conduite. Plus globalement on y traite aussi des cas d’utilisation dans l’environnement UML. Un chapitre rondement mené.

Le chapitre 3 aborde enfin une des originalités de l’approche des auteurs : le « business rules catalog ». Ce chapitre sert aussi d’introduction aux chapitres suivants en présentant les 4 niveaux de raffinement de ce business catalog.

Justement, c’est à la première étape de raffinement, la « façade iteration » que le chapitre 4 est dédié. Ce niveau de complétion correspond à des cas d’utilisation de niveau « résumé », avec une identification sommaire des règles métier. Les auteurs ont en fait un idée très précise de ce que signifie ce niveau de complétion. Trop même, car le processus s’avère franchement prescriptif !

Le chapitre 5 consacré au niveau de complétion suivant, le « filled iteration » suit le même schéma que le chapitre précédent, d(ailleurs il a pratiquement la même longueur. La vue très « processus » des auteurs et l’aspect répétitif des chapitres (pour ne pas parler des suivants) s’avère même un peu ennuyeuse.

On poursuit au chapitre 6 qui couvre la « focused iteration ». Un chapitre plus léger de 14 pages qui va plus droit à l’essentiel que les deux précédents. Dans la même veine, le chapitre 7 « finished iteration » est même encore plus court avec 8 pages !

Le chapitre 8 « managing requirements » est véritablement une vue gestion de projet. On y couvre des thèmes tels que la nature itérative et incrémentale du travail, la gestion des risques et les estimations.

Avec 4 pages, le chapitre 9 « working in team » est le plus court du livre. Sans rentrer dans le détail, il semble que les auteurs se soient sentis obligés de dire quelques mots sur le sujet, mais le résultat n’est ni utile ni convainquant.

Le dernier chapitre « classic mistakes » nous donne sur 15 pages des points de repère pour progresser. Hormis la présentation en tableau un peu pénible, le contenu est tout à fait valable. L’annexe A qui suit « beyond use cases » aurait pu être un chapitre du livre : on y évoque les articulations que peuvent avoir les cas d’utilisation par rapport aux autres travaux d’ingénierie. Le 5 pages de cette première annexe ne sont pas suffisantes pour couvrir décemment cet aspect. Il est mieux couvert dans « Applying Use Cases ».

Les chapitres du livre s’appuient sur un cas d’utilisation. La documentation de celle-ci dans son état finalisé est disponible dans l’annexe B. On en prend pour 140 pages : qui a envie de lire cela ?

Du coté des regrets, je ne suis guère convaincu par la séparation règles métier (qui se mappent sur les cas d’utilisation mais dont on ne peut déterminer les critères de vérification) et des spécifications non fonctionnelles (qui ressemblent à des exigences, mais ne sont pas mises en relation avec les cas d’utilisation). Je pense également que les annexes sont par trop volumineuses (elles représentent la moitié du livre), entre autre 2 exemples concrets de 60 pages chacun c’est trop. Un seul aurait suffit, et faire apparaître les différences entre 2 itérations dans une autre couleur aurait été une bonne idée.

En conclusion, le livre est raisonnablement bon, mais je continue à préférer celui de Geri Schneider. A noter qu’une seconde édition de cet ouvrage existe.

image

Référence complète : Use Cases : Requirements in Context – Daryl Kulak & Eamonn Guiney – Addison Wesley / A.C.M. Press 2000 – ISBN : 0-201-65767-8

Use Cases: Requirements In Context


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