Note de lecture : Unix, utilisation administration système et réseau, par Christian Pélissier

Note : 5 ; Unix pour les bénédictins, mais néanmoins très utile !

Je n’ai encore jamais croisé un bouquin sur Unix qui soit une franche tranche de rigolade. Celui-ci ne fait pas exception. En fait son style est franchement monacal. Je ne vais pas passer en revue les 37 chapitres composant les 750 pages de ce pavé. Et rester au niveau des 3 parties serait trop succinct.

Si l’aspect premier est rébarbatif, en y regardant de plus près, l’ouvrage est plutôt bien fait, à mi-chemin entre le manuel de référence et le guide de l’utilisateur, avec une prédominance pour ce dernier aspect. Tout d’abord le texte a le bon goût d’être finement découpé : 37 chapitres, c’est en moyenne une vingtaine de pages par chapitres. Le style est très sibyllin, mais il se débarrasse ainsi des circonvolutions qui rendraient l’ouvrage moins efficace. Il y a au moins 3 choses que j’apprécient :

  • Les exemples clairs de la ligne de commande. Cela ne se limite pas à la syntaxe, mais à l’usage réel que l’on peut en faire dans une séquence type.
  • Les variantes BSD et Système V sont présentées. Ce choix paraitra évidemment aujourd’hui un peu désuet.
  • Les commandes connexes sont évoquées : ainsi sur la création de répertoire, on parle de la façon de les supprimer, etc…

Bref, ce n’est pas un livre que l’on va lire avant de se coucher, ni même d’une traite d’une couverture à l’autre. Il est plutôt fait pour être lu de manière discontinu chapitre par chapitre, car ceux-ci sont courts. Il sera également utile comme référence. Mais il trouvera aussi ces limites ici, car le texte ne traite pas en profondeur des subtilités des options des différentes commandes. Ce n’est définitivement pas un manuel de référence. Il cible plutôt les nouveaux venus à Unix.

image

Référence complète : Unix, utilisation administration système et réseau – Christian Pélissier – Hermes 1995 – ISBN : 9782866014490

Unix, utilisation administration système et réseau

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

Management Workouts 3.0, par Jurgen Appelo

Management Workout, c’est le titre du dernier ouvrage de Jurgen Appelo. J’ai distillé ici une partie des ces exercices que l’auteur a mis à disposition. Le management workout, ce sont des exercices conçus pour pouvoir être mis en oeuvre « dès lundi matin » ! Cette présentation en survole un certain nombre.

  • Improvement dialogues : Ou comment générer des conversations nous guidant vers l’action.
  • Personal Maps : Ou comment gérer la relation à son travail et à ses collègues en terme de distances physiques et cognitives.
  • Kudo Box : Savoir valoriser le remerciement, c’est déjà changer la dynamique des relations dans une organisation.
  • Work Expo : Une organisation doit savoir être fière du travail de ses collaborateurs… et le montrer !
  • Project Credits : Comment penser le titre de votre job ou gérer votre réputation ?
  • Salary Formula : Comment concevoir les abaques salariaux ?
  • Delegation Board : Où comment partager le niveau de décision entre managers et équipes.
  • Metrics Ecosystem : Comment mesurer la performance d’une organisation et quels sont les impacts de ces pratiques ?
  • Merit Money : Le système des bonus ne porte pas la collaboration que l’on souhaiterai dans l’organisation. Repensons la façon de rétribuer !
  • Yay Questions : Des questions qui nous invitent à célébrer ce que nous avons bien fait !

Ce survol ne fait que picorer dans le différents sujets. Il y a mieux à faire : lire effectivement les workouts. Ou encore mieux : acquérir le livre de Jurgen … il y a de nombreux autres workouts à découvrir !

Agile Playground #18 : c’est mon tour !

Cela faisait un petit moment que je n’avais pas pris une part active à l’animation du Playground. L’occasion faisant le larron, la nécessité d’expérimenter un jeu autour de la mise en oeuvre de Scrum me donnait enfin l’occasion de prendre une part active à la soirée. Mais tout ceci n’est que vantardise de ma part : en réalité j’étais plutôt le co-animateur de ce jeu dont ma collègue Claire avait pratiquement fait tout le travail de préparation.

Mais revenons au début de cette 18ème rencontre. Une rencontre orchestrée par Cédric Chevalérias dans les locaux de Valtech que nous retrouvions ! Au programme : 3 jeux en parallèle et un Ice-Breaker.

Ice-Breaker : autour des rôles de Scrum

C’éait une demande venant d’Ideascale : faire un ice-breaker autour des rôles de Scrum. C’est Frank Beulé qui a relevé ce challenge en adaptant un autre jeu !

image

Ayant distribué des cartes aux différents participants, il fallait retrouver notre groupe et organiser nos cartes en une suite logique.

image

Enfin, le pitch avant les choses sérieuses.

image

A côté de notre « Live Scrum », il y avait un très attractif Sky Castle Game proposé par Yannick Quennec’hdu. Un jeu déjà pas mal éprouvé et très bien préparé: tables de jeux, cartes, Lego et tout et tout. Bref, quelque chose de bien attractif !

Etait également proposé un jeu autour du Story Mapping. Claire Léger s’essayait à l’animation de celui-ci.

Live Scrum !

Ce jeu a pour but de simuler les activités d’un projet Scrum : un backlog, un chiffrage et une priorisation de celui-ci. Puis, 2 itérations avec planning meeting, des sprints de 3 jours (avec leur stand-up), se terminant par une revue et une rétrospective. En fait, nous n’aurons le temps de ne faire qu’un seul sprint.

Petit comité autour de notre jeu clairement à l’état de MVP.

image

Nos buts premiers étaient de valider l’étude de cas travaillée par Claire, le timing des différentes phases et les difficultés de jeu que nous pouvions rencontrer.

image

Grand merci aux participants qui nous auront permit de noter des points importants :

  • L’étude de cas est complexe, mais sans l’être de trop. A garder !
  • Le timing doit être réviser. Le but est d’avoir des tranches courtes… mais pas trop quand même.
  • Mieux cadrer ce qui est attendu à chaque phase de jeu.
  • Clarifier explicitement l’objectif : la création d’une maquette et non un développement.
image

Le public de l’Agile Playground ne correspond pas nécessairement à celui des débutants que nous pouvons rencontrer en entreprise : parfois plus efficace, mais aussi s’enlisant parfois dans de longues discussions… Ils auront néanmoins produit un résultat tangible.

image

Fin de soirée

Que serait un Agile Playground sans l’indéracinable cocktail de fin de soirée ? J’avais prévu d’y amener une brioche maison, je l’ai ratée. Ce sera pour une prochaine fois.

image

Nous avons un autre jeu sur un thème complètement différent en cours d’élaboration, mais ce ne sera certainement pas disponible pour Janvier.

Note de lecture : Cross-Platform GUI Programming with wxWidgets, par Julian Smart et Kevin Hock avec Stefan Csomor

Note : 4 ; Pas un truc qu’on lit pour le fun !

Les frameworks IHM en C++ ne sont pas mort ! Et ce volume de 540 pages (hors annexes) compte bien nous en faire la preuve avec wxWidgets. Le bestiaux compte 20 chapitres, il faudrait aussi y ajouter presque 100 pages d’annexes.

Les deux premiers chapitres (assez courts) sont là d’une pour nous présenter très brièvement l’historique de wxWidgets, puis un « hello world » qui nous montre déjà une certaine ressemblance avec MFC…

Dès le chapitre 3 on rentre dans le dur avec la gestion des évènements. Je trouve la prose et les explications assez sèches. D’un autre côté, la petite taille des chapitres aide…

En comparaison, le chapitre 4 « Windows basics » fait plutôt mouse costaud avec ses presque 100 pages ! La prose me semble assez décousue et si la présence de nombreux tableaux de référence semble rassurante, elle fait ressembler ce chapitre d’avantage à un manuel de référence qu’à un tutorial.

La partie sur l’écriture sur les devices ressemble plutôt à une introduction sur le sujet. Fort heureusement on a quitté le mode « manuel de référence ». Si les contextes graphiques, arrières plans, etc… semblent décemment traités, j’ai quelques soupçons sur l’affichage de bitmaps, la gestion des imprimantes me paraît un peu légère et la partie 3D est carrément un gag !

Passons sur le chapitres 6 dédié à la gestion des inputs pour arriver aux chapitres 7 et 8 consacrés aux layouts puis aux dialogues standards. Ces deux chapitres sont justes introductifs avec de petits fragments de code pour illustrer les cas courants. En gros, ce que propose le manuel en ligne de wxWidgets. Ce n’est pas le cas du chapitre 9 qui traite les « custom dialogs » et s’appuiera sur un exemple plus conséquent.

Si le traitement des images au chapitre 5 m’avait déçu, le chapitre 10 rattrape le coup en traitant exclusivement de cet aspect.

Le drag and drop est toujours une fonctionnalité complexe, difficile à exposer clairement. C’est le cas ici, avec une approche confuse. Un exemple global appréhendé par morceau aurait aidé, ainsi qu’une explication de la cinématique globale. Suite des aspects avancés avec le chapitre 12 qui traite des différentes classes de fenêtres.

Les chapitres 13 et 14 nous ramènent à l’époque où l’on réinventait l’eau chaude en C++ à chaque librairie ! Voilà donc des objets de base pour gérer chaine de caractères, collections, fichiers, etc… Malheureusement toutes ces choses sont prises en paramètre par les API du framework…

Je passe sur le chapitre 15 qui décrit les facilités de debuggage et de gestion d’erreur et sur le chapitre 16 qui traite l’internationalisation très classiquement par le biais de ressources. Ces deux chapitres sont de toute façon assez courts. Plus intéressant, les chapitres 17 et 18 se focalisent sur des aspects systèmes : les threads et les sockets, prenant en charge ce que ACE fait en cross plateforme par exemple. On aime ou pas, mais wxWidgets permet de traiter ces aspects évènements de ces deux sous-systèmes dans sa boucle d’événement. Personnellement, j’aime pas !

Il est curieux qu’il faille attendre le chapitre 19 pour voir décrit le modèle « document – vue » de wxWidgets ! Il aurait dû être présenté bien avant. Quoi qu’il en soit, les auteurs proposent ici une approche par étape qui tranche un peu sur ce qui est fait par ailleurs dans le livre, et c’est une bonne nouvelle.

L’ouvrage se conclut par un chapitre 20 « perfecting your application » qui est un melting pot de différents sujets sans rapports les uns avec les autres.

Il faut voir les choses en face : il n’y a pas le choix de livres sur wxWidgets. C’est le seul. En terme de ciblage il se cherche un peu. Il voudrait être l’introduction à la programmation avec wxWidgets comme l’était le Petzold pour Windows mais tombe souvent dans le travers du manuel de référence sans en avoir la qualité. Ce n’est pas le Petzold non plus, c’est certain. Bref ce n’est pas un livre que je pourrais conseiller les yeux fermés, mais il n’est pas écrit avec les pieds non plus.

Plutôt vide, avec beaucoup de déclarations d’intention mais peu de concret.

Bref, un livre qui est loin d’être indispensable.

image

Référence complète : Cross-Platform GUI Programming with wxWidgets – Julian Smart and Kevin Hock with Stefan Csomor – Prentice Hall 2006 – ISBN : 9780131473812

Cross-Platform GUI Programming with Wxwidgets

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

Formons-nous à Kanban avec le FKUG

Zenika accueillait cette nouvelle réunion mensuelle dans le zLocalHost. Une foule très nombreuse s’y était donné rendez-vous pour cet opus dédié à la formation au Kanban et aux techniques associées.

image

Un programme très chargé. Peut-être un peu trop, c’est vraiment tout ce que l’on pourrait reprocher à cette remarquable soirée !

Après le mot d’accueil du Sponsor soirée, Couthaier nous donne quelques nouvelles de l’association. Elle est très active il faut bien le dire. D’ailleurs la soirée suivante aura déjà eu lieu quand vous lirez ces lignes. Mais place à l’action.

Et l’action pour commencer, c’est avec Pascal Poussard et les essentiels de Kanban !

Initiation au Kanban avec Pascal Poussard

C’est toujours un plaisir pour moi d’entendre Pascal. Cette fois encore, il nous gratifie d’une session d’initation au Kanban clair et énergique, se concentrant sur les aspect importants de l’approche. On pourra juste lui reprocher de faire des infidélités au Scrum User Group (dont il est l’un des membres éminents du bureau) pour faire une pige au FKUG !

image

4 objectifs et 2 notions clé

La Kanban, c’est surtout 4 objectifs :

  • La qualité
  • Equilibrer le rapport demande / débit
  • Livrer souvent
  • Réduire la variabilité

Deux notions clé font de Kanban une approche radicalement différente.

  • La chaine de valeur : Ici, elle part de l’aval. C’est la demande qui contrôle la mise à disposition, d’où la fameuse notion de « flux tiré ».
  • Le temps de cycle : On ne parle plus de vélocité ou de capacité. Kanban se focalise sur le délai entre la demande et la mise à disposition au-delà de toute chose. Si cette notion n’est pas importante pour vous, sans doute n’êtes-vous pas un bon candidat au Kanban. Mais réfléchissez bien…

6 principes

Visualiser la chaine de valeur. C’est la première pierre du Kanban. Car visualiser cette chaine de valeur, c’est rendre compte de manière claire de ce qui se passe, créer une adhésion autour de celle-ci et permettre de « casser les silos ».

Limiter le travail encours (WIP limit). Ce principe est à la fois le moteur du flux tiré et de la réduction du temps de cycle.

Gérer le flux. Dans un système, le flux est limité par son goulot d’étranglement (théorie des contraintes). Cette dernière nous dit aussi qu’il y a nécessairement un goulot d’étranglement dans le système, qu’il faut décider (et non subir) où celle-ci se positionne et subordonner le système à cette contrainte.

Rendre les processus explicites. Comme les approches agiles, Kanaban est une école de rigueur : les règles de passages sont clairement définies, ainsi que les procédures exceptionnelles.

Amélioration continue. L’observation et la mesure de ce qui se passe nous permettent de déterminer ce qui peut faire l’objet d’amélioration.

Feedback : Celui-ci vient des mesures et de la voix du client.

Pour quel contexte ?

  • Si notre flux de travail n’est pas équilibré.
  • Si notre chaine de travail est surchargée.

Comment commencer ? Avec ce que l’on a, simplement en rendant notre processus explicite. Puis en enclenchant des cycles d’amélioration.

Retrouvez ici la prestation de Pascal.

Ainsi que le support de sa présentation.

Le management visuel et l’Obeya, par Christophe Keromen

Au commencement

On commence fort avec Christophe en se posant la question suivante : pourquoi faire un management visuel ? Pour nous pousser à l’action ! Si celui-ci n’atteint pas ce but, il faut le jeter !

Pourquoi doit-il être visuel ? La Programmation Neuro-Linguistique nous dit que des 5 sens, le VAKOG de la PNL, c’est le sens visuel qui est dominant, car notre cerveau est efficace pour reconnaitre les motifs.

La question suivante sera donc : qu’en fait-on ? On va s’en servir pour rendre visible les problèmes, et rendre aussi visible le lien entre le problème (que l’on refuse souvent de voir) et l’action.

image

Commençons avec un tableau Scrum…

Celui-ci nous permet de rendre visible la progression. Mais rend-t-il visible le challenge ? Permet-il de voir les « impediments », les boulets qui nous freinent ?

Christophe nous résume ainsi ce que le management visuel rend possible :

  • Voir ensemble
  • Agir ensemble
  • Apprendre ensemble

Pour permettre cela, il faut non seulement faire attention à l’information que l’on montre (et qui conditionnera tout le reste), mais faire en sorte que l’information représentée sur ce tableau soit :

  • Univoque
  • Visible
  • Interactive

Un tableau soigné

Cela commence en soignant ce tableau au niveau du contenu. Ce sont les « 3 U » :

  • Utile (ce qui n’est pas utile constitue une pollution)
  • Utilisable
  • Utilisé (quelle est la dernière chose que vous avez apprise avec le tableau ?)

Cela signifie aussi un tableau soigné du point de vue esthétique. Eh oui je confirme : personne ne va aller voir un tableau moche !

Du manangement visuel à l’Obeya

Que doit montrer d’autre notre management visuel ?

  • Les objectifs (le challenge)
  • Les règles
  • La vision

C’est de tout cela dont on parle quand on évoque l’Obeya. Mais l’Obeya, c’est aussi un espace, l’Obeya Room, à l’agencement très spécifique. Le but ? Se mettre en position de faire du Kaizen !

Retrouvez ici la présentation de Christophe Keromen en vidéo.

Ainsi que les slides de sa présentation.

La résolution de problèmes avec le A3, par Laurene Vol

Le A3, c’était probablement la présentation que j’attendais avec le plus d’impatience. Mais ce fut aussi probablement la présentation la plus faible, hélas. Non pas qu’elle fut mauvaise, mais elle est restée très « by the book ».

Un A3 pour traiter des problèmes

Et ces problèmes, comment sont-ils identifiés ?

  • De manière spontanée, durant l’itération, quand on tombe dessus !
  • En rétrospective
  • Via des indicateurs

Ces problèmes, Laurene nous propose de les collecter au sein d’un tableau, plus précisément dans une matrice de Merill-Covey. Vous connaissez déjà certainement.

image

A partir de là, des règles nous permettront de déterminer la manière dont nous traiterons ces problèmes. Pour certains d’entre-eux, ce sera le A3 !

Du contexte à l’analyse

Le A3 débute avec une partie « contexte ». Elle répond à la question : Pourquoi en est-on là ?

Vient ensuite le « current state » : un état initial quantifié et si possible illustré avec un schéma. Si des contournements sont déjà mis en oeuvre, ils sont exposés.

image

L’objectif, c’est l’état final désiré. Il est lui-même quantifié.

La partie délicate, c’est bien l’analyse. On privilégie l’analyse causale à l’aide de différentes techniques : les 5 pourquoi, les diagrammes de cause-effets ou les diagrammes en arêtes de poissons.

Vous avez trouvé mon compte-rendu trop succinct ? Regardez la vidéo de l’intervention de Laurene.

Son support de présentation est également disponible.

Kaizen & PDCA avec Julien Karoubi

Je dois avouer que Julien affronte des challenges que je n’oserai pas, même dans mes jours les plus téméraires.

Ainsi, pour illustrer le principe de l’amélioration continue, Julien a proposé un jeu !

image

Ce jeu, Julien l’a imaginé spécialement pour cette soirée. Il s’agit d’effectuer des itérations et de consacrer un peu de temps pour trouver des améliorations de fonctionnement, à l’image du Ball Point. Ici, Julien s’évertue également de perturber le système en intervenant au milieu des itérations, histoire de casser de rythme et voir comment l’équipe réagit !

image

Résultat moyennement concluant. On arrive à la même productivité avec ou sans temps consacré à l’amélioration. Mais on doit pendre en compte que du temps de travail est alors consacré aux rétrospectives. Il faut dire que les tranches de temps sont réellement très courtes, surtout pour les rétrospectives. Voyons en video ce que cela donne.

Il était aussi audacieux de la part de Julien de faire ce jeu dans une configuration de soirée « plénière » : Il y avait 80 personnes dans le showroom Zenika, probablement moins de 10 pouvaient voir et suivre réellement ce qui se passait.

Quoi qu’il en soit, cette cassure était bienvenue dans ce marathon de présentations !

Key Performance Indicators pour Kanban, par Yannick Quennec’hdu

Yannick est très, très affuté (et expérimenté) sur les mises en place de Kanban et les mesures associées dans des contextes multi-équipes. On pouvait s’attendre à une présentation de haute qualité, nous l’avons eu !

Parlons pré-requis

Toutes nos présentations s’articulent bien ensemble, car pour Yannick, un pré-requis important est … la mise en place d’un management visuel ! Bon, il n’y a pas que cela. Il faut aussi que notre Kanban soit « stabilisé » également. Nous ne devons pas non plus perdre de vue notre objectif : rendre factuel notre Kanban !

image

Les indicateurs

Ils sont classiques, mais ça ne fait pas de mal de les reprendre :

Le Lead Time : combien de temps entre une « commande » et un client servi.

Le temps de cycle : Le temps séparant deux évènements identiques. C’est donc l’inverse de la fréquence et vice-versa.

Le débit : Le nombre d’items livrés dans un laps de temps donné. Là on ne parle plus d’étape du processus, mais de ce qui sort du Kanban !

Le travail en cours : combien d’éléments sont en élaboration aux différentes étapes du processus !

Le diagramme de flux cumulé est l’outil de prédilection permettant de mesurer et voir évaluer la plupart de ces indicateurs. Ca, c’étaient les bases. Et maintenant, voici…

Le grand Mix

Ces indicateurs se combinent pour voir les corrélations entre ces indicateurs.

La loi de Little : Elle indique que le temps pour terminer est inversement proportionnel à l’en cours. Donc réduire l’en-cours augmente le débit !

La prédictibilité : Un indicateur compliqué, basé sur le débit et la taille des tickets.

L’efficience : Pour mesurer dans notre processus, le temps qui ajoute de la valeur au produit. En pratique, on isole les zones tampon et l’on mesure le temps que le ticket y passe.

La qualité : C’est le coût de la non-qualité qui est mesurée, via des « tâches rework », par exemple. Yannick utilise cela pour mesurer la valeur économique de l’accroissement d’une équipe de tests !

Variabilité : Ces variabilités peuvent être locales ou globales.
Je vous recommande la vidéo de l’intervention très riche de Yannick

Et aussi, bien sûr, le support de sa présentation.

Mesure de la maturité par Nicolas Lochet

La soirée n’est pas encore tout à fait finie ! Nicolas nous expose à la vitesse de la lumière une grille d’audit de maturité Kanban, basée sur les éléments du livre de Laurent Morrisseau.

image

Il n’y a pas de support de présentation, car Nicolas nous présentait directement sa feuille Excel (que je n’ai pas non plus). Hélas, nous n’avons pas également de captation vidéo de cette intervention.

Enfin, un petit « preview » ne fera de mal à personne : voilà !

image

On a soif !

Il est plus que temps d’aller au ravitaillement. Vider le frigo rempli de bières et les petits fours et autres provisions de bouche laissées à disposition, telle était notre dernière tâche !

image

Ce que j’en ai pensé

Ce Meetup était vraiment très riche. La mission était d’initier le plus grand nombre aux éléments de base de Kanban. Les diverses présentations ont réellement rempli ce rôle. En fait l’agenda était même trop ambitieux. Nous aurions eu de la matière pour deux soirées ici.

Second point, bien que mineur : je n’ai pas compris la nécessité de rendre cette soirée payante. D’autant qu’étant hébergée chez Zenika, tous les coûts étaient assurés par l’hôte ! Cela n’a pas freiné les ardeurs (et la contribution demandée était minime) et cela a certinement alimentée la caisse de l’association.

Le FKUG montre une fois de plus son dynamisme, non seulement à organiser une soirée par mois, mais à varier les formules de ces soirées. Un rythme et une variété que j’avais escomptée pour le Scrum User Group il n’y a pas si longtemps que cela, et qui reste à retrouver.

L’association organisait aussi en décembre une soirée jeux, je n’ai malheureusement pas pu y participer. J’attends avec impatience l’année prochaine !

Scrum Shu Ha Ri, le live

Voici la vidéo de ma présentation « Scrum Shu Ha Ri » faite lors du Printemps Agile organisé à Caen. Un grand merci à l’équipe du CEMU qui a effectué la prise vidéo et le montage. Vous pouvez retrouver cette vidéo (et d’autres du Printemps Agile) sur cette page. J’avais par ailleurs fait deux posts sur cette conférence, accessibles ici et ici (), et une galerie photo visible ici.

Le support de cette présentation se trouve ici. J’ai par ailleurs rédigé un article un article s’appuyant sur le matériel de cette présentation que vous trouverez ici.

Open-Space des pratiques Agiles

Deux mois se sont écoulés depuis notre rendez-vous précédent chez Zenika. Nous voici de retour pour échanger sur les pratiques. Au menu : petit groupe, provisions de bouche en mode collaboratif, et des sujets qui restent à choisir !

SAFe, est plus que LESS ?

Premier sujet autour de SAFe, décidément, l’un des grands sujets du moment. Peut-être du fait de son adoption récente par JC Decaux ?

En dépit des retours très positifs de Lissa Adkins, je reste très dubitatif sur ce framework. Ce retour de formation SAFe correspond plus à l’idée que je m’en fais. Disons que je suis très dubitatif, mais j’entend aussi des choses positives de la part de gens que je respecte…

Yannick lui, voit un indiscutable avantage à SAFe : la possibilité qu’il ouvre de parler aux DSI ! Je suis hélas d’accord avec lui, mais pour une toute autre raison : C’est une sorte de perversion de l’agilité pour la transformer en un processus classique tel que l’apprécie nos vieilles DSI poussiéreuses (vous avez dit RUP ?). Pas étonnant qu’il gagne de l’attention.

image

Plus intéressant à mon gré, Vincent nous propose de déconstruire les pratiques de SAFe pour démontrer qu’elles sont effectivement utiles pour appliquer l’agilité à plus grande échelle. La démonstration est convaincante. Je pose toutefois la question : si les pratiques sont individuellement intéressantes et utiles, est-il besoin de les cimenter en un framework ?

Maintenant, on n’a finalement pas parlé du tout de LESS. Petite déception. Mais c’est sans doute parce que l’on ne savait pas en parler…

Hacker un projet pour l’agilifier

Le sujet sur le « hacking de projet agile » nous avait un peu intrigué par son intitulé. Un retour intéressant sur la manière de remettre un projet sur les rails avec des parties prenantes pas évidentes.

image

Mais il faut bien reconnaitre que nous n’avons pas été très inspiré pour échanger dessus. De quoi nous laisser le temps d’aborder le sujet proposé par Géraldine.

Est-il important d’avoir un objectif de Sprint ?

Oui, parfois c’est compliqué de faire rentrer le menu du sprint sous le chapeau d’un objectif ! Aussi est-il légitilme de se se poser la question : est-ce obligatoire ? Qu’est-ce qui se passe si on ne le fait pas ?

Certes, nous avons conclu qu’il est bien plus difficile pour le PO d’être capable d’exprimer cet objectif. Et parfois, ce n’est pas un, mais deux ou trois objectifs !

image

Mais nous avons aussi conclu que cet objectif de sprint apportait deux éléments très liés et complémentaires :

  • Donner un sens à ce que l’on va accomplir dans le sprint. Pas seulement une liste de trucs à faire qui transforme l’équipe en ouvriers spécialisés, mais un vrai but !
  • Permettre de co-construire la façon d’atteindre ce but, entre l’équipe et le PO. Nous parlons d’une dynamique et d’une relation différente. L’équipe n’est plus seulement le volet « réalisation », il s’implique et contribue au côté du PO sur le volet fonctionnel.

Cet objectif de sprint, finalement, n’est-ce pas un moyen d’obtenir les bonnes interactions entre les acteurs qui est la signature de l’agile ? « co-construction » restera le terme important de cette discussion.