Note de lecture : Practices of an Agile Developer, par Venkat Subramaniam & Andrew Hunt

Note : 3 ; Le petit frère simplet du « pragmatic programmers »

Tout a-t-il été dit sur le développement agile ? Si l’on est en droit d’en douter, la lecture de ce livre nous laisse penser le contraire. Car, franchement, à la lecture de cet opuscule on ne voit rien de neuf. Donc, je suis déçu, et étonné d’être déçu en ayant constaté qu’Andrew Hunt avait cosigné ce livre ! Au-delà d’une introduction et d’une conclusion destinés à parler de la migration vers l’agilité (mais sans propos utiles, je dois dire), le texte se compose de 7 chapitres :

  • Begining agility : Donne des pistes sur le « par où commencer », et comment se comporter au sein de projets agiles.
  • Feeding agility : Aborde les points sensibles, les « accélérateurs agiles », destinés à faire passer les projets à la vitesse supérieure.
  • Delivering what users want : Aborde le point crucial de la réalisation du projet par rapport à la demande utilisateur ; comment prioriser et comment obtenir du feedback.
  • Agile feedback : Aborde spécifiquement l’aspect retour d’expérience, comment mesurer les progrès et estimer la qualité et la pertinence de ce qui est réalisé.
  • Agile coding : Traite des pratiques liées au codage. Ces pratiques se rapprochent de celles de l’extrême programming.
  • Agile debugging : Ce chapitre se focalise sur la recherche des anomalies, mais aussi sur la façon d’en garder trace et de les capitaliser.
  • Agile collaboration : Donne des indications sur les façons d’interagir au sein d’une équipe de développement, mais aussi hors de cette équipe de développement.

L’ouvrage, bien Que découpé en chapitres est essentiellement constitué d’un ensemble d’items, traités de façon similaires : tout d’abord les auteurs énoncent l’anti-pattern (illustré d’une icône représentant un diable). Il s’en suit une discussion sur le sujet pour expliquer le bien fondé d’opérer différemment. Les auteurs énoncent ensuite une contre-proposition (illustré d’une icône d’ange). L’item se termine par deux paragraphes : le « what it feels like » expose les conséquences du changement opéré, tandis que le « keeping your balance » donne les pours et contres de l’item, en mettant l’accent sur les facteurs défavorisant qui peuvent être rencontrés.

En conclusion, ce court opuscule de 170 pages n’est guère une lecture indispensable. Bien au contraire, on lui préfèrera son grand frère, le « Pragmatic Programmer ».

practices-agile-dev-pragprog

Référence complète : Practices of an Agile Developer – Venkat Subramaniam & Andrew Hunt – Pragmatic Bookshelf 2006 – ISBN : 0-9745140-8-X

Practices of an Agile Developer: Working in the Real World

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

Publicités

Note de lecture : New Programmer’s Survival Manual par Josh Carter

Note : 4 ; Manque de ciblage clair

Sur le papier, le public cible de ce livre est claire : donner au jeune développeur arrivant dans la vie professionnelle une boite à outil pour lui permettre d’acquérir plus rapidement les bonnes habitudes et les bons comportements. C’est pourquoi les 225 pages de cet ouvrage au format inhabituel, plus proche du roman que du livre informatique dont nous avons l’habitude, sont découpés en 33 « tips ». Jusqu’ici tout va bien. En fait, cela ressemble au format emprunté par son ainé, le « pragmatic programmer ». Bonne également, l’idée de découper l’ouvrage en 4 parties :

  • Professionnal programming : 14 tips sur 2 chapitres, couvrant près de 100 pages, donc pas loin de la moitié du livre.
  • People skills : 9 tips sur presque 50 pages et toujours 2 chapitres.
  • Corporate world : Les deux chapitres composant cette partie regroupent 6 « tips » sur presque 50 pages aussi.
  • Looking forward : clos le texte avec 3 tips sur un seul chapitre.

Les conseils toutefois, quand on rentre dedans semblent un peu disparates. C’est sans doute pour cela que l’auteur à attribué 3 niveaux de maturité aux conseils qu’il prodigue : ceinture blanche, ceinture marron et ceinture noire. De mon point de vue c’est l’erreur fondamentale du livre. Au lieu de cibler le débutant l’auteur tente d’adresser différents publics et finalement ne satisfait correctement aucun d’entre-eux. C’est dommage car l’auteur écrit fort correctement et son savoir-faire et la pertinence de ses idées est réelle.

Le livre a voulu cibler trop large en parlant à différents publics, mais aussi en élargissant son débat depuis le craftmanship jusqu’aux aspects sociaux dans l’entreprise. On se trouve ainsi avec du code (Ruby) en début d’ouvrage et des questions sur les cycles de développement produit vers la fin. Ce n’est pas une diversité qui me choque en soi, mais j’ai du mal à y trouver une cohérence dans le propos.

En lisant ce livre, je n’ai pu m’empêcher de le comparer à « SQL antipatterns ». Ce dernier réussit là où celui-ci échoue. En effet ce premier à choisit délibérément de s’adresser au développeur souvent peu expert (et peu intéressé) par les questions ayant trait aux bases de données et à la modélisation de celles-ci. Je pense que ce « new programmer’s survival manual » aurait dû atteindre la qualité du « SQL antipatterns » en ciblant son public et surtout en maintenant sa cible dans son contenu et aurait peu et dû atteindre le même niveau de satisfaction.

C’est donc une déception.

new-prog-survival-manual-pragprog

Référence complète : New Programmer’s Survival Manual, Navigate your workplace, cube farm or startup – Josh Carter – Pragmatic Bookshelf 2011 – ISBN : 978-1-93435-681-4

New Programmer's Survival Manual: Navigate Your Workplace, Cube Farm, or Startup

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

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

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 !

agile-coaching-pragprog

Référence complète : Agile Coaching – Rachel Davies & Liz Sedley – Pragmatic Bookshelf 2009 – ISBN : 978 1 93435 643 2

Agile Coaching


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

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