You have to make the rules, not follow them.

Isaac Newton
Publicités

Note de lecture : IT Gouvernance, par Frédéric Georgel

Note : 7 ; Une très honnête introduction au sujet.

Si il est un sujet qui a le vent en poupe, c’est bien la gouvernance du SI ! Surfant sur cette nouvelle popularité, ce livre a pour but de nous en révéler tous les aspects. Et très franchement, je ne pense pas que ce livre puisse faire de nous le gourou de la gouvernance, mais il atteint très honorablement son but. Avec beaucoup de simplicité, il nous expose les domaines clés de la gouvernance IT et nous en explique les grandes lignes :

  • L’alignement sur la stratégie
  • Le management des ressources et des infrastructures
  • La gestion de la gouvernance et des ressources humaines
  • La maîtrise des risques sur le plan technologique et structurel
  • La gestion de la performance des services délivrés
  • Contrôle et audit des processus et des systèmes
  • Valeur économique des ressources informatiques
  • Maturité des infrastructures et des processus

Si la première partie nous dresse un sympathique contexte historico-culturel de l’émergence de la gouvernance IT (qui eut cru à l’importance du Colt 45 dans la façon d’appréhender l’égalitarisme pour nos voisins américains), les sujets évoqués ci-dessus font l’objet du seul chapitre 2. Et quel chapitre ! Il fait plus de 100 pages, donc plus de la moitié du livre ! C’est l’un des quelques reproches que je puis faire à cet ouvrage, par ailleurs moins sujet aux reproches récurrents que je peux faire à la qualité éditoriale des livres Dunod.

La troisième partie est dédiée à l’introduction aux 2 célèbres référentiels de la gouvernance IT : les incontournables ITIL et Cobit ! C’est bien sûr une excellente idée, mais hélas j’ai trouvé cette introduction confuse (même si un chapitre est consacré à chacun des référentiels). Peut-être devrais-je leur accorder une seconde lecture ?

En bref, je n’ai pas été déçu, ayant terminé les 180 pages du texte, j’ai la sensation de comprendre le sujet, sinon de la maîtriser. Je dois dire en outre, qu’il y a pas mal de références externes, et que le style de l’auteur, sans être extraordinaire nous fait grâce du style pédant qui est souvent la marque de fabrique des ouvrages français. On attend de l’auteur qu’il donne son avis et prenne position : il le fait !

image

Référence complète : IT Gouvernance, maîtrise d’un système d’information – Frédéric Georgel – Dunod 2005 – ISBN : 2-10-008312-0

IT Gouvernance, maîtrise d’un système d’information

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

Agile Playground #13

Retour chez Valtech pour cette nouvelle édition des Playgrounds. Aujourd’hui nous avions le choix entre deux jeux aussi attrayants l’un que l’autre : la Pompafric (présentée à l’Agile Game France 2014) mais que je n’avais pas expérimenté et le Values Advocacy. C’est Pierrick qui nous présente le programme.

image

Ice-Breaker

Pour amorcer joyeusement cette soirée, on a droit à un “nombre secret”, le même jeux que nous avions pu essayer lors de l’Open Space Agile France. Du coup, me voici exclus du jeu, c’est pas juste ! J’observe les efforts plus ou moins vains des participants pour se faire comprendre…

image

L’alignement final est assez étrange : on y a des “ordonancements locaux” signe qu’il a manqué une vérification de cohérence entre les groupes. Une mention spéciale à celui qui a tenté de se faire comprendre en convertissant son nombre en “taille de Schtroumph” !

image

Values Advocacy

Finalement, je me décide pour le Values Advocacy. En entrant dans la salle, on découvre le déroulement de la session affiché au mur, sous forme de fresque !

image

Le principe est assez simple : 4 équipes et les 4 valeurs agiles … et leurs “opposés”. On effectue une série de batailles : deux équipes s’affrontent pour défendre une valeur du manifeste et leur contraire. Les deux autres équipes forment le jury. Ensuite on tourne. C’est donc une sorte de tournante, mais en tout bien tout honneur. A la fin du jeu, chaque équipe aura eu l’opportunité de défendre une fois une valeur, une fois l’opposé d’une valeur, et de faire partie du jury deux fois. Il y a ensuite un système un peu compliqué pour compter les points, mais ce n’est pas très important.

Action !

Round 1 et 2

Chaque équipe prépare son plaidoyer. Pendant ce temps les membres du jurés circulent pour évaluer les idées qui émergent.

image

Un premier tour de vote a lieu à la fin du temps de préparation des plaidoyers.

image

Chaque équipe doit ensuite défendre ses idées et convaincre. Comme le fait ici Pascal.

image

Ou Corina

image

Un second tour de vote a lieu à l’issu de cette étape. La note final est une aggrégation un peu curieuse des deux votes.

Le second round se fait selon le même modèle (mais pas les deux mêmes équipes).

Rétrospective

A l’issu des deux premiers round : une rapide rétrospective.

image

Nous remontons essentiellement deux points :

  • Le temps de préparation des plaidoyers devrait être raccourcis
  • Il serait sympa de scénariser un peu le volet délibération / jury

Pas possible d’adresser le second point dès maintenant. Mais le premier est pris en compte : nous diminuons le temps de préparation de 8 minutes à 5.

image

Rounds 3 et 4

C’est donc reparti avec un rythme un peu plus soutenu. On prépare les argumentaires…

image

On s’active pour défendre ses positions.

image

L’une des équipes se trouve réduite à 3 membres, mais visiblement le nombre ne fait pas la force…

image

Et de nouveau, bien sûr, les plaidoyers !

image

Résultats et conclusions

Par deux fois les antithèses agiles ont battu les valeurs du manifeste et l’inverse est aussi arrivé par deux fois ! Que doit-on en penser ?

  • Tout d’abord que les équipes ont fait du bon boulot à défendre les idées auxquelles elles sont opposées. Pour tout avouer, c’est même beaucoup plus drôle !
  • Le Jury ont fait du bon boulot à juger en toute impartialité.
image

Au fur et à mesure du jeu, les plaidoyer ont aussi évoluer pour donner plus d’impact à la forme. Cela a finalement peu joué. Une équipe est d’ailleurs tombé dans le travers d’articuler complètement l’argumentaire autour de la forme, mais la faiblesse de cet argumentaire a joué en leur défaveur (alors même qu’ils défendaient les valeurs du manifeste) !

image

La réduction du temps de préparation a donné plus de rythme à la seconde partie, mais comme vous le voyez ci-dessous, l’impact sur le nombre d’arguments développés, bien que visible, n’est pas si important que cela.

image

Le jeu est réellement plaisant et nous oblige à réfléchir honnêtement non seulement à nos valeurs agiles que nous prenons pour acquises, mais aussi à ce que peuvent apporter leurs opposés. Ou au moins à comprendre à ce que les anti-agilistes y trouvent.

image

Curieusement d’ailleurs, je me suis retrouvé confronté dès le lendemain à ce cas de figure ! Nicolas a évoqué l’usage de ce jeu dans des groupes composés d’agilistes et d’anti-agilistes (ou de nouveaux venus). Je ne suis pas certain que l’on y obtienne les résultats escomptés. Notre population a fait un bon travail à argumenter solidement les deux côtés. Des anti-agilistes feraient-ils de même ?

Bref, j’ai passé un très bon moment. Mais je m’interroge encore sur l’usage que l’on peut faire de ce jeu. Vous retrouverez le vécu de la session sur le billet de blog de Nicolas.

Fin de soirée

Comme à l’accoutumé, on termine notre soirée de manière informelle autour d’un petit verre ou d’une bière.

image

Je ne m’éternise pas ce soir, j’ai une journée chargée le lendemain. Justement avec des agile games !

Agile France Open Space

Le mois de Février est généralement calme : un ou deux Meetup et bien sûr l’Agile Games France qui est pour moi l’évènement marquant de ce début d’année. Yannick Ameur a eu la bonne idée d’organiser un Open Space durant cette période calme.

image

Nous étions une petite vingtaine réunis pour cette soirée sous la houlette de l’association Agile France. Emmanuel Gaillot qui était des nôtres a d’ailleurs rappelé la mission de l’association.

image

Deux sessions au programme de cette soirée, entrecoupé d’un interlude. On y reviendra.

Comment convaincre sur la qualité du code

J’étais à l’initiative de cette première proposition. Enfin, deux autres sessions avaient lieu aussi en parallèle.

Mon problème :comment faire prendre conscience à une équipe “contente d’elle-même” de l’intérêt de chercher à s’améliorer, à perfectionner son code. Ma situation de départ : un code review où personne n’a rien à dire !

Des idées ont jailli. Je ne les essaieraient probablement pas toutes. Mais certaines méritent indiscutablement l’attention.

image

Mais l’échange me laisse à penser que lorsque l’on a pas encore éveillé l’intérêt, l’étincelle a bien du mal à prendre. Et il n’y a pas de solutions miracle. Seulement des choses à essayer qui marcheront peut-être, ou peut-être pas…

Interlude

Nicolas nous a gratifié d’un rapide jeux agile entre les deux sessions : le nombre secret. Il me rapelle celui sur les dates de naissances auquel nous avions joué durant le premier Agile Games France ().

image

Ca n’a pas trop mal marché.

image

Tester en agile

Pour ce second round, je me suis joins au groupe discutant des tests. Des discussions passionnées et des avis très partagés dans le groupe.

D’un côté les défenseurs de la séparation des pouvoirs : développeurs d’un côté, testeurs de l’autre. Les développeurs se limitent aux tests unitaires, les tests fonctionnels sont essentiellement exploratoires et fait par l’équipe de tests après la fin d’itération. Lorsque l’écart d’interprêtation entre développeurs et testeurs a fait son oeuvre (environ 10 secondes après que les testeurs aient reçu le système à tester), on saisie de gentilles anomalies et le tout peut retourner chez les développeurs pour une nouvelle itération. Itération au terme de laquelle on recommence le cycle. Ca booste à mort.

image

Autant dire que ce n’est pas ma vision des choses.

Les défenseurs de l’ATDD proposent de regrouper développeurs et testeurs au sein d’équipes pluridisciplinaires, de couvrir aussi bien que possible les items à développer de tests définis en amont (ce qui a aussi la vertu de les raffiner), et de tester “just in time” et non après la fin d’itération. Les tests exploratoires sont là seulement pour compléter les AT réalisés au début et pour, en quelque sorte, tester les tests !

Bref, deux visions inconciliables. Pour ma part, je pense que la première appartient à une époque révolue située quelque part dans le siècle précédent et n’a rien à voir avec l’agilité, ni dans son exécution, ni dans son état d’esprit. Mais cela me donne aussi une petite idée de billet, pour un de ces jours

Pendant ce temps, les sessions se déroulent dans d’autres salles

image

Fin de soirée

Les résultats de nos cogitations sont visible sur les murs. Ici le fruit d’une discussion sur le story mapping.

image

Les idées proposées pour cette soirée

image

Et bien sûr les inévitables discussions de fin de soirée. Peut-être le meilleur moment d’ailleurs !

image

How Spotify Builds Products

J’avais posté il y a quelques temps un lien vers l’article d’Henrik Kniberg à propos du scaling chez Spotify. Cet article expose la manière “lean startup” dont les produits sont pensés et évoluent :

  • Think it : on a une idée !
  • Build it : on construit un MVP.
  • Ship it : On le met en production.
  • Tweak it : Puis on l’améliore continuellement.

C’est même un Kanban au niveau de la société qui permet de visualiser la totalité des projets et leur état d’avancement.

Think it

Lorsque quelqu’un arrive avec une nouvelle idée, il peut former une petite “squad” (typiquement 3 personnes) s’il a le feu vert de la direction afin de développer celle-ci, typiquement sous forme de prototype. Il s’agit de répondre aux questions : pourquoi devons-nous construire ce produit et pour qui ? Quel va être la mesure du succès ? Bref, une vraie démarche Lean Startup dans l’esprit !

La partie la plus importante est un narratif qui est développé avant que le produit soit développé. De nombreuses maquettes (papier ou non) sont souvent élaborés en parallèle.

Le “done” est accompli lorsque le management décide que le produit vaut le coup. Cela est fait de manière subjective, sans épauler cela de chiffres ou d’études de marché. Cela viendra plus tard, dans le “ship it” !

Build it !

C’est la construction du produit, conduit en agile (Scrum, XP, Kanban) avec un squad plus étoffé. Parfois même plusieurs squad. L’objectif est la création du MVP.

Le MVP est un équilibre délicat entre un proto qualifié d’embarrassant, en tout cas pas assez abouti pour être mis dans les mains des utilisateurs et un produit standard, bien trop coûteux pour un premier jet. Pour Spotify, MVP signifie Minimum Loveable Product, qui soit “narrative complete”, plutôt que “feature complete”.

Le “done” est atteint quand le squad et le management pensent que le produit est assez bon pour passer en production.

Ship it

Il s’agit de déployer progressivement le produit vers 100% des utilisateurs. On commence par le déployer vers un petit échantillon d’utilisateurs, et c’est là que l’on commence à vérifier nos hypothèses initiales. Le processus standard est d’effectuer des itérations pour opérer des ajustements.

Le “done” est atteint lorsque le produit est déployé vers 100% des utilisateurs.

Tweak it

C’est la phase la plus importante. Le produit peut être amélioré de nombreuses façon. Le squad opère des évolutions via de l’A/B testing et le suivi des métriques d’utilisation. A un certain point le produit atteint un optimum local et les nouvelles fonctionnalités n’ajoutent guère de valeur au produit. Soit le squad passe progressivement vers un nouveau projet, soit l’on rentre dans une phase de “re-think” pour changer dramatiquement le produit.

Le MacIntosh dévoilé : c’était il y a 30 ans !

La machine emblématique d’Apple a fêté ses 30 ans il y a peu.

La présentation officielle du MacIntosh du 25 Janvier 1984 est certainement le moment le plus connu. Mais il fut précédé d’une présentation aux actionnaires un jour avant ! C’est ce que montre cette video, hélas de très mauvaise qualité ! Vous pouvez sauter l’introduction et aller directement vers 36’30 où débute ce qui nous intéresse réellement. Sinon la video visible depuis Techland (dont vous trouverez le lien plus haut) vous donnera un support de meilleure qualité.

Patricia, mon petit… Je voudrais pas te paraître vieux jeu ni encore moins grossier. L’homme de la Pampa parfois rude reste toujours courtois mais la vérité m’oblige à te le dire : ton Antoine commence à me les briser menu !

Michel Audiard in Les tontons flingueurs