On qualifie souvent
les méthodes agiles de méthodes « légères », en comparaison avec
les
méthodologies classiques qui exigent un formalisme et un outillage « lourds ».
Seulement
quelques livrables à produire, en plus de l’essentiel (les versions
intermédiaires
du produit),
quelques rôles définis, quelques étapes, quelques réunions… et la
démarche est
formalisée.
Une différence
entre les deux approches est essentielle : seuls les éléments clés sont «
prescriptifs
», il y en a
peu mais ils doivent être suivis avec rigueur ; cela entre en opposition avec
les méthodes
classiques pourvues de nombreux points dont aucun n’est réellement suivi
sérieusement.
Des outils,
oui, mais efficaces, à bon escient et réduits au strict nécessaire pour l’automatisation
des tâches
récurrentes, en particulier les tests et l’intégration continue. La
compétence des
ressources et la communication entre elles sont, on vient de le voir,
privilégiées
; par
conséquent, on ne doit pas inutilement doter une équipe d’outils complexes
auxquels elle
devra se former et s’adapter ; il faut des outils qui s’adaptent à la façon de
travailler1, pour supporter la
démarche, mais qui ne sont pas une fin en soi.
Cette légèreté
offre l’avantage de faire évoluer l’organisation, les processus et les outils,
si nécessaire ;
on est bien sur une approche adaptative, on parle même d’approche empirique
: on observe,
on ajuste, on expérimente, on apprend, on corrige… Le processus
agile de départ
est défini au démarrage du projet ; au fur et à mesure, l’équipe découvre
ce qui
fonctionne dans le contexte du projet, soumet à des discussions ce qui ne
fonctionne
pas, améliore
le dispositif, en fonction des spécificités du projet… et ce précisément
grâce à sa simplicité.
0 commentaires:
Enregistrer un commentaire