L'agilité en solitaire, c'est difficile 1/2

February 03, 2011

Le constat est malheureusement pessimiste, l’agilité en solitaire, c’est difficile!

Frédéric Doillon va même plus loin et affirme:

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 !

Je ne suis pas tout à fait d’accord. Il est facile de comprendre que scrum est à proscrire dans un projet en solitaire. Scrum est le terme anglais signifiant mêlée, notamment au rugby. Faire une mêlée tout seul ça n’a pas de sens. D’ailleur l’expression « équipe scrum » est plus souvent utilisée que le terme scrum lui même. Et jusqu’à preuve du contraire, une équipe ça se compose au minimum de deux individus. Une équipe scrum est composé d’au moins trois personnes: un ScrumMaster, un product owner et un développeur. Appliquer l’agilité en solitaire sous entend que je représente ces trois personnes en même temps. A part si je suis atteins d’une double schizophrénie (que les médecins ne m’en veuillent pas, je fais l’amalgame entre double personnalité & schizophrénie) il est difficile pour moi de jouer tous ces rôles en même temps. Pour ma part, je n’ai pas pu refuser ce genre de mission, et j’ai du faire avec, m’adapter ! Ma première idée à la suite de l’article de Frédéric Doillon était de faire jouer le rôle de Scrum Master par mon chargé de projet, et le product owner par le client. Je devais impliquer au mieux le client dans le processus de développement. J’ai vite compris que ce n’est pas aussi facile que ça ! Souvent, et ce fut mon cas, le client ne veut qu’un intermédiaire (chef de projet). Il pense gagner du temps. Je me retrouve donc avec un seul acteur pour construire mon équipe agile: le chargé de projet. Moi j’ai de la chance, mes idées farfelues d’appliquer l’agilité sont passées comme une lettre à la poste. Mon chef de projet a accepté de jouer le rôle de product owner. Mais ce n’est pas vrai pour tout le monde. J’ai réalisé moi même mon backlog produit et je me suis tourné vers mon product owner pour prioriser mes taches. Je n’ai pas utilisé de planning poker, mais c’est une idée que j’ai envisagée.

Couplé à cette méthode, j’utilise aussi d’autres pratiques tirées d’XP. Par exemple je travaille en sprint d’une semaine (5 jours). La durée de mon projet étant de 50 jours. J’ai toujours un logiciel qui fonctionne (intégration continue). J’utilise le développement piloté par les tests. Et comme le dit très bien Fabien Bezagu, je n’ai pas à demander pour utiliser TDD.

Les développeurs n’ont jamais demandé la permission d’utiliser un debugger. Pourquoi devraient-ils demander le droit de faire du TDD?

Néanmoins, c’est la seule méthode que j’applique vraiment en solo, car je ne peux pas binômer, je n’utilise pas non plus d’autres outils comme kanban ou les burndown chart et je ne fais pas de rétrospective pour moi tout seul. Par contre je promets d’essayer d’autres idées d’XP avant la fin du projet.

Par Guillaume Vincent