Application concrète des méthodes agiles

J’ai déjà parlé de plusieurs méthodes de travail sur ce blog, depuis le cycle en cascade jusqu’aux méthodes agiles en passant parle cycle en V et les cycles itératifs. Pour illustrer tout ça, je vais vous parler de la manière dont nous gérons les projets dans mon entreprise.

Le contexte

Pour situer un peu les choses, il est nécessaire que je vous parle un peu de l’entreprise elle-même.

Fine Media est éditeur de sites Web ; ce n’est pas une «web agency», nous sommes notre propre client. L’entreprise a officiellement commencé son activité en septembre 2007, elle existe donc depuis plus de 3 ans et demi. Nous sommes actuellement une trentaine de personnes.

Les deux premières années se sont déroulées dans un climat classique de start-up à la française, dans un joyeux mélange d’élaboration de process, de développements itératifs rapides, de recrutements stratégiques et de bonne humeur. Le cap des deux ans d’existence et de la vingtaine de personne s’est passé naturellement, l’entreprise quittant d’ailleurs à ce moment ses premier locaux (sous les toits et un peu serrés) pour un immeuble plus confortable.

L’équipe technique a évolué lentement mais sûrement. J’ai immédiatement embauché un administrateur système et une infographiste. Au départ, je réalisais l’intégralité des développements. Avec l’arrivée successive de nos développeurs, j’ai pu me recentrer sur les projets cruciaux. Nous avons désormais une équipe constituée d’un administrateur, de trois développeurs, de deux infographistes/intégrateurs et de moi-même (directeur technique). Cela reste une équipe réduite, mais qui représente quand même un quart des effectifs. Le reste de l’entreprise est constitué de référenceurs, de rédacteurs, de community managers, et de commerciaux. Les référenceurs ne sont pas considérés comme faisant partie de l’équipe technique, car ils ont un rôle très transverse, à la fois actif au niveau de la technique et de la rédaction.

Comme je le dis plus haut, nous avons longtemps abordé les développements de la même manière que dans la plupart des start-ups. En privilégiant la réactivité, nous avons réussi à mettre en place des choses relativement complexes dans un laps de temps assez court. Quand il le fallait, j’avais l’autorité nécessaire pour faire des choix structurels, soit pour réclamer plus de stabilité dans les développements, soit pour lancer les refactoring qui s’imposaient.

Ceux qui suivent le blog savent que la fin de l’année dernière a été une période un peu mouvementée, avec un énorme refactoring. En 4 mois, on a remis à plat et recodé l’ensemble de tout ce qu’on avait développé en 4 ans sur notre plate-forme principale. Le problème avec ce genre de situation, c’est qu’il est très difficile d’établir un plan de marche : On a beau tronçonner les projets en tous petits bouts, il reste toujours des zones d’ombre. Les projets développés durant la «période start-up» manquaient évidemment de spécifications, et cela s’est fait sentir le jour où on a voulu lister toutes les fonctionnalités qu’il fallait remettre au propre.
Ces 4 mois de travail ont donc été réalisés sur un mode «best-effort» qui ne peut pas durer très longtemps. Cela consiste à faire de son mieux, donc à se mettre une pression relativement forte en continu, avec les horaires et le stress qui vont de paire. Au final, cela a généré beaucoup de frustrations dans l’entreprise ; chez les informaticiens qui en faisaient beaucoup sans jamais avoir l’impression que c’était suffisant ; chez les «fonctionnels» qui avaient peur que la refonte prenne un retard incommensurable.

Refonte organisationnelle

Une fois cette période passée, le risque était grand de «rester» sur le même rythme de travail… c’est-à-dire sans revenir à de vraies méthodes de travail. Il était donc important de mettre en place une organisation stable.

Continuer la lecture de « Application concrète des méthodes agiles »

Les premiers enseignements de Rework

J’ai déjà parlé plusieurs fois de l’entreprise 37signals, de ses logiciels de gestion de documentation et de projet, et de sa méthode Getting Real. Actuellement, ses membres travaillent au successeur de leur livre, dont le nom sera Rework. Ils ont présenté quelques bribes d’information sur le livre, et je me suis arrêté sur le quatrième de couverture :

Je trouve que le texte qui s’y trouve est très intéressant, un brin controverse, et mérite qu’on s’y attarde. Voici une traduction très libre de son contenu, et ce que j’en pense.

“Dès que possible” est un poison

Il est vrai qu’en entreprise, on rencontre bien souvent ce genre de situation : On essaye de se mettre d’accord sur la spécification d’une nouvelle fonctionnalité, et quand vient le moment d’en définir la date de livraison, on se voit répondre “Dès que possible”. Cela peut sembler la réponse la plus honnête, la plus simple à comprendre de tous et la plus facile à gérer ; mais en fait il s’agit souvent d’un pis-aller qui démontre que le projet n’est pas réellement pris en main.

Quand on demande un développement ASAP (as soon as possible), on abdique sur tous les facteurs qui définissent un projet :

  • La définition exacte du projet n’a pas été faite correctement. On sait bien qu’on n’a pas pris le temps de réfléchir à tous les cas limites, à penser à toutes les situations. On sait − mais on ne le dit pas ouvertement − que les développeurs devront affronter tous ces culs-de-sac fonctionnels au fur et à mesure qu’ils se casseront les dents dessus, ce qui empêche d’apporter une quelconque valeur aux estimations qu’ils peuvent faire de leurs développements.
  • À partir du moment où la seule contrainte exprimée est celle du temps passé sur le projet, on accepte implicitement que des raccourcis soient fait pour atteindre l’objectif au plus vite. Un aspect en pâtira forcément, qu’il s’agisse de la qualité générale de la réalisation, de la maintenabilité du code, des tests, du débuggage, …
  • À l’inverse, l’absence de deadline réaliste autorise les développeurs à se lancer dans des développements inutiles (je ne parle même pas de ceux qui se tournent les pouces). On arrive ainsi à des situations où on découvre au bout de 2 semaines que le développement “ASAP” aurait pu durer 4 jours si on avait pris le temps de dimensionner et budgéter le projet correctement ; mais si on en fait la remarque au(x) développeur(s), on obtient une réponse du genre «Ah, moi j’estime que tout ce que j’ai fait était nécessaire pour que le projet fonctionne correctement. Il fallait me prévenir si c’était plus urgent que ça !».

Continuer la lecture de « Les premiers enseignements de Rework »

La diplomatie au travail

Quand on travaille en équipe, on doit apprendre à gérer les rapports humains. Nous ne sommes pas tous égaux face aux relations humaines. Certaines personnes se sentent à l’aise, d’autre non. Certaines personnes n’hésitent pas à imposer leurs vues, d’autres se mettent en retrait.

L’essentiel est de garder, en toute circonstance, un comportement qui permette de travailler efficacement. Si on peut se faire des amis au boulot, c’est la cerise sur le gâteau ; mais il ne faut pas se faire d’ennemis.

Les désaccords

Il existe un principe fondamental en entreprise : Critiquer les idées, pas les personnes

Quand on n’est pas d’accord avec les propositions de quelqu’un, il semble parfois plus facile de chercher à démolir la personne elle-même, plutôt que d’expliquer en quoi on est en désaccord. Ce n’est pas constructif, et vous attirera les inimitiés de vos confrères.

Continuer la lecture de « La diplomatie au travail »

Les réunions

Ah, les réunions… Suivant l’entreprise dans laquelle vous êtes, vous avez l’impression de ne pas en faire suffisamment ou au contraire d’en faire trop. J’ai connu les deux.

La recette

Voici les éléments-clés d’une réunion :

  • Un ordre du jour. Tous les participants à une réunion doivent savoir quel va en être le sujet. Cela peut être formalisé dans un email, ou être implicite si c’est une réunion qui se répète régulièrement. Mais si quelqu’un ne sait pas quel est le thème de la réunion à laquelle il se rend, pour pouvez vous attendre à une belle perte de temps.
  • Des participants. Oui, ça semble un peu bête. Mais pensez bien que toutes les personnes nécessaires aux prises de décisions doivent être présentes, sinon vous serez bon pour refaire une autre réunion par la suite. Évitez aussi les réunions où est conviée la moitié de l’entreprise « au cas où on aurait besoin d’eux » ; vous risquez surtout d’avoir des discussions sans fin qui s’éloignent du sujet, et des personnes qui perdent leur temps à se demander ce qu’elles font là. Si à un moment donné vous vous rendez compte que vous avez besoin de la présence d’une personne qui n’a pas été conviée, interrompez immédiatement la réunion pour aller chercher cette personne.
  • Des décisions claires. Trop souvent, les gens quittent une réunion parce qu’ils ont l’impression d’avoir fait le tour d’un sujet, ou par épuisement personnel. Il faut que les décisions prises à la fin de la réunion soient claires pour tous les participants. Si certains avis n’ont pas été tranchés, soyez clairs aussi sur cet état de fait, en notant éventuellement les impacts que cela peu avoir, et surtout en vous accordant sur les éléments qui empêchent de prendre la décision. S’il manque une analyse, notez à quelle date elle doit être terminée, et qui en est le responsable ; si la personne qui peut prendre la décision n’était pas présente ou n’a pas pu se décider, prévoyez immédiatement une prochaine réunion.
  • Un compte-rendu. Les décisions peuvent sembler claires en sortant de réunion, il n’en reste pas moins que chacun en gardera les souvenirs qu’il aura bien voulu mémoriser (ou qu’il aura daigné noter sur son cahier). Le seul moyen de s’assurer que la réunion sera suivie des effets prévus, c’est d’en rédiger un bilan qui sera envoyé à tous les participants. Impossible alors de se rétracter derrière le « Ah ? Je ne me souviens pas qu’on ait dit ça en réunion… ».

Continuer la lecture de « Les réunions »