The best way to predict the future is to invent it.
Alan Kay (via niptech)
Retours sur le printemps agile à Caen (2/2)
Je vous avais laissé en fin de matinée de ce premier Printemps Agile. Il est temps de faire une pause déjeuner bien mérité.
Rien dans l’ostensibilité dans ce buffet, mais beaucoup en convivialité. J’avoue aussi que cette pause organisée dans une salle de TP a des allures plutôt inattendues !
Il est temps de reprendre le collier, et pour commencer, la seconde présentation de Jurgen Appelo.
Jurgen Appelo : Let’s Help Melly
Quand on aime, on ne compte pas. Et on a vraiment beaucoup aimé la première intervention de Jurgen. C’est avec plaisir que je remets le couvert pour la seconde.
Cette intervention était plutôt focalisée sur le thème de son premier livre (Management 3.0). Avec comme point de départ : comment rendre Melly (la persona qui servait de fil rouge) heureuse et productive à son travail ?
Aujourd’hui encore nous vivons majoritairement sous le joug de “l’organisation scientifique du travail”, le Taylorisme. Que nous appellerons ici “Management 1.0”. Il se traduit par un asservissement, une aliénation du travail.
Que faut-il pour dépasser cela ? Donner plus de sens à notre travail ?
Les initiatives qui vont dans ce sens sont le six sigma, Total Quality Management, Business Process Reengineering. Hélas ces initiatives n’ont jamais délivré leurs promesses. Sacrifier l’humain au profit de l’organisation ne semble pas la solution optimale.
Les cycles de changement s’accélèrent, les facteurs d’incertitude s’accroissent. Les systèmes prédictifs ne peuvent plus prétendre gérer cela.
La complexité est justement le terrain de jeu des courants de l’agilité" (Lean, Scrum, Kanban, etc…) . Si les pratiques proposées par les unes ou les autres diffèrent, il ne s’agit que de détails, et l’on retrouvera les mêmes buts et les mêmes valeurs dans différents courants de pensée :
- Scrum
- Kanban
- Beyond budgeting : abandoner l’idée des budgets annuals prévisionnels mais rendre transparents dépenses et revenus.
- Lean Startup : Créer un cycle vertueux de “validated learning”.
- Design Thinking
D’un point de vue pratique, l’adoption de l’agilité se heurte à de nombreux obstacles, les principaux étant liés au management. Jurgen Apello nous propose quelques clés de mise en oeuvre
Se mettre à l’entrainement
Donner de l’énergie aux personnes
A l’image du “Kudo Box”, une façon pour les employés de manifester leur reconnaissance envers une autre personne de l’entreprise.
Redonner du pouvoir aux équipes. Mais comment garder la direction d’une équipe auto-organisée ? En agissant sur les contraintes du système ! Le management est en charge des contraintes.
Authority board
Il y a différents niveaux de maturité du management sur la façon dont il peut manifester son autorité. L’autority Board permet de visualiser cela et même de le partager avec l’équipe.
- Demander : C’est le niveau de base, du type contrôle / commande.
- Vendre : C’est chercher à convaincre le collaborateur que ce que l’on souhaite est désirable.
- Consulter : Le manager demande l’avis de ses collaborateurs avant de prendre une décision.
- Donner le consentement : Le management n’engage l’action que lorsque les collaborateurs marquent leur accord.
- Suggérer : Le manager va laisser les collaborateurs décider de leurs actions, sur la base de conseils prodigués.
- Investiger
- Déléguer : Le management fixe les objectifs et laisse les collaborateurs fixer le plan d’action.
Aligner les contraintes
Les outils pour cela peuvent être:
- Donner le sens de la finalité.
- Permettre aux personnes de s’identifier dans l’entreprise, par exemple en leur donnant la possibilité de se choisir un nom d’équipe !
- Leur donner l’opportunité d’être fiers de leur produit !
Développer les compétences
En permettant aux personnes de s’aguerrir en continu:
- Exploration days
- Brown bag lunches (là, c’est moi)
Faire grandir la structure
S’améliorer, ce n’est pas seulement améliorer les connaissances individuelles, mais aussi améliorer les pratiques et le corpus de connaissance des groupes dans l’entreprise.
Jurgen préfère parler de “guildes” que de “communautés de pratiques” … essentiellement parce que c’est plus sexy !
Améliorer l’ensemble
C’est être en quête d’amélioration continue, mesurer le plaisir des personnes à accomplir leur travail, ou plutôt de contribuer à l’entreprise !
Alors que la présentation du matin abordait les thèmes du dernier livre (ou livret, devrais-je dire) de Jurgen Appelo “How to change the world”, celle-ci traitait des thèmes de son désormais célèbre “management 3.0”. J’ai quand même préféré l’intervention du matin, dont le message était plus simple.
Management 3.0 reste une brique de connaissance ardue, difficile à rendre en seulement 1 heure !
Retour d’expérience SAP
Un retour d’expérience, ça peut être très bon ou très mauvais. Voir très très mauvais. En fait, les niveaux intermédiaires existent aussi. Qu’en est-il de celle-ci ? Le suspens est à son comble …
J’ai plutôt bien aimé ce retour d’expérience. Je n’y ai pas appris grand chose, mais c’est interessant d’observer ce qui a été fait, lorsque c’est exposé avec honnêteté et simplicité, ce qui était le cas ici.
La division Caennaise de SAP est en fait l’acquisition d’une société nommée Highdeal. Le passage vers l’agilité y a débuté en 2009 sous l’impulsion de la maison-mère, avec un focus sur le Lean Software Developpement, donc avec une attention particulière portée sur l’élimination du gâchis ! la déclinaison des différents principes agiles s’opère comme suit :
- Flow principle : PCP (Product Creation Process)
- Takt principle : ce sont les sprints
- Pull principel : Scrum, avec un backlog prioritisé
- 0 defect : C’est la mise en oeuvre de la roue de Deming.
Voici les points ont attiré mon attention :
Le product owner
Un vrai PO pour chaque équipe, c’est un vrai plus ! L’expérience du “PO partagé” s’étant avéré non concluante.
Il porte la vision, mais fait aussi le lien avec les interlocuteurs, et ils sont nombreux : équipes distantes, parties prenantes, partenaires SAP solution.
J’ai ressenti beaucoup de satisfaction par rapport à ces PO et au fait qu’ils s’approprient les projets et se sentent partie intégrante des équipes.
Difficultés sur la mise en oeuvre de l’agilité
Le projet est gros : il nécessite un “chief Product Owner” pour encadrer les POs !
SAP est une grosse mécanique, et cela signifie beaucoup (trop) de niveaux pour atteindre le client réel … si jamais on parvient jamais à le toucher directement !
Les items du backlog semblent aujourd’hui très gros : il faut souvent plus d’une itération pour les achever ! Cela a bien sûr un impact sur la fréquence des releases : 3 à 4 par an, ce qui reste un gros progrès par rapport à l’unique release annuelle qui était le standard précédent !
Teamwork
Chaque équipe dispose d’une “war room” qui sert aux réunions et à l’affichage de tout ce qui a besoin d’être affiché. L’équipe a d’ailleurs abandonné la gestion de tickets avec Jira au profit du tableau de tâches avec les post-it.
La visibilité a grandement progressé, mais il reste encore des problèmes telles que les “tâches non identifiées” qui apparaissent en cours de sprint et ne sont pas répertoriées sur le tableau. Cela impacte de manière non mesurable la vélocité.
La taille des équipes (environ 12 personnes) me semble trop importante ! Je serais curieux de voir comment cela fonctionne concrètement : il y a-t-il de petits groupes informels qui se sont formés ? Les membres des équipes travaillent-ils de manière isolée ? Curieusement, il y avait initialement 3 équipes plus petites et ce sont les équipes qui ont choisi de se réorganiser en 2 grandes équipes !
En conclusion
Beaucoup de progrès semblent avoir été effectués en 3 ans ! Cette société vient d’une culture “waterfall” très solidement ancrée et il me semble y voir de nombreuses réminiscences. Elle mettront du temps à partir !
Les Scrum Masters mesurent la maturité de leurs pratiques agiles en utilisant l’Agile Alliance Subway : je trouve cela assez futé et très pratique. C’est la première fois que je le vois utilisé ainsi !
Agilité 2.0
Durant cette dernière session de la journée, Sylvain Saby nous a présenté sa vision du “modèle étendu” de l’agilité. Il repose sur 3 piliers
Pour bien le comprendre, Sylvain évoque le modèle water-scrum-fall Evoqué par Dave West dans un rapport Forrester !
En effet, si le modèle est itératif dans la partie développement, il ne l’est souvent pas en amont dans les activités de définition de produit, pas plus qu’il ne l’est en aval dans les activités de production !
Devops !
Commençons par la parie aval.
Le passage en production casse la livraison itérative en lotissant les mises en production. On perd la boucle de feedback avec le client final et donc une importante part des bénéfices de l’agilité.
Là où les cellules d’opérations se focalisent sur le MTBF, donc des pannes les moins fréquentes possibles, ce qui exige de longues qualifications et un rythme réduit de passages en production, devops se focalise sur le “MTTR”, ou le temps nécessaire pour réparer !
Les conséquences du passage au devops sont :
- Nécéssité d’utiliser des technologies adéquates : des serveurs qui s’installent vite et simplement, des serveurs d’application qui démarent rapidement, etc…
- Intégrer dans la conception des “switeches” permettant d’activer ou désactiver des fonctionnalités à chaud.
- Lotir les évolutions par petits incréments de changements.
- Faire évoluer le concept de “done” pour le faire aller jusqu’à la production : “done”, c’est une feature déployée en production et utilisée par des utilisateurs !
Au final, devops lisse les passage en production (lorsque le mouvement a démarré chez Flickr, on en comptait en poyenne 10 par jours !).
Lean startup
Les cycles business se raccourcissent : on compte aujourd’hui en moyenne 7 ans entre la naissance d’une startup, son apogée puis son déclin (ou son pivot) ! Des plans projets couvrant des années ou même des mois ne sont plus de mise.
La définition du produit elle-même doit être agile. L’approche Lean Sartup avec son MVP et son cycle de “validated Learning” couvre bien cet aspect.
La technologie et le rôle de l’architecte
Sylvain a beaucop insisté sur le rôle de la technologie dans ce paysage. On voit que le sujet lui tient à coeur ! Il a évoqué 3 volets plus particulièrement.
NoSQL
Les différentes moutures de bases de données NoSQL offrent plus de flexibilité pour stocker les données et surtout permettre de faire évoluer la structure des données qui y sont stockées, car elles sont “sans schéma” pour la plupart d’entre elles.
Sylvian résume leurs caractéristiques par rapport aux bases de données relationelles : elles ne sont pas faites pour classer les donnés, mais sont fortes pour retrouver ! Ou de synthétiser leurs propriétés par les “3 V”: Volume, Variété, Vélocité !
Cloud computing
L’un des freins aux évolutions logicielle est le déploiement, la gestion de la compatibilité ascendante, l’hétérogéneité des configurations et versions déployées.
Pour se débarasser de ces freins, la solution est de déployer son soft en SaaS, donc en service hébergé. Les problématiques de configurations et de déploiement se trouvent immédiatement simplifiées. Bien sûr le prix à payer est de convaincre les clients de ne plus avoir ces services en local chez eux et aussi de suivre les évolutions de version qui leur sont imposées.
Architecture des applications
Le standard d’architecture de applications actuelles est le modèle en couche. Pour rendre le SI plus agile, il faut passer à une architecture plus “verticale” où les services sont modulariés sous formes d’applications indépendantes, communiquant potentiellement par les API implémentées sous forme de Web Services REST.
Une telle architecture devient plus facile à opérer et les évolulutions y ont un moindre impact. Sylvain milite sur ce plan pour un rôle accru de l’architecte (qui n’existe pas dans Scrum) par rapport au Product Owner.
La modularité permet aussi de basculer plus facilement vers de nouveaux frameworks ou des langages plus adaptés à telle ou telle technologies au fur et à mesure de leur apparition ! Ceci a des conséquences par rapport à notre appréhension des technologies:
- Des appliations qui deviennent “jetables”.
- Pas d’investissement “longue durée” sur des technologies, mais un usage qui se limitera aux “fonctionnalités centrales” faciles à appréhender et ne demandant pas un niveau d’expertise poussé.
- Un shift vers le “monkey développer”, allant très vite sur une nouvelle technologie ou un nouveau frameworks via un “copier-coller” de code issu d’une recherche Google !
Le constat peut sembler dur, je ne suis pas certain de le partager complètement, mais surement en partie toutefois.
En conclusion
L’agilité 2.0 vue par Sylvain Saby a plusieurs corollaires:
- Une manière d’opérer les systèmes “à la devops”, selon l’adage “you build it, you run it !”.
- La fin des architecture monolithique et la nécessité mettre l’architecture au même niveau d’importance que le travail fait sur le produit.
- La nécessité de tirer les profils vers le haut : travailler avec moins de personnes, mais des personnes plus solides, productives et capables d’appréhender très vite de nouvelles technologies, de nouveaux langages…
Partir revenir
C’est pour cette première édition du printemps agile !
Bien sûr le gros coup, c’était d’avoir fait venir Jurgen Appelo : encore bravo aux organisateurs pour ce tour de force !
Le reste du programme était tout à fait honorable, à la hauteur d’un agile tour, dirais-je. J’ai pu échanger un peu avec la communauté agile Caennaise et suis donc extrêmement heureux qu’elle existe !
Cette première édition du printemps agile est un succès, aucun doute là-dessus. Tout le monde semble motivé pour remettre le couvert l’an prochain. Moi aussi !
Note de lecture : Scrum and XP from the Trenches, par Henrik Kniberg
Note : 9 ; Du vécu, rien que du vécu ! Book of the Year 2009 !
Le titre à lui seul résume la direction du livre : « comment nous pratiquons Scrum ». Pas de descriptif de Scrum ici (l’auteur renvoie pour cela à d’autres références), ni de longue dissertation sur la théorie. Sur chaque pratique l’auteur décrit de la manière la plus concise possible la façon dont il pratique cela dans son équipe et le bénéfice qui en est retiré. La concision et la valeur du texte sont tout simplement impressionnantes ! Que n’ai-je lu ce livre avant ! D’ailleurs, avec un petit format, une quantité honorable d’illustrations et seulement 130 pages, il se lit très rapidement. Une seule journée m’a suffit.
Le livre compte quand même 15 chapitres, donc forcément très courts, ce qui est un plus. On couvre ici toutes les pratiques : Le product backlog, le sprint planning, la communication, le sprint backlog, l’organisation de l’espace, le sily scrum, démos et rétrospectives. Les pratiques XP combinées à Scrum ne sont pas oubliées : Scrum et XP et TDD ont droit à leur chapitres ! L’auteur s’offre même le luxe d’aborder les sujets « avancés » : les contrats au forfait, les équipes géographiquement dispersées et laa pratique de Scrum sur plusieurs équipes.
Le livre existe en version reliée, mais aussi en PDF librement téléchargeable qui offre l’avantage d’avoir les illustrations en couleur ! Si vous pratiquez Scrum ou vous y interessez, il n’y a vraiment aucune raison de ne pas lire cet ouvrage !
Référence complète : Scrum and XP from the Trenches, how we do Scrum – Henrik Kniberg – InfoQ 2007 – ISBN : 978 1 4303 2264 1
He who knows when he can fight and when he cannot, will be victorious.
Sun Tzu (via niptech)
ScrumBeer, ScrumBeer !
Qu’est-ce que l’on fait généralement devant une bière ? On refait le monde ! Nous autres agilistes ne sommes guère différents : on se réunit, sans agenda précis, pour parler de ce qui va, ce qui va moins bien ou de ce que nous voudrions ou aurions dû faire !
La ScrumBeer, au départ, c’est une initiative d’Arnaud Villenave (au fond à gauche, sur la photo suivante). Nous sommes loin de tenir le rythme d’une rencontre par mois que nous nous étions fixé au départ, mais nous sommes quand même passé de deux (Arnaud et moi) à une petite poignée de passionnés au fil du temps.
Parfois notre GO (donc Arnaud, vous l’aurez compris) ou quelqu’un d’autre vient avec un truc à essayer. Cette fois, c’était un “delegation poker”.
J’ai fait l’impasse, mon naturel indolent a pris le dessus. En fait, je n’ai pas parlé agilité ce soir-là, mais des mérites comparés des langages de programmation ! C’est ça aussi, les ScrumBeer !
Voilà, c’est tout pour aujourd’hui. Vous trouverez le lien sur cette rencontre sur Meetup.
Ah si, une dernière chose comme aurait Steve : Il me faut “remercier” Arnaud (décidément, encore lui) pour cette prise de vue !
Note de lecture : Pro SQL Server Disaster Recovery, par James Luetkehoelter
Note: 7 ; Un bon cocktail de technique, gestion des risqué et process, le tout fort bien écrit !
Décidemment APress propose une collection complète et de qualité pour couvrir SQL Server (2005 et maintenant 2008..). Cet ouvrage dédié au disaster Recovery, malgré sa publication récente couvre SQL Server 2005, avec un addendum évoquant SQL Server 2008.
Bon bouquin, disons-le tout de suite. Le cursus particulier de l’auteur (études de philosophie) n’est probablement pas étranger à la qualité rédactionnelle. Le style est vivant, voir intimiste. Même pour un livre technique (surtout pour un livre technique), cela compte ! Comme le DRP n’est pas seulement de la technique mais plutôt une alchimie entre technique et process, l’auteur aborde les deux aspects avec bonheur.
Bien entendue, le backup est la pièce maîtresse du DRP. Impossible d’échapper au traitement en profondeur de celui-ci. Le premier chapitre est purement introductif, mais les chapitres 2 à 5 (soit pratiquement les 100 premières pages) sont entièrement dévolues à cet aspect ! Après cela, on sait pratiquement tout ce que l’on a à savoir sur la réalisation des backups, leur restauration et la relation entre filegroups et backups ainsi que les stratégies possibles et conseillées.
Le chapitre 6 fait charnière en présentant les recovery plans possibles mettant en œuvre les techniques vues précédemment.
Les chapitres 7 à 10 constituent vraiment à mon avis le « plus » de ce livre en présentant les différentes fonctionnalités de SQL Server pouvant être utilisées pour le DRP, la façon de les utiliser et leur utilité dans un DRP d’un point de vue subjectif. Dans l’ordre, nous avons : le « log shipping » qui est clairement le préféré de l’auteur, le clustering, le miroring et enfin le snapshot. Une mention particulière pour le chapitre 10 qui traite de l’infrastructure matérielle : chapitre intéressant au point qu’il m’a laissé sur ma faim !
Les chapitres 11 et 12 traitent l’aspect purement processus du DRP. Le chapitre 12 est particulièrement étonnant (et intéressant) car il traite exclusivement de l’aspect humain. Il pourrait prendre place dans un livre traitant de toute autre technologie ou même d’aucune technologie !
Enfin, une annexe évoque les évolutions qu’apporte la version 2008. Cela ne couvre qu’une dizaine de pages, ce qui est plutôt succinct, mais il est vrai que l’on n’a aucun recul sur cette version. Pourtant n’est-elle pas « all about availability » ?
Pour conclure : je recommande vivement !
Référence complète : Pro SQL Server Disaster Recovery – James Luetkehoelter – Apress 2008 – ISBN : 1-59059-967-5 ; EAN : 978 1 59059 967 9
Il y a trois sortes d’esprit. Les uns entendent par eux-mêmes ; les autres comprennent tout ce qu’on leur montre ; et quelques uns n’entendent, ni par eux, ni par autrui. Les premiers sont excellents, les seconds sont bons, et les derniers inutiles.
Nicolas Machiavel
Scott Meyers : A unique perspective on C++
Scott Meyers est une figure majeure du monde du C++, et aussi un auteur au talent pédagogique remarquable. Il nous explique son parcours et nous livre son point de vue sur la place du langage C++ dans l’écosystème des langages modernes.
(Source: https://www.youtube.com/)
Note de lecture : La gestion électronique documentaire, par Jean-Yves Prax & Simon Larcher
Note : 4 ; Ennuyeux, mais à jour (en tout cas, au moment) !
Encore un ouvrage qui souffre du mal réccurent des livres français : un style pédant ! C’est toutefois un défaut dont on peut passer outre si le contenu est à la hauteur. Comme il est de coutume dans ce type de livre, les auteurs proposent une démarche projet de mise en place de GED. Celle-ci, exposée au chapitre 2, toutefois pose plus de question qu’elle ne propose de réponses.
Le chapitre 3 couvre les aspects « acquisition de documents », ce qui inclus encodages, typoes de documents, mais aussi : polices de caractères, formats de documents et d’images, OCR et types de compressions ! Il s’agit littérallement de l’état de l’art en la matière et le paysage est complet. Il faut dire que le chapitre fait quand même 60 pages…
Le chapitre 4 est tout aussi volumineux et couvre la chaine de traitements : indexations, langages de description, gestion de thésaurus et relations entre termes. En clair, il s’agit d’apporter une valeur sémantique exploitable au document. Sur les techniques, ce chapitre traite des indexations « à postériori » de type « full texte » et de la discrimination terminologique. Enfin, les aspects matériels tels que les technologies de stockages (primaires et secondaires) ainsi que les types et standards d’impression sont abordés ici.
C’est aux normes et aspects juridiques que le chapitre 5 est consacré. Les célèbres standards de structure des documents que sont SGML et DSSL (entre autres) sont succintement exposés. A cette occasion, les auteurs extrapolent le futur des applications Web, celles-ci étant dissimulées derrière les applications. Les aspects d’architecture, de répartition et autres datawarehouse sont également couverts ici. La détermination des besoins de sécurité, sauvegarde et encryptages avec des « approches standard » cloturent un chapitre encore une fois conséquent (70 pages).
C’est aux aspects collaboratifs (Groupware, Internet) et aux nouvelles technologies GED que le chapitre 6 est consacré. L’ISO 9000 est aussi abordé, mais de façon peu convaincante, il faut bien le dire…
Un tel ouvrage ne saurait être complet sans aborder les technologies avancées tels suq réseaux sémantiques, data mining et analyse linguistique. C’est le but du chapitre 7. Celui-ci est suivi d’un traitement de la gestion de contenu (le chapitre 8). C’est probablement pour se donner bonne conscience, tellement son traitement est pauvre.
Ce livre n’a pas de quoi soulever l’enthousiasme, mais as-t-on le choix ? La GED est un domaine sur lequel la littérature pratique est des plus pauvres, ce qui fait de ce livre le plus utile de sa catégorie.
Référence complète : La gestion électronique documentaire, 3ème édition – Jean-Yves Prax & Simon Larcher – Dunod 2004 – ISBN : 2-10-007891-7
Divide and rule, a sound motto. Unite and lead, a better one.
Johann Wolfgang von Goethe
Software Freethinker 
