Je viens d’achever la lecture du dernier livre de 37signals : Getting Real (voir à ce sujet mon précédent billet : Le livre ultime du développeur pragmatique).
Mes premières impressions : Wow ! Ils n’y vont pas par 4 chemins et leur approche de la conception d’applications en ligne est… révolutionnaire.
En substance, voici leur méthode de travail :
- pas plus de 3 personnes par équipe (1 concepteur / designeur, 1 développeur, 1 qui encadre les 2 précédents) ;
- ne pas utiliser de spécifications ou cahier des charges (pas assez flexible et apporte plus de contraintes qu’autre chose) ;
- réduire le périmètre fonctionnel à strict minimum (généralement 1 fonctionnalité) ;
- ne plus faire de réunions (c’est sûr qu’à 3 personnes dans le même bureau, ça rime plus à grand chose) ;
- ne plus utiliser de storyboard ou wireframe mais passer directement au prototype…
Plus surprenant encore, leur approche préconise même une organisation contre-nature :
- conserver à tout prix la date de lancement annoncée, quitte à réduire le périmètre fonctionnel ;
- ne pas prendre en compte les demandes d’évolution (du moins dans un premier temps) pour ne pas dévier de l’idée initiale ;
- se concentrer sur une niche d’utilisateurs potentiels…
Même si mes premières réactions étaient plus que mitigées, j’avoue être fortement séduit par ce type d’organisation pour un projet : flexibilité, pragmatisme, rigueur… Quand on voit la qualité de leurs réalisations, on est en droit de se dire que leur approche n’est pas non plus surréaliste.
La question que vous vous posez tous maintenant est la suivante : est-ce valable pour mon projet ?
Ce à quoi je n’ai malheureusement pas de réponse. Si vous souhaitez monter une start-up reposant sur un service en ligne novateur alors pas de doute : c’est cette méthode qu’il vous faut. Par contre, si vous évoluez dans un environnement professionnel plus structuré (en gros 99,99% des cas), si vous subissez une forte contrainte de la part des utilisateurs ou des commanditaires (en gros ceux qui financent le projet) ou si vous devez gérer une équipe disparate (plusieurs personnes de sociétés différentes)… ça devient tout de suite plus délicat.
N’étant pas un spécialiste des méthodes agiles, je laisserais les lecteurs concernés s’exprimer (de préférence APRÈS avoir lu le livre).
Je vous recommande également le billet suivant qui parle de ce livre : Getting Real, notes de lecture. Afin, si vous souhaitez approfondir le sujet, je vous conseille de lire le billet suivant sur le prototypage rapide : Ruby on Rails as rapid prototyping tool.