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.