Every society honors its live conformists and its dead troublemakers.
Marshall McLuhan
Carnet de route : Agile Tour Bruxelles 2013 (1/2)
Nous y étions tout juste 70 l’an dernier. Cette année, ce ne sont pas moins de 180 badges qui seront distribués aux participants ! L’Agile Tour Bruxelles a pris une nouvelle dimension pour sa seconde édition.
Parti à 6h20 de Paris, on apprécie évidemment d’être bien accueillis. Cela semble se vérifier d’année en année en Belgique.
Petit café et discussion habituelle entre frenchies avant le début de la première pleinière. Tiens, on se demande bien pourquoi on va jusqu’en Belgique si c’est pour continuer de discuter entre nous.
Un mot d’introduction
Pas de Keynote en Belgique, et donc du coup plus de sessions “au choix” auxquelles participer. On a quand même le mot d’accueil des organisateurs.
C’est Bruno Sbille qui, comme l’an dernier, est le maître de cérémonie. Un excellent choix qui nous permet de goûter son inénarrable “accent Anglais”. Il le précise d’ailleurs lui-même : “I am speaking English right now” !
Cette introduction présentait deux petites originalité. La première était de nous présenter à nos voisins. Sympathique, quoique j’avais un peu l’impression de me retrouver à l’église à souhaiter la paix du Christ au gars situé à ma droite…
La seconde originalité devient plutôt une tradition de l’Agile Tour Bruxellois : chaque orateur est invité à teaser sa présentation devant l’assemblée entière durant une minute ! Une bonne idée, je trouve, qui était déjà présente l’an dernier.
Il est maintenant temps de se diriger vers notre première session !
My Product is a James Bond Movie, par Pierre Neis
“My name is Neis, Pierre Neis” ! C’est ainsi que Pierre débute sa session. Avec lui, le show est assuré ! L’introduction est toutefois un peu longue. Pierre bosse dans une grande compagnie, qui est globale, qui fait de l’agile et améliore ses techniques, et… Mais Pierre n’est pas satisfait !
Il manque quelque chose, des choses !
- Le “fun”.
- L’excitation
- La relation directe au client.
Bref, il manque de quoi faire de bons produits. Et de bons produits ne sont pas des produits standards!
Pour Pierre Neis, les bons produits peuvent s’inspirer de la recette des films de James Bond :
- De gros succès
- Une trame facile à comprendre
- Toujours la même recette, en fait.
Et cette recette Pierre nous la décode ainsi : Boom ! => Yeah ! => Yeah ! => Boom !
- Le premier “Boom” corresponds à l’avènement de la roadmap.
- Les “yeah” suivants correspondent aux démos (amazing sessions !)
- Le dernier “Boom” est la release vers le client.
C’est un peu long pour arriver à l’idée finale, mais celle-ci mérite d’être creusée.
Pause du matin
Parmi les petites originalités de cet Agile Tour figurent les pauses: elles ne font pas moins de 30 minutes. Les organisateurs ont en effet acté que beaucoup d’échanges s’y passent qui font la valeur de l’évènement. Ils ont donc rallongé les pauses !
Produits bio et développement durable au menu de ces interludes.
Et aussi, bien sûr, échanges entre participants et orateurs.
Lean Startup for Developers : you can do it to ! Par Sébastien Arbogast
Je me suis tout bonnement trompé de salle ! Ce n’est pas cette session que j’avais sélectionné dans le programme ! Bien m’en a pris, ce fut ma session préférée.
Sébastien nous évoque sa propre expérience de Startuper. Une expérience qui a fini par s’arrêter d’ailleurs, mais qui ne signifie pas que l’orateur n’ait rien appris de valable à nous partager. Bien au contraire. Son expérience commence lors d’un startup week-end en 2011 auquel il s’était inscrit tardivement et qu’il avait préparé à la va-vite. A sa propre surprise … il a gagné ! Ainsi est né Kodesk, l’idée d’un service de partage de bureaux. Une idée qui n’a jamais pris l’ampleur escomptée car Sébastien avait sous-estimé la crainte fondamentale d’accueillir des étrangers au sein des bureaux d’une compagnie ! Mais de cette expérience a germé une autre idée : Peer Trust.
Mais ceci n’était que l’introduction. L’objet de cette présentation est à venir : Est-il possible de créer une startup pour n’importe qui ? Comment faire en appliquant le “lean startup” ?
Sébastien veut nous convaincre et nous rassurer : NOUS pouvons le faire !
- On a les compétences : pas besoin d’avoir un MBA !
- Nous avons les opportunités : il suffit de regarder autour de nous.
- Nous pouvons avoir les moyens : il existe de nombreuses initiatives destinées à aider.
- Trop vieux ! Mais non, on n’est jamais trop vieux.
- Mon idée n’est pas assez bonne. En fait le concept de “l’idée originale” est plutôt surévaluée. Allons même plus loin : l’idée n’a pas de valeur intrinsèque, tout est dans l’exécution.
L’une des choses qui nous effraie le plus est de perdre notre boulot … pour obtenir quoi ? En fait, il n’est pas utile de quitter son travail, en tout cas pas tout de suite. Sébastien nous conseille même d’attendre le plus possible, chose que lui-même n’a pas faite.
Votre produit n’est pas votre produit ! Votre produit est un business model. Et qui dit “business model” dit “business plan”, n’est-pas ? Erreur !
Mais l’entrepreunariat n’est pas une loterie. En vérité, on commence en ne sachant rien sur nos clients potentiels et il faut avoir le courage de l’admettre. Et d’en admettre aussi le corollaire : on ne fera pas bon du premier coup. C’est un peu comme si on allait rater sa démo Scrum.
C’est tout l’objet du cycle Lean Startup : construire quelque chose pour le valider par le biais d’une mesure. Mais pas n’importe quelle mesure. Plutôt qu’une mesure quantitative (aka l’étude de marché, vous savez, celle avec laquelle le Paic Citron n’aurait jamais vu le jour…) on va chercher une mesure qualitative, donc en fait un (ou plusieurs, mais pas beaucoup) utilisateur avec un problème, et l’on va chercher à le rencontrer en personne !
Pour illustrer la démarche, Sébastien nous introduit la démarche Lean Startup sous forme de pseudo-code. Je ne saurais me livrer au même exercice que l’orateur (il est préférable d’aller voir sa présentation), mais cela donne des choses de ce genre :
Ou pour résumer de manière plus sibylline:
- Revenir au problème (prendre de la distance avec la solution)
- Identifier les clients potentiels
- Identifier 3 clients potentiels. A priori les plus prometteurs, mais en définitive on fait un peu confiance à la chance…
- Pour chaque client, établir un Lean Canvas, celui décrit dans Running Lean (https://freethinker.addinq.uy/post/39835584866/note-de-lecture-running-lean-2nd-edition-par-ash)
- Trier les clients par :
- “pair level” c’est à dire votre alter égo, celui qui vous donnera donc le plus de feedback
- Facilité à atteindre. C’est à dire : puis-je facilement lui parler en direct
- Capacité à payer : Ou plus exactement : combien ce client est prêt à payer.
- Taille de marché. C’est en fait le dernier critère !
Lister les hypothèses. Attention il ne faudra tester qu’une hypothèse à la fois. En s’aidant, par exemple, du “validation board” (http://leanstartupmachine.com/validationboard/). Attention aux hypothèses ! Les clients potentiels ne paieront pas pour quelque chose qu’ils trouvent simplement “bien”, mais pour quelque chose dont ils ont vraiment besoin ! Sortir du bâtiment, pour aller faire des interviews. Le mieux est de pouvoir faire les interviews à deux, avec un observateur concentré sur la communication non-verbale. Travailler le MVP et le pricing Evaluer la solution proposée ; itérer si nécessaire Obtenir un signup et un paiement
Alors seulement, vous pouvez envisager de quitter votre travail. Mais pas avant : se sentir menacé alors que l’on a pas commencé le business est la meilleure façon de prendre de mauvaises décisions !
See you soon
Vous n’êtes probablement pas encore rassasié de ce Agile Tour Bruxelles ? Nous non plus. En fait, il est l’heure de se rendre au buffet de midi. Nous nous retrouverons très bientôt pour la suite de cette journée !
Le management, c’est bien faire les choses.
Le leadership, c’est faire les bonnes choses.
Peter Drucker
Note de lecture : Software Project Management, par Walker Royce
Note : 6 ; La gestion de projets selon Unified Process.
Un ouvrage un peu dense et un peu difficile à lire, mais dont le contenu est indéniable, notamment sur les métriques de suivi de projet. Walker Royce porte un fardeau assez difficile : son père, Winston, est en effet l’auteur d’un article décrivant le cycle en cascade qui est à l’origine du « cycle en V »… à son corps défendant !
Les 4 parties constituées de 17 chapitres de la partie principale du livre couvrent un peu plus de 250 pages. Il faut y ajouter les très conséquentes 5 annexes de la 5ème partie qui totalisent à elles seules 150 pages !
La première partie « software management renaissance » comprend 4 chapitres et un peu moins de 70 pages. Bien entendu, le premier chapitre traite du modèle en cascade présenté dans l’article de 1970 de papa Royce. Plutôt que de critiquer son géniteur, Walker fustige, à juste titre je dois dire la manière dont le modèle a été mal compris. Le second chapitre, s’il est court avec sa dizaine de page, n’est pas une ballade de santé. Il présente l’évolution de l’économie du logiciel en terme de ROI, coût par SLOC, etc. En comparaison le 3ème chapitre qui présente logiquement l’amélioration de cette économie est nettement plus accrocheur. L’auteur y évoque l’influence de différents paramètres tels que le langage de programmation, l’utilisation de la conception orientée objet ou la pratique du peer review. Cette première partie se conclut par la comparaison des « anciens principes » contre les nouveaux (ceux de l’auteur). J’ai trouvé l’énoncé des 30 principes de Davis bien plus intéressante (même si certains sont clairement erronés), en regard des 10 principes de Royce.
La seconde partie « a software management process framework » rentre dans le dur de UP. 65 pages sur 5 chapitres y sont consacrés. Le chapitre 5 se focalise sur le concept de phase (vous savez, celui que l’on a abandonné avec agile…). Bien entendu ce sont les 4 phases d’UP qui y sont évoquées. C’est sans surprise que l’on aborde le chapitre 6 qui s’avère consacré à la question des artéfacts projet, les 25 pages de se chapitres évoque l’existence de nombre d’entre eux en les ventilant sur 5 pratiques d’ingénierie. Un chapitre que j’ai du mal à trouver passionnant, bien qu’il soit central dans les méthodes prescriptives et finalement bien abordé ici, y compris la discussion sur l’usage et l’apport d’artefacts formels. Les deux chapitres suivants sont étrangement courts. D’abord le chapitre 7 sur les modèles n’évoque que l’existence de 5 modèles (qui rappellent les 4 + 1 vues de Philippe Kruchten), mais sans aller plus avant parce que hors du sujet de l’ouvrage probablement. Ensuite le 8 chapitre 8 nous parle du workflow de l’itération, décrivant celle-ci comme un mini waterfall. Beurk ! Le dernier chapitre de cette seconde partie est plus ésotérique en évoquant les jalons majeurs et mineurs.
La troisième partie « software management disciplines » couvre 85 pages sur 5 chapitres. Il commence avec le chapitre 10 qui aborde la planification itératif et son outil phare : le WBS (Work Breakdown Structure). Encore un truc que l’on ne fait plus en agile. Toutefois si vous voulez rentrer dans le sujet, vous avez là une référence de première main. Non seulement il donne une méthode de découpage, mais évoque les répartitions budgétaires relatives et leur évolution en fonction des phases du projet ! Le chapitre 11 lui traite de l’organisation de projet, au sens « administratif ». C’est donc à des organigrammes qu’il nous faut faire face, avec des listes de responsabilités et tout et tout… Le chapitre 12 focalise sur l’automatisation du processus et notamment du change control. Bref, pas mal d’outillage « projet ». Fort logiquement, au chapitre 13, ce sont les indicateurs de management qui sont à l’honneur et principalement le fameux Erned Value Tracking (EVT). Le chapitre 14 aborde la customisation du processus (car UP se customise). Walker Royce aborde cela en classant les types de projet en 2 dimensions : la complexité technique sur un axe et la complexité de management sur l’autre. Chaque axe nécessite une emphase particulière sur certaines disciplines et certains artefacts. Il n’y a plus qu’à combiner les deux, hein ?
La dernière partie du corps du livre « looking forward » ne compte que 3 chapitres et se contente donc d’une trentaine de pages. Elle débute par le chapitre 15 qui évoque les projets dits « modernes ». C’est finalement là que l’on retrouve des choses qui se rapprochent le plus des projets agiles : des exigences qui évoluent, de l’intégration continue, mais le tout encore et toujours dans les fourches caudines d’XP aux forceps. Au chapitre 16, on tente de tourner notre regard vers un nouveau modèle économique des projets. Il s’agit en partie d’une remise en cause partielle des postulats de Boehm dans le cadre des développements actuels. La partie textuelle de cet ouvrage se conclu par un chapitre 17 assez courts évoquant les problèmes de transition vers ces processus…
La 5ème partie du livre est consacrée aux annexes. Comme je l’ai dit, elle est franchement volumineuse. L’annexe A évoque l’état des pratiques en s’appuyant sur des rapports. Hélas tout ce ceci n’est plus d’actualité, mais cette partie est au moins courte ! L’annexe B rentre dans le modèle COCOMO 2 de Boehm, et on s’en tire pour une vingtaine de pages. Une dizaine de pages sont consacrées à des métriques de changement qui à mon avis ne servent à rien. L’annexe D est un cas d’étude et franchement il faut être motivé pour s’en taper les 60 pages. Enfin, même si l’annexe D compte 30 pages, il est plus facile de s’y intéresser : challenger UP face à CMM peut s’avérer instructif.
Le livre est dense, très dense. Il traite de processus semi-prescriptif est déballant beaucoup de matériel, beaucoup de concepts et un niveau de technicité, en processus, en métriques et un petit peu dans tout, il faut bien le dire, qui est très élevé. Le vrai risque est d’être un peu noyé à force d’en vouloir pour notre argent. L’erreur de l’auteur est d’essayer d’augmenter le niveau de technicité, de finesse dans la maitrise et la gestion de projet, là où la clé serait plutôt la simplification.
Référence complète : Software Project Management: A Unified Framework – Walker Royce – Addison Wesley 1998 – ISBN: 0-201-30958-0
Forum ouvert et agilité
Ce 22 Septembre (oui, un dimanche), Christine Koehler nous a proposé de nous rassembler afin de réfléchir ensemble aux convergences entre forum ouvert et agilité. C’était aussi une opportunité d’échanger avec des orateurs du Scrum Gathering que Christine avait contacté pour l’occasion: Dan Mezick, Suzanne Daigle et Jasmina Nikolic. Suzanne nous a d’ailleurs gratifié d’un post pour l’occasion.
Zenika hébergeait ce rassemblement, je ne saurais trop remercier Carl Azoury d’être venu spécialement nous ouvrir les locaux ! Par contre l’aménagement spécifique à cette réunion nous était dû à Christine et entre la tenture d’affichage électrostatique, les posters répartis dans notre zLocalhost et la signalétique des points de rendez-vous, c’était de la mise en musique élaborée.
Parmi les appointés, quelques habitués des rendez-vous agiles.
Sur 22 inscrits, nous étions finalement 17, ce qui n’est finalement pas si mal. Le nombre ne fait pas la qualité de toute manière.
Christine et Suzanne ont ouvert la séance en rappelant le fonctionnement du forum ouvert. Je ne le rappelle pas ici, on trouve pas mal d’information sur le Web à ce sujet.
La première étape, c’est de proposer les sujets, bien sûr. Il n’y a pas de limite. On l’écrit sur un grand format…
… et on le présente devant tous.
Impact hub ? Cela ne me parle pas trop. L’occasion pour moi d’en apprendre plus…
Lorsque qu’on a fait le plein, on vient faire son marché.
D’ailleurs le lieux s’appelle bien la “place du marché”.
Dan Mezik et Jasmina Nikolic semblent assez pensifs devant les sujets. Le temps donné au groupe s’il est alloué ne veut pas dire que l’on s’y limite: Comme le dit Suzanne, la passion et l’énergie n’arrivent pas sur la base de la contrainte du temps.
J’en sais un peu plus maintenant sur l’impact hub ; le tout me laisse encore un peu dubitatif, bien que je sois à priori convaincu sur l’idée de croiser des champs d’activité différents pour faire germer des idées nouvelles. Mais pourquoi et comment ? L’idée fera peut-être son chemin avant de vraiment m’interpeler.
D’autres sessions en cours. pas très facile pour moi de m’insérer en cours de route, je passe.
Je passe aussi celle avec Dan Mezik !
Finalement je reste un peu sur une session consacrée au respect des règles et à la cohésion d’équipe !
Je ne suis pas sûr d’accrocher à la direction que prends la discussion. Assimiler les “valeurs agiles” à une spiritualité, c’est peut-être trop fort pour moi. Et oui, en bas de la feuille, c’est bien marqué “sexualité”.
Pour le coup, j’ai aussi manqué la discrète discussion menée par Jasmina autour du “oscrumban” ! Donc, je ne sais toujours pas ce que c’est !
Au risque de vous frustrer, je ne vais pas retranscrire les discussions. Un forum ouvert, ça se vit plus que ça ne se restitue. Même si le “grand journal” essaie de se faire l’écho de notre après-midi !
There’s no sense in being precise when you don’t even know what you’re talking about.
John von Neumann
Devfest Nantes 2013
Le DevFest Nantes 2013 est une journée de conférences organisée par le GDG Nantes, qui s’inscrit dans un évènement mondial : les DevFests.
Les DevFests sont des événements communautaires de grande envergure à travers le monde, suivant la tradition des Google Developer Days et organisés par des groupes d’utilisateurs locaux. Ils constituent une occasion unique de partager et d’échanger autour des technologies du Web et du Cloud ! Et plus particulièrement sur Android, Dart, AppEngine, Angular JS, Chrome, HTML5, WebGL, Google Drive, Go, GWT… Cet événement sera suivi d’une AfterParty afin de discuter de manière conviviale et faire du networking !
Zenika est partenaire de longue date du Google Developers Group de Nantes et aussi l’un de cette manifestation.
Nous serons aussi parti prenante de l’évènement avec une session que je co-animerais avec Martin Mouterde. La session mérite bien sûr son petit teaser !
De l’agilité pour mon projet : pour quoi faire ?
Les développeurs ne sont pas tous des individus mal rasés, travaillant la nuit et jonchant leur sillage de boites de soda et d’emballages de pizzas.
L’agilité ne se réduit pas à des hurluberlus cherchant à couvrir chaque centimètre carré des murs de post-it multicolores.
Et d’ailleurs, l’agilité, qu’est-ce que c’est ? Vraiment !
Est-ce une nouvelle mode qu’il me faudra subir et passera à mon grand soulagement ? Ou est-ce une véritable réponse à la sclérose et l’inefficacité qui gangrènent nos projets ?
Durant cette session de découverte, nous allons voir ensemble ce qu’est réellement l’agilité, en quoi elle peut vous aider à réaliser des projets qui déchirent tout en y prenant plaisir ! Depuis les principes de base (adaptation aux changements, collaboration et transparence) jusqu’aux pratiques telles que le test-driven développement, le pair-programming, l’intégration continue, etc. nous iront à la rencontre des fondamentaux de l’univers agile.
Enfin, nous dérouleront un jour dans la vie du développeur agile pour comprendre comment les choses se passent. Réellement.
Rendez-vous à Nantes le 8 Novembre pour la DevFest !
Purely awesome – Chess Games and Neo4j
I wasn’t able to follow the post. I got myself lost into the superb presentation built for it. Chess game replays. Dynamic graphs. Pure awesomeness.
This is by far the most entertaining blog entry presentation I’ve seen since I’ve start reading and writing about NoSQL.
Original title and link: Purely awesome – Chess Games and Neo4j (NoSQL database©myNoSQL)
Cedric Fauvet évoquait justement ce cas d’usage de Neo4J lors du meetup de mardi. Voici a chose mise en musique, hélas seuls les vrais amateurs d’échec sauront vraiment apprécier la chose, ce qui n’est pas non plus mon cas. Comme l’auteur du post, je me suis simplement laissé hypnotiser par ce très beau replay…
When you feel the need to write a comment, first try to refactor the code so that any comment becomes superfluous.
Martin Fowler in Refactoring
Software Freethinker 
