Impossible n’est pas un fait, c’est une opinion.
Mohamed Ali (via NipTech podcast)
Reducing Requirements to EIS Specifications Gap using RM-ODP Viewpoints
Oui, je peux assumer ce que j’ai écrit là ! Il s’agit d’un modèle de traçabilité entre expression du besoin et modèle d’architecture. Have fun !
Voici également le lien vers ce papier dans Issuu
(Source: http://static.issuu.com/)
Note de lecture : Agile Coaching, par Rachel Davies & Liz Sedley
Note : 5 ; Une vision claire de ce qui est nécessaire à un projet agile, mais un texte plutôt entre la conduite de projet et le coaching proprement dit.
Coacher une équipe pour la rendre agile est sans aucun doute un exercice difficile. Que faire ? Comment interférer, comment aider l’équipe à se prendre en main, à quel moment faut-il faire preuve de fermeté ? Bref, faire les bonnes actions, adopter les bonnes approches et les bonnes attitudes ne sont pas choses aisées et la frontière entre le succès et l’échec est parfois bien mince.
L’objectif de ce nouvel opus des pragmatic programmers est d’aider le coach à agir de manière opportune le long des pratiques agiles classiques. L’écueil de ce type d’ouvrage est de tomber dans une nouvelle description des pratiques agiles en négligeant la façon dont le coach doit ou peut entreprendre l’équipe sur chacun de ces sujets.
Je ne vais pas revenir sur chacun des chapitres, il y en a 14, pour 200 pages, sachez donc que la brièveté des chapitres joue en faveur de l’efficacité du texte et donne un rythme à la lecture, celle-ci n’est donc pas pesante. Je peux toutefois dire quelques mots à propos des 4 parties qui découpent le livre.
La première partie (ainsi que la dernières) sont celles qui concernent réellement la partie coaching « humain ». Les 4 chapitres couverts sur 58 pages sont consacrées au travail avec les personnes et avec les équipes. Le parti pris est ici de « coacher par l’exemple » et non de se ternir en retrait. Bien sûr l’observation, le feedback et la communication font partie des outils abordés. C’est fort peu à propos que je parle d’outil, car le texte montre plutôt des directives et si j’ai certaines idées générales une fois la dernière page tournée, je me suis quand même senti plutôt démuni.
La seconde partie nous montre clairement que l’expérience des auteurs vient plus des projets agiles que du pur coaching. En effet cette partie est consacrée aux pratiques de projet : planning meeting, stand-up, etc… Le tout sur 4 chapitres et un nombre de pages qui va de pair avec la première partie. Ici on est en terrain solide et les auteurs savent parler de la matière. Dommage que la matière n’ait plus l’attrait de la nouveauté car ces sujets ont déjà été largement traités par ailleurs. Le texte est intéressant mais devrait prendre place dans un ouvrage sur les projets agiles plus que dans un texte consacré au coaching.
Un pas plus loin, la troisième partie traité des pratiques de craftmanship : qualité du code, build, définition du « done ». Là encore les auteurs connaissent leur sujet, mais on en est plus à donner des conseils sur les pratiques de développement qu’à guider l’équipe ou ses membres.
La quatrième partie est dédiée au feedback : démo, rétrospective et progression du coach lui-même. Le chapitre sur la démo est dans la continuité des chapitres précédents, donc d’avantage lié à la conduite de projet qu’au coaching tandis que le chapitre sur la rétrospective, s’il est plus dans la continuité de ce à quoi je m’attendais n’est qu’un condensé de « Agile retrospective » d’Esther Derby, lecture que l’on préfèrera. Cette partie me laisse un goût d’inachevé.
Au final, le bilan est assez mitigé. J’ai trouvé que l’ouvrage insistait trop sur les pratiques déjà bien connues : standup, planning meeting, rétrospectives, démonstrations, ainsi que sur les activités d’ingénierie (build, design, tests). Fort heureusement, le tout est émaillé de conseils et d’histoires venant de l’expérience des auteurs. Mais ceux-cis ne constituent pas une part assez importante du livre à mon goût. J’avoue avoir quand même apprécié les sections « hurdle » et « check-list » à la fin de chaque chapitre.
Si je semble quelque peu déçu (et peut-être un peu sévère dans a notation), c’est sûrement que j’attendais beaucoup de ce livre en particulier et du « pragmatic bookshelf » en général, dont la qualité s’avère quand même élevée de manière récurrente. Mais je n’irais pas jusqu’à déconseiller la lecture de ce livre. Au pire, vous y aurez appris des choses sans consacrer trop de temps à la lecture !
Référence complète : Agile Coaching – Rachel Davies & Liz Sedley – Pragmatic Bookshelf 2009 – ISBN : 978 1 93435 643 2
Si je n’avais écouté que mes clients, j’aurais inventé un cheval plus rapide.
Henry Ford
Les 30 jours du Canard
Depuis quelque temps j’utilise Duck Duck Go comme moteur de recherche. Je souhaitais donner sa chance à une alternative à Google. C’est la moins commerciale des options en présence. Voici mon feedback.
Présentation
Duck Duck Go (je vais simplement l’apeller DDG à partir de maintenant) est un moteur de recherche dit “hybride” qui s’appuie à la fois sur ses propres crawlings et sur des moteurs de recherches externes. Deux aspects (par ailleurs très corrélés) ont mis en luière ce nouveau venu dans la bataille des moteurs de recherche:
- Il est désormais le moteur de recherche par défaut de plusieurs distributions Linux.
- Sa politique de respect de la vie privée, DDG ne conservant aucune information nominative de navigation !
L’un des reproches grandissant à l’encontre des moteurs de recherche en général et de Google en particulier concerne les règles de ranking. Aujourd’hui Google intègre dans ses rankings des paramètres locaux mais aussi des paramètres liés aux recherches précédentes des utilisateurs. Cela introduit un “biais de confirmation”. En clair: si vous recherchez des avis ou des informations sur un sujet controversé, disons par exemple le créationisme, vous aurez des chances de tomber en premier sur des sites pro-créationistes si vous êtes l’un d’entre-eux car vos recherches précédente auront tourné en ce sens. L’exemple est un peu grossier, mais vous comprendrez l’idée générale ! Evidemment, cette caractéristique va rendre les résultats apparemments plus désirables car ils iront d’avantage dans le sens de vos opinions initiales. Mais vous avez aussi moins de chance d’apprendre quelque chose de nouveau ou de confronter une opinion différente !
Duck Duck Go s’écarte délibérément de ces traits de personalisation. Donc outre la comparaison des résultats remontés, le ranking des informations est aussi intéressant à comparer !
Les recherches vagues
Aujourd’hui, une recherche que j’apellerais “vague” est composée de deux ou trois terme. Faire une recherche à un seul terme est à peu près inutile car ce n’est pas suffisamment discriminant. En fait aujourd’hui la plus grande part des recherches sont faites sur deux mots !
Sur ce type de recherches les deux moteurs m’ont paru globalement de pertinence égale par rapport à ce qui est remonté.
L’un des tests classiques est de rechercher sur mon nom.
- Google flatte plus mon égo en remontant très haut, mon blog, mon profil LinkedIn ainsi que diverses choses que j’ai comises dans un passé pas très éloigné.
- DDG est moins complaisant. Il ne va pas remonter plus haut ce que j’aimerais voir haut. Par contre il va me remonter des choses plus inattendues et que j’aurais même cru définitivement perdues pour certaines.
Dans certains cas de figure particuliers, DDG ne parvient pas à me remonter ce qui m’intéresse, alors que Google y parvient. Je n’ai pour l’instant jamais fait l’expérience inverse.
Ergonomie
Il serait dommage de passer sous silence l’apect ergonomique. DDG se distingue positivement du géant de Mountain View par l’absence de liens sponsorisés d’une part et d’autre part par un affichage particulièrement clair facilitant le repérage des sources par l’iconographie située à gauche. Je m’en sert pour repérer nottament les liens vers Wikipedia ou Twitter. Autre originalité, le propositions de termes secondaires situés à droite. Honnêtement, je les ai essayés de temps à autres mais n’en ai pas encore perçu l’utilité ou la pertinence. Mais l’idée parait bonne.
Les recherches précises
Dans ce cas, les choses se compliquent sérieusement pour DDG. Il s’agit des recherches où je souhaite cibler du contenu particulier avec 5 ou 6 termes. Je dois bien l’avouer DDG échoue souvent à me remonter ce qui m’intéresse, du moins avec un ranking valable. Je tombe à moins de 20% de recherches courronnées de succès (c’est un pourcentage au feeling, je n’ai pas de mesure précise), alors que je suis plutôt dans les 50% voir plus pour Google.
J’avoue que j’essaie généralement les deux recherches dans cette configuration. Parfois même vais-je directement sur Google. Au mieux, les deux recherches ont des pertinences équivalentes. Au pire, DDG prend cher.
Je suis venu te dire que je m’en vais ?
La bataille, au simple niveau de la pertinence tourne à l’avantage de Google ! Mais il ne faut pas négliger l’aptitude de DDG à remonter de “l’inattendu”. Parfois, c’est justement là où vous trouverez votre bonheur. Dans de rares cas, c’est ce qui m’est arrivé.
Les recherches pointues continuent à laisser à Google une confortable longueur d’avance, aucun doute là-dessus.
Maintenant la vrai question : la position éthique de DDG compense-t-elle sa performance en retrait par rapport à Google ? Dit autrement: vais-je garder DDG comme moteur de recherche par défaut ?
Au début, j’aurais répondu Non. Mais aujourd’hui je le trouve suffisemment bon dans la plupart des cas (sans compter un affichage supérieur esthétiquement dans les résultats de recherches), même si je dois régulièrement sur Google. Je vais donc le garder jusqu’à nouvel ordre, en espérant qu’il s’approche de son redoutable concurent !
Une dernière chose…
Le titre de ce post est inspiré du titre d’un film, saurez-vous le reconnaitre ? Je laisse le plus affuté et/ou le plus rapide répondre ici même !
Le Lean Startup expliqué aux développeurs, par Camille Roux
Camille Roux est le (jeune) fondateur de Human Coders et un adepte du Lean Startup, sinon un évangéliste et un addict ! Je n’ai hélas pas encore eu l’opportunité d’assister à une de ses présentations ni d’échanger avec lui (j’espère remédier à cela un jour prochain).
Voici un support de présentation sur l’approche Lean Startup qu’il a employé pour la création de Human Coders
View more presentations from Camille Roux
Le leadership : c’est l’art de faire faire à quelqu’un quelque chose que vous voulez voir fait, parce qu’il a envie de le faire.
Dwight Eisenhower
Note de lecture : Blue Ocean Strategy par W. Chan Kim & Renée Mauborgne
Note : 7 ; La stratégie de la non compétition expliquée
Le « blue ocean strategy » est devenu un grand classique du marketing, et ce livre en est la bible. La première partie explique (exemples à l’appui) ce qu’est cette stratégie et pourquoi elle est si porteuse. Les exemples sont clairs tout comme l’est le raisonnement.
En deux mots, et en simplifiant beaucoup : plutôt que de combattre dans un secteur d’activité fortement concurrentiel où l’on se comparera aux compétiteurs en terme de prix d’images ou de performance (le red ocean), l’idée est de créer son propre espace (le blue ocean) où l’on ne peut être comparé aux autres acteurs du marché. Bien sûr, c’est plus facile à dire qu’à faire. Tout d’abord cela à fort à voir avec l’innovation et ensuite il faut s’assurer que la création de ce nouveau marché attirera des clients, que ce soient les anciens ou un nouveau segment.
La suite du livre se focalise sur la démarche pour arriver dans ce type de positionnement. La aussi, et toujours bien aidé par des exemples on comprend ce qu’il faut faire et ne pas faire. Cela commence par les « principes de formulation » : se focaliser sur la « big picture », aller chercher au-delà de la demande directe formulée par le marché, etc.. Pour cela on utilise la nouvelle courbe de valeur : quels facteurs doivent être réduits ? Lesquels doivent être augmentés ? Lesquels doivent être éliminés ? Lesquels doivent être créés, que l’industrie n’a jamais offert ?
La seconde partie « formuler le blue ocean » se focalise sur la façon de faire émerger celui-ci d’un marché existant. La chapitre 3 évoque la reconstruction des limites du marché. Les auteurs proposent 6 chemins pour cela :
- Examiner les autres secteurs industriels susceptibles de proposer une alternative.
- Examiner les sous-ensembles de stratégies au sein du secteur industriel où l’on opère.
- Explorer la chaine d’achat.
- Evaluer l’offre des produits et services complémentaires.
- Evaluer l’attraction fonctionnelle et émotionnelle des acheteurs.
- Regarder les tendances à travers le temps.
Les 6 directions qui devront être explorées serviront à construire le planning stratégique. C’est le sujet du chapitre 4 : construire la « big picture ». Celui-ci propose de Visualiser cette stratégie en 4 étapes :
- Visualiser la prise de conscience.
- Visualiser l’exploration (en s’appuyant sur les 6 chemins vus précédemment)
- Visualiser la stratégie à venir.
- Visualiser la nouvelle stratégie en terme de « avant / après ».
A partir de là, le chapitre 5 évoque la façon de dépasser la demande existante. C’est le principe des trois tiers de « non clients » qu’il faut identifier, au-delà de ce qui est notre marché actuel : ceux qui sont prêts à devenir nos clients, ceux qui refusent d’être nos clients et ceux qui ne sont simplement pas explorés.
Le chapitre 6 se concentre sur l’exécution du plan stratégique : évaluer l’utilité pour l’acheteur, cibler le prix, calculer les coûts et construire l’adoption.
Il faut maintenant exécuter un plan qui nous y amènera : c’est le sujet de la troisième partie.
Le chapitre 7 évoque les obstacles organisationnels. Ils peuvent être cognitifs (le blocage sur le statu quo), politiques (l’opposition de ceux qui n’ont pas intérêt à sortir de la situation existante), motivationnels ou liés aux ressources existantes limitées.
Le chapitre 8 se focalise sur le « fair process » : comment mettre en action une nouvelle stratégie dans l’entreprise en engageants les personnes qui y participeront ?
La stratégie « blue ocean » n’est pas un processus statique, elle s’entretient et évolue dans le temps. Le chapitre 9 évoque la tenue de ce processus dans le temps.
Personnellement, étant un béotien du marketing, ce fut une découverte, une nouvelle façon de voir le positionnement d’un produit. Il s’agit d’une nouvelle façon de dire : « si les règles du jeu ne te plaisent pas, change les règles ! ». Il s’agit aussi probablement d’une application particulière de certains préceptes de l’art de la guerre.
Je recommande vivement !
Référence complète : Blue Ocean Strategy: How To Create Uncontested Market Space And Make The Competition Irrelevant – W. Chan Kim & Renée Mauborgne – Havard Business Press 2004 – ASIN : B001E5207M (Kindle edition)
Vous trouverez aussi en ligne une mind map reprenant les éléments du livre
Mes retours sur l’Agile Day Valtech 2012
Ce 19 Juin 2012, Valtech nous accueillait dans ses locaux du 103 rue de Grenelle pour une journée de présentations et d’atliers dédiés à l’agilité. Quelques retours.
Keynote
C’est toujours quelque chose d’écouter Laurent Sarrazin ! Il y a du dynamisme, de la substance, beaucoup d’anglicisme et des phrases choc ! C’est sous un format singulièrement raccourcis que Laurent nous a présenté Sweet Rupture qu’il avait déjà joué au Scrum Day. Je n’avais alors assisté qu’à une partie de cette présentation. Ici, j’ai tout vu, mais en accéléré !
Laurent nous raconte l’odyssée du centre agile de la société générale et ses nombreuses sources d’inspiration qui en font de “l’agilité Benetton” selon ses propres mots. Difficile de raconter cette session, je vous propose plutôt d’en visonner la version longue celle du Scrum Day.
Kanban game
Laurent Morisseau est probablement l’une des personnes les plus pointues en France sur l’application de Kanban en France. Il est d’ailleurs l’auteur d’un livre qui arrive en librairie ces jours-ci : Kanban pour l’IT. Vous devriez d’ailleurs avoir droit à une note de lecture à ce sujet dans euh … un certain délais, car Laurent a eu la gentillesse de m’en faire parvenir un exemplaire !
Cet agile game est désormais un classique, car Laurent a déjà joué le Kanban Game à de nombreuses reprises. Toutefois je n’avais jamais eu la possibilité d’y participer. J’étais donc bien décidé à combler cette lacune.
Je n’ai pas été déçu, d’autant que Laurent et son complice Dimitri Baeli (visiblement faire collaborer Bretons et Normands est donc possible) sont rompus à l’exercice. Nous avons donc exécuté par équipe de 6, 8 itérations de développement afin de délivrer de la valeur, mais surtout de l’argent (eh oui : la valeur délivrée tôt capitalise et rapporte plus…). Voici ce que j’en ai trouvé:
- Le jeu est intéressant et prenant, la qualité de l’animation aide sans aucun doute !
- Des équipes de 6, c’est un peu trop: on se marche sur les pieds et cela génère trop de discussions quand aux différents choix !
- Le jeu met bien en évidence les “limites de WIP” et le focus sur le flux et les goulots d’étranglements.
- L’aspect “comptabilité” est un peu complexe et ce n’est pas évident d’en tirer les enseignements. Au minimum, il aurait fallu passer plus de temps (encore !) pour les décoder.
- Le timing était un peu trop serré, mais c’était lié à l’agenda spécifique de cet Agile Day. Les conditions normales requièrent un peu plus de temps.
Bref, je suis satisfait de cet agile game qui matérialise très bien les aspects principaux du Kanban.
Outside in Design : the BDD way
Cette session présentée par Marcus Anhve de Valtech Suède était pour moi la session hard core de cette journée ! Concrètement, cette session dédiée au Behaviour Driven Developement par l’exemple était d’un abord ardu pour moi : Marcus a réalisé ses exemples en Ruby (que je ne connais pas), en y ajoutant du Rails, de la compilation avec Rake et évidemment du RSpec pour l’acceptance testing ! Sans oublier un moteur de templating pour le HTML que j’ai justement oublié …
Bref, au-delà de la présentation d’introduction il me fut très difficile de suivre le fil, j’ai juste réussi à ne pas être complètement noyé. Respect pour notre très cool présentateur qui a réussi à faire du “par l’exemple” avec absolument aucun code préparé à l’avance et en réalisant absolument tout en live ! Franchement il faut le faire et c’est la première fois que je le vois ainsi fait intégralement. Marcus m’a confié qu’à son avis c’est vraiment la bonne façon d’exposer la façon dont on avance et on construit les choses : de le faire sans tricher !
Innovation needs waste
Ce fut ma sesion préférée de la journée ! L’animateur de cette session, Dirk Lässig de Valtech Germany était venu nous initier au Design Thinking. Dirk a intelligemment combiné une présentation limpide avec un exercice hélas un peu trop sous la contrainte du temps !
Le Design Thinking, quest-ce que c’est ? Une approche et un ensemble de pratiques pour permettre l’innovation radicale, celle qui n’est pas une simple amélioration d’idées existante mais l’émergence d’un concept nouveau en rupture avec l’existant !
Les approches agiles parlent souvent de “vison” et de son importance. Mais d’où vient-elle ? D’une personne particulièrement géniale qui l’a sortie de son chapeau à l’aide d’un quelconque tour de magie ? Faire émerger les Visions innovantes ne doit plus être comme le-boulot-de-quelqun-d’autre-car-nous-on-écrit-du-code ! Le design thinking nous apprend à mettre ensemble des personnes d’horizons différents justement pour élargir le champs du possible. Et justement pour élargir ce champs il faut générer des idées sans se censurer, même si au final la plupart et peut-être même toutes seront écartées.
Nous avons donc tenté (avec un succès mitigé, je le crains) d’abord d’identifier des cibles et des contextes d’utilisation pour une application smartphone, puis de développer ce concept à l’aide de techniques de brainstorming. Bien sûr en si peu de temps, il ne pouvait s’agir que de jeux de l’esprit. Toutefois un peu plus de temps aurait certainement produit un résultat plus pertinent.
Mais j’ai appris une nouvelle chose, un nouveau territoire à explorer qui fait le lien avec d’autres que je connais. J’ai aussi remarqué et apprécié la synergie très importante entre cette approche et le Lean Startup. D’ailleurs cette technique est fugitivement évoquée dans le livre d’Eric Ries. Ici aussi on parle d’emettre une hypothèse, de confronter celle-ci à la réalité le plus vite possible, d’apprendre sur cette base et d’itérer en s’appuyant sur ce que l’on a appris.
Bravo Dirk !
L’agilité au service du marketing, une révolution en marche
Une mauvaise pioche m’a fait choisir cette session que j’ai trouvé la plus décevante de la journée ! J’étais impatient de voir et comprendre l’agilité projeté dans le domaine du marketing. Hélas la présentation de Laura Guillemin manquait cruellement de substance ! Certes, la bonne idée de cette présentation était d’y faire participer des acteurs métier (mais aussi un consultant). Alors oui, on peut facilmement se douter que les plan marketing à long terme se voient balayés par les itérations rapides et les possibilités qui nous sont offertes de mesurer les impacts dans l’économie numérique ! Mais même un gros bourrin d’informaticien comme moi sait cela depuis longtemps.
Il existe une substance, des concepts dans le marketing numérique dont j’ignore même l’existence. Un question venant de la salle (mais vite balayée) sur les modèles d’attribution en a été l’un des exemples. Bref, je n’ai rien appris !
Keynote de cloture
A la session de Laura Guillemin, j’ai largement préféré la cloture que nous a proposé Scott Brinker ! Difficile de résumer cette intervention vraiment très riche. Je vous recommande la présentation qui est en lien, ce support est vraiment très bon (avec un petit arrêt sur le slide 16). Le(s) message(s) de base de cette présentation est (sont):
- Tout est marketing !
- Tout le monde doit être agile !
Un grand merci à Valtech d’avoir organisé cette journée !
Les détails font la perfection, et la perfection n’est pas un détail.
Léonard de Vinci
