Retour d’expérience #3 : Agilité & intégration

janvier 29th, 2009 · 4 Comments ·

Après Flex et les extensions Firefox, nous voici dans un tout autre domaine, celui de l’organisation (de pearltrees).

Présentation du développement agile

« Agile software development » ou « Développement en méthode agile », est une méthodologie de développement logiciel apparu à la fin des années 90 ‘. Elle se définie bien souvent par cette liste de 12 grands principes. A noter qu’il existe en réalité autant de variantes que d’entreprises qui l’implémentent. Ceci s’explique sûrement par le dernier principe:

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

C’est à dire qu’à chaque itération (ou « release »), les processus de travail sont affinés. On distingue néanmoins une certaine constance dans les valeurs suivantes :

  • L’équipe (« Personnes et interaction plutôt que processus et outils ») : Dans l’optique agile, l’équipe est bien plus importante que les moyens matériels ou les procédures. Il est préférable d’avoir une équipe soudée et qui communique composée de développeurs moyens plutôt qu’une équipe composée d’individualistes, même brillants. La communication est une notion fondamentale.

  • L’application (« Logiciel fonctionnel plutôt que documentation complète ») : Il est vital que l’application fonctionne. Le reste, et notamment la documentation technique, est secondaire, même si une documentation succincte et précise est utile comme moyen de communication. La documentation représente une charge de travail importante, mais peut pourtant être néfaste si elle n’est pas à jour. Il est préférable de commenter abondamment le code lui-même, et surtout de transférer les compétences au sein de l’équipe (on en revient à l’importance de la communication).

  • La collaboration (« Collaboration avec le client plutôt que négociation de contrat ») : Le client doit être impliqué dans le développement. On ne peut se contenter de négocier un contrat au début du projet, puis de négliger les demandes du client. Le client doit collaborer avec l’équipe et fournir un feed-back continu sur l’adaptation du logiciel à ses attentes.

  • L’acceptation du changement (« Réagir au changement plutôt que suivre un plan ») : La planification initiale et la structure du logiciel doivent être flexibles afin de permettre l’évolution de la demande du client tout au long du projet. Les premières releases du logiciel vont souvent provoquer des demandes d’évolution.

Pour une entreprise BtoC comme la notre, en période de développement produit, les clients sont bien évidemment nos utilisateurs.

Même si il existe des valeurs communes, chaque entreprise est libre d’adapter les recommandations du manifeste, Pearltrees ne fait pas exception, et je dirais même que nous sommes allé encore plus loin.

Une construction agile de l’entreprise.

L’agilité, que nous appelons plus communément « intégration », est présente depuis les premiers jours de pearltrees. Les 5 documents fondateurs de l’entreprise ont été écrits de manière récursive, chaque document influençant les autres. Le microcycle d’itération était alors d’une semaine.

Ces documents continuent leur vie depuis maintenant 1 an et sont d’ailleurs toujours revues chaque semaine. Le document marketing s’enrichit d’un plan commercial, le document financier prépare une prochaine levée de fonds, le document produit fait le point sur des dernières fonctionnalités à implémenter. Certains documents en sont à leur 44ème itération.

L’agilité au jour le jour

Vous l’aurez compris, l’agilité est une histoire d’équipe. L’intégration commence dès 9h30 le matin avec un morning meeting de 15 minutes. Il permet à chacun de communiquer sur ses actions du jour et éventuellement démarrer directement avec l’intégration d’une problématique « marque », « produit » ou « design ».

Pour chaque fonctionnalité il existe un document de travail (« brief »), qui n’est pas un cahier des charges mais simplement 1 ou 2 slides présentant les objectifs et les grands traits de cette fonctionnalité. Tous les détails, toutes les spécifications, sont intégrées quasiment en « live » et sont d’ailleurs modifiées plusieurs fois en cours de route. On passe son temps à jeter du code et à en réécrire.

Une méthodologie particulièrement bien adaptée au web

Pourquoi l’agilité est-elle bien adaptée au web ? Vous êtes tenté de dire. Bah ouai, normal, le web 2.0, la beta perpétuelle, tout ça, tout ça, …

Et bien nom, si l’agilité est tant bénéfique aux start-up webs c’est qu’elle est un facteur déterminant pour souder une équipe. Le web est une industrie bouillonnante qui de part sa nature est composée de métiers et de personnalités très différentes. Peu de points communs entre le e-marketer portant un badge ben & jerry’s, le développeur-chercheur-mathématicien-presque-fou, le designer peintre et photographe, le directeur financier qui pense que cet article trop long est une perte de temps pour l’entreprise, ou l’ingénieur de production qui balance des 10ènes de milliers de requête sur un pauvre server qui lui a rien fait du tout… L’agilité permet à toutes ces personnes de travailler ensemble, comprendre en profondeur les autres métiers de l’entreprise, et obtenir au final, un produit fini, synthèse des contraintes de chacun.

La vraie valeur de l’agilité n’est finalement pas de pouvoir livrer une nouvelle version chaque mois, mais plutôt ce que cela implique en terme d’intégration et de culture d’entreprise.

Tags: pearltrees


4 responses so far ↓

  • Magnifique article Nicolas !
    Merci d’avoir partagé ton schéma d’orga, c’est très enrichissant.

    Petite question : le morning meeting est il vraiment efficace sur le fond (i.e. est ce que cela a des réelles incidences sur le travail au quotidien) ou est ce un moyen – simple à mettre en place – de fédérer l’équipe ?
    15 min ca me semble court pour rentrer dans le détail …

    Concernant les remarques, seul point noir identifié : « un e-marketer avec un badge ben & jerry’s « ? no way ! (tu aurais parlé d’un badge amazon.com, je m’inclinais par contre… 😉

  • Il dure 15 minutes car nous sommes maintenant relativement rodés. Il prenait un peu plus de temps au début. C’est aussi un outil pour fédérer l’équipe, mais ce n’est pas sa vocation principale. Comme je le disais c’est un bon moyen pour préparer des points de synchronisation, et c’est aussi un excellent outil pour détecter en amont les problèmes. Tout problème bloquant peut être identifié en 24h. En tout cas l’objectif n’est surtout pas de rentrer dans le détail.

    By the way, dans l’article je n’ai fait que survoler notre organisation, nous avons mis en place beaucoup d’autres outils, ça sera sûrement le sujet d’un prochain article.

  • Vous dites : « Il est préférable de commenter abondamment le code lui-même, »

    Dans les méthodes agiles, il n’est pas conseiller de mettre des commentaires dans le code car ces derniers ne sont jamais mis à jour. Un bon nommage des mathodes, classes et variables est obligatoire, et est la sources du code commenté, d’une autre façon. Un autre type de commentaire : les tests U : en effet, ces dernier sont là également pour aider à la compréhension du code. Eux sont fiables, car ils reflètent toujours le code existant !

  • @fmottet
    Je suis entièrement d’accord avec toi. J’ai fait un copié / collé de wikipedia (honte à moi) et il s’avère en effet que les commentaires sont très difficilement maintenable dans un code agile.

    Merci pour la rectification.