Affichage des articles dont le libellé est agilité. Afficher tous les articles
Affichage des articles dont le libellé est agilité. Afficher tous les articles

06 novembre 2012

BreizhCamp 2013, "WAR-RAOK"

L'an dernier, à la même période, je bloggais un appel à volontaire pour m'aider à organiser le breizhcamp.

J'ai porté quasiment seul la première édition de cette conférence, profitant d'une période charnière dans ma vie professionelle qui me laissait pas mal de temps libre - comprenez, ma démission d'Orange. L'exercice est enrichissant et très formateur, mais particulièrement éprouvant. Disons qu'il faut avoir les reins solides pour prolonger ce mode de fonctionnement.




Pour la seconde édition, j'ai voulu m'entourer de lieutenants, chacun se chargeant d'un "silo" et me soulageant de ce poids. Avantage pour moi : garder le contrôle dans le role du "dictateur". Inconvénient, lorsqu'un lieutenant ne peut pas assurer pour diverses raisons, je suis seul apte à venir jouer les pompiers, ayant une vision globale de l'organisation. Au final, entre les contraintes de chacun, je me suis retrouvé à gérer bien plus de choses que prévu. Par ailleurs, difficile de motiver les gens si on ne leur laisse pas voix au chapitre.



C'est ainsi qu'en octobre, après un démarrage en cacahuète pour la rentrée du BreizhJug, j'ai du annoncer à contre coeur à mes camarades que je ne pourrais pas assurer un nouveau breizhcamp. 

Heureusement, pour l'un de ces silos j'avais eu le plaisir de recruter Guillaume Collic, une figure de l'écosystème Agile Rennais. Il nous a donc proposé de mettre un peu d'agilité dans notre organisation, laissant les casquettes tourner et les responsabilités se répartir au sein d'une équipe pluri-disciplinaire.


Sur le modèle bien rodé d'Agile Tour, BreizhCamp est donc en train de se convertir en Conférence Agile, portée par une équipe sans leader-dictateur, en fonction des disponibilités de chacun, et en totale transparence. Evidemment, cela suppose beaucoup plus de communication et de synchronisation pour que les casquettes puissent changer de tête, mais on ne part pas non plus dans l'inconnu avec deux éditions réussies du BreizhCamp et l'expérience d'Agile Tour.


Au final, cela me permet de m'investir dans la conférence maintenant que j'ai du temps tout en sachant qu'il y aura du monde pour prendre le relai lorsque j'en aurais moins (JenkinsConf@Paris). Ca m'oblige aussi à tenir compte des avis des autres - ça c'est plus dur :P

L'organisation concrète sera mouvante et est encore à définir (par l'équipe, me souffle guillaume), mais on a déjà un nouveau logo, conçu à quatre mains et adopté à l'unanimité :

(version non définitive)

Dans le même esprit, l'application qui va gérer le call-for-paper est développé par une équipe de volontaires en mode auto-organisé-distribué "carte blanche", avec comme seule contrainte un trello des fonctionnalités donnant les priorités, et avec la liberté de définir leur propres stories techniques pour se faire plaisir. 



Nous avons aussi testé Google Hangout pour notre premier meeting, et poursuivrons avec skype et un simple google docs partagé, ce qui ouvre la porte à des contributeurs non-Rennais. Il s'avère en effet qu'il ya très peu d'actions dans les phases amont de la conférence qui nécessitent d'être physiquement présent à Rennes !



Bref, j'espère être capable de réfréner mes tendances dictatoriales (vous aurez peut être noté dans les couleurs du logo que je n'ai pas lâché sur le orange :P) et que cette expérience sera riche d'enseignements et de fierté pour chacun de nous, avec un troisième BreizhCamp encore plus réussi !


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.

24 octobre 2009

Une nouvelle méthode agile ?

Pour faire face à une liste de tâches anarchique, j’expérimente une méthode agile de mon cru : SCUM.

Issu à l’origine d’une faute de frappe, c’est devenu l’acronyme de SCrum for Unique Member (Scrum appliqué à sois tout seul).

Les mêlées quotidiennes sont faciles à organiser, et en plus c’est rapide. Le simple fait de se demander ce qu’on a fait la veille avant d’attaquer est tout de même pas totalement inutile quelque fois !

Un sprint dure de 2 jours à une semaine. Tout seul c’est tenable :)

Jusqu’ici c’est plus du vent qu’autre chose, alors voici le BACKLOG du sprint, et ses célèbres post-it sur le tableau Veleda. L’intérêt énorme de cet outil c’est :

  • qu’il n’a pas toutes les limitations de nos trackers en tout genre avec leur cycle de gestion pourrie, leurs champs obligatoires et autres complications inutiles.
  • qu’il est dynamique – par définition, un post-it, ça se déplace - et naturellement synthétique

L’air de rien ça permet rapidement de voir où on en est et ce qu’il reste à faire – pour certains ça ferait sans doute peur d’ailleurs, mais ce serait pourtant un bon indicateur !

J’organise donc la “SCUM’Conf 2010”, il reste encore des places pour ceux que ça intéresse :p

08 mars 2008

CI : Hudson vs Continuum

La fondation apache héberge pour ses projets un serveur Continuum ET un serveur Hudson
(http://vmbuild.apache.org/continuum, http://hudson.zones.apache.org/hudson). Continuum étant développé en marge de Maven2, son intégration des projets Maven se doit (dervait?) d'être exemplaire.

Or le serveur Continuum est régulièrement dans les choux. Pas forcément à cause de Continuum bien sur, peut être aussi un peu à cause du serveur HTTP Jetty ou de la "zone" d'hébergement... mais en tout cas une migration sous Hudson est envisagée, au moins à titre expérimental dans un premier temps. Un sérieux revers pour Continuum !

J'utilise moi aussi continnum, tout simplement parce qu'il propose depuis le début la fonction "envoyer un mail à ceux qui on cassé le build", et surtout l'ajout automatique d'un domaine email aux IDs subversion pour identifier les fautifs. Et le rythme de développement d'Hudson est impressionnant !