les choses évoluent très rapidement chez drift. si vite d’ailleurs, que nous-mêmes n’arrivons même plus à nous suivre parfois !
on avait besoin d’un moyen d’améliorer la rapidité de mise en oeuvre des actualisations incrémentales de nos produits. un sprint traditionnel nous prenait environ deux semaines pour pouvoir soumettre une nouveauté en production. on voulait un système qui nous permette de mettre en production des updates plus modestes, en parallèle, et de manière plus incrémentale.
pendant des mois, on a cherché un système plus rapide qu’agile et qui pourrait s’adapter facilement à notre réalité. mais la plupart des frameworks nous a paru trop structuré et n'offrait pas la flexibilité dont nous avions besoin. on a continué à chercher...
après de nombreuses recherches infructueuses, nous avons décidé de créer notre propre méthode de développement qui s’adapterait parfaitement à notre approche orientée client. nous avons retroussé nos manches pour créer le framework dont nous savions qu’il allait répondre parfaitement à nos besoins.
chez drift, nous appelons cette méthode de développement le framework burndown, qui repose essentiellement sur des microsprints et sur la gestion sémantique de version. les microsprints sont des éléments itératifs qui font parti d’une fonctionnalité et qui peuvent être validés indépendamment. la gestion sémantique de version correspond à la nomenclature qui nous permet d’organiser ces micro-envois et les rendre compréhensibles à n’importe quel membre de l’équipe.
si nous allons construire une nouvelle version du tableau de bord client - appelons-le “tableau de bord 2.0.0”, nous avons deux options:
- nous pouvons envoyer la fonctionnalité complète en une fois, après deux semaines de travail, ou…
- nous pouvons envoyer cinq actualisations incrémentales aux clients grâce à des microsprints de 2 jours.
quelle option choisissez-vous? pour nous, l’évidence saute aux yeux: l’option 2 est préférable, et de loin.
pour compléter notre approche via microsprints, nous voulions un moyen de garder une trace de toutes les actualisations. on a introduit le concept de gestion sémantique des versions, un langage commun qui nous a permis de simplifier nos échanges en évitant les erreurs de communication.
(mais soyons honnêtes, après un certain temps de rodage, notre aisance avec cette nouvelle méthode de développement nous a permis de nous passer de la gestion sémantique des versions; en somme, on a enlevé les roulettes du vélo!).
pour concrétiser cette nouvelle approche, nous avons finalement choisi trello, l’outil le mieux adapté à notre framework burndown. on avait besoin de rapidité, de flexibilité (changement de priorisation constant), de releases incrémentales - et trello nous a offert tout ce dont nous avions besoin en ce sens. vérifiez par vous-même.
les microsprints: la solution à vos besoins d’agilité
chaque microsprint est une liste de trello dont le nom est défini par notre système de gestion sémantique de version. ces listes sont réévaluées quotidiennement pour vérifier qu’elles correspondent toujours aux tâches prioritaires du moment.
voici les principes qui guident notre méthode de développement avec le framework burndown et la gestion sémantique de version:
- flexible
- approche orientée client
- itératif
- rapide
- incrémental
- Évolution constante
- data-driven
depuis l’introduction de ces concepts dans les méthodes de développement de l’équipe “produit” de drift, nous avons développé un nombre impressionnant de fonctionnalités en l’espace de quelques mois - toutes ayant directement contribué à accélérer le succès de drift.
notre flux de travail sur trello est orienté de gauche à droite. le plus à gauche, on retrouve les prochaines fonctionnalités à implémenter, tandis qu’à droite, ce sont les projets dont il manque le cahier des charges et qui doivent être mieux définis et attribués à un responsable.
tandis que les listes se déplacent de droite à gauche dans le tableau de bord, elles traversent différentes phases, y compris l’attribution d’un responsable du projet. suivant notre méthode de développement, c’est justement l’endossement du projet par le chef de produit qui constitue l’initialisation du projet.
une fois le cahier des charges du projet défini par l’équipe d’ingénieurs et les designers, la responsabilité de la liste va être transmise à l’équipe de conception produit, qui va transformer les idées en réalité. la conception est réalisée de manière itérative et le projet va être découpé en plusieurs microsprintsts qui peuvent être réalisés indépendamment les uns des autres. ces microsprints pourraient être désignés par “reporting 2.0.0” et “reporting 2.1.0” par exemple.
le designer va communiquer avec les ingénieurs pour réaliser l’implémentation et ces derniers vont prendre le relai. grâce à notre méthode de développement, la gestion sémantique des versions permet de nous assurer que lorsque que nous re-priorisons les tâches au milieu du tableau de bord, il n’y ait pas de confusion dans la séquence des tâches. impossible d’avoir une release de “reporting 2.1.0” avant “reporting 2.0.0” par exemple, ce serait mettre la charrue avant les boeufs!
comment adapter le framework burndown à trello?
certaines caractéristiques de trello le rendent parfait pour cette méthode de développement:
un outil visuel pour un framework visuel
le framework burndown est visuel par essence; les images et les screenshots accompagnement systématiquement le développement des fonctionnalités et servent à communiquer l’information exacte de ce qui doit être fait à chaque release. au sommet de chaque microsprint, nous créons une carte de haut niveau avec un screenshot qui montre exactement le résultat attendu de ce microsprint. tout le monde a accès à ce tableau trello, chaque département peut voir exactement quel sont les prochains éléments du pipeline - secteur commercial, direction marketing, managers, etc.
un maximum de flexibilité - on évite les dépendances en cascade
cette méthode de développement s’adapte parfaitement à trello, où il est très facile de déplacer des tâches et des projets en toute liberté. le framework burndown et les microsprints définissent une méthodologie ultra agile et ultra flexible. on avait besoin d’un outil qui ne nous limite pas lorsque nous souhaitons chambouler les priorités.
dans chaque tableau des équipes de développement de produit, les releases sont spécifiques à des parties distinctes du produit final, ce qui permet aux équipes de travailler en parallèle à l’aide de microsprints sans se bloquer les unes les autres. si l’un des microsprint possède une dépendance vis à vis d’une autre équipe, nous créons un label “dépendance d’une autre équipe” sur la carte trello. l’ingénieur qui travaille sur ce sprint est alors responsable de la collaboration entre les équipes.
en effet, certains outils gèrent les dépendances entre les tâches de sorte qu’un simple déplacement de tâche met rapidement le bazar dans l’ensemble du projet. avec trello, pas d’effet domino du genre “si je déplace ceci, est-ce que je vais avoir une mauvaise surprise et ma timeline va se retrouver sans dessus dessous?”
fonctionnalités utiles comme les labels ou les pièces jointes
trello autorise également l’ajout de pièces jointes et l’intégration des commentaires permet d’avoir de courtes discussions sur chaque microsprint, ce qui le rend très efficace et compatible avec notre méthode de développement.
nous utilisons les étiquettes de manière à mettre en valeur les éléments qui ont encore besoin d’être conçus (étiquette rouge), les tâches bloquées (étiquette orange), et les dépendances liées aux rendus d’autres équipes (étiquette bleu).
adopter trello pour les microsprints et la gestion sémantique de version dans votre équipe de gestion de produit
dans une grande structure organisée suivant des processus déjà très ancrés dans la culture de l’entreprise, il est préférable de faire un test au sein d’une première équipe de gestion de produit (ingénieur / chef de produit / designer).
en organisant les méthodes de développement d’une équipe en respectant le framework burndown, avec des microsprints et la gestion sémantique des versions grâce à trello, vous allez prouver à vous-même, à vos collaborateurs et à vos supérieurs que c’est une méthode efficace et efficiente de concevoir des produits, et vous pourrez envisager le déploiement de ce framework au sein d’autres équipes.
si votre organisation se situe à un stade plus précoce, vous devriez adopter la méthode de microsprints gérés via trello dès le départ, et disséminer ces pratiques dans la culture de l’entreprise.
l’idée est de prévoir deux à trois semaines d’activités à venir (10 à 15 microsprints). nous n’allons pas plus loin afin que notre vision à long terme ne nous empêche pas de nous adapter rapidement aux changements, comme c’est souvent nécessaire dans une startup. chaque ingénieur prend la responsabilité d’une seule carte trello à la fois, et ils sont entièrement responsables de la mise en oeuvre de la fonctionnalité du produit liée à la carte.
voici comment fonctionne notre système de gestion sémantique de version...
n.x.x (major release)
correspond au développement d’une nouvelle branche du produit ou à la refonte complète d’une partie existante.
x.n.x (minor release)
correspond à l’introduction d’une nouvelle fonctionnalité à l’intérieur d’un élément déjà existant.
x.x.n (patch)
quand un élément d’une fonctionnalité est légèrement modifié.
là encore, je rappelle que la gestion sémantique des versions est un peu comme les roulettes du vélo: recommandée au début, on peut s’en passer après 3 ou 4 mois ou lorsque l’équipe est parfaitement à l’aise avec cette méthode de développement.
chez drift, nos équipes de gestion de produit sont divisés suivant les fonctionnalités associées aux différents profils d’utilisateurs, ce qui nous permet de travailler sur l’évolution de plusieurs aspects du produit en parallèle. bien entendu, cela signifie également une organisation du code pour qu’il soit divisé suivant la même logique, afin de ne pas créer de dépendances.
microsprintez pour améliorer la gestion produit
si vos méthodes de développement sont semblables aux nôtres, si vous êtes orienté clients sur toute la chaîne de valeur, les microsprints et la gestion sémantique de version sont deux outils puissants pour créer de nouveaux produits plus rapidement.
aujourd’hui, les solutions de software deviennent des “commodities”, nous avons besoin d’un cadre stratégique d’évolution, et ce dernier pourrait très bien être la rapidité à laquelle vous êtes capable de répondre aux changements du marché et aux nécessités des clients. avec le framework burndown et les microsprints gérés dans un outil comme trello, vous pouvez atteindre un autre niveau en terme de compétitivité grâce à votre flexibilité dans l’adaptation aux changements.
si vous avez la moindre question à propos du burndown, des microsprints et de notre sémantique de version, vous trouverez plus d'informations ici (en anglais). n'héstez pas à me contacter si vous voulez en savoir plus, matt@drift.com ou @mattbilotti sur twitter.
faites-nous part de vos commentaires! retrouvez-nous sur twitter (@trello)!
