[talk] Sans documentation, la fonctionnalité n’existe pas !

Voici la vidéo, les slides et surtout les liens complémentaires de la conférence que j’ai eu l’honneur d’animer au PHP Tour 2018 à Montpellier. J’avais intitulé ma session Sans documentation, la fonctionnalité n’existe pas ! et le titre avait déjà amené beaucoup de débats avec mes pairs. Je vous laisse donc m’écouter, me lire et, si le sujet vous intéresse, approfondir la question par vous-même.

La vidéo de la session

Les slides de « Sans documentation, la fonctionnalité n’existe pas »

J’ai pris soin de garder les animations, c’est pourquoi vous avez un grand nombre de diapos : quand il y a deux versions, c’est que j’ai gardé les versions avant et après l’animation.

 

Les liens complémentaires

Durant ma présentation, je cite des outils ou je référence le travail d’autres personnes, voici les liens complémentaires.

 

Publicités

Mon interview dans le podcast Echo : gérer et maintenir une documentation

J’ai été interviewée par le podcast Echo, qui compte déjà 4 épisodes, lors du PHPTour à Montpellier, ce qui m’a donné l’opportunité de dire à haute voix ma vision de la documentation au quotidien. Si vous avez 7 minutes devant vous, c’est l’occasion d’écouter ma voix.

 

Qu’ai-je appris dans mes études supérieures qui me sert encore aujourd’hui ?

Qu’avez-vous appris dans vos études supérieures qui vous serve encore aujourd’hui ?demande Eric Daspet.

Je voudrais répondre à cette question précise car, contrairement à beaucoup de mes collègues passés, présents et futurs(?), je suis allée à l’Université. Vous trouverez sur mon profil LinkedIn/Viadeo le détail de mon cursus.

J’ai appris l’usage de Linux, ce qu’est l’opensource, lire des textes de lois (pour lire le code du travail) et les comprendre, faire une synthèse de mes idées, et à l’inverse développer mes idées, présenter à l’oral devant un public pas intéressé, travailler en binôme ou en petit groupe, lire la doc/chercher de l’aide, préparer mon boulot avant de m’y mettre, être fière de mon boulot, et LE truc précieux : faire des sauvegardes de mon travail. Cela me sert encore aujourd’hui dans mon métier.

Woman in Blue Reading a Letter, Johannes Vermeer painting

Johannes Vermeer [Public domain], via Wikimedia Commons

Ah je n’ai pas été en école d’ingé mais à la fac, c’est peut-être le détail. Les élèves en école d’ingénieur que j’ai côtoyé étaient parfois un peu trop choyés pour se rendre compte de la chance qu’ils avaient au niveau des moyens fournis.

Sur les savoirs plus informels, qui me servent encore, mais pas forcément dans mon métier, j’ai appris à m’y retrouver sur un campus universitaire et cela m’a appris à m’orienter (parfait quand tu es formatrice/consultante et que ton lieu de travail n’est pas fixe) et à demander mon chemin pour être à l’heure, boire du café, ne pas préjuger des compétences des gens selon leur apparence (quand le sysadmin de ton université ressemble à un clochard et le prof de réseaux à un poivrot, au hasard), écouter et prendre des notes (utile durant les conférences), mémoriser des tas de trucs grâce à des techniques de mémorisation, apprécier le bon café, partager l’information, et dénicher les bons livres dans les bibliothèques.

Investir et former

Même le stage de fin d’étude n’est qu’une autorisation à être un peu moins productif ou à passer quelques jours à lire des documentations.

Hé bien, là encore, mon stage de fin d’études a été prétexte à une offre d’embauche, et j’ai mis les mains dans le code, si je puis dire, sur une partie annexe et non-commerciale du projet.

FEMA - 19762 - Photograph by Greg Henshall taken on 11-28-2005 in Louisiana

Je comprends néanmoins ce que soulève Eric Daspet comme problème : l’investissement (monétaire, eh oui) sur les savoirs et le fast-savoir.
Les formations sont très bien comme démarreurs, ensuite, il vous faudra digérer tout ce qui a été vu, le refaire. Ce n’est pas après quelques jours sur une technologie ou une méthode que vous serez au point. Pire, il faudra être confrontée à l’échec pour apprendre. (Comment croyez-vous que j’ai appris pour les sauvegardes ?)
Et dans le pire des cas, il est attendu que vous sachiez déjà, ou que vous soyiez prêt à vous former par vous-même, sur votre temps personnel.

C’est un sujet de longue haleine, sur lequel je peine à me faire un avis, la veille techno sur temps de travail et hors temps de travail, donc je ne développerai pas mes idées maintenant.

La Documentation comme une punition

L’autre matin encore, j’ai entendu mes collègues parler de leurs tâches possibles pour les prochaines heures, et l’un dire à l’autre : « Tu peux écrire la documentation de telle Story, si tu veux » et l’autre répondre : « Non, je ne suis pas désespéré à ce point. »

Mes collègues sont formidables et ils me donnent l’occasion de parler de cette tradition de voir la documentation de ses développements comme une punition. Évidemment, ce n’est pas la partie la plus sexy du code de se taper la Documentation. Evidemment, c’est pas l’fun de devoir expliquer ce qu’on a brillamment conçu avec son cerveau super-intelligent pour que d’autres péons puissent comprendre le fonctionnement, sinon l’intention de votre création.

Pillory (PSF)

Cloué au pilori, la punition

Simplement, si vous avez fait vos développements super-cools, qui va savoir les utiliser hormis vous ? Qui va savoir qu’ils existent si vous n’en faites aucune promotion ?

Pour moi, la documentation sert à plusieurs personnes :

  •  Le développeur qui est forcé d’expliquer et remettre à plat l’utilité et le fonctionnement de son oeuvre.
  • Les utilisateurs qui veulent s’en servir, qu’ils soient utilisateurs techniques ou non
  • Les autres collègues, incluant le développeur lui-même dans le futur, qui sont parfois forcés de reprendre le code de quelqu’un d’autre. On disait parfois en riant : « ça a été difficile à écrire, ça doit être difficile à lire », en réalité, c’est une blague, faut pas le faire.
  • La partie marketing qui peut ainsi affirmer que la fonctionnalité existe et qu’il est possible de s’en servir

Quand vous voyez la Documentation comme une punition, en réalisé, vous punissez les personnes que je cite dans ma courte liste. Et quand j’évoque la Documentation, cela ne se limite pas aux pages écrites dans un bon anglais/français, avec des jolis exemples théoriques de code. Cela inclut les bons messages d’erreurs, les informations retournées par l’API, et les commentaires dans le code, ainsi que les diagrammes concernant l’architecture et le pourquoi de ces choix.

Le CommitStrip m’y a refait penser au point que je me suis dit que j’allais écrire un billet sur le sujet : http://www.commitstrip.com/fr/2016/07/27/documentation-just-before-vacation/

Il est temps de réfléchir et mûrir un peu sur ce sujet, ne croyez-vous pas ?

 

Les fausses promesses de GTD

Il y a un bout de temps de cela, j’ai fait partie des quelques personnes parisiennes qui ont lu Getting Things Done en V.O. et l’ont apprécié assez pour en parler sur leur blog, sur des forums, des mailing-listes. C’est amusant de retrouver cet ouvrage comme conseil qu’on me donne régulièrement quand je me plains d’avoir une vie trop remplie et pas gérable.

Note supplémentaire, si vous lisez Getting Things Done, n’oubliez pas de lire le complément Ready for Anything: 52 Productivity Principles for Getting Things Done. Enfin je l’ai lu après plusieurs années de pratique de GTD, et j’en ai pleinement apprécié le contenu.

Des principes géniaux…

Pour moi, les principes de GTD qui sont géniaux sont de vider sa tête des « boucles » qui permet d’éviter de ruminer des choses importantes, ainsi que le seuil des 2 minutes : si la tâche prend moins de 2 minutes, faites la immédiatement, car c’est plus coûteux de la reporter. Les autres propositions moins mises en avant qui sont pourtant cruciales pour réussir à utiliser GTD à tout son potentiel sont la Revue Hebdomadaire et le fait de prendre de la hauteur sur ses buts dans la vie. La Revue Hebdomadaire est cruciale, et donne tout le sens des lieux de collecte de l’information (Inbox). Le fait de prendre de la hauteur est important pour une vision moyen-long terme de ses projets et de sa carrière.

…aux illusions

Le principal reproche que je fais à GTD est de donner l’illusion qu’on peut tout faire. J’ai cru un bon moment que faire des listes suffirait à me donner la possibilité de réaliser mes projets. Et j’ai des projets qui sont restés non-aboutis de liste en liste (1), tandis que d’autres étaient rapidement réalisés. Ces projets étaient voués à l’échec car ils ne m’intéressaient pas vraiment, ou ont rapidement cessé d’être pertinent. Pourtant, une fois inscrits dans ma liste et la Next Action définie, ils y gagnaient une place ad vitam æternam.
Dans son inspiration, GTD ne met pas l’accent sur le fait d’abandonner si cela ne convient finalement pas. Evidemment, chacun garde son libre arbitre et la Revue Hebdomadaire permet de reprendre les projets et de les éliminer. Cependant, j’ai, pour ma part, tenu à garder des projets zombies trop longtemps et je me suis faite mordre.

De plus, il existe les listes « Un Jour, Peut-être » qui conduisent à accumuler, comme dans votre outil de favoris (Wallabag, Pocket, Instapaper, etc.) des potentiels sujets d’intérêts. La liste peut s’allonger à l’infini, sans tri ni revue, c’est une sorte de grenier de vos envies. Pour ma part, j’en ai listé des films à voir, des livres à lire, des choses à faire…avant de comprendre que c’était les envoyer dans /dev/null.
Depuis, j’ai lu un billet intéressant titré : If you want to follow your dreams, you have to say no the all the alternatives que je vous recommande de lire. Finalement, c’est peut-être une façon diférente de remettre à « Un Jour, Peut-être » les propositions parasites de votre but ultime ?

Un autre reproche que je fais à cette méthode, c’est que c’est difficile de rattraper si on abandonne un petit moment. Les options sont donc de reprendre depuis zéro, ce qui peut fonctionner ou de s’y recoller péniblement en essayant de démêler quel était le but du projet en question. J’ai souvent trouvé décourageant de reprendre une ancienne liste (mettons de 12 mois) pour la faire revivre.

C’est également très frustrant, pour moi, de s’investir dans des projets dont l’avancement ne dépend que peu de vous. Relancer sans cesse est une Next Action potable, et pourtant j’ai l’impression de piétiner si les projets n’avancent pas assez vite. La conséquence est que je me limite à des projets unipersonnels, qui ne dépendent de personne.

Avec ces fausses promesses de productivité personnelle à tout prix, j’ai cru que je pouvais glandouiller et que, grâce à GTD, tout serait fait en temps et en heure. Bien entendu, appelez moi naïve, cela ne fonctionne pas. GTD permet de réaliser ses projets sans paniquer, mais il pousse aussi à multiplier les projets sans fin et sans répit.

Un livre fondateur

Getting Things Done est un livre fondateur pour moi, une méthode intéressante à laquelle je reviens régulièrement, et ce dans tous les domaines de la vie. Lisez le livre surtout si vous évoluez dans une façon de travailler agile. Si vous rêvez comme moi de journées avec des heures en plus pour y caser tout ce que vous voudriez faire : méfiez-vous ! Votre euphorie du début pourrait faire place à un échec sur la durée.

(1) J’utilise un calepin papier, donc je recopie dans un nouveau calepin quand l’ancien est plein.

La keynote Mix IT édition 2016 (compte-rendu)

Ce n’était pas la première fois que je participais à Mix IT, et j’espère que ce ne sera pas la dernière. Il s’agit de deux jours de conférence, à Lyon, sur des sujets autour de l’informatique : technique et pratiques, notamment agiles. C’est en général passionnant parce que les sessions sont variées et les orateurs viennent d’horizons très différents.

mixit-banner

J’ai poussé fort pour que dans mon entreprise, on envoie des salariés à cet événement, et ça a été possible.

Ce qui me plaît dans Mix IT est aussi le démarrage de journée, tous les orateurs viennent pitcher leur session en 30 secondes, pour donner envie. Parfois, même moi qui a fait mon programme à l’avance, je change d’idée et je vais voir une session qui ne m’avait pas attirée sur le planning.

Keynote : agilité et pédagogie

Chrisian DEN HARTIGH

La Keynote de démarrage frappe fort. Un enseignant de collège, nous fait un REX sur ses pratiques agiles en classe.

Les bureaux des élèves sont en rond autour de tables supportant la documentation (dictionnaires et ouvrages de référence). Du coup, ils sont tous au premier rang. Difficile de sa planquer dans cette configuration. Pour d’autres phases de travail, les tables sont changées de place, et ce sont des ilôts pour encourager le travail en petit groupe.
Sur les groupes et dynamiques de groupe, il nous explique l’holarchie. Les élèves sont par classe d’âge, sans plus d’affinité que cela.

L’enseignant déplore qu’il a 100 nouveaux élèves chaque année et aucun retour sur ses pratiques. Il ne fait partie de leur vie scolaire qu’une seule année.

Ce qui m’a interpellée :

  • Tous les 15 sujets de rédaction de l’année sont donnés au début de l’année (ex : repas qui se termine mal). Les élèves préparent leur rédaction à la maison, en suivant un modèle (la double molécule) quant au déroulement de leur histoire. En réalité, s’ils n’ont rien préparé, ce n’est pas non plus un handicap. Puis en classe, ils échangent entre eux car les individus et interactions sont plus importants que les outils (hoho, l’avez vous vu le Agile Manifesto ?). Ensuite ils écrivent leur rédaction.
  • Les élèves ont des fiches d’auto-évaluation et choisissent sur quoi ils veulent s’améliorer.
  • Le papier de la colère : feuille identifiée comme « le papier de la colère » à froisser violemment en cas de colère.
  • Le smiley « doigt sur la bouche » à poser devant l’élève trop bruyant (chut).
  • Pour tous les travaux notés, les élèves ont accès à beaucoup de documentation.
  • Certains exercices ont une double réponse : une fois faits par l’élève, une fois fait avec des dés. Par ex, un exercice de grammaire avec les terminaisons -é -er et -és à placer est réalisé en deux colonnes. L’élève remplit avec son savoir, puis en suivant le dé.
  • Le Kanban en classe. Hé oui, la visualisation de ce qui est en-cours et de ce qui reste à faire est très puissante.

La citation

« J’ai deux moyens de communication, digital et numérique. »

En savoir +

https://pedagogieagile.com

Ensuite, je suis restée assise. Bon j’étais un peu soufflée, il faut bien le dire. Et la conférence suivante toujours dans le cadre de la keynote était fort intéressante.

La confiance en soi, ça ne sert à rien

Laure JOUTEAU

Laure Jouteau nous explique qu’en fait, pour changer de voie, ou se lancer dans quelque chose de nouveau, la confiance en soi n’est d’aucune utilité.

Inutile donc de rester paralysé par le conformisme, ou d’essayer de se rassurer en cherchant des bonnes raisons de se lancer.

Ce qui m’a interpellée :

  • Défi : faites LA chose que vous ne faites pas parce que vous n’osez pas, faites le pour vous, par pur égoïsme
  • On essaie toujours de rationnaliser par une idée de génie, un vocation alors qu’il faut une autorisation de se planter
  • La nouveauté est toujours assortie de trouille et c’est ok.

La citation

« On n’est pas la bonne personne pour réaliser ses rêves, on devient cette personne en le faisant. »

En savoir +

La vidéo de la conférence

Le texte du talk « La confiance en soi ça ne sert à rien »

 

Ce que m’a appris le HackDay Symfony

Tout d’abord, on pourrait croire que j’ai hacké comme une petite folle ce jour là, eh non…mes responsabilités parentales ont fortement limité mon champ d’action.
Cependant, voici ce que j’ai appris durant le HackDay Symfony lyonnais du 5 juillet 2014 :

  • demandez le minimum aux gens
  • encouragez les dès le départ
  • soyez attentifs à votre environnement : les gens aiment résoudre des problèmes (poussette dans l’escalier, intitulé des tickets)
  • le temps passé ensemble est précieux (ma fille qui me dérange tout le temps, partager autour d’une pizza)
  • tout le monde peut faire avancer les choses (même un tout petit point peut aider, parler peut donner des idées)

Allez lire le compte-rendu sur le site de l’AFUP.

Le son du Bip de caisse

Monoprix a changé le bip des caisses pour ses produits.

C’est pour le buzz car le son bip est un contrôle pour la caissière qui passe les produits. Il est audible par dessus tout. Le son est très court et permet donc de passer rapidement plusieurs produits à la suite.Cashier's box equipment at Magnit Chain Store
Les sons présentés dans la vidéo, comme la musique pour le thé ou le meuglement de vache sont bien plus longs.
Le travail d’une caissière est peu valorisé et un peu abrutissant, cependant le confort gagné avec l’expérience est anéanti par ce « truc sympa de changer le bruit du bip de contrôle ».