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...)
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.
