Our Age of Anxiety is, in great part, the result of trying to do today’s jobs with yesterday’s tools !
Marshall McLuhan
Mois : janvier 2015
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 !
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.
It always takes longer than you expect, even when you take into account Hofstadter’s Law.
Douglas Hofstadter in Gödel, Escher, Bach: An Eternal Golden Braid
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.
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
Our courage comes from the courage of others.
Simon Sinek
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.
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.
Soirée « en finir avec… » organisée par le French SUG
Connaissez vous les articles de l’agiliste fleuri ? L’objectif de cette soirée est de débattre ensemble de certains aspects dans l’agilité. Challengeons-nous et posons nous les bonnes questions…
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 !
Software Freethinker 