Gestion de projet – Vers les méthodes agiles
94
comprise), chaque « passage de relais » entre les différents intervenants risque de
dénaturer le besoin exprimé. Pour des raisons d’interprétation possible, de subjectivité, d’absence de clarification ou encore de non-disponibilité du client, le résultat
peut être tout à fait différent.
2. La traçabilité est nécessaire.
Comment attribuer un besoin à un propriétaire ?
Sur un grand projet, notamment, le recueil des besoins peut impliquer de nombreux
interlocuteurs ; l’association besoin/propriétaire est utile pour la clarification, la
confrontation entre plusieurs besoins et la validation.
Comment s’assurer que tous les besoins sont traités ?
« Noyé » dans un paragraphe, dans un volumineux document de plusieurs dizaines
voire centaines de pages, le besoin peut être oublié ; un document linéaire ne facilite
pas, non plus, la visibilité sur les liens ou les dépendances entre besoins exprimés à
des pages différentes. Comment mesurer l’impact d’un changement sur les autres
besoins exprimés ?
Comment suivre le cycle de transformation de chaque besoin ?
Il est essentiel de savoir où en est le traitement d’un besoin et de pouvoir rapprocher
celui-ci des classes correspondantes, par exemple, ou encore de s’assurer que chaque
besoin fait bien l’objet d’un scénario de test.
Puisque les besoins évoluent, veut-on conserver l’historique des modifications ?
Dans un contexte classique, basé sur un mode relationnel contractuel entre client et
équipe de réalisation, il pourra s’avérer utile de savoir qui est à l’origine du changement, quand le changement est intervenu, et pour quelles raisons. Dans le cadre d’un
projet faisant intervenir de nombreux acteurs, il peut se révéler utile d’informer
toutes les parties prenantes des changements survenus. Doit-on alors rédiger une
nouvelle version du cahier des charges initial ?
Dans une approche agile, la traçabilité est simplifiée ; en effet, les cycles de développement sont raccourcis, le lien entre le besoin initial et la fonctionnalité livrée est
rapidement établi ; la fonctionnalité livrée au client constitue ensuite elle-même le
support de discussion. La formalisation est minimale et éphémère, puisque celle-ci
n’est pas nécessairement conservée une fois le besoin traité et satisfait (voir ci-après,
l’approche par les user stories).
Disposer d’un référentiel et d’un langage communs entre les différentes parties prenantes
du projet apparaît nécessaire pour formaliser les besoins. Ce référentiel prendra des
formes différentes selon l’approche retenue : base d’exigences, cas d’utilisation, liste de
besoins grossiers ou détaillés. On privilégiera le langage de l’utilisateur, orienté autour
des besoins et des fonctionnalités – c’est-à-dire le « quoi » –, le jargon technique – qui
définit, lui, le « comment » –, étant réservé à l’équipe de réalisation.
GestProjInform Livre Page 94 Vendredi, 3. avril 2009 12:07 12
94
comprise), chaque « passage de relais » entre les différents intervenants risque de
dénaturer le besoin exprimé. Pour des raisons d’interprétation possible, de subjectivité, d’absence de clarification ou encore de non-disponibilité du client, le résultat
peut être tout à fait différent.
2. La traçabilité est nécessaire.
Comment attribuer un besoin à un propriétaire ?
Sur un grand projet, notamment, le recueil des besoins peut impliquer de nombreux
interlocuteurs ; l’association besoin/propriétaire est utile pour la clarification, la
confrontation entre plusieurs besoins et la validation.
Comment s’assurer que tous les besoins sont traités ?
« Noyé » dans un paragraphe, dans un volumineux document de plusieurs dizaines
voire centaines de pages, le besoin peut être oublié ; un document linéaire ne facilite
pas, non plus, la visibilité sur les liens ou les dépendances entre besoins exprimés à
des pages différentes. Comment mesurer l’impact d’un changement sur les autres
besoins exprimés ?
Comment suivre le cycle de transformation de chaque besoin ?
Il est essentiel de savoir où en est le traitement d’un besoin et de pouvoir rapprocher
celui-ci des classes correspondantes, par exemple, ou encore de s’assurer que chaque
besoin fait bien l’objet d’un scénario de test.
Puisque les besoins évoluent, veut-on conserver l’historique des modifications ?
Dans un contexte classique, basé sur un mode relationnel contractuel entre client et
équipe de réalisation, il pourra s’avérer utile de savoir qui est à l’origine du changement, quand le changement est intervenu, et pour quelles raisons. Dans le cadre d’un
projet faisant intervenir de nombreux acteurs, il peut se révéler utile d’informer
toutes les parties prenantes des changements survenus. Doit-on alors rédiger une
nouvelle version du cahier des charges initial ?
Dans une approche agile, la traçabilité est simplifiée ; en effet, les cycles de développement sont raccourcis, le lien entre le besoin initial et la fonctionnalité livrée est
rapidement établi ; la fonctionnalité livrée au client constitue ensuite elle-même le
support de discussion. La formalisation est minimale et éphémère, puisque celle-ci
n’est pas nécessairement conservée une fois le besoin traité et satisfait (voir ci-après,
l’approche par les user stories).
Disposer d’un référentiel et d’un langage communs entre les différentes parties prenantes
du projet apparaît nécessaire pour formaliser les besoins. Ce référentiel prendra des
formes différentes selon l’approche retenue : base d’exigences, cas d’utilisation, liste de
besoins grossiers ou détaillés. On privilégiera le langage de l’utilisateur, orienté autour
des besoins et des fonctionnalités – c’est-à-dire le « quoi » –, le jargon technique – qui
définit, lui, le « comment » –, étant réservé à l’équipe de réalisation.
GestProjInform Livre Page 94 Vendredi, 3. avril 2009 12:07 12