D'abord, si vous pensez qu'Agile est nouveau, détrompez vous ! Le manifeste Agile a été signé en 2001 par un groupe de professionnels qui ont une réputation internationale. Tiré de l'article Agile manifesto sur Wikipédia :
"En février 2001, aux États-Unis, dix-sept spécialistes du développement logiciel se sont réunis pour débattre du thème unificateur de leurs méthodes respectives, dites méthodes agiles. Les plus connus d'entre eux étaient Ward Cunningham l'inventeur du Wiki via WikiWikiWeb, Kent Beck, père de l'extreme programming et cofondateur de JUnit, Ken Schwaber et Jeff Sutherland, fondateurs de Scrum, Jim Highsmith, prônant l'ASD, Alistair Cockburn pour la méthode Crystal clear, Martin Fowler et Dave Thomas ainsi qu'Arie van Bennekum pour DSDM (Dynamic System Development Method), la version anglais du RAD (développement rapide d'applications)."
(Je rajouterais ici Robert C. Martin ("Uncle Bob"), père du Clean Code, soit la réingénierie et la réorganisation du code)
Or, de ces 17 experts mondiaux du monde du développement logiciel sont ressorties les règles qui régissent aujourd'hui les méthodologies agiles. Les valeurs ou règles des méthodes agiles encouragent la livraison rapide de fonctionnalités potentiellement livrables, tout en misant sur la qualité du contrôle qualité et du code source produit par l'équipe de développement.
- Les individus et leurs interactions plus que les processus et les outils
- Du logiciel qui fonctionne plus qu'une documentation exhaustive
- La collaboration avec les clients plus que la négociation contractuelle
- L'adaptation au changement plus que le suivi d'un plan
Cette énumération de valeurs des méthodologies agiles signifient que bien qu'il y ait de la valeur dans les de droite, l'agilité favorise les éléments en gras.
Les individus et leurs interactions plus que les processus et les outils
Du logiciel qui fonctionne plus qu'une documentation exhaustive
Vous est-il déjà arrivé de devoir entretenir une documentation complète, et de documenter chaque changement ? Combien de fois vous est-il arrivé de vous retrouver devant une documentation désuette ? L'agilité favorise une documentation minimale, car en bout de ligne, c'est avec un logiciel qui fonctionne que vous voulez travailler ! De plus, bien des gens ne lisent même plus les livres ou les guides utilisateurs, alors à quoi bon faire une documentation complète et doubler le temps requis du développement, alors qu'on peut documenter ce qui est nécessaire, et produire un logiciel qui fonctionne ?
La collaboration avec les clients plus que la négociation contractuelle
Cet élément est extrêment important, selon moi. Et c'est ici que j'ai le plus de difficulté, à faire participer les clients. D'abord, ce point met l'emphase sur une relation de confiance avec le client. Maintenant, je ne dis pas que l'agilité est contre les contrats ! Comprenez-moi bien, on préfère collaborer avec le client, amener le client à travailler avec nous pour la réussite du projet. En ce sens, si le client s'implique, il est en mesure de comprendre ce qui se passe, il est à l'affût des difficultés rencontrées et des directions prises par l'équipe de développement. Et s'il y a des changements à apporter, le client peut les apporter immédiatement, en étant informé de l'évolution des travaux en tout temps. De plus, la collaboration du client signifie également que c'est au client à définir SES priorités ! À partir du moment où le client a bien priorisé les éléments de travail, l'équipe de développement sait où elle s'en va et ce qu'elle doit faire en ordre pour rajouter de la valeur au client. Seul le client sait ce qui est important pour lui. De plus, cela évite de confier la responsabilité importante du développement de votre système informatique à une firme, et de ne plus en entendre parler durant des semaines, et en arriver au point où la moitié du logiciel est à reprendre car il y a eu des malentendus ou des erreurs dans les analyses préalables au développement.
L'adaptation au changement plus que le suivi d'un plan
On le sait, les besoins évoluent. C'est comme ça, on n'y peut rien ! Et comme il peut prendre un certain temps avant de compléter un système de gestion intégré, par exemple, il se peut que le besoin du client change en cours de route. Bien sûr il est important d'avoir un plan, on dira ici les grandes lignes directrices, si on veut. Néanmoins, on encourage ici l'adaptation au changement. Bien que le besoin initial était X, si maintenant il est Y, alors le système doit répondre au besoin Y, car X est périmé, invalide ou dépassé ! Un autre exemple pourrait être que comme client, vous n'êtes pas forcément au courant de tout ce qu'on peut faire en TI, ou encore des limites de certaines technologies. Et en suivant l'évolution du projet, des idées peuvent surgir de votre expérience, ou encore, vous aviez simplement oublié ce faire mention d'un détail qui vous paraissait anodin au départ, et qui au final se révèle crucial pour votre système. Ce détail peut entrainer plusieurs changements. Alors on favorise l'adaptabilité dans le but de répondre à VOTRE besoin, et non le nôtre.
Il existe plusieurs méthodologies dites Agiles comme Scrum et Kanban, pour la gestion et le suivi de projets, le BDD, DDD et le TDD pour le développement et l'écriture de code, et plusieurs autres outils adaptés et développés pour aider les équipes de développement et vous, comme client, à bien suivre les principes et ensemble collaborer pour des systèmes d'information de plus grandes qualité en moins de temps qu'il n'en faut pour le dire !
No comments:
Post a Comment