Tag :Agilité

Rencontre avec Cécilia Bossard, développeuse et fan d’agilité!

Poursuivons notre série d’interviews de femmes speakeuses et allons aujourd’hui à la rencontre de Cecilia Bossard, développeuse et fan d’agilité! Encore une fille plein d’énergie et pluri-activiste!

Cecilia Bossard

Agnès : Peux-tu te présenter, ton métier, ton parcours? As-tu des activités geeks extra-pro ?

Cécilia : Je m’appelle Cécilia, et je suis développeuse / scrum master et un peu coach agile.
J’ai réellement commencé l’informatique avec l’option informatique au lycée à la grande époque des sites web perso (années 2000). Du coup, en terminale, je me suis dit « pourquoi pas ? » et je me suis lancée dans un DUT informatique. J’ai préféré commencer par un parcours court au cas où je n’accrocherais pas. Finalement, à la fin du DUT, j’ai continué en école d’ingénieur (Polytech’Nantes) dont je suis sortie en 2005.

J’ai des activités extra-pro assez geek. Vivant avec un informaticien, notre maison est fatalement envahie de PCs, Raspberry, Nabaztag, Myo et autre gadgets 🙂 Et nos filles sont déjà des fans inconditionnelles de Nao ^^

En dehors de mon travail, j’aime bien bidouiller sur mon PC, même si le temps imparti à ces activités est assez réduit. J’aime également faire de la couture et j’ai réussi à combiner mes deux passes-temps avec les wearables electronics. Je ne fais rien de très concret, mais j’expérimente pour peut-être un jour fabriquer des super costumes à nos filles avec des LEDs qui clignotent dans tous les sens !

Je suis également membre fondatrice des Women In Technology à Nantes (groupe de femmes et d’hommes dans la technique dont le but et de montrer qu’on peut être une femme et s’épanouir dans ces métiers et les faire découvrir aux plus jeunes. En gros, ça regroupe les missions des Duchesses et des Devoxx4Kids en une seule structure sur Nantes).

Je suis également pas mal impliquée dans la communauté agile sur Nantes en participant à l’organisation de l’Agile Tour et en essayant autant que faire se peut de participer aux activités d’Agile Nantes.

Agnès : C’est quoi dans « ta vie » qui t’a donné le goût de ton métier?

Cécilia : J’ai commencé très tôt à m’intéresser aux ordinateurs. Mon père était instituteur et avait dans sa classe des EXL 100. Avec mes sœurs, nous avons passé de nombreuses soirées parents/enseignants à attendre en jouant sur ces ordinateurs. Nous savions taper les lignes de commandes pour lancer les jeux avant même de savoir lire !

Mes parents étaient un peu geeks dans l’âme et nous avons eu très tôt un ordinateur à la maison. J’ai tout de suite voulu comprendre comment il fonctionnait et voir ce qu’on pouvait faire avec (le site web de l’école de mon père en a été un triste cobaye).

Je pense que cette éducation m’a particulièrement aidée à prendre goût à la technique et m’a donné envie de continuer dans cette voie. En tout cas, je remercie énormément mes parents de ne pas m’avoir bridée dans cette envie de comprendre et de mettre les « mains dans le cambouis ».

Agnès : Quels sont les derniers talks que tu as donné? Les prochains?

Cécilia : Le dernier talk que j’ai donné n’avait absolument rien de technique et traitait de la diversité en entreprise (hommes, femmes, jeunes, vieux, petits, grands, …) pour le DevFest à Nantes. Nous l’avons élaboré avec les WIT. J’avais précédemment présenté des lightning talks à propos des femmes dans les équipes de dev. Je pense que nous allons continuer de travailler sur notre talk sur la diversité pour le présenter ailleurs.

Je proposerai également à l’Agile Tour nantais un Pecha-Kucha (dont le sujet reste une surprise, mais traitera… de l’agilité 😉 ).

J’aimerais proposer à l’avenir un sujet technique, mais il faut que je bosse plus sérieusement sur le sujet.

Agnès : C’est dur pour toi de faire des talks ou, au contraire, tu trouves ça fun? Quels sont tes trucs pour te préparer?

Cécilia : Je n’ai pas ressenti de crainte particulière à l’idée de faire des talks. Il faut dire que je vise des publics restreints, donc ce n’est pas plus intimidant que de donner une formation.

J’ai fait mes premiers talks en binôme, sur des sujets que je maîtrisais bien et à destination d’un public débutant (initiation à l’agilité). Ça m’a permis d’évacuer une grande partie du stress : on sait que l’autre personne sera là si on oublie de dire des choses et on sait qu’on ne risque pas de dire de trop grosses bêtises car le sujet est bien maitrisé.

En commençant par des événements locaux ou des meetup, ça permet de se lancer devant un public réduit et qu’on connait en grande partie (surtout en province où les user groups se transforment en retrouvailles entre anciens collègues ou camarades de promo).

En fait, je trouve ça plutôt fun de « monter sur scène ». Je trouve surtout super intéressant d’avoir les retours des participants et de discuter avec eux du sujet après la session.

Agnès : Tu t’impliques dans les Coding Gouters de Nantes. Peux-tu expliquer en quoi cela consiste? Et qu’est-ce qui te pousse à t’investir sur ce type d’activité bénévole?

Cécilia : Les coding goûters, tels qu’on les fait à Nantes, sont des après-midi où parents et enfants vont venir « jouer à programmer » avec des logiciels comme Scratch, Scratch Jr pour les plus petits, Code combat,… On y croise aussi de temps en temps des Makey Makey ou des Lego Mindstorms apportés par des participants.

Contrairement aux Devoxx4Kids où les parents ne sont pas présents, là ils sont totalement impliqués. Le principe est vraiment que les adultes et les enfants apprennent et progressent ensemble. Ce sont parfois les adultes qui emmènent leurs enfants (ce sont souvent dans ce cas des informaticiens qui veulent faire découvrir leur métier à leurs enfants), mais nous avons également des enfants ayant participé à un Devoxx4Kids qui ont souhaités faire découvrir tout ça à leurs parents.

Ce sont des moments vraiment chouettes et conviviaux où tout le monde apprend ensemble, où on s’entraide, on s’amuse et bien sûr, on mange tous ensemble des gâteaux ! Ce qui est chouette également, c’est que nous avons des enfants de tous âges qui sont présents (bien sûr, les plus petits n’arrivent pas à rester derrière un écran ou une tablette toute l’après-midi, mais ils font des coloriages / découpages qui égayent la session et ils s’émerveillent des créations des plus grands).

Avec mon conjoint, nous avons eu l’envie de lancer ces événements récurrents après avoir participé à plusieurs Devoxx4Kids sur Nantes où nous ressentions une certaine frustration des enfants de ne pas pouvoir terminer ce qu’ils avaient commencé, et également une frustration des parents de ne pas comprendre ce qu’avaient fait leurs enfants et pourquoi ils étaient si enthousiastes après avoir passé 2 heures derrière un PC. Le but de ces ateliers est vraiment à mon sens de les rendre acteurs des technologies et non consommateurs.

Pour moi, m’impliquer dans ce type d’atelier permet de transmettre ma passion, de montrer qu’être informaticien, ce n’est pas être enfermé dans une cave toute la journée (et toute la nuit) et de montrer qu’on peut s’amuser en créant des choses, même virtuelles. Quoi de mieux que de jouer avec ses copains sur un jeu vidéo qu’on a créé soi-même ?

Agnès : Est-ce que tu vas régulièrement à des confs techniques? Qu’est-ce que tu aimes particulièrement dans ce type d’évènements? Quelles sont tes chouchoutes?

J’essaie d’aller autant que possible à des confs techniques, mais le planning n’est pas toujours facile à gérer avec les enfants (surtout quand on est deux à vouloir assister aux confs). Du coup, c’est par alternance que j’y vais, une sorte de garde alternée technique 😉

Ce que j’aime dans ces événements, c’est déjà de pouvoir faire en une journée (ou plusieurs) une grande partie de la veille que je n’ai pas eu le temps de faire, apprendre de nouvelles choses et me mettre en dehors de ma zone de confort.

J’apprécie également de pouvoir discuter avec les autres participants de sujets particuliers sur lesquels je n’ai pas l’occasion de parler avec mes collègues tous les jours, de découvrir leurs pratiques, etc… Et ce sont aussi des moments où on retrouve d’anciens camarades ou collègues, ce qui est toujours sympa 🙂

Je privilégie les confs plutôt locales (Agile Tour Nantes et Rennes, BreizhCamp, DevFest, JUG Summer Camp, …), en grande partie pour des raisons logistiques. Mais je n’ai pas trop à me plaindre, elles sont de qualité dans l’ouest !

Agnès : Quels sont à tes yeux les trucs qui peuvent marcher pour « accrocher » les filles aux métiers techniques de l’informatique ?

Cécilia : C’est assez difficile à dire… Il y a beaucoup d’initiatives en ce moment qui vont dans le bon sens (et les Devoxx4Kids en sont une très bonne à mon avis). Et pour les plus grand(e)s, ce que font les RailsGirls est vraiment top ! D’ailleurs, j’en profite pour lancer un appel à volontaires pour lancer une telle initiative dans l’ouest !

Je pense qu’il y a un travail de fond à faire dans notre société pour que les gens arrêtent d’assimiler technique à garçon et que les petites filles se sentent entièrement à leur place derrière un PC, un fer à souder ou une imprimante 3D. Pour ma part, j’ai appris à faire abstraction des remarques machistes, mais je sais qu’elles finissent par en dégoûter certaines et je trouve ça très dommage (c’est vrai que s’entendre dire 500 fois au travail qu’étant donné qu’on est une fille, on va pouvoir faire des gâteaux pour toute l’équipe pour fêter tel ou tel événement, ça devient lassant…)

Montrer que l’informatique est un métier de création, où les relations sociales sont primordiales peut changer les choses. En gros, il faut casser les clichés des geeks 🙂

Merci Cécilia !

N’hésitez pas à la suivre sur twitter.

Cet interview a été préparé par Agnès CREPET

Hands-On Agilité

On fait quoi ce soir ?

Première partie – Découverte de l’agilité avec Luc Bizeul

Luc Bizeul

Gonfler des ballons ? Faire des châteaux de cartes ? Autant de challenges à réaliser en compétition avec d’autres équipes pour voir celles qui seront les plus à même de travailler ensemble, de tirer parti des principes agiles pour tenir leurs estimations, donner du feed back et délivrer le plus de valeur pour leur client afin d’être l’équipe gagnante de la soirée !
 
Derrière ces activités, banales en apparences, nous verrons les principaux écueils que peut rencontrer une équipe et les solutions qu’apportent l’agilité. Cette soirée vous permettra de vivre au rythme des itérations dans la peau d’une équipe et d’un client, d’expérimenter, de s’ajuster ensemble pour une meilleure coopération.
 
Reporting, estimations, indicateurs, amélioration continue, relation avec le client, comment définir le travail à faire, les critères de satisfaction associés et comment fiabiliser les engagements sont une partie du programme de ce soir, mais pas que… Préparez vous à être surpris !
 
Comment ça va se passer ? 
 
Nous vous proposons de commencer par une courte introduction de 20 minutes (oui il faut arriver à l’heure :)) sur les aspects théoriques et pratiques de l’agilité, pour embrayer sur un Xp Game (attention, exclusivité ! Il s’agit de la V5, la dernière version, tout juste traduite en Français), qui vous fera vivre 3 itérations dans un projet pendant lesquelles vous vivrez tour à tour chacun des rôles (client et développeur).
 
Pour finir – Learning exchange 
 
Vos expériences, les échanges, retours, questions permettrons d’explorer dans la bonne humeur les thèmes que vous souhaitez lors d’un moment d’échange participatif qui clôturera la soirée.
 
C’est pour qui ? 
 
Cet atelier s’adresse à tous, venez avec votre enthousiasme et envie de partager 🙂
 
Luc Bizeul est coach agile et coach professionnel. Il aide des organisations à devenir plus agiles en travaillant à la fois sur des dynamiques de groupes, processus et design d’organisation. Il contribue activement à l’écosystème agile, en qualité de conférencier depuis 6 ans et plus récemment en co-créant Agile Tour Sophia Antipolis. Il aime aussi explorer ce qui se fait dans d’autres communautés (coaching professionnel, The Art of Hosting, Open Space/Forum Ouvert, Stoos etc…) ou encore en créant les JavaCamps 🙂
 
Pascal Moreno occupe depuis 18 mois le poste de directeur commercial au sein de la société ACTISKILLS, centre de formation orienté management de projet. Sa curiosité l’a conduit à l’Agilité : à ce jour 50% de son temps est consacré à la mise en place de formations Agile. Il participe aux cotés de Luc Bizeul aux événement AGILE GAME CENTER, ou encore Agile Coach Camps.
 
La soirée se déroulera le jeudi 6 septembre à partir de 19h30 dans les locaux de la société Valtech, que nous remercions pour son accueil.
 

valtech

Vous pouvez vous inscrire dès à présent sur Eventbrite.

Retrouvez Aline Paponaud lors des ateliers Programatoo à Devoxx France et Théâtre d’Impro pour jouer à être Agile à Mix-IT

Pour continuer notre série, voici l’interview d’Aline Paponaud (@bootis). Vous la retrouverez à Devoxx et Mix-IT pour des présentations où vous devrez être actif (comme on les aime chez les Jduchess ;-) ). Aline coorganise l’atelier Programatoo à Devoxx avec Audrey Neveu et vous a préparé un match d’impro pour jouer à être Agile à Mix-IT.

Blandine : Qui es-tu ? Peux-tu définir ton travail actuel ?
Aline : J’ai 26 ans, je suis arrivée dans la région parisienne en septembre.
Mon travail actuel c’est développer en .net de nouvelles fonctionnalités sur du legacy code (une application qui existe depuis longtemps, qui était en TMA et pour laquelle un « grand projet » a commencé), et aussi d’animer et essayer d’améliorer les choses dans l’équipe pour l’amener vers de plus en plus d’agilité (mon côté scrummaster).

Blandine : Dans quel projet(s) /user group interviens-tu ?
Aline : Mes projets du moment c’est surtout programatoo (@programatoo, visible sur les blogs de Sfeir, Jduchess…) : c’est un projet longue durée chez Sfeir qui a commencé avant Devoxx et qui continuera après, l’objectif étant de savoir apprendre la programmation avec les enfants, et ensuite de diffuser au maximum ces pratiques.

Sinon tous les mercredis je suis chez /ut7 au Coding Dojo pour apprendre avec quelques compères. On fait un peu de tout, mais toujours dans les règles de l’art (TDD, plus forte valeur métier en 1er, et autres bonnes pratiques).

Ma prochaine action va être de parler un peu plus de .net et plus particulièrement de la solution d’intégration continue TFS sur mon blog techaline.wordpress.com qui est un peu mort en ce moment… et mettre un peu de source sur codeplex.

Blandine : Tu travailles actuellement sur un projet en .net, mais cela ne t’empêche pas de participer à Devoxx France ou Mix-IT. On croise peu de gens qui ont la double compétence Java/.Net. Penses-tu que ces deux mondes soient vraiment différents ?
Aline : En fait, je suis naïve et j’ai cru ce qu’on m’a dit quand je suis sortie de l’école en ayant fait plein de Java : « ce que vous savez faire, c’est pas Java ou C ou n’importe quel LANGAGE, c’est appliquer des CONCEPTS : vous savez développer en respectant de bonnes pratiques, vous savez faire des tests, vous savez concevoir des trucs ». Après 3 ans d’expérience, je me retrouve « coincée » par ma bonne connaissance des subtilités du langage et de quelques frameworks .net (ce qui pour moi ne fait pas de moi une bonne dev).

C’est simple : je veux apprendre plein de langages, tout comme à titre personnel je veux apprendre plein de langues étrangères.

Je refuse de croire qu’il y a un manque d’ouverture. Pour moi, c’est juste qu’il y a beaucoup de peurs, car on n’arrive pas à évaluer un bon développeur en dehors de sa maîtrise du langage qu’il sera payé pour utiliser.

Blandine : Pourquoi as-tu choisi ce métier ? As-tu les mêmes motivations qu’au début ?
Aline : Parce qu’il y a de la « magie » dans notre métier, quelque chose qui fait qu’on a le pouvoir de rendre facile et intuitives des choses très compliquées au départ.
Ce qui me plaît c’est de fabriquer des outils pour les gens et de savoir comment fonctionnent des systèmes complexes.
Ça n’a jamais vraiment changé.

programatooLogo

Blandine : Lors de Devoxx France, tu vas animer l’atelier Programatoo avec Audrey Neveu. Comment t’es venu l’idée d’organiser un atelier pour les enfants ?
Aline : J’ai rencontré lors de Agile Innovation Grenoble (la meilleure conférence Agile ;-) : www.agileinnovation.fr) que je coorganisais en 2011 des personnes de /ut7 qui s’intéressaient au sujet, et qui s’apprêtaient à faire leur premier Coding Goûter.

On en a pas mal discuté, on s’est rappelé de nous enfant et de notre première expérience avec la programmation, et j’ai vu qu’il y avait un écart avec ce que maintenant les enfants apprennent en premier sur un ordinateur : recherche google, emails ,facebook, utilisation du smartphone… là ils savent mieux que moi, mais pour le reste, il manque quelque chose.

Et une fois Agile Grenoble passé, et mon installation en région parisienne bien en place, je me suis dit que c’était le moment de lancer un projet. Et voilà… J’en ai parlé à Sfeir qui m’a donné son support. On s’inspire totalement du Coding Goûter, d’ailleurs on est en contact permanent avec eux. Mais nos objectifs, à terme, sont différents : on souhaiterait se tourner vers tous les enfants (pas forcément accompagnés de leurs parents) pour des ateliers dans la ville, dans les écoles… Mais on n’en est pas encore là !

Lors des ateliers Programatoo et des Coding Goûters chez nos amis de ut7, on se rend compte d’une chose, et c’est même le mot d’ordre : ce sont les enfants qui ont quelque chose à nous apprendre et à nous montrer. Ce qui m’a surprise : leur créativité, leur capacité à trouver des idées rapidement… Non pas que j’en aie douté, mais je me rends compte que mon enfance à moi s’éloigne !!!

Blandine : Lors de Mix-IT, tu organises un « atelier Théâtre d’Impro pour jouer à être Agile ». Peux-tu nous en dire plus ? Comment est-ce que ça va se passer ? On peut venir même si on n’a jamais fait d’impro ?
Aline : C’est du théâtre d’impro 100% débutant. On ne parle pas d’agilité, on s’amuse, on improvise en respectant les règles. L’idée est que chaque participant se rende compte de sa capacité à être réactif, à imaginer, et à s’adapter à toutes les situations. Que le groupe forme un ensemble cohérent, qu’on s’écoute, qu’on s’impose sans imposer à l’autre…
Le format : comme un typique entraînement d’impro, on commence par un échauffement, ensuite on fait quelques exercices et on finit avec des improvisations sur un thème donné.
A la fin, on fait une petite rétrospective, et les participants se rendront facilement compte du parallèle avec n’importe quel projet !

Blandine : Les méthodes agiles semblent importantes pour toi. Pourquoi ? Comment es-tu tombée dans la marmite des méthodes Agiles ? Pourrais-tu aujourd’hui travailler dans une équipe qui ne les applique pas ?
Aline : Déjà, je n’ai pas appris le Cycle en V à l’école, mais les méthodes Agiles. Donc forcément je n’ai pas pu m’imaginer un projet différemment. Ensuite, arrivée sur un projet directement en sortant de l’école, j’avais besoin d’aide et j’en ai trouvé au Club Agile Rhône Alpes… J’ai rencontré plein de gens épanouis et je leur ai fait un chèque pour les rejoindre, et j’ai organisé une grande cérémonie avec… non sans rire, c’était vraiment super et j’ai appris plein de trucs. Se retrouver avec des gens de différentes entreprises permet vraiment de prendre du recul sur la situation.
Aujourd’hui bien sûr je pourrais travailler dans une équipe qui ne les applique pas, d’ailleurs il y a beaucoup d’équipes qui disent qu’elles l’appliquent et qui ne l’appliquent pas… C’est une situation plutôt normale pour moi, et ce qui est intéressant dans ces équipes c’est justement d’essayer d’améliorer le process. Ce que je ne pourrais pas faire, ce serait travailler dans une équipe qui refuse tout changement.

 

Merci Aline ! Rendez-vous : 

Petra Cross from Google will be at Devoxx France and Mix-IT

Petra Cross

Continuing our interview series, the Mix-IT team asked some questions to Petra Cross who will be at Devoxx France and at Mix-IT.

 

Photo by Cody Bratt

 

Petra is a Senior Software Engineer at Google and an avid photographer. You could follow her on twitter or on G+.
With Petra, we will look behind the scenes of day-to-day development workflow in the engineering teams at Google. She will speak about this topic at Devoxx France and Mix-IT .

Mix-IT Team : Who are you?
Petra : I’m a Googler, photographer, and a pretty good wife. I live in San Francisco, California.

Mix-IT Team : Could you describe your typical day? Do you work all the day?
Petra : I wake up at 10am, get ready, and then walk to work (yes, I get to walk to work). I work from about 11am until about 7pm. I sometimes go rollerblading in the middle of the day (Google San Francisco office is right by the waterfront, with very ice trail along the bay) and do yoga in the evening. When I get home, I tend to work on a photography project or work on my travel plans.

Mix-IT Team : Which new tools/framework do you discover recently and that has inspired you?
Petra : Since I joined Google Wallet in San Francisco, I have been writing code using Android libraries. I have never done mobile development before, so a lot of the concepts are new to me, but I’ve been having fun.

Mix-IT Team : Does your team at Google use Scrum, or is it just inspired by Scrum?
Petra : Let’s not confuse Scrum with Agile. Scrum is a method for managing software projects. Most of Google engineering managers do not use Scrum, but some do.
However, Agile is more wide-spread at Google. Lots of engineering teams use Agile principles of planning task backlog, iterating in cycles, and estimating the tasks for the upcoming iteration.

Mix-IT Team : What would be your ideal technical stack for a webapp today ?
Petra : I have not seen an ideal technical stack yet. All technologies have their pros and cons and it takes time to learn about all the quirks and gotchas. I am comfortable with the Google server stack with Javascript on top. I’m not a Javascript expert though. I’ve spent most of my seven years at Google working on Java backends which use Google’s powerful distributed computing and storage resources.

Thanks Petra !
See you at Devoxx France for your talk about software development Workflow at Google on Thursday 19 April at 5 p.m. and at Mix-IT on Thursday 26 April at 2 p.m.

Agile Open France 2012

Du 18 au 20 Janvier 2012 aura lieu en Alsace, Agile Open France 2012.

Qu’est-ce-que Agile Open ?

Agile Open est un cycle de conférences au format Format Ouvert. Il est organisé par des agilistes un peu partout dans le monde. Vous avez peut être vu l’article de Linda Van Der Pal à ce sujet sur le blog World Wide Duchess. Le concept est tout simple : des participants auto-organisés proposent des sujets en rapport avec le développement logiciel et les méthodes agiles. Vous voulez partager des pratiques, idées, codes, expériences sur le sujet ? Cette conférence est faite pour vous !

Agile Open France 2012

Agile Open France est organisé toutes les années depuis 2008 en Alsace. Pour suivre l’actualité de cette conférence, vous pouvez suivre leur blog : http://blog.agileopenfrance.com/

Dans un cadre magnifique et avec un format participatif, cet évènement rencontre chaque année beaucoup de succès. Mais les conférences se suivent d’année en année mais ne se ressemble pas ! Car les sujets sont faits par et pour vous.

Informations pratiques

  • Où ? En Alsace à Itterswiller.
  • Quand ? Le 18-19-20 Janvier 2012.
  • Combien ? 360 euros pour toute inscription jusqu’au 25 décembre 2011.
  • Comment ? Tout est expliqué ici .

Attention les places sont limitées alors inscrivez-vous vite !

Entrevue avec Sébastien Douche : vous reprendrez bien encore un peu de Git et d’Agilité?

Le 20 septembre prochain, le Lyon JUG propose une session sur Git, animée par Sébastien Douche. Il proposera également le lendemain, toujours à Lyon, un coding dojo pour vous fournir une initiation pratique à Git!

@sdouche Quand on demande à Sébastien de se présenter voici ce qu’il nous répond : “Je m’appelle Sébastien Douche, 36 ans, j’ai commencé à tater des ordis avec les jeux vidéos il y’a 30 ans au Japon. Je me suis mis à la programmation assez jeune (C et assembleur x86) sous MS-Dos (ah le compilateur Watcom). La découverte d’Internet en 95 a bouleversé mon existence de geek, avec Linux et les Logiciels Libres, ainsi que pas mal de langages comme Eiffel, D, Erlang, Ada, Objective C, Smalltalk, Forth, REBOL et tant d’autres. Mais mon profil est assez atypique car je me suis vite intéressé à d’autres domaines comme l’agilité, l’administration système, le coaching et enfin la gestion d’organisation car je ne comprenais pas pourquoi je me sentais aussi mal dans les entreprises où je travaillais. Depuis 4 ans, je peux mélanger toutes ces passions dans mon activité professionnelle chez un éditeur logiciel Français.”

Puisque Sébastien et le Lyon JUG avaient envie de vous faire plaisir, vous avez le droit à cet interview mais également très bientôt à un nouvel opus du podcast Cast-IT, qui sortira peu après le 20 septembre (le temps du montage!). Si vous ne connaissez pas ce podcast émanant de la team du Lyon JUG, Cast-IT, allez vite écouter les premiers épisodes de ce nouveau podcast participatif sur l’écosystème Java, certes, mais ouvert également à des sujets comme l’Agilité ou d’autres langages. Ça tombe bien, même si Sébastien va nous parler de Git pour sa session au Lyon JUG, on voit dans sa présentation qu’il a bien d’autres centres d’intérêts : on va donc parler de Git bien sûr, mais aussi aborder avec lui d’autres de ses sujets de prédilection, notamment l’Agilité!

Cet interview a été préparé conjointement par Agnès CREPET et Cédric EXBRAYAT, deux membres de la team du Lyon JUG.

Agnès & Cédric: Tu proposes un talk sur Git, un système de gestion de version décentralisé (DVCS). Étant depuis longtemps présent dans les communautés des logiciels libres, peux-tu nous dire en quoi les DVCS ont été bénéfiques pour ces communautés ?

Sébastien: Les DVCS ont permis d’améliorer grandement la gestion de projet, raison pour laquelle beaucoup de projets Libres ont sauté le pas. Torvalds avait compris dès 2002 l’intérêt de BitKeeper (le 1er DVCS) et refusait catégoriquement d’utiliser CVS. Il faut dire qu’avec 10 ans d’expérience de management du plus gros projet Libre, il commençait à avoir de la bouteille. Dans un projet Libre, on passe beaucoup de temps à tester et à intégrer du code, et la souplesse offerte par l’outil de gestion de source est importante. Or, SVN impose de par sa conception un management restrictif, seules les personnes habilitées ont droit de commit, donc de travailler avec l’outil. Pire, chaque développeur ne peut pas choisir librement sa méthode de travail sans impacter les autres développeurs, voir la stabilité du projet. C’est pour cela qu’il faut bien souvent montrer patte blanche avant de réellement participer, alors que la facilité d’immersion dans un projet Libre est fondamentale pour sa réussite.

Dans ces conditions, le DVCS est un atout majeur en décorellant la façon de gérer le projet des envies ou besoins des développeurs. Chacun pouvant donc, à son niveau, définir sa méthode de travail. C’est ce que j’appelle workflow organisationnel (le management de projet) et workflow personnel (la méthode de travail du développeur). Voici un exemple avec le projet Python : le responsable projet demande un commit unique par fonctionnalité si je suis core développeur ou un patch sur le bugtracker dans le cas contraire. Cette contrainte n’impose pas une quelconque façon de travailler sur ma machine, mais seulement ma relation avec le projet. Par une IHM bien pensée et des fonctionnalités intéressantes, des sites comme GitHub ou Bitbucket abaissent encore plus le coût de participation.

De plus les DVCS sont bien mieux pensées. SVN croule sous le poids des années. Il faut rappeler qu’il est sorti en 2001 comme une amélioration de CVS sorti en 1990, lui même étant une amélioration de RCS sorti en 1982, lui même un portage Unix de SCCS sorti en 1972 (ouf !). On a beaucoup appris en 30 ans. Je pense notamment au graphe des commits (que l’on appelle le DAG) des DVCS et son équivalent atrophié SVN, qui impose cette façon si peu efficace de gérer les branches. Tellement peu efficace qu’elles sont rarement utilisées, voir interdites.

Agnès & Cédric: Naïvement, on peut facilement voir l’intérêt d’un DVCS pour des personnes travaillant en mode distant, mais au sein d’une entreprise, ce type d’outil a t’il vraiment des plus-values? Si oui lesquelles? En quoi une entreprise doit-elle être vigilante avant de passer à un outil comme Git ?

Sébastien: Le terme distribué est trompeur, car on pense «déconnecté» ou «distant» alors qu’il faut lire «autonome». La possibilité de télétravailler chez soit ou dans le train n’est qu’une conséquence d’une architecture qui me permet avant tout de travailler localement, sans fil à la patte. Je suis autonome et je décide ce que je veux partager : le développeur devient un producteur de contenu. C’est la distinction des workflows de ma réponse précédente. En tant que responsable, la possibilité de définir le workflow organisationnel est un atout majeur pour améliorer la qualité du projet. Et pour le développeur, un confort incomparable de disposer de sa méthode de travail. Pour rien au monde je ne reviendrais à SVN et pour tout dire je refuserais un poste si je devais travailler avec. Pour citer ma présentation DVCS au ParisJUG, le dernier slide dit «si vous devez apprendre une chose en 2010, ce n’est pas (je liste les technos Java à la mode) mais un DVCS». A part virer Windows, je ne crois pas avoir vu un gain de productivité aussi notable avec un simple changement d’outil. Et c’est le développeur, le coach, le responsable R&D et le directeur technique qui parlent :) .

En tant que responsable R&D, j’ai vécu le changement SVN vers Mercurial, puis Git. Il y a deux difficultés :

  1. bien comprendre les concepts des DVCS, et de Git en particulier qui est à l’opposé de SVN tant vous êtes libre de faire ce que vous voulez avec. C’est pour cela que ma conférence est avant tout structurée pour assimiler les concepts, et non les commandes comme je le vois malheureusement trop souvent.
  2. il faut expliquer aux développeurs et aux responsables projets les différents workflows pour les aider à en adopter un. C’est le deuxième objectif de la conférence, mais l’avantage de l’atelier est ici évident car on peut pratiquer et en parler assez longuement.

Si je dois résumer, je dirais que l’on passe d’un mode de travail rudimentaire à une liberté totale. C’est banal à dire, mais la liberté est une chose merveilleuse et on se demande comment on a pu être aussi stupide de se laisser enfermer. Mais cette liberté exige discipline et responsabilisation. Et ne rêvez pas, vous ne deviendrez pas magiquement un meilleur développeur pour autant ;) .

Agnès & Cédric: Utilises-tu un système de workflow avec Git ? As-tu des astuces pour simplifier la migration et l’adoption en entreprise ?

Sébastien: On a toujours un workflow, même sans le savoir :) . Voici mon workflow personnel pour chaque fonctionnalité que je dois coder :

  • je commite énormément et de toutes petites modifications.
  • j’utilise beaucoup de branches de travail (comme wip, backup, step1, step2) comme marqueur pour identifier chaque étape et y revenir si besoin.
  • une fois le travail terminé, je pousse tout dans la branche principale de la fonctionnalité nouvellement créée et je la nettoie si cela est nécessaire : fusion et ré-ordonnancement des commits, décomposition d’un commit en plusieurs si j’ai mélangé plusieurs modifications sans lien entre elles et ré-écriture des messages de commit si besoin. J’appelle cela une branche «propre», un historique agréable à lire et facile à comprendre pour un relecteur, avec des commits «unitaires», c’est à dire cohérents et compréhensibles par eux-même.
  • je pousse sur le serveur principal pour revue de code.
  • quand la revue est validée, je rebase avec la branche master et je merge en non fast-forward.
  • je supprime toutes les branches locales ainsi que la branche sur le serveur.

Nous avons eu plusieurs workflows organisationnels dans le temps. Par exemple avec Mercurial, j’étais l’intégrateur : les développeurs envoyaient un patch une fois la revue terminée et j’intégrais. C’est un workflow qu’utilisent beaucoup de projets Libres. Actuellement avec Git, nous avons la branche master, la branche par fonctionnalité, une branche pour chaque étape de développement de cette fonctionnalité et enfin une branche de maintenance par version majeure. Mais nous n’avons pas de branche d’intégration générale (lisez git-flow si cela ne vous semble pas clair ou venez à une de mes conférences :) ).

Agnès & Cédric: Tu as essayé d’autres DVCS que Git, tu dis être passé de Mercurial à Git par exemple. Qu’est-ce qui t’as poussé à changer de DVCS. As-tu des retours sur d’autres DVCS moins répandus comme Veracity de SourceGear proposant un certain nombre de features en plus de Git ?

Sébastien: J’ai utilisé Mercurial (Hg) deux années au taff et un peu joué avec Monotone et Darcs, deux DVCS de première génération. Faisant beaucoup de veille, je reste à l’affût de toute nouveauté, et j’ai quelques fonctionnalités en tête que j’aimerais bien voir dans Git. Nous sommes passé de Hg à Git pour deux raisons : la curiosité intellectuelle, et parce que la gestion des branches dans Hg est assez simpliste, il faut cloner le dépôt quand on veut travailler temporairement sur une branche ce qui est loin d’être convivial (je crois que les développeurs de Hg travaillent là dessus). Notez qu’on aurait pu rester sur Hg, mais je suis très heureux d’avoir basculé.

Pour Veracity, je suis circonspect. Un outil qui intègre DVCS, wiki, bugtracker et Burndown Chart donne l’impression d’un outil qui se veut certes accessible pour l’entreprise, mais bien trop intégré à mon goût. C’est l’opposé de ma philosophie qui vient d’Unix : un bon outil pour une tâche donnée. Je n’aime pas les outils intégrés, surtout si c’est une brique d’infrastructure. Il a fallu une semaine pour passer de Hg à Git et adapter nos outils, que se passe t’il si je veux quitter Veracity ? Mais il est intéressant de noter que les nouveaux outils (Veracity, Fossil) sont des DVCS. Ceci dit, je mets *tout* dans un dépôt Git: code, données, binaire, fichier de configuration, documents (vive le format texte comme le rst ou le markdown), blog, site web et j’attends un bugtracker et un wiki digne de ce nom avec un backend Git. Il faut noter que Git, Mercurial et Bzr partagent une conception assez proche et les migrations entre DVCS sont simples, et on trouve d’ailleurs des projets Libres en dépôt Git et Hg.

La seule fonctionnalité intéressante que j’ai pu voir dans les DVCS récents est l’autosync de Fossil, permettant de “simuler SVN”, utile pour ceux qui débarquent dans le monde du DVCS. Sinon j’apprécie la facilité du cherry-picking de Darcs et les tags locaux de Hg. Mais pour moi l’avancée marquante sera un outil graphique de visualisation du graphe des commits puissant. Je suis certes un amoureux de Git, mais je n’hésiterais pas à changer si je trouve un outil plus intéressant. Il est important de ne pas se scléroser mentalement.

Agnès & Cédric: Tu viens d’écrire un article “L’Agile est mort” dans l’été, qui a engendré pas mal de discussions/commentaires… A la fin de l’article tu proposes de regarder d’autres méthodes ou outils : tu parles notamment de Kanban. Peux-tu nous dire ce que Kanban t’a apporté ces dernières années ?

Sébastien: Pour être précis, j’ai dit que le modèle Agile, inventé pour vendre du service, doit mourir. Nous progressons régulièrement dans la compréhension de notre métier et il est ridicule de continuer à pratiquer un management de 2001 parce qu’il est «bankable». C’est une problématique de consultants, pas des gens qui produisent. Toyota, Google ou Apple ne font pas du Lean truc ou du Scrum machin, ils font ce qui est utile et bon pour eux. Il est illusoire de déléguer à des consultants le management de son projet ou de son organisation, c’est *votre* travail. C’est l’objet de mon prochain billet sur le management qui s’intitule “N’écoutez pas les consultants”, et j’avoue que cela me démange de taper sur quelques personnes connues (françaises et internationales) qui disent n’importe quoi pour vendre leurs sauces. La montée en puissance du Kanban est un bon exemple, ou l’on retrouve régulièrement des sessions qui expliquent comment faire du «Scrum + Kanban», ce qui est assez pitoyable et montre soit l’incompétence, soit une volonté de protéger son business, mais en aucun cas de proposer l’état de l’art au client. Faire du business ok, mais il faut avoir une éthique. Un mec comme Schwaber me faire vomir tant il ne s’intéresse qu’au fric et je me bats contre Scrum car ce n’est qu’une marque.

Pour revenir au modèle, c’est je crois le défaut de tout modèle générique quel que soit sa qualité intrinsèque, il suffit de voir les dégâts de CMMi ou de RUP par exemple. Il faut toujours se rappeler que la ruée vers l’or a surtout enrichi… les vendeurs de pioches.

Pour le Kanban que j’utilise depuis plus de 3 ans, c’est à la suite de l’échec rapide dans mon contexte du mode de management agile «traditionnel». La tactique que l’on utilise en agilité est de limiter le travail en segmentant la vie du projet en «itération», étape où l’équipe doit produire un logiciel fonctionnel. Cette itération est fixe, au niveau du temps comme du travail à produire, préalablement choisi avec le responsable projet à l’aide d’une métrique appelée vélocité. Un dashboard permet de visualiser l’avancée de l’itération. Je pense que tout le monde est maintenant familier avec tout cela, je n’irais donc pas plus loin.

J’ai commencé par une itération de 15 jours pour finir avec une itération de 5 jours, du déploiement continu et des phases de Q/A important lors des releases officielles (une par trimestre, mais on release chaque mois en interne). J’ai trouvé plusieurs lacunes graves à ce mode de management :

  • la vélocité est une métrique boiteuse, sorte de moyenne des estimations des développeurs. Sans compter qu’on passait 1/8 de notre temps en planning poker.
  • le dashboard n’est pas assez précis, il ne permet pas de comprendre finement le «système» (la R&D dans mon contexte).

Parallèlement je demandais depuis longtemps tant au responsable produit qu’au développeur de découper les tâches de plus en plus petites car je voulais une sortie rapide du système (un développement rapide), ce que le Lean appelle «cycle time». Et en modifiant petit à petit le management du projet pour combler les lacunes apparentes, je me suis rendu compte que la notion de flux était puissante. Je venais par petite touche de me rapprocher du Kanban. Depuis j’ai abandonné les estimations et les itérations pour une approche plus fine et souple avec une intégration des fonctionnalités quand elles sont prêtes (merci la gestion des branches des DVCS), des phases différentes selon qu’on release officiellement ou non (une release officielle demande des docs, une synchro avec le marketing et le commerce, etc), des «classes de service», c’est à dire des priorités différentes selon les demandes. Je modélise aussi bien les demandes fonctionnelles, de correction de bugs que de modification de l’infrastructure de création de doc. Je suis ravi de ces changements, je suis sorti d’un carcan pour créer une environnement adapté au business de la société. Entre temps, j’ai fait la relation avec mes lectures passées (le Lean et la théorie des contraintes) et découvert le Kanban, la plus proche émanation de la théorie des flux dans le contexte de développement logiciel. Bien que cela puisse paraître récent, c’est en fait assez vieux : la théorie des files d’attente du mathématicien Erlang, le travail du professeur du MIT John Little, la théorie des contraintes, l’efficacité des batchs, on parle des années 1920 à 1970 ! On utilise ces théories dans beaucoup de domaines et Toyota l’a par exemple bien compris depuis longtemps. Après l’agilité, le Kanban représente pour moi une nouvelle avancée marquante dans le management de projet. Plus besoin de triturer son itération, et je rigole souvent quand j’entends les retours d’expérience de Scrumistes qui déforment leur pratique managériale pour faire tenir les demandes. Sans compter le puéril débat Scrum / Scrumbut qui ne fait que mettre en exergue le carcan qu’impose les soit disant experts. Dernier point, notre dashboard (un énorme tableau blanc avec des fiches cartonnées) permet de connaître à tout instant l’état exact du système, cela est très intéressant.

Voici un exemple que j’espère compréhensible : un jour, un des développeurs de l’équipe qui n’avait rien à faire prend une fiche de très basse priorité (les fiches importantes sont bloquées pour diverses raisons). Cela part d’un bon sentiment, il n’est pas payé à ne rien faire. Mais alors que la fiche semblait simple, cela à pris plus de temps que prévu. Pire la fiche a fait 2 aller/retour (la revue de code est obligatoire chez nous), elle a pris du temps à la R&D et une fiche plus prioritaire fut retardée. Du point de vue du développeur, il a occupé son temps à 100%, c’est donc positif. Mais du point de vue du système on est perdant, la fiche prioritaire est retardée. Une conséquence possible aurait pu être la non intégration de la fonctionnalité impactée pour la release du mois, ou pour la livraison d’un POC (test en avant vente) très important pour la société. Le Kanban a montré très facilement cela : on écrit la date quand on déplace de colonne la fiche (rappel, une colonne = un type de tâche), on peut ainsi voir le temps qu’elle a mis dans le système (temps du commencement du dev jusqu’à l’intégration dans la branche principale). On note aussi les aller / retour entre la colonne dev et la colonne revue. Il fut donc facile de constater que la fiche dite “facile” a passé 2 jours dans le système, avec 2 A/R. La fiche importante ayant du coup pris 1 jour de délais supplémentaire dans le système (alors qu’on avait prévu de finir assez facilement la veille). Si le développeur avait attendu au lieu de travailler, il aurait revue la fiche prioritaire 1h après et elle sortait rapidement. Autrement dit, il aurait mieux fallu qu’il glande au lieu de bosser ! Étonnant non ? Mais du point de vue du système, c’était la meilleure solution. Depuis, les développeurs n’ont plus honte d’utiliser le «slack time», temps où on ne peut rien faire et qu’on met a profit pour, par exemple, faire de la veille.

Il y a tant à dire sur le sujet que cela dépasse largement le cadre de cet interview. J’ai peur que beaucoup de lecteur se disent «encore un truc de manager» ou pire «c’est pour mettre encore plus de pression». Le meilleur moyen de faire baisser la pression et de travailler sereinement, c’est d’être efficace et sûrement pas de finir la mise en prod le vendredi à 22h ! Je suis devenu manager pour créer un environnement que le développeur que j’étais aurait aimé avoir, loin des environnements pourris qu’il a connu. Je vais bientôt proposer une conférence sur le sujet tellement je suis émerveillé. Mais la théorie des flux ne fait pas tout, cela rentre dans un cadre plus global de recherche de marché, d’analyse marketing produit, de gestion des hommes et de pratiques de développement logiciel. Je souris toujours quand je repense au geek qui ne pensait qu’a coder seul devant sa machine, mais tous ces domaines sont passionnants et surtout importants pour la réussite d’un projet. Développer un produit logiciel est fascinant.

Agnès & Cédric: Comment se déroule l’une de tes journées types ? As-tu le temps de faire de la veille techno et de mettre les mains dans le code ? Ou es-tu maintenant plus passionné par l’agilité et le coaching ?

Sébastien: Je fais environ une heure de veille par jour depuis que je travaille, ceux qui me suivent sur Twitter le croiront sans mal :) . J’ai cumulé beaucoup de casquettes pendant longtemps : directeur technique, admin système & réseau, responsable R&D, coach agile, coach organisationnel, testeur, responsable projet, responsable support, responsable logistique (nous vendons logiciel + matériel), release manager, développeur. On a fini d’optimiser certains process assez lourds comme la logistique et j’ai délégué certaines tâches comme le support, je peux donc revenir plus vers du code commun avec les développeurs. Mais avec mon emploi du temps, il est impossible de travailler sur du besoin métier, qui exige de gros blocs de temps sans interruption (ce qui est rarement le cas d’un manager) et surtout de travailler de concert avec les autres développeurs. Je m’occupe donc plus de projets d’infrastructure comme développer des outils internes, revoir nos techniques de tests, refactorer les couches techniques, simplifier la configuration du serveur d’application, extraire le code métier du code technique, repackager le code… Bref, baisser la complexité générale et éliminer les points techniques qui posent problème.

Cela permet d’apprendre beaucoup car on touche à tout sauf malheureusement au code métier. La couche système est ma seule implication de bout en bout car je suis un peu plus expérimenté que les autres.

La semaine dernière par exemple, j’ai transformé notre guide utilisateur OpenOffice en document Sphinx ce qui permet de publier en plusieurs formats dont le HTML afin de l’intégrer aux sondes et d’utiliser Git comme backend. Et je suis en train de me replonger dans Latex pour modifier le format PDF. J’ai modifié notre socle pour faire du support par clé modem 3G et ainsi aider nos avant ventes chez des clients un peu parano qui n’acceptent pas le VPN par Internet (ce qui m’a demandé de refaire un nouveau kernel Linux, de transformer un usbstorage en usbserial, et de configurer ppp). Et j’ai testé plusieurs logiciels car je dois revoir notre pratique de tests fonctionnels. Bref, Je suis bien loin du manager qui fait du Powerpoint. J’ai d’ailleurs horreur des outils bureautiques, mes pres. comme mes blogs ou les documents que je produis sont aux format rst ou Markdown :) .

Si je dois faire l’exercice de l’ascenseur à un recruteur, je dirais : vous gérer le commerce, le marketing et les finances, je m’occupe du reste ! Avoir autant de casquettes n’est pas facile et j’ai même failli devenir schizo, mais cela à un avantage indéniable : la prise de décision est fort simple :) . En gros je fais ce que je veux, c’est la raison pour laquelle 99% de ce que j’ai mis en place depuis 4 ans était nouveau pour moi : je trouve quelque chose d’intéressant, quelques heures ou jours après c’est mis en place et appliqué, car je n’ai pas à convaincre un client ou mon chef. Résultat, une courbe d’apprentissage exceptionnelle, j’ai appris ces 4 dernières années 100x plus qu’en 8 ans de SSII. Pire, je me suis aperçu que mon expérience était faible et que je ne savais vraiment pas grand chose (j’en sais un poil plus maintenant :) . De plus, je trouve le métier d’éditeur logiciel est bien plus intéressant et passionnant que de travailler en SSII, le business model étant plus contraignant : vous ne gagnez de l’argent qu’une fois le produit fini, et encore si le client en veut ! L’efficacité est primordiale, surtout si vous êtes une startup avec peu d’argent.

Agnès & Cédric: Fais-tu quand même un peu de Java (on te sait assidu au ParisJUG) ? Quel regard as-tu sur cette plateforme et cette communauté par rapport à Python ?

Sébastien: Il y a beaucoup à dire, notamment sur ce que j’appelle le «prisme Java», c’est à dire la déformation que vous avez à force de vivre dans cet écosystème. Je déteste Java (je suis devenu admin en 2001 pour ne pas faire du Java ou du PHP, véridique !), et si j’avais la moindre velléité d’en faire quand je suis arrivé au ParisJUG, ils m’ont définitivement dégoûtés :) . L’objectif initial était d’aller vers des communautés de développeurs pour m’enrichir d’autres regards et pratiques sur le développement, et je côtoie toujours beaucoup de communautés. La rencontre avec des Javaistes fut… comment dire… difficile. Le monde Java est assez fermé (avec des œillères bien solides), possédant sa propre novlangue. Je ne comprenais rien (et je ne comprends toujours pas grand chose) des Javaistes quand ils parlent ! De mon point de vue, il y a 3 soucis majeurs dans le monde Java :

  1. Une culture fortement dominée par des entreprises commerciales et cela se ressent, tant du coté des fournisseurs de solutions que des prestataires. Sans compter que 80% des développeurs Java que je vois travaillent pour des grands comptes, c’est fortement structurant.
  2. Je n’apprécie pas du tout le système de typage, avec l’extrème verbosité d’un typage explicite et des NullPointerException au runtime par exemple. De mon point de vue, Haskell, OCaml ou C# sont bien plus intéressants sur ce point si on est intéressé par le typage statique. Scala est sur ce point une avancée intéressante. D’où aussi l’utilisation presque obligatoire d’un IDE.
  3. Un langage rustique par certains cotés, qui a mal évolué, avec des lacunes. Quand je vois qu’il faut attendre Java 7 pour avoir la gestion des contextes (le try-statement) la gestion de plusieurs exceptions à la fois ou une librairie I/O potable, je rêve un peu. On gardera un voile pudique sur des errements comme la gestion des classpath :) . Alors que de l’autre coté, le manuel de référence fait plus de 800 pages ! Par comparaison, Python en fait 120.

Pour moi, c’est la JVM qui sauve Java. Je trouve le langage en lui même assez médiocre. Mais le pire est que je constate souvent qu’un développeur Java passe 70% de son temps à régler des problèmes Java et non des problèmes métiers, d’où le surnom que je vous donne : «Mario», et l’expert Java «Super Mario». La complexité moyenne d’un projet est absolument incroyable ! Le développeur Java passe son temps à câbler des librairies (qui pour la plupart comblent les errements du langage) et à faire fonctionner des frameworks ensemble, c’est ennuyeux à mourir. Je suis impressionné par le niveau de connaissance nécessaire pour mener à bien un projet. Malheureusement la grande majorité des informations que vous emmagasinez n’a aucun intérêt pour moi. La conséquence est que votre échelle de complexité est maintenant complètement biaisée, et ce que vous appelez simplicité est pour moi bien trop complexe. Pire, ma simplicité est suspecte pour un développeur Java ! J’ai halluciné de lire un jour le résultat d’un questionnaire qui montrait qu’un développeur passait 14% à 28% de son temps à… attendre que le serveur d’application se lance ! Ou qu’un développeur lambda écrivait tout autant de xml que de Java. Le besoin de productivité, le fameux «time to market», ne permet plus de dépenser autant d’argent pour des résultats aussi faibles.

Mais depuis 3 ans les choses changent : la déception du rachat par Oracle, les 5 ans pour avoir 8 fonctionnalités, l’arrivée de Clojure, Scala, Groovy et surtout la prise de pouvoir du monde Web, philosophiquement assez éloigné du monde Java ont changé la donne.

Mais la raison essentielle de ma présence aux 3ème mi-temps (celle ou l’on boit, tu ne me verras pas souvent aux confs), c’est de se confronter à d’autres opinions, d’autres regards, car il est important de ne pas se figer dans ses croyances, de permettre de réfléchir à son propre prisme, ses propres blocages, ses propres lacunes. Ma conférence sur les langages dynamiques est par exemple une conséquence d’une réflexion sur ma relation avec la programmation qui fait suite à des discussions au ParisJUG. Et puis discuter entre passionnés autour d’une bière, j’adore. Que l’on parle moto, mécanique, photo, programmation, coaching, organisation, méthodo, rencontrer des gens est vital pour moi, j’ai besoin des autres pour initier et enrichir ma réflexion. Je suis trop stupide pour penser seul dans mon coin, j’ai besoin d’input :) .

Pour Python, c’est bien différent :

  • d’abord par l’aspect communautaire, très proche du Libre, que l’on retrouve dans beaucoup de langages. Il n’a pas des annonces tous les 2 mois de la techno géniale X qui va révolutionner le monde, j’apprends les sorties car je suis… le flux RSS du serveur qui centralise les composants Python.
  • C’est un langage accessible, raison de sa popularité en tant qu’outil de formation à l’algorithmie dans de nombreuses universités. L’abandon de Scheme par Python au MIT à fait grand bruit d’ailleurs (le livre Scheme utilisé depuis 30 ans est un best-seller).
  • Une productivité assez impressionnante par son expressivité et des axiomes puissants, qui vous rend accro très vite. Il partage avec Git et Unix une conception orthogonale : il existe un petit nombre de concepts mais qui donne une belle puissance quand ils sont additionnés. De plus il est cohérent, vous n’avez pas à lire la doc toute les 5 min pour comprendre ce qui se passe. Je ne parle pas du first class object, la facilité d’introspection, ou la grosse librairie standard.
  • Le langage est développé par une petite équipe (bien qu’on doit atteindre les 100 développeurs maintenant) qui fait cela sur leurs temps libres, ils ne se battent pas pour imposer telle ou telle lib (suivez mon regard), mais veillent avant tout à une cohérence d’ensemble. Et de toute façon on a un dictateur bienveillant qui tranche régulièrement. Malgré la faible taille, Le projet est fortement structuré (un exemple : l’équivalent du JSR appelé PEP est utilisé depuis 2000) et un management solide qui me laisse de temps en temps un poil baba. Python 3 est un bel exemple, notamment si on le compare avec PHP 6 et Perl 6.
  • Ensuite, j’apprécie fortement le codage par «Duck Typing», beaucoup moins contraignant que le typage statique en Java. Lisez un code Java et dites vous quelles sont les lignes qui sont utiles pour le métier. En Java, c’est assez consternant. En Python, vous êtes proche du pseudo-code, tout en gardant une forte lisibilité. Cela n’a pas que des avantages bien sûr (Haskell ou OCaml ont bien plus d’intérêt), mais associé à la simplicité et l’expressivité du langage, l’équilibre général du langage est très intéressant.
  • La communauté est dynamique, compétente et accueillante. Que ce soit celle des utilisateurs ou des core developers. Il existe une liste de diffusion pour débuter en programmation, de tutorat pour devenir core developer par exemple. Il existe beaucoup de projets impressionnants par leur maturité technique. On est loin de la communauté PHP avec ses logiciels phares codés avec les pieds.
  • Et enfin le projet PyPy (VM avec un JIT) est très prometteur. La version en cours de développement est presque 5x plus rapide que l’interpréteur de référence CPython et ce n’est pas fini. Il existe même des implémentations de PHP ou de Smalltak et des backends .NET et JVM. Ce projet va sûrement rendre Python encore bien plus attractif.

Mais comme je le répète souvent, chaque langage est une vision du développement, et tout est question d’équilibre entre facilité et contrainte. Le saint Graal que représente la fusion du bon coté des langages dynamiques (le fun) et du bon coté des langages statiques (la performance et la plus grande sécurité) n’est pas encore atteint malgré quelques tentatives comme OCaml. En ce moment je suis beaucoup le langage Go et j’attends une stabilisation du projet pour m’y remettre. Je suis déçu par Scala qui manque d’accessibilité tant dans la syntaxe que la sémantique. C’est un langage puissant mais trop «brute de fonderie». Je garde ma préférence à Python car non seulement je me sens très productif tout en gardant une qualité de code certaine, mais aussi parce que le plaisir de coder est largement présent. Et ça, c’est essentiel.

Merci Sébastien!

Les inscriptions pour la session de Sébastien au Lyon JUG le 20 juillet sont ouvertes! De plus nous vous proposons un coding dojo, pour vous fournir une initiation pratique et gratuite à Git. Celui-ci sera animé par Sébastien Douche lui-même et se déroulera mercredi 21 septembre de 19h à 21h à l’Epitech et se limitera à 20 personnes. Le Lyon JUG offrira les pizzas ! Rendez-vous sur le site du Lyon JUG.

Mix-it… Des idées pour tout de suite!

logo_mixitLe 5 avril aura lieu à Lyon la première édition de Mix-it!

Le Lyon JUG et le Club Agile Rhône-Alpes s’unissent pour vous proposer une journée exceptionnelle autour de l’agilité, des technologies Java/JEE et des tendances novatrices. Mix-IT 2011 est avant tout un rassemblement d’acteurs de tous horizons et de tous domaines.

La conférence Mix-it 2011 vous propose 5 thèmes :

  • Techy : Java et son écosystème
  • Agility : Agilité pour débutants et passionnés
  • Mixy : Le meilleur de l’agilité et des technologies Java
  • Trendy : Tendances novatrices et avant-gardistes
  • Gamy : Échanges autour de jeux agiles, de coding dojos ou de code retreats
  • En mettant en avant l’innovation, les bonnes pratiques et la découverte, Mix-it concerne toutes les personnes et entreprises qui veulent en savoir plus sur l’agilité et/ou les technologies Java/JEE.

    Vous êtes développeur, testeur, architecte et vous avez envie de rencontrer des intervenants renommés sur des projets tels que Spring ? Vous vous demandez ce que peut bien être NoSQL ou Apache Mahout? Vous avez envie d’avoir les bons arguments pour promouvoir l’agilité au sein de votre société ? Cette conférence est pour vous !

    Vous êtes chef de projet, responsable produit, manager et vous voulez maîtriser des sujets tels que les estimations, la planification ou la contractualisation agiles ? Vous désirez échanger avec vos homologues sur la mise en place de l’agilité en entreprise ? Vous souhaitez également comprendre ce qui se cache derrière le mouvement DevOps… Cette conférence est pour vous !

    Niveau speakeurs, on retrouvera des noms connus des JUGs (Nicolas Martignole, David Gageot, Didier Girard, Michaël Figuière) et des agilistes reconnus (Laurent Bossavit, Mack Adams, Mauro Talevi, Thierry Cros)…

    Si vous désirez proposer une session, vous êtes invités à envoyer ce document de proposition renseigné à l’email orateur@mix-it.fr.
    Les propositions de session sont à envoyer au plus tard le 08 Mars 2011.

    Au niveau pratique, les frais d’entrée sont très modérés (20€ ) et toute la conférence se déroule dans les locaux de l’E.P.I.T.E.C.H. (Ecole pour l’Informatique et les nouvelles Technologies) à Lyon (à 5min. de la gare Part-Dieu).

    Allez découvrir le programme sur le site pour vous inscrire et proposer un talk!
    Et d’ici là suivez @mixIT_lyon sur twitter pour avoir plus d’informations!

    En continuant à utiliser le site, vous acceptez l’utilisation des cookies. Plus d’informations

    Les paramètres des cookies sur ce site sont définis sur « accepter les cookies » pour vous offrir la meilleure expérience de navigation possible. Si vous continuez à utiliser ce site sans changer vos paramètres de cookies ou si vous cliquez sur "Accepter" ci-dessous, vous consentez à cela.

    Fermer