Dev4Fun première !

Un nouveau Meetup, encore un ! Celui-ci est organisé par Xavier Detant et cette première édition se déroulait dans les locaux de Zenika !

Un beau succès pour cette première édition, car elle a rassemblé environ 30 personnes, c’est bien plus que ce que j’aurais parié. Et le groupe Meetup compte déjà 150 inscrits !

image

Ce meetup se veut une introduction douce aux coding dojos. Et pour que ce soit en douceur, c’est via la plateforme codingame. Le choix de langages est large et nous avons eu des amateurs pour Java (bien sûr), mais aussi Python, Scala, Haskell, Go et Dart ! En fait, il y a même eu du C !

image

L’une des choses sympathique de cette plateforme, outre son interactivité, c’est de fournir un canevas de code qu’il suffit de modifier. On a immédiatement une vue du résultat et les sorties pour trouver les erreurs ! Même au niveau simple, certains exercices deviennent ardus du point de vue algorithmique et l’on aurait certainement dû plus rapidement s’atteler à mettre ça sur papier. Chose que nous n’avons pas fait.

En fait, les problèmes à résoudre ne sont pas nécessairement si simple que cela. Pas évident si l’objectif est d’attirer des nouveaux venus. Par contre, j’ai trouvé le concept plutôt sympathique pour se familiariser avec de nouveaux langages.

image

Et moi, me demanderez-vous ? Eh bien j’ai fait du C ! Je ne me souvenais plus à quel point c’est bien plus bas niveau que le C++, il faut dire que la dernière fois que j’en ai fait remonte à plus de 22 ans… Pour être honnête, je n’ai pas tellement bossé (un peu quand même). Notre binôme était plutôt mal assorti, ni l’un ni l’autre n’étant probablement des binômeurs dans l’âme. Je ne pourrais être là au prochain rendez-vous, mais pour le suivant je pense plutôt recruter mon binôme à l’avance pour voir ce que cela peut donner en Go ou en Dart.

image

Les rendez-vous devraient en principe avoir lieu les 3ème jeudi de chaque mois. Les quelques prochains meetups devraient se poursuivre sur la plateforme codingame. Mais déjà il est question de varier un peu la formule afin de ne pas tomber dans la monotonie. Quoi qu’il en soit, cette première édition est incontestablement un succès !

Note de lecture : Pragmatic guide to GIT, par Travis Swicegood

Note : 5 ; Globalement efficace mais parfois frustrant

Le principe de cet ouvrage est excellent : 130 pages, un format de poche et 44 « taches » qui sont autant de recettes longues de 2 ou 3 pages réparties en 8 chapitres. On est sensé avoir là de la matière concrète pour utiliser Git au jour le jour, non selon la description de la ligne de commande, mais rapport aux cas d’usage !

Heureusement le tout est organisé en 8 chapitres correspondant à autant de cas d’usage. Le premier d’entre-eux a trait à l’installation et au setup de Git. De ce point de vue les 4 recettes constituant ce chapitre sont un peu courtes par rapport au sujet traité.

Le second chapitre regroupe 8 recettes gravitant autour des tâches locales du développeur est mieux adapté au format des tâches. Il permet de s’y retrouver avec les tâches courantes : ajout de fichier, suppression, déplacement, pull, etc..

Les 6 tâches évoquées au chapitre 3 permettent d’organiser et réorganiser un répo et ses branches en les créant, les mergeant ou via un rebase. La plupart de ces recettes ont le bon goût d’être illustré d’un petit schéma. L’auteur aurait pu étendre cette pratique avec profit à nombre d’autres tâches décrites dans l’ouvrage. Mon regret avec ce chapitre est qu’il traité de l’organisation du repo sous forme de tâches, c’est à dire sous l’angle de ce que Git peut faire, et non sous l’angle pattern / stratégie qui aurait un peu élevé le niveau de réflexion.

Cette remarque pourrait s’étendre aux 5 tâches décrites au chapitre 4 et dévolues aux pratiques de travail en équipe. Les tâches décrites ici ont trait aux branches remote et à la recherche des changements. Plus encore qu’au chapitre précédent j’aurais apprécié une remise dans le contexte d’un travail quotidien…

Le chapitre 5 traite de fonctionnalités avancées ou plus exactement particulières à Git telles que le Cherry picking. Le format de description des tâches est presque toujours trop court pour aider à comprendre la mise en œuvre de ces options. Bref, un chapitre réellement frustrant.

Au chapitre 6, on explore les différentes manières d’aller rechercher une information dans le repository. Les 5 tâches qui y figurent sont à la fois trop et pas assez. Trop, car on va au-delà de la recette de cuisine à l’usage de tous les jours, même si on peut se féliciter de les avoir. Et pas assez car cela reste très superficiel, tout d’abord avec seulement 5 tâches décrites et sur un format qui reste incomplet.

J’ai trouvé le chapitre 7 précieux car il nous enseigne comment utiliser Git pour corriger non seulement ce qui figure dans le repository mais pour trouver des bugs, comme avec bisect par exemple. Le format de description remplit ici pleinement son office.

Le dernier chapitre est un petit fourre-tout pour « aller plus loin » : exporter son repo, synchroniser avec Subversion, etc. En fait il s’agit surtout de tâches qui ne rentraient pas dans un autre chapitre. Ce dernier chapitre ne m’a pas paru indispensable eut égard à la cible du texte.

Je dirais que l’opuscule atteint sa cible à moitié : les cas d’usage sont bien choisis, depuis les usages courants aux utilisations avancées. Les explications sont claires, quoique parfois un peu élidées. Mais il nous manque souvent de petits graphiques à l’image de ceux qui ont servit à l’illustration du début du livre. Cela a suffit pour que je me retrouve perdu à quelques occasions.

J’aurais surtout apprécié, soit en sus, soit en remplacement, des patterns d’usage de Git de plus haut niveau déclinant comment les mettre en œuvre à l’aide de Git. Une sorte d’instanciation des configuration patterns en quelque sorte…

Bref, sans être mauvais, je suis un peu déçu par ce livre qui ne m’a pas apporté tout ce que j’en attendais.

image

Référence complète : Pragmatic guide to GIT – Travis Swicegood – Pragmatic Bookshelf 2010 – ISBN : 978 1 93435 672 2

Pragmatic Guide to Git

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

Focus

Chap 1 : Où l’on parle de flux

Le focus, au niveau de l’entreprise, qu’est-ce que cela signifie ? En premier lieu, de se concentrer sur la chaine de valeur. Et sur le flux, plutôt que l’utilisation des ressources. Le Value Stream Mapping est un des outils permettant de mettre en évidence les possibilités d’amélioration de ce flux.

Le corollaire est de se concentrer sur un petit nombre de features plutôt que sur des gros batches qui mettent du temps à passer dans le rétroviseur. Donc du Focus !

Chap 2 : Se faciliter la vie

Nous avons vu le problème du « trop de choses à faire ». Et le temps pour le faire est limité. Bien entendu, nous avons moins de temps disponible que de choses à faire. Mais en réalité celles qui sont indispensables n’en sont qu’une fraction. On pourrait appeler le reste des « options » ! Nous sommes maitres de nos choix, n’en devenons pas les esclaves.

Chap 3 : Tel un hamster dans sa roue

Les sollicitations nous viennent de toute part ! Elles créent un bruit qui nous empêche de faire ce qui est important. S’isoler de ces perturbations et se concentrer sur une seule chose jusqu’à ce qu’elle soit terminée, il n’y a rien de nouveau là. Quelques techniques peuvent nous aider comme le « zéro inbox » ou le Pomodoro.

Chap 4 : « non, merci »

Nous avons du mal à dire « non ». En tout cas, moi j’ai cette difficulté. Quand, comment et pourquoi dire « non », afin de se focaliser sur ce qui a vraiment de la valeur, c’est le sujet de cette partie. C’est ce que Henrik Kniberg appelle le « value filter ».

Chap 5 : s’échapper de la roue du hamster

Une seule règle : se ménager du mou. Mais du mou qui nous remettre dans une boucle vertueuse … pour enfin sortir du cercle vicieux !

Chap 6 : Ce que nous faisons définit là où nous sommes

Cela signifie (en clair), que pour être maître de notre destin, nous devons nous efforcer de donner la priorité aux tâches nous conduisant à ce que nous voulons faire. C’est un peu un raccourcis, mais c’est un peu l’idée ! Donc travaillons notre répartion de ccharge de travail, non pas en fonction des nécessités du moment (en tout cas pas seulement), mais en fonction de ce que l’on veut qu’elle soit !

Chap 7 : Une histoire (très) personnelle

Où Henrik Kniberg nous parle de son voyage autour du monde avec sa famille. Une approche qui me rapelle en de nombreux points le « solution focus » : plutôt que de lister ce qui nous empêche de le faire, se focaliser sur ce qui est nécessaire pour rendre cela possible. Et planifier ensuite ce qu’il y a à faire ou les expérimentations à mener qui vont valider les hypothèses.

Plus amusant, ce que les enfants ont appris sur la rationalisation de leurs affaires, qu’ils ont ensuite appliqué en rentrant à la maison !
Cet épisode a été largement exposé dans agile@home !

Chap 8 : World WIP Waste

La réutilisation n’est probablement pas du gâchis, car Henrik Kniberg se ressert à tour de bras du matériel de agile@home !

Le gâchis, c’est ce qui nous empêche d’aller vite, donc d’être agile. Dit autrement : on cours moins vite avec des bottes en plomb !

Meetup Craftsmanship : où il est (aussi) question de documentation…

C’est dans les locaux de Zenika que s’est déroulé ce nouveau meetup Craftsmanship, en fait le premier pour moi ! Cyrille Martraire sera le maître de cérémonie, il introduit le déroulement de la soirée, à savoir : 2 lightning talks, 1 talk moins light et enfin le coeur de cette soirée, l’open-space

image

Alors, Dev4Fun, qu’est-ce que c’est ?

Xavier Detant est venu nous présenter un nouveau meetup, non pas concurrent, mais complémentaire à Software Craftsmanship : Dev4Fun !

image

Dev4Fun, c’est un « coding dojo », mais sans le mot « dojo », car ciblant plus les débutants. Pour rendre cela Fun, on s’appuiera, au moins pour la prochaine rencontre planifiée pour le 22 Janvier, sur une plateforme dédie au développement de code sur des jeux : codingame.

Bref cette rencontre a pour but de faire découvrir, comme le dit Xavier « pourquoi on kiffe sur les barres vertes » !

Comment amener les changements techniques dans l’entreprise ?

Cette présentation avait pour but de donner un coup de projecteur sur ce sujet issu du livre de Sandro Mancuso sur le Software Craftsmanship. Plus précisément, il est question ici de classifier les profils d’une équipe afin d’adopter la bonne stratégie en fonction des interlocuteurs !

image

On trouvera ainsi :

  • Le Non-Informé : Il ignore tout du sujet, on peut l’amener à bord en partant de zéro.
  • Le mouton : Pas la peine de s’en préoccuper. Si on embarque les autres, il suivra.
  • Le cynique : Il va prendre le contre-pied juste pour le plaisir de se montrer plus malin. Attention de ne pas perdre trop de temps avec lui.
  • Le désabusé : Il a essayé des choses et s’en est mordu les doigts, il n’a plus le goût à essayer.
  • Le surbooqué : Il n’a pas le temps de vous écouter
  • Le boss : Ne pas perdre de temps avec lui, car de toute façon, il n’y cmprendra rien.
  • L’irrationnel : c’est le cynique mais en pire ! Il va contre-argumenter sans but et va vous faire perdre du temps.
  • L’indifférent : Il ne se sent pas impliqué, mais attention ! Il peut être la source de mauvaises implémentations de bonnes idées.
  • Le persécuté : Il nuit au projet en attendant sa prime de licenciement. A écarter à tout prix.
  • L’inapte : Simplement pas à sa place. A éviter.
  • L’architecte « tour d’ivoire » : Il croit tout savoir mais ne touche plus au code. Attention, il peut avoir beaucoup d’influence…
  • L’inscure : Il s’est construit son petit confort, mais il est « has been » et a peur que l’on s’en rende compte.
  • Le fan boy : Implémente le pattern « golden hammer » avec une technologie qu’il admire et connait très bien. Mais si on peut le convertir…

Dans ce tableau idylique, il manque bien sûr le gars normal ! Comme le souligne l’orateur, identifier les profils, c’est déjà 50% du travail. Sur le fond, je trouve ici une matière un peu intéressante mais pas révolutionnaire. En fait, c’est une vision très simplifiée de ce que l’on peut trouver dans Fearless Change. Quand au livre, vous pouvez en voir un excellent résumé ici.

Does your code speak business ?

Pas un lightning talk ici, mais plutôt une présentation de 30 minutes (avec les petits soucis techniques qui l’ont émaillée). Maxime énonce le problème qu’il veut traiter ainsi : comment ajouter de la valeur si votre code ne parle pas métier. A titre de contre-exemple, il nous assène le syndrome de l’homme fort ! Vous savez, celui qui écrit un code incompréhensible plus vite que son ombre, qu’il ne faut jamais déranger et qui au final livre une usine à gaz à côté de la plaque ?

image

L’homme fort n’est pas le seul syndrome. De manière générale, on rencontre nombre d’équipe où le business et l’équipe de développement utilisent des vocabulaires différents ! Un problème encore amplifié par les modèles de développement en silos où le besoin initial fait l’objet de traductions successives…

image

La solution ? Le fameux « ubiquitous language » du DDD. Mais l’orateur nous invite à ne pas en rester là : pour découvrir ce vocabulaire, parlons Event Storming ! Il s’agit d’une approche proposée par Alberto Brandolini, elle prend la forme d’un workshop dans lequel on invite « des personnes avec des questions (les développeurs) et des personnes avec des réponses (le business) ». On part de « l’évènement le plus important dans le système » et on remonte dans le temps. A chaque évènement correspondra une commande et au final on sura comment le système doit se comporter.

Je ne connaissais pas l’Event Storming, un nouvel outil à considérer sérieusement !

Open-space : alors, cette doc ?

Oui, c’est un open-space, vous savez celui où on forme des groupes, on propose des sujets et on vote sur ceux-ci. Le zLocalHost de Zenika a fait le plein et nos 3 cercles sont un peu enchevêtrés…

image

Donc, on propose des sujets…

image

Puis on vote ! Je vais m’incruster dans le groupe qui parlera de documentation !

image

La discussion démarre sur les chapeaux de roues : moi j’utilise Sharepoint, moi un Wiki … Mais un instant : La documentation n’est qu’un moyen, non ? Quelle finalité cherche-t-on à atteindre avec cette documentation dont on pense implicitement qu’elle est indispensable ? Car là, on commence à parler du moyen du moyen !

Visiblement, la finalité, c’est souvent de transmettre de l’information quand quelqu’un part ou qu’un nouveau membre de l’équipe arrive. Un bien pauvre substitut au partage du savoir que l’on obtient en travaillant ensemble. On évoque aussi les tests, plus précisément les acceptance tests en tant que « living documentation ».

image

Pour en revenir à la documentation sensu-stricto, je relève :

  • Que je ne suis pas le seul à avoir des problèmes pour m’y retrouver dans les Wiki. Cyrille semble avoir le même problème que moi. Donc un bon moteur de recherche full-text y est indispensable.
  • Coupler la documentation avec la gestion de version, une option importante.
  • Les nomenclatures de noms de documents ou de répertoire, ça fait peut-être « old school », mais ça marche !
  • Le problème de la divergence de la documentation avec la réalité : un obstacle sur lequel on finit toujours par arriver. Pourtant on reste câblé sur l’idée de la documentation qui sauve de tout…
  • Les docs de haut niveau sont finalement celles qui sont le plus souvent demandées et utiles. Outre qu’elles ne sont pas trop volumineuses, elles souffrent moins du phénomène d’obsolescence, donc plus faciles à maintenir.

Cet échange n’a pas révolutionné mais idées, mais il était agréable. Les 2/3 choses que j’ai notées au passage ne feront pas de mal !

Assez bossé, il est temps de migrer vers le buffet pour conclure la soirée !

image

The New New Product Development game, par takeuchi et Nonaka

Cette publication est connue pour être la source d’inspiration des créateurs de Scrum. Il fut publié en 1986 dans le Harvard Business Review et Hirotaka Takeuchi et Ikujiro Nonaka en sont les auteurs. Ils viennent du marketing et non du développement logiciel.

Les 6 caractéristiques du “Scrum”

On parle bien déjà de Scrum ! Et l’on prête à ce processus 6 propriétés fondamentales :

  • Une instabilité intrinsèque : le top management ne donne aux équipes qu’une direction générale avec un challenge très élevé à relever. Par ailleurs ce management donne une grande liberté d’action et d’interprétation. Cela crée une tension dans l’équipe à même de favoriser la créativité.
  • Des équipes auto-organisées. Elle apparait quand sont réunies 3 conditions :
  • L’autonomie : peu d’intervention du top management, son rôle est de fournir les ressources adéquates. L’entité fonctionne comme une startup.
  • L’auto-transcendance : L’équipe est dans une quête continuelle pour dépasser ses limites.
  • L’auto-fertilisation : une équipe pluri-disciplinaire renforçant leur connaissances respectives à l’image d’un impact hub.

Des phases de développement en chevauchement : le rythme de développement agit comme le poul de l’équipe. Pour permettre le développement selon ces phases courtes, il faut adopter le “sashimi system”. Le multi-apprentissage : il s’effectue à différents niveaux (individuel, collectif, entreprise) et dans les différents domaines d’expertise de l’équipe.

  • Le contrôle subtil : le management influe par petites touches sur l’équipe pour prévenir le chaos. Les auteurs identifient 7 axes d’action :
  • La sélection des membres de l’équipe
  • L’environnement de travail
  • L’encouragement à voir ce qu’il en est sur le terrain (où l’on rejoint le Lean…)
  • Une évaluation et des récompenses au niveau du groupe et non au niveau individuel
  • Gérer des différences de rythmes entre le début et la fin du projet.
  • Tolérer et anticiper les erreurs.
  • Encourager les fournisseurs à devenir eu-même auto-organisés.

La gestion du transfert de connaissance : Il est réalisé de manière osmotique, en réaffectant les membres de l’équipes sur d’autres équipes une fois le projet terminé.

Limitations et implication du management

  • On parle ici d’efforts extraordinaire, de journées de 60 heures ou plus … on est loin du “sustainable pace"…
  • Ce processus ne s’applique pas aux projets d’innovation disruptive
  • Il ne s’applique pas aux organisations centrées autour d’un "génie”.

Au niveau managérial, il faut 3 changements :

  • Un style de management promouvant ce processus.
  • Le management doit accepter que le développement des produits ne s’opère pas linéairement mais itérativement.
  • Le processus implique une suite d’essais / erreurs.

Les entreprises ont pour habitude de voir les projets innovants comme de nouvelles sources de revenus. Mais ils sont en fait avant tout des agents du changement. C’est donc avant tout un changement culturel.

Note de lecture : Essential Scrum, par Kenneth S. Rubin

Note : 8 ; La référence sur Scrum, à la hauteur des ouvrages de Mike Cohn

Le nom de l’auteur ne m’évoquait rien jusqu’à présent. Mais Kenneth Rubin n’est pas seulement un vieux routier de l’informatique et de l’agilité, il fut aussi le premier chairman de la Scrum Alliance ! La motivation de l’auteur était, pour cet ouvrage, de réaliser un texte de référence sur Scrum, que l’on puisse prendre avec soi et qui suffise lorsque l’on se pose une question sur la mise en œuvre de Scrum. Je vais certainement casser le suspens, mais c’est pour moi mission accomplie. En prenant un peu de recul, on peut constater que les points abordés tombent dans 3 catégories.

  • Les éléments et pratiques qui font partie du cœur de Scrum. C’est ce que l’on va trouver dans le Scrum Guide, par exemple, ou dans les 3 ouvrages de Ken Schwaber.
  • Les pratiques généralement admises dans la mise en œuvre de Scrum, mais qui ne font pas partie du framework officiel. Ce sont par exemples les pratiques empruntées à l’Extreme Programming. A ce titre, c’est ce que nous pourrons rencontrer dans l’excellent « Scrum from the Trenches » de Kniberg ou le livre en Français sur Scrum de Claude Aubry.
  • Les pratiques avancées qui peuvent compléter Scrum. Nous pouvons penser au Management 3.0 de Jurgen Appelo ou au Lean Startup…

Ce livre vise à couvrir complètement les deux premiers aspects et une bonne partie du 3ème. C’est un vrai texte pratique qui ne se limite pas à ce que l’on doit faire, mais surtout développe le « comment ». On s’appuie ici sur une prose de bonne qualité (je l’ai comparé à Mike Cohn tout à l’heure), mais aussi sur une abondante illustration. Le tout pèse benoitement ses 400 pages, c’est le prix à payer ! Au niveau du contenu, il faut compter avec 23 chapitres regroupés en 4 parties principales.

Le premier chapitre est une courte introduction sur la raison d’être de Scrum. Un peu ce que l’on retrouve dans « Software in 30 days », mais mieux écrit. C’est expédié en 10 pages.

La première partie regroupe 7 chapitres sur un peu plus de 150 pages et est dédiée aux « core concepts ». On commence très classiquement par un chapitre 2 justement nommé « the Scrum Framework » de 15 pages. Juste Scrum, rien que Scrum. C’est ce que couvre le Scrum Guide, rien à ajouter.

Ce sont aux principes agiles qu’est consacré le chapitre suivant. Par principes on entend : gestion du changement, taille des lots (WIP size) ou coût du délais, le tout comparé aux approches « plan driven ». Un chapitre un peu dense, dont les 30 pages ciblent plutôt le middle management et les décideurs. On reste encore beaucoup dans les principes avec les 17 pages du chapitre 4 consacré aux sprints : à quoi sert le timeboxing, les conséquence d’un changement en cours de sprint, etc. On retrouve un propos plus en phase avec les préoccupations du praticien. « requirements et user stories » qui est le titre du chapitre 5, c’est un bon condensé de ce que l’on trouvera dans l’ouvrage de Mike Cohn sur le sujet. C’est une sorte de MVP des stories pour partir du bon pied. Le chapitre 6 consacré au backlog continue sur cette lancée mais couvre également les cas particuliers de backlogs multi-équipe et autres spécificités. Les 20 pages destinées aux estimations sont aussi un condensé d’Agile Estimating and Planning de Cohn. Mais c’est très bon et suffisant pour démarrer. Le sujet des dettes techniques tient visiblement à cœur pour l’auteur, les 23 pages qui sont dédiées à ce point sont un peu en décalage avec les chapitres précédent. Le sujet est traité sous l’angle économique, qui distribue la nature de cette dette en 4 catégories.

La seconde partie est consacrée aux rôles de scrum, enfin à une couverture un peu plus large que les rôles officiels. On leur dédie 5 chapitres sur un peu moins de 100 pages. Contrairement à moi, l’auteur s’accroche à la séparation des rôles « by the book », avec un chapitre 9 consacré au Product Owner, complet et bien fait, où il est toutefois admis que l’ensemble des compétences demandées ne se retrouvent pas forcément en un seul homme… Le chapitre 10 est logiquement dédié au Scrum Master. Là aussi je diffère de l’auteur qui préfère le SM « professionnel » quite à se qu’il s’occupe de plusieurs équipes. Les 8 pages dédiées au sujet paraissent étrangement peu. L’équipe est traitée au chapitre 11. Il est beaucoup question de polyvalence au long de ces 16 pages, mais aussi de « profil en T » que je vois rarement évoqué. Le modèle a ses limites, à mon avis. Une dizaine de pages sont consacrées à la question du « team structure ». Sceptique sur l’intérêt du sujet de prime abord, j’avoue que l’auteur fait du bon boulot à opposer le « feature team » au « component team » et à évoquer le travail en équipes multiples. Le chapitre 13 qui clot cette partie est dédié au management. On sort un peu de Scrum pour aborder des questions qui sont reprises du Management 3.0 de Jurgen Appelo.

La troisième partie sort en grande partie du « Scrum by the book ». Elle est intitulée « planning » et couvre 5 chapitres sur 90 pages. Le chapitre 14 sert d’introduction et aborde sur 8 pages les principes économiques sous-tendant la manière d’aborder la planification agile. Le chapitre 15 sert de guide au reste de cette 3ème partie en reprenant le « multi-level planing » que Rallye Software évoquait déjà en 2006. Le chapitre 16 embraye donc sur la planification de portefeuille qui sort du cadre projet. Disons que le sujet n’est pas mal abordé sur une vingtaine de pages, bien qu’il lui manque un volet réellement pratique. Le chapitre 17 « envisonning » semble être un sujet qui passionne l’auteur. Il lui dédie même un début d’étude de cas, ce dont on n’a pas eu le droit avant. Et on y évoque aussi le release plan du projet et le « validated learning » du Lean Startup ! Ce sont 25 pages qui sont consacrés au release planning traité au chapitre 18. Je ne suis pas fan du sujet, mais il est fort bien traité en y intégrant plusieurs stratégies de contraintes.

J’aurais préféré voir cette quatrième partie « Sprinting » plus tôt dans l’ouvrage, car c’est quand même le cœur de Scrum ! 11 pages semblent suffire pour couvrir le Sprint planning au chapitre 19. C’est très concret, à la limite de la recette de cuisine, donc réellement exploitable. Le chapitre 20 « sprint execution » n’est pas facile à aborder car il doit traiter de ce qui se passe entre le début et la fin de Sprint. Bien sûr on y évoque le Daily Stand-up, mais aussi la communication dans l’équipe et la manière de se distribuer les tâches. Bon boulot, finalement. Très logiquement le chapitre 21 aborde la démo, pardon le « sprint review » ! Pas trop de blabla sur cette dizaine de pages et l’auteur y aborde aussi des points épineux comme le « rien à montrer » ou la démo de réalisations sous le capot ! Enfin c’est à la rétrospective que se consacre le chapitre 22. Le contenu reprend plus ou moins la trame d’Esther Derby, mais l’auteur consacre un peu plus de développement à la timeline. Pourquoi pas ? C’est mieux que de paraphraser un ouvrage déjà bien connu. Aller plus loin, c’est le thème du chapitre de clôture. C’est un peu mon « Scrum Ri ». Une bonne façon de terminer l’ouvrage.

De mon point de vue, l’objectif est atteint. Ce livre vise le même créneau que l’ouvrage de Claude Aubry : être un livre de référence sur Scrum. Je pense qu’il est un cran au dessus de son équivalent Français déjà fort honorable. Son seul réel défaut est peut-être que sa cible naturelle est constituée d’un public peu enclin à avaler un ouvrage de 400 pages.

image

Référence complète : Essential Scrum, A practical guide to the most popular agile process – Kenneth S. Rubin – Addison Wesley / Signature series 2013 – ISBN : 978 0 13 704329 3

Essential Scrum: A Practical Guide to the Most Popular Agile Process

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

Soirée « en finir avec… » organisée par le French SUG

Ca y est, je l’ai : Ma soirée mégalo à moi ! En effet, le 29 Janvier nous nous retrouverons sous l’égide du French Scrum User Group pour une soirée exceptionnelle « en finir avec… ».

Pourquoi une telle soirée ? Tout d’abord pour fair écho bien sûr à la série de post que je vous ai asséné depuis maintenant 3 étés, et que vous retrouverez encore quelque temps. Ensuite et surtout pour réfléchir ensemble à nos pratiques agiles : les comprendre et savoir les remettre en cause !

En effet, nous tenons pour acquis la nature agile des pratiques identifiées comme « bonnes pratiques ». Qu’en est-il réellement ? Quelle est la nature et l’objectif fondamental de chacune d’entre-elles ? S’inscrivent-elles vraiment dans notre système de valeur ou s’en éloignent-elles au contraire sous pretexte de compromis à un environnement aux antipodes de ce que nous voulons faire ? Notre acceptation inconditionnelle même de ces pratiques s’inscrit-elle dans un état d’esprit agile ? Mais là, je crois que nous avons déjà la réponse…

Si ma prose vous interpelle, rejoignez-nous le 29 Janvier ! Aucune promesse ne sera faite sur ce que vous pourrez en retirer, car cela dépendra largement de ce que vous saurez y apporter !

Soirée « en finir avec… » organisée par le French SUG