27 février 2007

Communiquer : le choix des mots

Je suis amené, dans le cadre de ma mission en cours, à présenter
l'avancement du projet à un panel de managers.

Certains aspects du projet sont préoccupants, dans les deux sens
du terme :
- étymologique : je préfère m'en occuper "en avance de phase"
- tout simplement "problématiques".

Habituellement, je communiquai ces aspects sous forme de
"risques", en précisant bien que certaines stratégies de gestion
de projet sont très prophylactiques (voir en particulier :
http://agile.thierrycros.net/docs/agileRisques.pdf )

Or, le terme "risque" est souvent perçu négativement : il y a
des risques donc "ça va mal" alors qu'en fait, il s'agit bien au
contraire d'être proactif, dans une véritable gestion des
risques.

J'utilise aussi l'expression point de vigilance qui offre une
connotation plus positive : une certaine configuration du projet
mérite notre vigilance. Notez que nous parlons de la même chose
: la gestion d'un risque passe par la mise en place d'une
surveillance, d'une vigilance face aux causes du risque et
également par la mise en place d'actions de diminution du
risque.

Je relatai cet exemple simplement pour pointer du doigt
l'importance de notre langage, de notre terminologie dans la
sphère professionnelle. Sans être naïf, inconséquent, utiliser
un terme plus positif ou tout simplement neutre est très
important car il donne une couleur plus efficace aux échanges,
aux réunions.

Autrement dit, le même sujet est traité, dans une ambiance
plus confortable et positive, donc pertinente.


Happy Modeling & Extreme Programming.

17 février 2007

Feedback concret et rapide


Il n'est pas facile de mettre en oeuvre XP voire même l'Agile, tant les visions, les perceptions, de ce qu'est un développement de logiciel sont encore marquées par une compréhension simpliste du cycle en V.

La question est alors : quelle est tout de même la prochaine étape vers l'Agile, à la fois ambitieuse et accessible ?

J'interviens actuellement sur un projet qui est sensé suivre ce type de cycle de vie :
  • Spécifications
  • Réalisation
  • Tests de recette
  • Mise en production.
Inutile de dire que l'effet tunnel inhérent à cette approche - plusieurs mois de réalisation sans aucun retour concret - ne me satisfait pas. Comment être agile sur ce projet ?

Que faire ?

Quels sont les principes "agiles" qui semblent le plus nécessaires et/ou réalisables ?
En partant d'une modélisation qui "voit" l'activité de développement, le projet, comme un système, l'élément crucial est alors le feedback.

Qu'est-ce qu'un feedback concret et rapide ?
Un feedback est un retour d'information : il peut être spontané ou bien demandé, formalisé, géré. Au delà d'une apparence libertaire, XP formalise très rigoureusement de nombreux feedbacks : résultats des tests unitaires, stand-up meetings, résultats des tests-client, etc.
Ce retour d'information est sensé nous permettre de nous forger une opinion sur le déroulement du projet et, par là, de nous aider à décider. Actions, choix... autant de décisions qui sont alors rendues pertinentes grâce au feedback préalable (voir aussi l'aspect graphique dans ma présentation de l'Extreme Programming).

Feedback concret et rapide. Un principe sous-jacent au cycle habituel est qu'une documentation fournit par elle-même un feedback : "si ce document est produit, alors le projet est dans tel état d'avancement". Or, de nombreux facteurs, à commencer par la "spécification molle" rendent ce principe arbitraire, infondé, voire inopportun.

Un feedback concret est un feedback de l'application elle-même, donné aux utilisateurs. Injecter des intermédiaires : personnes (chef de projet, analystes...) et/ou d'autres livrables (documents) rend le feedback de moins en moins valable.

Un feedback est rapide (sachant qu'il est aussi concret) lorsqu'il intervient au plus vite après la production de ce qui est l'objet du feedback. Autrement dit, si l'équipe développe une fonctionnalité demandée semaine 9, le feedback devrait intervenir semaine 9, 10 ou semaine 11. Ainsi, les équipiers ont encore en tête les éléments constitutifs du produit testé et leur intervention de mise au point est alors plus efficace.

En pratique
Il s'agit donc de créer les conditions d'un feedback rapide et concret. Quelles sont les questions ?
Tout d'abord, préciser les pratiques à mettre en place : écriture des tests-client, passage de ces tests, analyse et prise de décision par rapport aux résultats de ces tests.
Ensuite, qui fait quoi ? La MOA - utilisateurs - est toute désignée pour conduire ces opérations, dans le cadre d'une collaboration avec les développeurs.
Enfin, quel est le rythme ? Il me semble qu'un rythme basé sur :
  • des tests "permanents" autrement dit, tester dès qu'une fonctionnalité est programmée,
  • dans un cadre itératif incrémental centré sur des itérations de 2 semaines à un mois
est un excellent cadre pour un feedback concret et rapide.

Le mieux étant l'ennemi du bien, il convient alors de faire la part des choses. Sur le principe, découper une "longue" phase de réalisation en plusieurs itérations est déjà une avancée significative. Attention, il s'agit de bien comprendre quelle est l'unité de travail. Dans un cadre XP, c'est la user story qui joue naturellement ce rôle. Dans un cadre plus classique, ce sont les exigences qui prennent le relai.
Autre point important : jouer sur la notion de "fin d'une réalisation". Trop souvent, le développement d'une fonctionnalité est réputé terminé lorsque le développeur a saisi le dernier point-virgule de la dernière instruction. Ici, une fonctionnalité est terminée lorsque le client, qui s'appuie sur les résultats de ses tests, le décide, pas avant.
Enfin, si votre MOA rechigne parfois à écrire des tests... aidez-là.

Ce qui est fait
Nous mettons donc en place des itérations d'un mois. Il se trouve que l'environnement de développement et le domaine sont parfaitement adaptés à une découpe en fonctionnalité "courtes". Ce sont des aspects du logiciel (les droits d'accès, les éléments structurants...) qui sont traités lors d'ateliers et qui donnent lieu à un ensemble de spécifications, de tests-clients, d'implémentation et de passages de tests.


En conclusion...
Vous souhaitez être agile ? Interrogez-vous : comment pouvez-vous mettre en oeuvre un feedback concret et rapide sur vos projets ?

photo : plage du Diamant, Martinique (Thierry Cros)