Bootstraper un déploiement continu sur le cloud avec CloudBees

En 25 minutes, Henrik Kniberg nous fait la démonstration depuis zero de la création d’une petite webapp type « hello world » sous Eclipse, avec son test local avec Jetty et ses tests unitaires, vers la mise sous Git dans CloudBees, l’intégration dans Jenkins et le déploiement dans un sandbox, toujours sur CloudBees. Partant de là, on complexifie l’application en y intégrant une persistance avec MongoDB sur la base des services accessible depuis la plateforme SaaS !

La vidéo montre en totalité le processus de réalisation, étape par étape, y compris la correction d’erreurs, sans rien omettre ! Un véritable guide à suivre pour construire sa première application sur CloudBees !

Publicités

Agile France 2014, Bonus Track

Comme chaque année, il y a de nombreuses sessions que je n’ai pu voir. Je vais tenter d’y remédier en partie dans ce post.

Pour rappel les autres présentations, celles auxquelles j’ai assisté, sont couvertes ici et ici pour la journée du Jeudi. Elles sont ici et ici pour le Vendredi.

Projets Agiles, arrêtez les dérives

Cyrille Deruelle, en plus de sa présentation sur l’amélioration continue, a proposé ce sujet sur les projets agiles. Quelques clés et rappels pour ne pas pervertir nos pratiques et garder le cap sur ce qui est important.

Patrick Bobo a par ailleurs développé le contenu de cette session dans un post.

Lire la suite

What is Agile ? Par Henrik Kniberg

Cette présentation de Kniberg est plutôt dédiée à ceux qui veulent découvrir l’agilité : développeurs et managers. Elle répond en terme simple au « pourquoi » et présente l’avènement des approches agiles par le manifeste: ses valeurs, ses principes et les approches logicielles sous-jacentes.

L’auteur présente le cycle agile comme hautement itératif et incrémental. Ce qui est vrai mais un peu réducteur.

C’est ensuite aux questions de planning, d’estimation et de vélocité que s’attaque Kniberg, avec des illustrations ma foi fort bien faites ! Cette partie me semble plutôt destinée aux managers. Elle joue en tout cas un rôle efficace d’introduction au « maximize value, not output ».
Le point suivant me semble clé : donner à l’équipe un problème à résoudre et non une solution à implémenter … ou comment revenir au « start with why » de Simon Sinek ! Cette résolution de problème s’alimente de feedback, qui lui-même permet de maximiser la valeur et de réduire les risques : la cohérence de ce cycle est bien mis en valeur dans cette présentation !

Une équipe agile c’est une équipe pluridisciplinaire, et Kniberg en profite pour rebondir sur le modèle Spotify et la culture « être agile » d’une organisation.

L’agilité ne se limite pas au développement, il va jusqu’à la mise en production, une occasion de mettre en lumière les principe de déliverie continue. En amont, il implique les vrais utilisateurs au jour le jour.

Au niveau de l’organisation, le présentateur expose le « portfolio level Kanban », qui n’est pas sans rappeler les éléments développés dans Lean From the Trenches.

En conclusion : il y a un prix à payer à la mise en place de l’agilité (organisation, environnement, etc.) et « big is bad », aussi bien pour les projets, les fonctionnalités, les cycles ou les équipes !

Carnet de route : Le ScrumDay 2014 (4/4), Bonus track !

Après avoir couvert mon parcours de ces 2 jours de ScrumDays (ici, ici et ici), une question reste en suspens : et les autres sessions ? J’ai donc été rechercher du mieux que j’ai pu les supports de présentation des sessions auxquelles je n’ai pu assister. Il en manque encore hélas beaucoup, sans compter la mise en ligne des vidéos. Si vous avez des liens vers les supports manquants, faites m’en part, je les rajouteraient.

Pour commencer, voici le livret des sessions, en mode présentation

La transformation numérique de France Télévision

France Télévision fut le premier sponsor « client final » du French SUG ! Ils nous partagent leur retour d’expérience.

Vous retrouverez aussi cette présentation via le blog d’Alain Buzzacaro.

Le Lean Startup au service du Product Owner, par Jérôme Guenver

J’ai entendu dire beaucoup de bien de cet atelier animé par Jérôme. Un atelier que Jérôme a imaginé suite à une discussion que nous avons eu ensemble chez Zenika. Je suis donc plutôt heureux d’avoir eu un petit rôle pour inspirer un collègue !

Des outils du monde de la psychologie… par Bruno Sbille

On ne présente plus Bruno, en tout cas on ne devrait plus ! Bruno est l’un des piliers de l’imposante communauté agile Belge. Il est aussi l’organisateur de l’Agile Tour Bruxelles auquel je participe depuis sa création (et j’espère continuer). Lors de ce ScrumDay, il proposait cet atelier en plus de son rôle dans la « coach clinic » !

Dans cet atelier, Bruno présentait et permettait d’expérimenter divers outils tels que la PNL, le VAK, etc. Je me souviens encore que Bruno avait fait le déplacement depuis Bruxelles pour la soirée de création du French SUG il y a 6 ans de cela. C’était justeent pour nous parler de PNL !

Let’s Sketch together, par Alvin Berthelot

L’atelier d’Alvin était articulé autour de la création visuelle de produits. Je sais qu’il le produit régulièrement, j’aimerais bien avoir l’opportunité d’y participer…

The big payoff, par Alexandre Boutin

J’avais eu l’occasion de pratiquer ce jeu lors des premiers Agile Game France. Alex remet le couvert pour ce très bon agile game. Vous pouvez en trouver le descriptif en anglais ici. Et mieux encore le descriptif en Français ainsi que le matériel de jeu sur le blog d’Alex.

Faites Revivre vos spécifications

Un autre sujet orienté BDD issu d’une expérience récente de Yannick. Il m’en avais parlé lors d’un déjeuner, plus tôt dans l’année. Une optique de l’acceptance testing qui diffère un peu de la mienne, mais sans être incompatible (si, si !).

Open Agile Adoption, par Pablo Pernot et Oana Juncu

Encore une session à laquelle j’aurais aimé pouvoir assister si j’avais pu me dédoubler. Too many sessions, so little time…

Ici, Oana et Pablo nous dévoilent (en partie) le framework de Dan Mezik.

Créer le bon produit avec le Lean Canvas, par Romain Couturier

Romain a vécu un ScrumDay mouvementé, avec une panne de sonorisation suivi d’un changement de salle. Ici Romain nous parle du Lean Startup et plus précisément de l’outil de référence développé par Ash Maurya .

Les nouveaux outils du Product Owner

Story Mapping, Impact Mapping, Lean Canvas et Kanban : ce sont les « nouveaux » éléments que nous propose Claude pour le Product Owner.

Agilité : la fin du middle management ? Par Kevin Maccioni et Fabien Barbaud

Avec le passage à Scrum, le retour d’expérience des deux orateurs les amènent à répondre oui !

Introduction to Visual Management, par Natalie Yadrentseva

Je ne suis pas certain de joindre ici le bon support, je l’avoue…

Certains éléments de cette présentation me rapellent furieusement le Lightning Talk d’Igor Sviridenko à l’Agile France 2013…

Devops Game, par Vincent Daviet

Le troisième atelier Zenika de ce ScrumDay nous était proposé par notre nouveau venu Lyonnais avec ce Devops Game que je n’ai hélas pas pu expérimenter.

Podojo : PO, viens t’améliorer par la pratique avec nous ! Par Guillaume Duquesnay et Nicolas Verdot

A défaut d’un support de présentation, voici une petite vidéo avec une interview de Dominique Lequepeys sur cet atelier

Le Product Owner est-il un Product Manager agile ? Par Sébastien Saccard

Sébastien Saccard n’est pas un inconnu pour moi : tout d’abord il fut à l’initiative du workshop d’Ash Maurya à Paris, ensuite en tant que président de l’association We Do Product Management, il fut à l’instigation de la rencontre avec Gojko Adzic hébergée chez Zenika.

Sébastien cherche à développer le métier de Product Manager en France. Sa présentation va dans ce sens.

Vous pouvez aussi retrouver la présentation de Sébastien sur son Blog.

Agile-Lean-Kanban : Le guide du routard 2014, par Christophe Keromen

Bien rodée, j’avais eu l’occasion d’assister à cette très vivante présentation de Christophe à l’Agile Tour Rennes 2013. Mais était-ce réellement la même ?

My Product is a James Bond Movie – part V, par Pierre Neis

Les présentations de Pierre ne ressemblent à rien de connu ! Elles sont difficile à raconter, et je doute que le support ci-dessous lui rende justice. J’avais assisté à la « part I » de cette série « James Bond Movie » lors de l’Agile Tour Bruxelles 2013 … nous voici rendu au 5ème opus !

Développer en mode Kick-Ass, par Samuel Le Berrigaud

Le Kick-Ass de Samuel, cela me fait penser au « programming motherfucker » ! D’ailleurs en fait, il en parle dans sa présentation. Je vous recommande ce support pas mal du tout … en attendant la vidéo !

De la culture projet à la culture produit, par Céline Stauder et Gregory Alexandre

La présentation de Céline et Grégory est tout à fait dans le thème de ce ScrumDay. Par contre le support ne vous permettra guère de saisir la substance de la présentation !

Le prétotyping, avec Elalami Lafkih

Le prétotyping, c’est du prototypage « low cost », plus tôt donc avec un feedback anticipé. Elalami nous en expose un certain nombre de techniques. J’ai repris le support de l’orateur utilisé durant l’Agile Tour. Je suis parti du principe qu’il s’agissait du même…

Kapla Challenge, avec Dragos Dreptate

Construire un pont par itération (avec des Kapla), c’est le challenge que nous propose Dragos durant cet atelier

Faire Agile, c’est bien…, par Aurélien Morvant et Simon Jallais

Simon et l’homme aux chaussures de couleurs différentes nous proposent de découvrir ce qu’est « vivre agile ». Une session plutôt décalée !

DSL et refactoring pour les tests d’acceptation, par Laurent Py

Laurent nous fait partager son expérience ATDD / Devops chez Smatesting. En fait, la session ressemble terriblement à une promotion de l’outil Zest’ qui est, oh surprise, développé par la société dont Laurent Py est CEO !

Bon, voici quand même cette présentation…

Les reportages du ScrumDay

Une petite séquence « fun », tournée en bonne partie durant la pause déjeuner du second jour.

Et le reportage du ScrumDay, avec quelques interviews et des interventions de Xavier Warzee et Alistair Cockburn

Ils en parlent aussi…

Quelques liens vers des articles de blog que j’ai peu glaner à droite et à gauche. Si vous avez d’autres liens, n’hésitez pas à m’en faire part.

Il y avait une Coach Clinic, mise sur pied par Fabrice Aimetti et Bruno Sbille. Côté Zenika, Géry Derbier y participait ainsi que Laurent Sarrazin pour Rupture 21. Un compte-rendu est disponible sur le site d’Ayeba.

Alex Boutin nous livre sur son Blog la manière dont il a vécu ce ScrumDay.

Un retour de Laurent Sorin sur la table ronde menée par Véronique Messager

Autre retour également en provenance d’Ippon, un feedback sur la session de Rachel Davies par Victoria Pedron.

Dominique Lequepeys nous adresse les points forts des sessions auxquelles il a participé. Youpi, ceci inclut la mienne !

Christophe Deniaud fait aussi son billet de Blog sur les sessions qu’il a vu, ainsi que sur l’open-space. Lui aussi donne son feedback sur mon atelier. Pas sûr que mon message principal sur l’écriture collaborative des tests soit bien passé…

Coactiv nous livre aussi ses retours.

FKUG #3 avec Laurent Morisseau

Laurent n’est pas un inconnu pour nous, car il a fait partie du French SUG avant de s’orienter nettement vers le Kanban, en créant tout d’abord l’association Lean Kanban France qui organise la conférence du même nom et dont il est président, et en écrivant un livre sur le Kanban, le seul en Français à ce jour si l’on excepte la traduction du livre de David J. Anderson.

D’ailleurs la seconde édition de ce livre vient de sortir, elle évoque quelques nouveautés, des avancées dans la communauté Kanban. C’est pour les évoquer que Laurent est venu au FKUG la veille du ScrumDay.

C’est aussi hélas parce que c’était la veille du ScrumDay et que j’avais quelques petites choses à terminer pour l’atelier que j’animais que je n’ai pu venir de nouveau.

Fort heureusement cette soirée a été entièrement filmée (la vidéo est donc très longue) et nous pouvons profiter de cette soirée en différé comme si nous y avions été.

Enjoy !

Scrum Shu Ha Ri, la présentation

« On a pas mal de nouveaux venus à l’agilité, et on n’a pas beaucoup de sessions pour eux ». C’est ce que Jean-Luc Lambert me disait à propos de ce Printemps Agile 2014. En fait, je fais peu de sessions d’initiation, ce n’est pas ce que je préfère. Puis j’ai repensé à mes expériences récentes et ma façon d’appréhender Scrum comme un framework à même de nous accompagner du débutant à l’agiliste expérimenté.

Ainsi est née cette présentation « Scrum Shu Ha Ri ». Il n’est pas certain que j’aurais l’occasion de la resservir, ce n’est en tout cas pas prévu pour l’instant.

Le thème est inspiré du « Shu Ha Ri » présenté par Alistair Cockburn. J’ai en quelque sorte « instancié » ses idées à l’image que je me fais de Scrum.

J’escompte aussi pouvoir vous proposer plus tard cette présentation sous forme d’article, comme je fais parfois. Il vous faudra quand même patienter un peu.

Kniberg au Scrum Gathering Paris 2013 : Cullture over Process

Henrik Kniberg faisait la keynote d’ouverture lors du Scrum Gathering à Paris en Septembre dernier. La vidéo est en deux parties : la première est ci-dessus et la seconde , ci-dessous !

“Happy people build better products … and better products makes people happier !”. Telle est l’introduction qu’Henrik Kniberg nous assène. Mais quand une compagnie grandit, sa capacité à conserver des employés heureux diminue.

Une fois de plus, c’est de Spotify dont nous parle Kniber avec les clés suivantes:

  • Pour persister : l’agilité doit devenir une culture plutôt qu’un process.
  • Au fur et à mesure que la maturité d’une organisation grandit, la vision “shu” de Scrum devient un obstacle. Il faut abandonner certaines pratiques pour passer aux niveaux Ha et Ri.
  • Les Scrum Teams deviennent des “squads” ; l’autonomie qu’on leur accorde est une clé importante.
  • Attention à ce que l’autonomie ne devienne pas de l’autarcie : la communication entre squads doit être cultivée.
  • L’autonomie ne signifie pas discordance : l’alignement avec un leadership fort est possible !
  • L’autonomie a des impacts sur le découpage architectural du produit.
  • Passer d’une culture de la crainte de l’échec (Netflix) à une culture de l’apprentissage au travers de l’échec.
  • Le contrôle favorise la stabilité, mais empêche l’innovation.
  • Le contrôle se focalise sur la vélocité alors que ce sont les mesures de la valeur et de l’impact qui importent.

Ne ratez pas la conclusion de Kniberg sur le dernier slide : des conseils concis à suivre absolument.

Discours inaugural de la promotion 2005 à Stanford

Steve Jobs était un showman, ce n’est pas un scoop. On a gardé en mémoire ses keynotes et ses présentations produit et la simplicité emprunte de sophistication avec laquelle il les déroulaient.

Pourtant son discours le plus marquant ne ressemble à aucun de ceux-ci. je doute même que les doyens de Standford se soient attendus à ceci lorsqu’ils ont invité le fondateur d’Apple. La biographie de Steve Jobs y fait référence et plutôt que de vous en parler, je vais vous laisser le découvrir.

Gojko Adzic : Making impact !

L’association We Do Product Management nous proposait ce 11 Mars une soirée exceptionnelle avec 2 orateurs. Gojko Adzic himself nous proposera une présentation sur le thème “making impact” tandis que Nicolas Gouy nous gratifiera d’un développement autour de l’Agile with GUTS !

Zenika accueillait cette soirée : un grand merci à Sébastien Sacard et Lisa Marçais du côté du WDPM, et aussi à Al chez Zenika pour son aide avant, pendant et après la soirée !

On commence d’ailleurs par une petite présentation du WDPM avant d’attaquer les choses sérieuses.

image

Making Impact par Gojko Adzic

La définition amont d’un produit se heurte à des facteurs d’imprédictabilité. Facteurs que l’on connait par ailleurs depuis plus de 100 ans :

  • Le facteur local
  • Le facteur temps
  • Le facteur Humain

Ces facteurs ont été identifiés par Peter Palchinsky. Dans The Ghost of the Executed Engineer, les auteurs reviennent sur certains désastres de l’Union Soviétique illustrant les facteurs de Palchinsky. Intéressons-nous spécifiquement à l’un d’entre-eux: le canal de la Baltique à la Mer Blanche.

image

Ce canal peut être considéré comme un succès, car il a bel et bien vu le jour, comme prévu. Cependant, il échoue aux 3 critères da Palchinsky et malgré son existence c’est effectivement un échec cuisant :

  • Le facteur temps : la construction du canal n’a pas anticipé l’évolution des cargos. En définitive, le canal s’est avéré rapidement trop peu profond pour les nouveaux navires !
  • Le facteur local : Sa situation septentrionale le rend gelé, donc impraticable 6 mois par an !
  • Le facteur humain : creusé à main d’hommes par des prisonniers dans des conditions extrêmes, il aura coûté le vie à 200000 d’entre-eux !

Autre exemple d’échec : le PC Junior d’IBM. Cette aventure coûta à IBM pas moins de 2 milliards de dollars ! Et pourtant, le géant de l’informatique ne fit jamais que délivrer exactement ce que l’utilisateur voulait ! Mais il échoua sur l’imprédictabilité du facteur humain.

D’un point de vue du Product Manager, on tend à planifier comme si tout était sous notre contrôle. Il faut au contraire créer des plans à même d’exploiter cette imprédictabilité au lieu de la combattre vainement.

Rechercher de nouvelles idées, essayer de nouvelles choses.

Cette approche trouve une incarnation dans le Set Based Design, l’aptitude à essayer différentes solutions en éliminant progressivement les moins valables.

En 2002 (ou était-ce en 2003 ?) Ducati se lance dans l’aventure Moto GP. Plutôt que d’essayer de construire d’emblée la meilleure moto, les ingénieurs conçoivent un engin sur lequel ils peuvent essayer multitude d’options. Après des débuts laborieux, celle-ci devient redoutable en seconde moitié de saison et l’écurie finit 2nd au championat constructeur !

Vous courrez après le déploiement continu ? Mais qu’en est-il de votre capacité à multiplier les versions, les comparer, créer des variations ? Cette approche permet d’expérimenter et d’apprendre. Bref essayer de nouvelles idées pour comprendre dans quelle direction il convient de se diriger !

La survivabilité

Le principe est simple : si votre expérimentation échoue, que les dommages en soit minimes … en tout cas que cela ne fasse pas couler l’entreprise !

Les connaissances et les pratiques d’ingénierie sont là … mais pas l’état d’esprit du product management !

Selection

Il faut faire le nettoyage sur ce qui ne sert à rien ou ce qui a échoué. En développement logiciel on ne supprime jamais rien (on garde, on ne sait jamais…). Et ce code ou ces composants morts deviennent un passif qui nous empêche d’avancer.

Non aux roadmaps, oui aux map of roads"

Mauvaise nouvelle pour les agilistes : le Product Manager n’est pas intéressé par les User Stories ! Ou plutôt, il est intéressé par leur faible granularité et leur côté “survivable” !

C’est le boulot du Product Manager de se créer des options, et les User Stories sont un bon outil pour cela : explorer des directions, sélectionner, changer d’option … bref tout sauf un plan linéaire ! Quelque chose qui ressemblerait à un plan avec un GPS pour s’y diriger. Ce GPS, c’est l’impact Mapping !

L’alignement rapide avec l’impact Mapping

L’impact mapping, c’est avant tout 4 questions pour arriver à une meilleure solution : 

  • Pourquoi ?
  • Qui ?
  • Comment ?
  • Quoi ?

Ce framework nous aide, car il nous évite de nous enfermer dans une logique unidirectionnelle, il nous permet d’explorer des variations : cette hypothèse contribue-t-elle au pourquoi ? Dois changer le “quoi” … ou m’intéresser à un autre acteur… S’il est parfois difficile de déterminer le pourquoi, les clients ont souvent moins de mal à dire ce qu’ils ne veulent pas. C’est un autre moyen d’arriver à nos fins !

On peut rapprocher l’approche Impact Mapping du Design Thinking : se générer des options, les explorer et les éliminer ! On a changé le mode dialogue au niveau du product management : on est passé du sacro-saint périmètre aux options et à leur contribution à un objectif…

Nicolas Gouy : Agile with GUTS

Nicolas est l’auteur d’un ebook portant ce titre et publié par infoQ.

image

Désolé pour la piètre qualité de la photo, vraiment l’éclairage (ou son absence, plutôt) m’a rendu la tâche difficile…

Parlons de valeur

Tout d’abord, c’est une notion subjective ! Et comme l’a indiqué précédemment Gojko Adzic, elle est subordonnée aux facteurs d’imprédicatabilité. Histoire de bien commencer, et de commencer fort (je dois dire), Nicolas nous parle des Shreddies. Les voici en image, pour illustrer le propos.

image

En passant d’un modèle à l’autre (sic !), Schreddies a vu son chiffre d’affaire s’envoler : la valeur n’est pas une question de sens commun ! Mais cela se travaille. Pourtant, sur nos projets agile, nous arrêtons notre horizon au backlog, comme si ce qu’il y avait avant était tabou !

Dans GUTS, il y a “G”, et ce “G”, c’est le Goals ! Notre but, c’est d’avoir un impact en étant en empathie avec notre client.

Le “U” quand à lui, c’est “Uncertainty”, et nous retrouvons les éléments que nous a partagé Gojko juste avant : il nous faut être à l’aise avec cela, et même en tirer parti. Comment ? En “crash testant” nos idées, en les validant au plus tôt.

Le “T” est plus original, car il s’agit du “Trade Off”. La solution parfaite est rarement un but désiré et raisonnable : il faut faire des compromis intelligents. Sur ce point, je ne suis pas sûr d’avoir compris ce que Nicolas voulait dire (exprimé plus simplement : je n’ai en fait rien compris). Bon, je verrais cela plus tard…

Le “S” signifie lui “Speed”. Une notion qui devrait remplacer celle de vélocité. Si la seconde notion couvre l’idée d’abattre plus de travail en moins de temps, la seconde consiste plutôt à atteindre un but plus rapidement … donc à être intelligent sur la manière d’y arriver ! C’est donc en fait remplacer la notion de périmètre par celle d’objectifs !

Quand on met l’acronyme ensemble, eh bien on parle bien entendu de “courage”. Et avoir du courage, c’est savoir être pertinent : toujours chercher à faire plus avec moins !