title: Être develop-père

> Travaillant en mode agile, nous intégrons dès la première itération au moins un membre de l’équipe cliente, même s’il n’a qu’une expérience limitée des technologies utilisées. La relation que nous établissons avec lui n’est pas celle d’un fournisseur avec son client ou d’un formateur avec son élève, mais celle d’un contributeur senior avec un contributeur débutant : nous lui confions des tâches simples afin de lui faire découvrir nos techniques et nos bonnes pratiques, nous nous occupons des tâches ingrates et nous démystifions ce qui lui semble compliqué ou effrayant. Au fil des itérations, nous l’incitons à s’améliorer et à prendre en charge des tâches plus complexes.
>
> Au terme du processus, au contraire d’un développeur à qui on dirait: « Tu vas t’occuper de ce logiciel, voici la doc, il y a tout ce qui faut » et qui se sentirait abattu, contraint, et dans une certaine mesure infantilisé et donc dé-responsabilisé, le développeur a le sentiment d’avoir progressé avec ce nouveau projet, et ayant effectivement grandi, il va pouvoir assumer sa responsabilité de nouveau père pour le logiciel.
> 
> <cite>*[Être develop-père](http://makina-corpus.com/blog/metier/2015/etre-develop-pere)* ([cache](/david/cache/1da7a055cf7c4a65f61ebb3050e3150c/))</cite>

J’ai un peu de mal avec la métaphore mais je ne dois pas mettre suffisamment d’affectif [dans mes lignes de code](/david/blog/2013/utilite-code/). C’est une pratique qui demande à être expérimentée cependant. Le curseur d’intégration des différentes parties prenantes est différent pour chaque projet et évolue dans le temps. C’est pourquoi je préfère la métaphore de la recette qui diffère en fonction des personnes, des goûts et des envies du moment.

Les *frameworks* seraient des livres de recettes, les bibliothèques des *fast-foods* et la Californie s’arracherait les chefs étoilés. Le guide Michelin ne saurait tarder…