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.

Publicité

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.

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.

Trouver n’est rien, c’est le plan qui est difficile.

Le titre est une citation de Dostoievski.

En plus du SMS évoqué plus haut, mon téléphone sans options connectées m’a fait prendre conscience que la ville manquait de plans. Quand j’étais jeune, je possédais un livre-plan de Paris fort pratique. Je l’avais dans mon sac à dos en permanence, et je l’utilisais dès que j’avais un RV. Je localisais la station de métro la plus proche, je m’en servais pour m’orienter, bref, une mini-carte-papier pour piéton.

Brockhaus and Efron Encyclopedic Dictionary b44 801-0

Quand je partais quelques jours dans une ville nouvelle, je me procurais souvent le plan papier avec index des rues. Cela me permettait de me situer et de rentrer à pied de n’importe quel endroit.

Même avec un smartphone disponible, je l’estimais tellement fragile et coûteux que je préférais avoir un plan Vélib dans mon panier de vélo plutôt que de risquer sortir mon smartphone en pleine rue.

L’autre soir, j’ai eu à me rendre en terre inconnue lyonnaise. J’avais vaguement repéré les lieux alentours mais, trop confiante, je marchais en vain dans la mauvaise direction, sans croiser les rues espérées. Pour remettre la main sur un plan, j’ai cherché un arrêt de bus. Et pour savoir où était la rue, j’ai dû demander.

Le manque de plans a réduit l’autonomie piétonne. Qui sait, un jour, vous serez peut-être en rade de batterie, vous aussi…
Vatican City Map 1929

Le SMS est plus puissant que Twitter ?

Ma batterie de smartphone étant en explosion lente, j’ai dû revenir à un téléphone moins connecté. J’ai la 3G, et point de WiFi. Et cette interface est si lente (si je vous dis que c’est un OS en Java, ça vous évoque quoi ?) que je télécharge parfois les en-têtes de mes mails en IMAP mais c’est plutôt rare que j’aille lire l’e-mail en entier sur le téléphone. Je me contente du titre.

L’autre soir, à l’arrêt de bus, délestée d’un compagnon tel que peut l’être Twitter, manquant de lumière pour lire un vrai livre (ma liseuse est si vieille qu’elle n’a pas d’éclairage intégrée), j’ai envoyé quelques SMS à des copains géographiquement loin, mais dont j’ai été très proche durant des années. Non seulement ils m’ont répondu, mais la conversation a duré quelques SMS et j’ai eu le sentiment d’être connectée à eux.

Teen girl texting close-up

Au final, je commence à entrevoir les limites des liens sociaux virtuels. Je parle de la différence entre les gens que je fréquente en ligne tous les jours, parfois je les rencontre en chair et en os, mais pas toujours. J’ai des amis jamais rencontrés dans le monde physique et cela ne me semble pas fou.

Les amis que j’ai contactés ne sont pas des vieilles croûtes ou des personnes qui rechignent devant la technologie. Je pense qu’elles n’ont pas les mêmes priorités que moi. Ces personnes vont sur Facebook une fois par mois, sans forcément poster de contenu, elles se contentent de lire. Produire et écrire un SMS n’est pas écrire des billets de blog pouvant être lu par le monde entier. On reste dans l’intime.

#nppt Pour avoir plusieurs profils Firefox

Quand on fait du dév, qu’on ne peut pas upgrader Firefox (je travaille avec Firefox 16, plaignez moi,c’est bon maintenant, ça va mieux) et qu’on a besoin de tester, le mieux, c’est de faire des profils différents. Chaque profil bénéficie de ses extensions, c’est fort pratique. Et parfois un peu pénible : par exemple, quand on a bien installé une extension mais qu’on cherche à l’avoir sur un autre profil, et qu’on ne se souvient plus du nom de l’extension, on veut changer de profil.

Mais comment retrouver ses profils ?

– Who you gonna call ?
– ProfileSwitcher :: Modules pour Firefox.

Installation de ReadtheDocs en local (Ubuntu)

Je suis les instructions sur ma Ubuntu fraîchement installée : https://read-the-docs.readthedocs.org/en/latest/install.html

Premièrement j’installe python. Avec apt-get install, tout simplement. Je fais confiance à mon OS.
Comme l’installation bloque, je finis par installer un paquet de versions de Python mais les paquets se débrouillent pour me faire un :
python 2.7 et un python3

sudo apt-get install python-virtualenv virtualenvwrapper
sudo apt-get install python3-pippython

Quand j’arrive à la partie d’installation avec pip, premièrement c’est Mercurial qui me claque à la figure. Alors, je lance la commande avec pip3 au lieu de pip tout court.

cd readthedocs.org
pip3 install -r pip_requirements.txt

Erreur

Downloading/unpacking virtualenv==1.11.1 (from -r pip_requirements.txt (line 2))
Real name of requirement virtualenv is virtualenv
Error while getting https://pypi.python.org/packages/source/v/virtualenv/virtualenv-1.11.1.tar.gz#md5=7875c2d8c2075571abe5e727449af4d8 (from https://pypi.python.org/simple/virtualenv/)
Exception:
Traceback (most recent call last):
File "/usr/lib/python3.3/urllib/request.py", line 1252, in do_open
h.request(req.get_method(), req.selector, req.data, headers)
File "/usr/lib/python3.3/http/client.py", line 1061, in request
self._send_request(method, url, body, headers)
File "/usr/lib/python3.3/http/client.py", line 1099, in _send_request
self.endheaders(body)
File "/usr/lib/python3.3/http/client.py", line 1057, in endheaders
self._send_output(message_body)
File "/usr/lib/python3.3/http/client.py", line 902, in _send_output
self.send(msg)
File "/usr/lib/python3.3/http/client.py", line 840, in send
self.connect()
File "/usr/lib/python3/dist-packages/pip/download.py", line 90, in connect
sock = socket.create_connection((self.host, self.port), **self.connection_kwargs)
File "/usr/lib/python3.3/socket.py", line 417, in create_connection
for res in getaddrinfo(host, port, 0, SOCK_STREAM):
FileNotFoundError: [Errno 2] No such file or directory

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/pip/basecommand.py", line 139, in main
status = self.run(options, args)
File "/usr/lib/python3/dist-packages/pip/commands/install.py", line 266, in run
requirement_set.prepare_files(finder, force_root_egg_info=self.bundle, bundle=self.bundle)
File "/usr/lib/python3/dist-packages/pip/req.py", line 1033, in prepare_files
self.unpack_url(url, location, self.is_download)
File "/usr/lib/python3/dist-packages/pip/req.py", line 1161, in unpack_url
retval = unpack_http_url(link, location, self.download_cache, self.download_dir)
File "/usr/lib/python3/dist-packages/pip/download.py", line 534, in unpack_http_url
resp = _get_response_from_url(target_url, link)
File "/usr/lib/python3/dist-packages/pip/download.py", line 569, in _get_response_from_url
resp = urlopen(target_url)
File "/usr/lib/python3/dist-packages/pip/download.py", line 143, in __call__
response = self.get_opener(scheme=scheme).open(url)
File "/usr/lib/python3.3/urllib/request.py", line 473, in open
response = self._open(req, data)
File "/usr/lib/python3.3/urllib/request.py", line 491, in _open
'_open', req)
File "/usr/lib/python3.3/urllib/request.py", line 451, in _call_chain
result = func(*args)
File "/usr/lib/python3/dist-packages/pip/download.py", line 123, in https_open
return self.do_open(self.specialized_conn_class, req)
File "/usr/lib/python3.3/urllib/request.py", line 1255, in do_open
raise URLError(err)
urllib.error.URLError:

Version de virtualenv
Je mets donc à jour virtualenv

sudo apt-get upgrade python-virtualenv

Cela ne fait rien de plus 😦
Alors je cherche sur Internet et je finis par trouver un moyen de mettre à jour virtualenv pour python 2.7

python2.7 -m easy_install virtualenv

La suite…j’ai répété la procédure d’installation et tout s’est bien passé. C’est presque décevant !

Kanban, premier problème rencontré

Depuis maintenant 1 mois, mon équipe de maintenance est passée à Kanban dont j’ai écrit une présentation sur le blog tech. Nous rencontrons un problème de modélisation des colonnes et du flux.

Quand une validation fonctionnelle a échoué, faut-il revenir en arrière, à la manière d’une boucle ou avoir des colonnes qui ne serviront que dans le cas d’une non-validation ?

Voici nos colonnes :

 

Colonnes de mon Kanban (les [x] représentent des étiquettes)
  TODO   Dév. en cours Valid métier Dév. Fini
max 10 max 4 max 6 max 4  
  Réalisation Valid Tech Prêt pour valid Validé Ready for merge Mergé (todo backport) Fini
  [x] [x] [x] [x][x] [x] là => [X] [x] [x] [x] [x] [x] [x][x] [x][x] [x][x] [x][x] [x][x] [x][x] [x]

Quand l’étiquette est en « Prêt pour valid », et que le ticket n’est pas validé, où le mettre ?

Jeunesse rêve, vieillesse décompte.

Avant mes collègues n’avaient pas le même profil que moi, plus jeunes, sans enfants. Ils parlaient de trucs marrants : Lego, voitures, cinéma, derniers gadgets technologiques à la mode, de cookies. Peut-être que je trouvais cela marrant parce que c’était d’autres domaines, sur lesquelles je ne connaissais pas grand chose ? Peut-être que j’appréciais de devoir m’intéresser à des nouvelles choses et apprendre d’eux ?

Après des mouvements dans les collègues, j’ai désormais des collègues qui me ressemblent plus, ils ont de jeunes enfants, par exemple. Et bien leur conversation me touche moins, ils parlent de crédit d’impôt pour l’assistante maternelle, d’achat de maison, de taux du Livret A, de mariage. Peut-être que je ne veux pas me sentir assimilée à eux ? Peut-être que je n’assume pas mon rôle d’adulte ?

Peter Pan 802

Alors CMA ou Syndrôme de Peter Pan ?

CMA = C’était Mieux Avant

Le syndrome de Peter Pan (parfois nommé complexe de Peter Pan ou puer aeternus et abrégée SPP) est une expression utilisée pour désigner l’angoisse liée à l’idée de devenir adulte et le désir associé de rester enfant et plus généralement pour caractériser un adulte immature, en référence au personnage éponyme du garçon qui ne voulait pas grandir créé par J. M. Barrie.

Sur l’argent roi dans la politique américaine, et un super site web animé

Faisant des recherches pour implémenter du scroll avec AngularJS, je tombe sur ce magnifique site Money wins Elections. : on scrolle pour connaître la suite, et les diagrammes animés complètent le débat. C’est Tony Chu dans le cadre d’un projet scolaire pour son école d’arts qui a réalisé ce site.

Repost : Ma première fois

déjà publié sur Travailleurs du web

De nombreuses personnes m’ont déjà entendu dire que je continuerais à faire de l’informatique jusqu’à ce que je vois un projet sortir en temps et en heure. C’est une blague récurrente, qui reflète, malheureusement le manque de soin apporté à l’évaluation des risques, des ressources et des spécifications dans les projets de développement web.

Pour faire écho à l’article de Damien Mathieu, j’ai déjà rencontré de très bons chefs de projet. Mon expérience de consultante-formatrice m’a amenée dans des entreprises privées aussi bien que dans des établissements publics, au contact d’équipe variées. J’ai toujours constaté une certaine fatalité envers le retard dans les projets web.

Et pour la première fois, lors d’une mission, nous livrons des features au rythme prévu. Parfois, cette date a été ré-ajustée au fil du développement, parfois la feature B devance en produit livrable la feature A et se retrouve livrée plus tôt. Tout va bien, me direz vous, alors plutôt que de pointer encore et encore les erreurs des projets, les erreurs des développeurs, je vous propose d’examiner les conditions de cette réussite.

Maîtrise des développements

Pour une fois, ma mission de développement se déroule chez un éditeur de logiciels, et pas dans une SSII ou web agency. Les contraintes sont différentes : ajouter des nouveautés permet de continuer à faire évoluer le site web. Et maintenir l’existant permet de gagner la confiance des utilisateurs. Le besoin de qualité est important pour un code pérenne et maintenable, cette qualité est plus importante que le besoin de livrer rapidement. Les dates limites existent néanmoins et permettent de border les tâches, et de découper les features en tâches.

Direction du projet

Les projet ont deux têtes pensantes : un lead développeur, une chef de projet (commune aux projets). Et en plus,  un directeur technique est disponible, pour les points plus critiques ou les choix techniques d’évolution du projet (modification du système de traduction, par exemple). Les technologies les plus performantes sont envisagées pour remplacer les technologies classiques. Cela donne du dynamisme au projet, et attire des développeurs de qualité dans l’entreprise.
Malgré un recrutement soutenu, les développeurs sont bien intégrés aux équipes par des formations aux outils, et comme habituellement, des tâches autonomes et indépendantes des autres du projet à réaliser. Le temps de midi est également mis à profit pour la convivialité.

Des horaires souples

Pour mes besoins personnels, je préfère arriver tôt et repartir tôt. D’autres collègues préfèrent arriver plus tard (après 10h) et j’imagine qu’ils partent plus tard. La pause déjeuner n’est pas non plus chronométrée. Nous sommes managés à la tâche plutôt qu’au créneau horaire, et responsabilisés sur notre tâche. Les dates de planning nous ont permis de déterminer un rythme à tenir pour la sortie de notre feature.

Rencontres fréquentes

Malgré l’open space, dont on sait qu’il est moins bon pour la productivité que les bureaux individuels, les développeurs s’isolent pour se concentrer. Les rencontres sont donc provoquées par un stand-up quotidien, qui a lieu après la pause déjeuner. Parfois, les développeurs d’un même projet — qu’on croirait connectés — se retrouvent à échanger, parfois c’est une simple énumération de ce sur quoi chacun travaille.
Même si nous travaillons sur des logiciels différents, nous avons des fonctionnalités communes, pour résoudre les mêmes problèmes, nous communiquons entre les projets. Les solutions éprouvées sont alors dépistées, ainsi que les impasses.

Challenge technique

En plus d’utiliser des technologies de pointe, toutes les deux semaines, une journée consacrée à la technique est organisée, les développeurs comme l’infra se retrouvent à mettre en place des nouveautés techniques dans l’application, à faire des tests sur les futurs produits techniques, à réparer de petits agacements dans le code ou la configuration qui ralentissent tout le monde.
Cette journée de technique pure, sans but de plaire aux commanditaires (ou actionnaires) des logiciels est toujours un jour agréable. Nous passons en production des nouveautés qui ont été testées précédemment, ou des ajustements qui augmentent le confort de développement.

Convivialité

La pause repas ayant déjà été évoquée, j’ajouterais les outils d’Instant Messaging, la mise à disposition de consoles de jeux (et canapés), le café à volonté, ainsi que la présence d’un outil de « Perles » qui recueille les propos les plus amusants, sortis de leur contexte, évidemment. Ces différents outils renforcent les liens inter-personnels et la confiance entre les développeurs.

Pour terminer, les développeurs sont considérés comme essentiels à la production de valeur dans l’entreprise. Le fait qu’ils soient nombreux les rend majoritaires par rapports aux autres services (marketing, RH ou comptabilité). La direction des projets fournit le matériel nécessaire au confort de chaque développeur (écrans, lampes, etc.) et les responsabilise sur leur code et le code de leur projet.
Sans utiliser de l’eXtrême Programming ou du Scrum, quelques pratiques issues des méthodes agiles améliorent le confort des développeurs et la qualité des produits.

[traduction] 16 moyens de torturer vos développeurs

billet originel : 16 ways to torture developers par Andrew Oliver, le 4 mars 2013

Je dédicace cette traduction à Alexandre Rodière et à Eric Lemoine qui ont été inspirants dans ma carrière.Si vous reconnaissez certains points comme faisant partie de votre travail, je vous invite à calculer le score de votre entreprise 🙂

By Kristaps B. from Tukums, Latvia (Summer’s boredom) [CC-BY-2.0 (http://creativecommons.org/licenses/by/2.0)%5D, via Wikimedia Commons

Lire la suite

Un tour à Mix-IT – jour 1

J’attendais cette conférence depuis un petit moment, ayant raté l’édition de l’année dernière. Cette année, on y a été entre collègues, puisque la moitié de mon équipe (4 personnes) étaient présentes. C’est toujours intéressant d’y aller entre collègues pour partager nos impressions et réflexions à l’issue des conférences.

Particulièrement fatiguée mais tout de même très motivée, j’ai été ravie de découvrir que des petits calepins nous attendaient à l’entrée de Supinfo, ainsi qu’un petit déjeuner avec des viennoiseries, du jus de fruits et du café.
Le Mix IT étant co-organisé par le JUG, je m’attendais donc à du café en quantité.
J’ai live-twitté toutes les conférences auxquelles j’ai assisté, vous retrouverez cela sous mon compte : @sarahhaim

logo de Mix IT

Comme Guillaume EHRET, j’ai voulu manger du ROTI alors j’ai essayé de noter chacune des conférences en faisant un ROTI (Return Of Time Investment) et en reprenant sa grille :

(1) Inutile je n’ai rien gagné rien appris. J’ai vraiment perdu mon temps
(2) Utile mais ça ne valait pas à 100 % le temps que j’y ai passé. J’ai donc perdu du temps
(3) Juste moyen je n’ai pas perdu mon temps sans plus
(4) Bonne au dessus de la moyenne j’ai gagné plus de temps que j’en ai perdu
(5) Excellent ça valait plus que le temps qu’on y a passé

Jouez, apprenez

Après un rapide tour des locaux, c’était déjà l’heure de la Keynote « Jouez apprenez » dans laquelle Christian Martinez nous a rappelé que les animaux utilisent le jeu pour apprendre (transmission des adultes aux enfants, par exemple, les fauves « jouent à se battre »). Christian Martinez a proposé à ses formateurs d’utiliser des jeux de sociétés durant les formations. Les jeux permettent de simuler, d’expérimenter tout en cadrant la prise de risque, puisque le jeu a une fin et fait la plupart du temps appel à un système de personnage (mon personnage en jeu n’est pas moi-même). L’aspect simulation est très intéressant pour recréer des situations rapidement (apprendre la négociation et échanger des ressources) ou sans risques (gérer une entreprise dans un jeu ne me met pas en danger)
Cette intervention m’a beaucoup plu pour des raisons combinées :
– avant j’exerçais le métier de formatrice
– je suis joueuse
– je m’intéresse à toute forme de pédagogie et de transmission du savoir
ROTI : 4

Ensuite les différents conférenciers de la journée nous ont fait une intervention « publicitaire » pour nous attirer à leur conférence. Cela permettait, en plus de nous éclaircir sur leurs intentions, de repérer les intervenants conférenciers directement.

Usinette et Fablab

La matinée ne m’offrait pas de conférence qui me semblait indispensable, alors je suis allée faire un tour du côté du stand Usinette et Fablab. C’était également très intéressant puisque j’ai pu poser des questions sur la RepRap tranquillement pendant qu’ils l’installaient et la mettaient en route. J’ai également à cette occasion rencontré Claude XXX avec qui nous avons pu troller un peu Java/PHP mais surtout nous avons eu des échanges intéressants concernant la gestion de gros et long projets, sur l’architecture en Java, et sur Devops4Kids (on ne se refait pas…) dont une instance devrait voir le jour à Lyon dans le cadre d’une tournée d’un événement.
J’ai également eu le plaisir de rencontrer le président de l’asso Fabrique d’Objets Libres, le FabLab lyonnais, qui m’a confirmé que les travaux du local avançaient bien.
ROTI : 4

Ensuite, j’ai visité le stand d’Objet Direct qui proposait un concours de montage de Lego. Puis j’ai repéré Tasha Carl et Blandine Bourgeois qui préparaient leur intervention publicitaire du lendemain. Ces deux femmes sont développeuses Java de métier et font partie du Developper Program du robot Nao. Il s’agit d’un robot humanoïde d’un mètre de hauteur environ, créé en France par Aldebaran Robotics, et je vous reparlerais de l’intervention de Tasha Carl et Blandine Bourgeois qui a été le dernier atelier du dernier jour dans le prochain billet.

Sandwichs bio et M&M’s

L’heure de manger est arrivée et j’ai apprécié les sandwichs, muffins et fruits offerts par MixIT. Je rappelle que l’entrée de l’événement est 30 euros par jour, alors je trouve ça vraiment super qu’un repas par personne et des collations soient prévues dans ce tarif là.
Après un revigorant pique-nique en compagnie de mes studieux collègues qui étaient allés voir des conférences, eux, l’après-midi a repris avec les Lightnings Talks. Là encore, je salue l’initiative de proposer un cadre d’intervention pour des messages courts et percutants à ceux qui veulent faire passer un message mais n’ont pas de conférence dans leurs cartons.

Deux ans dans le flux

Juste après, j’ai été à ma première conférence de MixIT, pour écouter Olivier Azeau nous faire un REX (retour d’expérience) intitulé « Deux ans dans le flux ». Il s’agissait de nous présenter la solution trouvée par son (ses) équipes de dév pour livrer en temps et en heure leur logiciel. Le cadre de ce logiciel est un développement chez un éditeur, dans le monde de la Santé. Le problème qu’ils ont rencontré a été : « on ne peut pas livrer dans les temps, car notre développement n’est pas terminé. »
Les solutions qu’ils ont trouvées ont été multiples : branche unique, probabilités statistiques sur le planning, par exemple (je pense faire un compte-rendu de cette conférence en particulier).
ROTI : 4

The hitchhikers guide to UXing without a UXer

Cette conférence a été suivie d’une intervention de la dynamique Chrissy Welsh. Le créneau était propice à la torpeur d’une sieste mais Chrissy Welsh a su me captiver durant « The hitchhikers guide to UXing without a UXer » où elle a présenté toutes les choses que vous pouvez faire si vous n’avez pas de professionnel de l’interaction utilisateur sous la main. J’y ai revu les concepts de Personas, de tests à partir de maquettes papier, et même si je n’ai rien découvert, le contenu était agrémenté de blagues et références à Douglas Adams, et Chrissy Welsh a tellement d’énergie qu’elle m’a subjuguée.
Après une courte pause, j’ai suivi mes collègues dans la session de Camille Roux sur « Testez vos idées en quelques heures ! ». Cette session présentait le Lean Canvas à travers l’expérience de Camille Roux sur le projet Human Coders. Cela m’a permis de découvrir cette grille d’analyse qui peut servir à établir un Business Plan prélimaire. Camille Leroux a rappelé l’importance de réfléchir avant d’agir et a donné des tonnes d’idées pour évaluer une idée de projet : en parler autour de soi, sonder les utilisateurs finaux, passer des coups de fil aux concurrents, par exemple.
ROTI : 5

Scrum Metal Jacket

Et pour le dernier créneau de la journée, j’ai commencé par aller à l’intervention de Eric D. et David Larlet sur l’API. En live-twittant la conférence, je me suis retrouvée à voir une photo de la conférence d’à côté, avec laquelle j’avais hésité, et qui finalement répondait plus à mes questions que celle sur l’API. J’ai donc rejoint « Scrum Metal Jacket » pour bénéficier de la fin du REX de la mise en place de Scrum à la Société Générale.
L’équipe se connaissait un peu avant le projet, ils étaient tous prestataires. Ils ont eu la possibilité de travailler en méthodo agile, et ont voulu faire du Scrum « by the book’. Cela n’a pas fonctionné, car toute la société n’était pas impliqué de manière « Scrum » dans le projet. Ils ont donc adapté Scrum à leur environnement. Cela signifie, par exemple, qu’ils ont fait exclusivement du Pair-programming.
ROTI : 4

La soirée s’est ensuivie au Blogg, où j’ai pu retrouver avec plaisir d’anciens collègues pour papoter et avec moins de plaisir attendre mon burger-frites au son d’une musique expérimentale. Le blocage au niveau du service burger-frites aurait pu être une bonne démonstration de l’intérêt de Kanban mais les coachs agiles avaient déjà éclusé trop de bière pour imposer leur savoir.

— retrouvez d’autres compte-rendus et les slides des conférenciers sur le site MixIT