Gestion de projet – Vers les méthodes agiles
192
Une équipe agile se caractérise, en plus, par des pratiques spécifiques. XP, par exemple,
propose un ensemble de pratiques destinées à favoriser l’émergence de la collaboration
au sein de l’équipe :
• La métaphore : il s’agit d’utiliser des termes imagés pour décrire le produit qui doit
être développé pour éviter un jargon technique énigmatique pour certains, par exemple
le facilities management pour expliquer un serveur d’applications ou encore le pizza
guy pour Corba (voir http://chiefmetaphorofficer.blogspot.com/).
• La programmation en binôme (pair programming) : le principe est de faire travailler deux
développeurs ensemble sur un même poste de travail. L’un contrôle le clavier, l’autre
effectue une relecture en temps réel ou propose des solutions alternatives, mais les
rôles (et les binômes, d’ailleurs, au sein d’une équipe) sont interchangeables.
Ça coûte cher, le pair programming !
1) La réponse de l’expert Régis Medina, consultant indépendant spécialisé dans l’accélération
des projets de développement.
À première vue, on pourrait effectivement penser qu’avec deux personnes par machine le
projet coûte deux fois plus cher. Cela dit, je pense que l’on peut avoir une vision un peu plus
réaliste de la situation en réalisant que ce qui prend du temps sur un projet, ce n’est pas de
taper le code au clavier mais plutôt de savoir ce qu’il faut écrire !
En pratique, le surcoût apparent du binôme est largement compensé par le fait que celui-ci
dispose d’une plus grande puissance de frappe, en raison d’une sorte de « vision stéréo » qui
lui fait appréhender le problème de manière plus large, avec davantage d’expérience et d’idées
différentes. On voit par exemple beaucoup moins de cas où un développeur reste bloqué sur
un problème pendant plusieurs jours, ou bien met en place des solutions exotiques qui se
révéleront difficiles à maintenir par la suite. D’une manière générale, j’ai observé que le travail
était bien mieux fini, éliminant des tâches ultérieures de correction ou de nettoyage.
Il faut également garder à l’esprit le fait que chaque binôme prend en charge des activités
traditionnellement réalisées en début ou en fin de projet : spécification détaillée (échanges
avec le client), conception (remaniement) et validation (tests automatiques). Au final, les pratiques XP étant tellement dépendantes les unes des autres, il me semble dangereux de considérer le coût de cette pratique isolément. Je pense qu’il vaut mieux considérer l’efficacité du
processus dans son ensemble – et mon expérience me fait dire que le gain est réel.
Par contre, je n’irai pas jusqu’à dire que le travail en binôme est automatiquement rentable. Il
ne suffit pas d’asseoir deux développeurs côte à côte pour les voir immédiatement fonctionner
efficacement ensemble ! Il faut voir le travail en binôme comme une compétence spécifique,
qui s’apprend et se travaille. Il faut également en tenir compte au moment où l’on forme
l’équipe, en s’assurant que les développeurs pourront s’entendre suffisamment.
2) La réponse de l’expert Pascal Pratmarty, consultant indépendant et ingénieur expérimenté
en développement logiciel.
Développer un logiciel est complexe et l'unicité de chaque projet rend improbable toute véritable automatisation. À cette complexité nous pouvons opposer un large spectre de réponses.
GestProjInform Livre Page 192 Vendredi, 3. avril 2009 12:07 12
192
Une équipe agile se caractérise, en plus, par des pratiques spécifiques. XP, par exemple,
propose un ensemble de pratiques destinées à favoriser l’émergence de la collaboration
au sein de l’équipe :
• La métaphore : il s’agit d’utiliser des termes imagés pour décrire le produit qui doit
être développé pour éviter un jargon technique énigmatique pour certains, par exemple
le facilities management pour expliquer un serveur d’applications ou encore le pizza
guy pour Corba (voir http://chiefmetaphorofficer.blogspot.com/).
• La programmation en binôme (pair programming) : le principe est de faire travailler deux
développeurs ensemble sur un même poste de travail. L’un contrôle le clavier, l’autre
effectue une relecture en temps réel ou propose des solutions alternatives, mais les
rôles (et les binômes, d’ailleurs, au sein d’une équipe) sont interchangeables.
Ça coûte cher, le pair programming !
1) La réponse de l’expert Régis Medina, consultant indépendant spécialisé dans l’accélération
des projets de développement.
À première vue, on pourrait effectivement penser qu’avec deux personnes par machine le
projet coûte deux fois plus cher. Cela dit, je pense que l’on peut avoir une vision un peu plus
réaliste de la situation en réalisant que ce qui prend du temps sur un projet, ce n’est pas de
taper le code au clavier mais plutôt de savoir ce qu’il faut écrire !
En pratique, le surcoût apparent du binôme est largement compensé par le fait que celui-ci
dispose d’une plus grande puissance de frappe, en raison d’une sorte de « vision stéréo » qui
lui fait appréhender le problème de manière plus large, avec davantage d’expérience et d’idées
différentes. On voit par exemple beaucoup moins de cas où un développeur reste bloqué sur
un problème pendant plusieurs jours, ou bien met en place des solutions exotiques qui se
révéleront difficiles à maintenir par la suite. D’une manière générale, j’ai observé que le travail
était bien mieux fini, éliminant des tâches ultérieures de correction ou de nettoyage.
Il faut également garder à l’esprit le fait que chaque binôme prend en charge des activités
traditionnellement réalisées en début ou en fin de projet : spécification détaillée (échanges
avec le client), conception (remaniement) et validation (tests automatiques). Au final, les pratiques XP étant tellement dépendantes les unes des autres, il me semble dangereux de considérer le coût de cette pratique isolément. Je pense qu’il vaut mieux considérer l’efficacité du
processus dans son ensemble – et mon expérience me fait dire que le gain est réel.
Par contre, je n’irai pas jusqu’à dire que le travail en binôme est automatiquement rentable. Il
ne suffit pas d’asseoir deux développeurs côte à côte pour les voir immédiatement fonctionner
efficacement ensemble ! Il faut voir le travail en binôme comme une compétence spécifique,
qui s’apprend et se travaille. Il faut également en tenir compte au moment où l’on forme
l’équipe, en s’assurant que les développeurs pourront s’entendre suffisamment.
2) La réponse de l’expert Pascal Pratmarty, consultant indépendant et ingénieur expérimenté
en développement logiciel.
Développer un logiciel est complexe et l'unicité de chaque projet rend improbable toute véritable automatisation. À cette complexité nous pouvons opposer un large spectre de réponses.
GestProjInform Livre Page 192 Vendredi, 3. avril 2009 12:07 12