De cette citation de Paul Valéry, l’écrivain québécois Gary Klang a tiré un roman en 2005. Déjà, Jules Verne, dans son roman de 1905 « Le phare du bout du monde » explique pourquoi les gardiens de phare étaient toujours trois : si par malheur l’un des gardiens venaient à mourir, ils seraient deux à lui survivre, et il est toujours moins terrible de veiller un mort à deux que tout seul.
Alors, si vous avez à mettre en place un projet d’une charge estimée d’une année-homme, montez une équipe de trois à quatre développeurs, pour une durée de trois à quatre mois. Mais n’imposer pas jamais ce projet à un seul développeur. C’est garanti, à la fin, vous aurez sur la conscience la « mort » du développeur et celle du chef de projet.
Bien entendu, une équipe agile ne sera jamais, par définition du mot « équipe », confrontée à une telle situation tragique. L’agilité, si elle ne garanti pas le succès d’un projet par simple automatisme, garantit au moins la survie des développeurs !
Un développeur seul, aussi doué soit-il, ne pourra jamais assuré un succès à un projet. En effet, le poids du retard ou de l’échec est trop lourd à supporter pour une seule personne. S’il est seul, le développeur cherchera à dissimuler le retard qu’il a pris. Parfois même de la pire des manières, en accumulant les heures supplémentaires, les nuits blanches et les week-ends studieux, au bureau ou chez lui. Lorsque l’on est trois ou quatre dans une équipe, la responsabilité est collective. En cas de retard ou de problème, l’équipe dans son ensemble n’hésitera pas un instant à remonter les problèmes rencontrés, même au sein d’un projet non agile.
De même, de quel soutien externe peut bénéficier un développeur isolé ? Dans une équipe, chacun peut trouver auprès des autres membres une source de motivation, une pression douce pour suivre l’avancée collective. Et en cas de retard de l’un des membres de l’équipe, les autres peuvent se mettre à son niveau pour l’aider à refaire surface. Bon, juste une petite précision ici, c’est effectivement plus aisé à faire dans une équipe agile, où le scrum master est là pour faciliter ce genre de démarche, par l’incitation au travail en binôme ou en trinôme, afin d’optimiser les phases de passages de connaissances et le montant de compétence collective.
A tous les développeurs du monde, si un chef de projet tient à vous mettre sur un projet où vous serez seul, fuyez ! À toutes jambes, sans même vous retourner. N’acceptez jamais ce genre de mission. Sinon, vous signez votre arrêt de mort !
A tous les chefs de projets du monde, si votre boss vous oblige à mettre en place un projet dans lequel vous ne disposerez que d’un seul développeur, fuyez ! À toutes jambes, sans même vous retourner. N’acceptez jamais ce genre de projet. Sinon, vous signez votre arrêt de mort !
Enfin, à tous les bosses du monde, si vous voyez au sein de votre service, de votre compagnie, de votre organisation, un projet ne disposant que d’un seul développeur, arrêtez tout ! Stop ! Sinon, honte à vous ! Car c’est l’arrêt de mort de vos collaborateurs, et sans doute de la votre aussi, que vous signez.
Merci (Peu Importe!) pour cet éclairage différent. Ce témoignage permet d'ouvrir un débat interessant.
Avis à tous pour vos retours d'expérience!
Rédigé par : Frédéric Doillon | jeudi 11 septembre 2008 à 11:38
Bonjour,
Cet avis me semble un peu caricatural. Ca m'est arrivé plusieurs fois de bosser seul comme architecte/développeur sur des projets entre 100 et 200j (avec plusieurs itérations) avec succès et surtout plaisir.
J'apporterais les nuances suivantes :
- ce n'est pas parce qu'un développeur est seul sur un projet qu'il est seul dans l'équipe, il peut toujours échanger avec les autres même si les autres n'auront pas sa vision métier
- le développeur isolé porte peut-être plus de pression, mais aussi une liberté et une motivation supplémentaire avec un défi à la clé. En plus, il maîtrise le projet de bout en bout. Il peut donc être plus productif dans ce contexte.
- certains développeurs sont plus efficaces quand ils travaillent seuls qu'en équipe : pas besoin de reprendre du code d'un autre, pas besoin d'expliquer précisément son travail, ...
Je ne veux pas dire qu'il faut privilégier le travail isolé, loin de là, mais ca ne me semble pas une option à éviter à tout prix, ça dépend du bonhomme.
Le problème me semble plus être du côté de la maintenance du projet par rapport à la dépendance à une seule personne.
Rédigé par : Peu Importe | jeudi 11 septembre 2008 à 10:04