Gestion de projet – Vers les méthodes agiles
48
L’acceptation du changement
Embrace change, dit Kent Beck, l’un des « pères » du mouvement agile… « Accueillez
le changement à bras ouverts » plutôt que de le craindre et de le combattre.
On sait que nombre de paramètres sont imprévisibles lors d’un projet ; il s’agit alors de
mieux contrôler cette imprévisibilité sans la nier en voulant être systématiquement
conforme aux plans initiaux rapidement obsolètes.
On échappera, de fait, aux gaspillages de temps et d’énergie et aux frustrations qui en
résultent, constatés sur les projets qui ne peuvent admettre le changement : temps
(souvent conséquent) consacré à l’élaboration du planning, temps dédié à l’analyse des
écarts, efforts fournis pour rattraper le retard, temps accordé à la négociation et au refus
des changements, temps affecté à remobiliser l’équipe…
Une équipe agile se dote de pratiques et d’outils lui facilitant l’accueil du changement.
Peut-on vraiment montrer et livrer quelque chose au client à une telle fréquence ? (suite)
Le découpage facilite également le travail des développeurs. Plutôt que de gérer à la fin
tous les problèmes tels que les bogues, la montée en charge, l’ergonomie, l’installation ou
l’adéquation avec le métier, ils ont l’opportunité de trouver des solutions petit à petit et de
les valider au plus tôt.
Cependant, il est vrai que c’est parfois un challenge technique que de parvenir à livrer des
modules indépendants fonctionnellement et techniquement. Il faut alors penser nos applications comme un ensemble de services indépendants, capables de collaborer (façon SOA), soit
comme un ensemble de plug-ins (façon Eclipse). Cette dernière solution est une approche
facilitée par les dernières avancées techniques.
3) La réponse de l’expert Dominic Williams, coach XP.
Oui, les équipes avec lesquelles j’ai pratiqué XP étaient réellement capables de livrer aux utilisateurs une nouvelle version chaque semaine, et il ne s’agit pas de cas isolés.
Pour y arriver, le premier ingrédient est d’éliminer du processus toutes les files d’attentes et
passages de relais. Il faut une équipe polyvalente et autonome. Chaque membre de l’équipe
doit être capable de tout faire et l’équipe ne doit pas dépendre d’une autre équipe, par exemple
pour faire les tests.
Le deuxième ingrédient est l’automatisation. Tout ce qui est répétitif doit être automatisé :
compilation, installation, exécution des tests, mesure du temps passé par tâche, etc.
Enfin, il faut avoir des gens à qui livrer et prêts à tenir le même rythme. Un maître d’ouvrage
disponible et consciencieux peut faire l’affaire, mais la véritable agilité consiste à court-circuiter
cet intermédiaire et livrer directement aux utilisateurs. Certains sont impatients d’avoir les
dernières nouveautés et prêts à changer leurs habitudes de travail. Dans d’autres cas, il faut
prévoir, par exemple, d’introduire les nouveautés de façon optionnelle.
GestProjInform Livre Page 48 Vendredi, 3. avril 2009 12:07 12
48
L’acceptation du changement
Embrace change, dit Kent Beck, l’un des « pères » du mouvement agile… « Accueillez
le changement à bras ouverts » plutôt que de le craindre et de le combattre.
On sait que nombre de paramètres sont imprévisibles lors d’un projet ; il s’agit alors de
mieux contrôler cette imprévisibilité sans la nier en voulant être systématiquement
conforme aux plans initiaux rapidement obsolètes.
On échappera, de fait, aux gaspillages de temps et d’énergie et aux frustrations qui en
résultent, constatés sur les projets qui ne peuvent admettre le changement : temps
(souvent conséquent) consacré à l’élaboration du planning, temps dédié à l’analyse des
écarts, efforts fournis pour rattraper le retard, temps accordé à la négociation et au refus
des changements, temps affecté à remobiliser l’équipe…
Une équipe agile se dote de pratiques et d’outils lui facilitant l’accueil du changement.
Peut-on vraiment montrer et livrer quelque chose au client à une telle fréquence ? (suite)
Le découpage facilite également le travail des développeurs. Plutôt que de gérer à la fin
tous les problèmes tels que les bogues, la montée en charge, l’ergonomie, l’installation ou
l’adéquation avec le métier, ils ont l’opportunité de trouver des solutions petit à petit et de
les valider au plus tôt.
Cependant, il est vrai que c’est parfois un challenge technique que de parvenir à livrer des
modules indépendants fonctionnellement et techniquement. Il faut alors penser nos applications comme un ensemble de services indépendants, capables de collaborer (façon SOA), soit
comme un ensemble de plug-ins (façon Eclipse). Cette dernière solution est une approche
facilitée par les dernières avancées techniques.
3) La réponse de l’expert Dominic Williams, coach XP.
Oui, les équipes avec lesquelles j’ai pratiqué XP étaient réellement capables de livrer aux utilisateurs une nouvelle version chaque semaine, et il ne s’agit pas de cas isolés.
Pour y arriver, le premier ingrédient est d’éliminer du processus toutes les files d’attentes et
passages de relais. Il faut une équipe polyvalente et autonome. Chaque membre de l’équipe
doit être capable de tout faire et l’équipe ne doit pas dépendre d’une autre équipe, par exemple
pour faire les tests.
Le deuxième ingrédient est l’automatisation. Tout ce qui est répétitif doit être automatisé :
compilation, installation, exécution des tests, mesure du temps passé par tâche, etc.
Enfin, il faut avoir des gens à qui livrer et prêts à tenir le même rythme. Un maître d’ouvrage
disponible et consciencieux peut faire l’affaire, mais la véritable agilité consiste à court-circuiter
cet intermédiaire et livrer directement aux utilisateurs. Certains sont impatients d’avoir les
dernières nouveautés et prêts à changer leurs habitudes de travail. Dans d’autres cas, il faut
prévoir, par exemple, d’introduire les nouveautés de façon optionnelle.
GestProjInform Livre Page 48 Vendredi, 3. avril 2009 12:07 12