23 mars 2011

"à la Facebook"

Mon twitter (1) me pousse cet article très intéressant : http://framethink.wordpress.com/2011/01/17/how-facebook-ships-code/

On y découvre le mode de fonctionnement de Facebook, ou comme le géant du web utilise la culture geek pour piloter ses développements. Ce que je note, c'est l'importance et la liberté données aux ingénieurs, et la contrepartie : l'engagement qu'on leur réclame.

Je vais tenter de résumer l'article en quelques lignes (en tout cas, les points qui on retenu mon attention...)

 
Facebook ce sont des ingénieurs, triés sur le volet, qui bossent en totale autonomie sur le sujet qui leur plait, avec éventuellement un Product Manager qui essaie de leur souffler des idées. Un PM pour 7 à 10 développeurs, ça me laisse rêveur - on aurait presque l'inverse en France parfois. Chaque développeur a une semaine pour monter son truc, de l'UI au backend. Les premières semaines dans la boite, le "bootcamp", leur permet de découvrir tous les rouages du site et d'être autonome par la suite - pour ceux qui arrivent à suivre. Quand on vous dit "triés sur le volet"...

Cette liberté totale et le manque d'emprise des PM sur le projet est à contre courant de tout ce que j'ai pu rencontrer jusqu'ici :) D'un autre côté, avec un cycle de release très rapide, ça ne doit pas être aussi anarchique qu'on pourrait le croire a priori. Sur des projets de 6 mois évidemment ce serait ingérable, mais si on compte en jours ?

La contre-partie de cette très grande liberté est que les développeurs sont ici partie prenante du projet avec une très lourde responsabilité. Sans doute facilité par une connaissance de l'ensemble du SI et pas juste d'une brique isolée, les ingénieurs assurent le reporting, ils sont le contact direct pour toutes les questions relative au projet. Autrement dit, ils incarnent implicitement le rôle de PM. D'autre part, il y a le mardi.

Le mardi, c'est le jour de la mise en prod - oui, une par semaine, ça surprend toujours tant cette notion  est lourde dans nos contextes traditionnels. Tout les développeurs qui ont introduit du code doivent être présents sur site et disponibles. Ne pas répondre aux demandes des Ops et/ou ne pas supporter un bug détecté dans son code est un motif de licenciement. Et avec 60.000 serveurs à mettre à jour, il doit y en avoir quelques unes des demandes de la part des Ops !

On rentre dans une logique différente, un esprit de responsabilité que la culture MOA/MOE, forfait, prestataire nous a fait perdre : on ne développe pas juste du code, on développe du code qui doit tourner en production. La logique DevOps semble particulièrement mise en pratique chez Facebook.

Pourrait-on appliquer cela ailleurs ? 

Je vous vois venir, je ne parlerais pas de mon cas personnel. Par contre, globalement il y a des lessons à retenir :

  • On ne motive pas des développeurs en les infantilisant. Les ingénieurs ont besoin de créer quelque chose, d'en être fier, et de le porter au yeux de leurs pairs. Arrêtons de leur affecter des tâches, de leur imposer des roadmaps à plusieurs mois. Evidemment, cela passe par un raccourcissement des cycles de production. Compter en mois (voir en années) cela impose une planification. Compter en semaines cela permet de tenter des choses, de laisser une part d'inconnu, d'expérimenter sans faire de gros frais.
  • La culture DevOps a encore du chemin à faire. On ne crée pas de l'engagement en les mettant dans des silos. On pourra faire toute l'agilité qu'on veut, si le développeur n'est pas directement responsable des bugs constatés en production et du client qui gueule au bout du fil, il continura à délaisser sa stratégie de test pour passer à quelque chose de plus "intéressant".

Pour moi, le premier point à traiter est notre cycle de release. Il ne s'agit pas juste de créer tous les 30 jours un "logiciel potentiellement livrable" comme nous le suggère Scrum, il s'agit de mettre à l'épreuve toute notre chaine de production aussi souvent que possible. Le liens vers DevOps est alors évident et rapidement indispensable.

Comment vendre cette évolution à nos Managers ? 

Un seul argument à vous proposer (je vous laisse trouver les vôtres) : combien de temps faut-il pour fournir une évolution ou un correctif sans désorganiser l'équipe (je ne parle donc pas du gros bug critique "stop the line") ? Avec un cycle tel que celui de Facebook, cela peut être juste une semaine, sans créer le moindre stress supplémentaire. Avec une approche traditionnelle, en 13 ans, je n'ai connu aucun projet qui faisait des mises en production à moins de quelques mois d'intervalle. Le time-to-market est le nerfs de la concurrence, et de ce point de vue tous les CMMi du monde n'ont rien à nous proposer.

(1) pour ceux qui en doutent, twitter est aussi un outil de veille technologique et de support. Comme tout réseau social, il peut porter des choses totalement futiles ou des infos pertinentes, le tout est de mettre en place les bon filtres.

22 mars 2011

BreizhCamp, c'est parti


Il y avait le BreizhJUG, et ses soirées Java.
Il y avait AgileRennes, et ses soirées agiles.
Il y avait alt.Net, et ses rencontres .Net
Il y avait Rennes-on-Rails, et ses rencontres Ruby.
Il y avait le club .Net-ouest, et ses sujets .Net
Il y avait aussi les Flex-istes, Python-istes, PHP-istes, JavaScript-istes, pas spécialement structurés mais bien présents

Maintenant, il y a le BreizhCamp, une rencontre "par des techos, pour des techos", inter communautés. Une journée complète de conférence, 4 tracks sur des sujets d'actualité, 27 sessions par des speakers de tous horizons.

Les inscriptions ne sont pas encore ouvertes, et le programme pas encore finalisé, mais préparez vous pour rafler l'une des 200 places disponibles.

C'est le 17 juin, toutes les infos sur www.breizhcamp.org