Abonnez-vous au fil RSS du Lablogatoire

LABLOGATOIRE


Archive pour le mot-clef ‘scrum’

homard

Si DuProprio était un homard, il changerait de carapace aux deux semaines. La croissance est rapide et comporte conséquemment son lot de périls. Il y a plusieurs débats — sains, comme tous les débats — à l’interne sur l’impact des méthodes de travail et des structures mises en place. Cette organisation survient par la force des choses, afin de naviguer dans la complexité grandissante. Dans l’équipe de développement, on s’interroge entre autre de l’impact de la méthodologie scrum sur quelque chose qu’il est convenu d’appeler innovation. Mais au fait, qu’est-ce que ce buzz-word signifie? Voici ce que j’en pense.

Tout d’abord, innovation pour moi n’est pas synonyme des expressions suivantes:

  • Différent
  • Créativité
  • Spontanéité
  • Originalité
  • Technologie
  • Quelque chose qui fait qu’on parle de vous sur Branchez-vous.
  • Quelque chose qui provoque une envie folle de développer une fonctionnalité plus pressante qu’une envie de tourista.
  • Juste nouveau.

En fait oui, l’innovation est quelque chose de nouveau. Nouveau est une condition nécessaire mais non suffisante pour décrire une innovation.  Pour moi, l’impact de l’innovation fait partie de sa définition. Non seulement la méthode doit être nouvelle, mais les bénéfices qu’elle procure aussi.  Les innovations admirables sont celles qui impactent positivement beaucoup de personnes. Les innovations itératives sont intéressantes, mais celles qui perturbent l’ordre établi sont splendides. Quelques exemples d’innovations perturbatrices dans différents domaines sont:

  • Le transistor - Un tout petit bloc à la base de la révolution de l’information. Tous voyaient l’intérêt des ordinateurs, ces machines à calculer. Mais l’arrivée du transistor, cheap et compact, a permis le déploiement à grande échelle d’une force de calcul dans les objets qui nous entourent.
  • Le iPod - Un objet qui redéfinit carrément la façon dont on consomme notre musique.
  • Amazon - Un site qui permet de trouver à peu près n’importe quel livre sur n’importe quel domaine.

Évidemment, il y a des milliers d’autres exemples. Le point que je veux faire ressortir de ces exemples est que, dans tous les cas, l’innovation n’est pas survenue sur le coin d’une table. Certains flashs ont sûrement été inclus dans l’élaboration des ces technologies ou entreprises. Cependant, ça prend une direction claire. Je suis à peu près certain que Steve Jobs et ses acolytes n’arrivaient pas avec une nouvelle fonctionnalité à toutes les deux semaines durant le développement du iPod. Si ça avait été le cas, ils auraient aboutis sur le Zune. De la même manière, Bezos et son équipe se concentrent sur ce qui ne change pas pour avoir une évolution totalement focusée qui a transformée le visage de leur industrie.

Les spécificités du web, mythes ou réalités?

“Oui mais sur le web, on peut itérer tant qu’on veut, on n’est pas obligé de tout planifier.” D’accord, le web est réellement unique pour ça. Encore faut-il être capable d’itérer en ce sens que la base sur laquelle on bâtit doit pouvoir grandir. Par ailleurs, il faut savoir dans quelle direction itérer pour ne pas se retrouver après des années de développement avec un amalgame de fonctionnalités plus ou moins bien alignées et utilisées. Et c’est pour tout ça qu’on changera de nouveau de carapace dans les prochains mois. L’évolution se poursuit, avec l’ambition que le résultat colle à ma définition d’innovation.

[photo: fchosson sur flickr]

Ça y est, l’équipe de dev de DuProprio vient d’accoucher de la nouvelle version du site de location. Devant le chaos qui avait accompagné le développement des différents projets toute l’année dernière (du type tout est encore plus prioritaire que ce qui est prioritaire), j’ai été séduit par la sirène de la méthode agile. Armé du livre Scrum and XP from the Trenches sugéré par Nicolas de chez Wanted, on a mis sur le feu le premier projet à être réalisé à la sauce agile chez DuProprio.

La méthode agile est très simple conceptuellement. On peut l’aborder de différents angles, selon la nature de nos projets. Les grandes lignes de comment on s’y est pris:

  • Deux équipes — Chez DP, on doit vivre avec le fait qu’il y a aura toujours des cheveux qui arrivent sur la soupe (bugs, campagnes de pub à intégrer, opportunité à saisir, etc.) Réaliser en parallèle des projets et régler des problèmes courts termes, ça devient très étourdissant et très peu productif. On a donc séparé l’équipe en deux,  une pour les affaires courants, l’autre qui peut se concentrer sur le sprint.
  • Basecamp — Cette application web est utilisée pour centraliser les échanges et gérer les échéanciers, colliger les choses à faire. Dans le cadre du scrum, on s’en est servi seulement pour discuter et logger les heures (pour comptabilité). Les développeurs ont aussi séparé les grandes tâches en to-do plus digestibles.
  • MindmapMindomo a été utilisé au départ pour la planification, discuter avec la direction des priorités et de ce qui allait être inclus dans le sprint. C’est une façon très visuelle et intuitive d’avoir une vue d’ensemble et de changer l’ordre durant la planification. Au départ, les objectifs d’affaires ont été discutés. Les programmeurs ont pu repartir de ça pour traduire en actions techniques.
  • Gros tableau — Avec des aimants dans une salle. Sur chaque aimant une tâche assez macro (1/2 à 5 jours)
  • Planning poker - Pour estimer la durée de chaque action au départ.

Globalement, l’expérience a été positive. Ce que j’aime de l’approche:

  • Focus sur l’essentiel — On a tous la même maladie de bouillonite cervicale. C’est bon la créativité, mais à un moment il faut canaliser. Une fois le but clairement établi (dans ce cas-ci c’était de simplifier au maximum), toutes les discussions divergentes peuvent se régler. C’est vrai autant dans les discussions avec la direction qu’au sein de l’équipe de dev. Comme le temps de projet est fini, on coupe court aux solutions fonctionnelles et on se débarrasse de ce qui, au fond, ne compte pas vraiment.
  • Prise en charge par l’équipe — Ceux qui ont travaillé avec moi savent que je ne suis pas du type à mettre de la pression, pour le meilleur et pour le pire. La beauté de la méthode agile, c’est que toute l’équipe prend possession du projet. Les estimés sont effectués de façon démocratique au départ, puis on se voit une fois par jour. Tout le monde est autonome mais a des comptes à rendre le lendemain matin à toute l’équipe.
  • L’effet démo — Tout sprint se termine par une démo à qui veut bien la voir dans l’entreprise. C’est un aspect qui semble anodin mais qui est d’une subtile puissance. Ça m’a toujours irrité de voir comment on se force pour des comptes à rendre à l’externe mais qu’on est moins rigoureux envers nous-mêmes. Avec une démo, on se trouve à extérioriser le reste de l’entreprise et ça motive à faire quelque chose de fonctionnel à temps. C’est aussi valorisant pour l’équipe de dev, et très positif de passer l’information horizontalement dans l’entreprise.
  • Partage des connaissances — L’idée de la méthode agile, c’est que tout le monde devrait être capable de tout faire. Pour que le projet avance, certains doivent quitter leur zone de confort et en apprendre des autres. À long terme, je crois que c’est très positifs pour une organisation.

Comme n’importe quelle première expérience, il y a des choses qu’on aurait aimé faire autrement, mais on ne le sait pas tant qu’on ne l’a pas fait. Ce qui a été plus difficile:

  • N’importe qui ayant construit ou rénové une maison sait que la finition est toujours plus longue que le rough. Au début, on peut avoir le mirage qu’on avance vite alors que ce n’est pas le cas. Il y a pleins de détails qu’on n’a pas su prévoir et qui ont causé des retards.
  • Dans le même ordre d’idée, comme tout est inter relié, j’ai trouvé difficile de définir ce qu’on peut considérer comme “terminé”.
  • On aurait aussi dû séparer le travail en action un peu plus courtes. Plus les durées sont longues, plus l’incertitude grandit. 3 jours devrait être maximal.

Utilisez-vous ces méthodes dans votre organisation? L’utilisez-vous à autre chose que pour de la programmation? Je suis curieux de connaitre vos expériences ou conseils.