par Ghislain Lévesque, professeur, Département d’informatique, UQAM
Contact : Levesque.Ghislain@uqam.ca
Les processus agiles sont reconnus aujourd’hui pour assurer une meilleure adaptation aux changements requis dans l’environnement de travail. Par ailleurs, la documentation des exigences est souvent un processus plus formalisé dont l’objectif principal est de saisir le degré de complexité d’un système et d’un projet au début du processus de développement.
Est-il réaliste de penser que la définition des exigences puisse alors se faire selon un processus itératif et partiel? Voilà la question à laquelle ont tenté de répondre deux chercheurs américains (Cao et Ramesh, 2008 ) en investiguant 7 pratiques de collecte des exigences considérées agiles dans 16 organisations différentes. Nous allons d’abord tenter d’expliciter ces pratiques et ensuite d’en identifier les bénéfices potentiels et les défis qu’elles posent, prenant pour acquis que chacune de ces pratiques est fondée sur une plus grande participation des clients aux processus.
En conclusion, les chercheurs se sont demandés dans quelle mesure ces pratiques étaient suivies. Les résultats obtenus démontrent ce qui suit :
|
Les pratiques d’exigences agiles |
Une description des pratiques |
| 1- Face à face Client – Ingénieurs des exigences | Privilégie les rencontres aux spécifications écrites, les scénarios utilisateurs de haut niveau, la présence régulière de clients conseillers |
| 2- Approches itératives initiées avec des exigences de haut niveau qui se précisent lors de chaque cycle | Développement d’une vision globale des aspects et caractéristiques critiques dans un environnement jugé volatil, inconnu et à découvrir. À chaque cycle, le design amène à préciser les exigences et des hypothèses d’implantation |
| 3- Choix des exigences priorisés à l’extrême | Tendance à prioriser au départ et à chaque cycle les exigences qui ont le plus de valeur d’affaires au lieu d’une seule fois dans un projet; Les autres facteurs comme les risques techniques, les coûts et difficultés d’implantation sont souvent négligés |
| 4- Accommodation aux changements par une planification constante | L’ouverture aux changements d’exigences à chaque cycle amène à discuter plus en profondeur chacun des besoins, à les réviser suite aux tests à la fin d’un cycle et, de ce fait, limite le nombre de changements majeurs par la suite ou entre les cycles. |
| -5 Le prototypage | La réalisation d’un prototype opérationnel livré aux utilisateurs de façon itérative permet de répondre rapidement aux attentes et de déployer l’application dans Internet même si elle n’est pas encore robuste. |
| 6- Exigences centrées tests (test-driven development) | Il s’agit de formuler des exigences selon un gabarit de spécifications qui inclut des exemples de cas types valides et invalides à tester |
| 7- Revue des exigences pour validation et tests d’acceptation | À la fin de chaque cycle, une revue implique les clients, développeurs et le personnel d’assurance qualité (AQ) et parfois des tests d’acceptation sont déposés. |
–
Les pratiques d’exigences agiles
1-Face à face Client – Ingénieur des exigences
-
Leurs bénéfices
Les clients peuvent explorer des directions nouvelles au gré des changements ou de leur compréhension de la solution logicielle;
La communication informelle remplace la documentation et les processus d’approbation.
-
Leurs défis
Le succès dépend grandement de la qualité des communications entre les clients et les développeurs et du degré de consensus atteints entre les groupes clients impliqués. Tout est fondé sur le niveau de confiance réciproque qui s’établit.
2-Approches itératives initiées avec des exigences de haut niveau qui se précisent lors de chaque cycle
-
Leurs bénéfices
Permet d’explorer des voies nouvelles quand le client ne sait pas trop dans quelle direction aller; permet d’arriver à mieux expliciter des exigences floues au départ en assurant une meilleure présence du client.
-
Leurs défis
L’établissement d’une cédule et d’un budget de projet est impossible au début tant que l’étendue du projet n’est pas précisée; le fait de minimiser la documentation exige en environnement de travail stable client développeur sinon c’est la catastrophe; les exigences non fonctionnelles sont trop longtemps ignorées causant souvent de gros ennuis à la fin des projets.
3-Choix des exigences priorisés à l’extrême
-
Leurs bénéfices
Une meilleure compréhension des besoins du client entraîne une réponse plus satisfaisante à leurs besoins. Le processus agile en soi encourage la révision des priorités contrairement aux approches traditionnelles.
-
Leurs défis
Le fait de tout prioriser en fonction de la valeur (time to market) peut amener à négliger la sécurité, l’efficacité, le changement d’échelle et résulter en de sérieux problèmes d’opération et d’instabilité.
4-Accommodation aux changements par une planification constante
-
Leurs bénéfices
Cette ouverture aux changements change complètement l’approche par rapport à la gestion des exigences traditionnelle.
-
Leurs défis
Des problèmes d’architecture peuvent être rencontrés à la suite de changements fréquents, ce qui peut être coûteux ; peut rendre le « refactoring » ou le besoin de réécriture du code plus fréquent.
5-Le prototypage
-
Leurs bénéfices
Élimine les coûts associés à la préparation de la documentation; permet d’obtenir un feedback rapide des clients sur leurs exigences
-
Leurs défis
La tendance à déployer des prototypes non matures cause de lourds problèmes de sécurité, robustesse, et d’échelle; Elle laisse aussi croire aux clients qu’ils n’ont pas à prendre le risque de déliais plus longs pour une meilleure qualité.
6-Exigences centrées tests (test-driven development)
-
Leurs bénéfices
Plus facile d’expérimenter et de tester véritablement l’exigence et le comportement du système
-
Leurs défis
Exige beaucoup de discipline des développeurs puisque les tests ne sont pas toujours préparés avant le codage; exige le raffinement des exigences de bas niveaux avec lesquelles les clients sont souvent peu familiers.
7- Revue des exigences pour validation et tests d’acceptation
-
Leurs bénéfices
Cette rencontre permet de mettre les pendules à l’heure et d’améliorer la confiance entre les clients et l’équipe de développement.
-
Leurs défis
Mets l’emphase sur la validation des exigences mais néglige souvent les aspects liés à la vérification formelle parce qu’il n’y a pas de modèles détaillés disponibles; les tests d’acceptation reposent souvent sur la contribution du personnel d’AQ.
En conclusion, les chercheurs se sont demandés dans quelle mesure ces pratiques étaient suivies. Les résultats obtenus démontrent ce qui suit :
a- toutes les organisations consultées (au nombre de 16) se sont classées dans la catégorie élevées et moyennes pour les pratiques qu’elles appliquent;
b- cependant, ce ne sont pas toutes les organisations qui rencontrent les défis identifiés;
c- presque toutes les organisations ont rapportées que leur principal défi est celui d’avoir accès aux clients et d’obtenir des consensus entre les différents groupes;
d- la pratique des « exigences centrées tests » est la moins employée (seulement 6 entreprises) à cause du fait que les développeurs ne sont pas habitués à la discipline qu’elle requiert;
e- de façon surprenante, même si le prototypage est une pratique bien établie, au moins un tiers des entreprises ne la pratique pas;
f- enfin la pratique des revues contrairement aux attentes était courante dans les 16 organisations.
La pratique des exigences agiles se fait principalement dans les organisations où il s’avère impossible de développer au départ des exigences claires, appropriées et complètes. En se concentrant sur le sujet à chaque itération, les participants à l’étude ont indiqué que c’est la communication intense entre le client et les développeurs qui s’avère être la pratique la plus fructueuse et la plus dynamique. En plus de se préoccuper des défis identifiés, les organisations qui s’y intéressent feraient bien de se préoccuper aussi des coûts et bénéfices que ces pratiques entraînent
Référence : Cau Lan et B. Ramesh, 2008, IEEE Software, January/February. P. 60-67
