Mise à jour ; je me renseigne sur l’état des méthodes agiles, domaine qui m’intéresse beaucoup et qui volue vite. Après ces trois mois de pause, je décide de m’intéresser aux progrès fait dans ce domaine. C’est un post qui risque de n’intéresser que mes amis informaticiens, désolé.
(N’hésitez pas à commenter si vous pensez différemment, ce qui est illogique mais pas impossible ;-) )
Le but
Trouver une méthode de développement pour mon prochain projet (un CV en ligne qui démontre par l’exemple mes connaissances en XML et Java).
Le profil idéal
Employer une méthode agile permet principalement d’éviter une trop longue période de planification avant d’entrer dans la phase de réalisation. Une planification trop longue rend en effet le projet difficile à modifier après coups.
Une telle méthode touche de nombreux points de l’organisation et de la planification du travail. Une grande partie concerne souvent la collaboration entre les différents protagonistes. Dans mon cas, ce n’est pas très important car je travaillerai seul, je recherche donc une méthode ’’Agile’’, centrée sur la planification est les méthodes/moyens de développement. L’eXtrême Programming (Derrière ce nom pompeux se cachent la méthode agile la plus pratiquée aujourd’hui) par exemple semble trop axée sur la collaboration pour qu’il soit vraiment intéressant de l’utiliser dans ce cadre même si les scénarios et l’approche itérative sont alléchants.
Le processus itératif
Un Processus itératif constitue le principal atout de ce mode de fonctionnement Il permet un contrôle plus précis car plus fréquent de l’état d’avancement du projet et de la qualité du produit. Il permet souvent d’obtenir une version utilisable du logiciel bien avant un processus linéaire ou en “V”. L’utilisation d’une méthode itérative est toutefois appliquée presque universellement aujourd’hui, même dans les méthodologies les plus rigides, du moins, celles qui sont toujours employées.
’’La tendance des méthodes agiles est de procéder par itération les plus courtes possible.’‘
Différentes méthodes
XP
XP begins with four values: Communication, Feedback, Simplicity, and Courage. It then builds up to a dozen practices which XP projects should follow. Many of these practices are old, tried and tested techniques, yet often forgotten by many, including most planned processes. As well as resurrecting these techniques, XP weaves them into a synergistic whole where each one is reinforced by the others.
http://www.martinfowler.com/articles/newMethodology.html
XP met en avant le travail d’équipe, le partage de la connaissance et la qualité de la réalisation. Il s’agit donc d’une méthode principalement centrée sur le facteur humain, ce qui est super en équipe, moins en solitaire.
Crystal
Méthode également orientée sur le côté humain, elle diffère de l’eXtrême Programming par sa discipline, moins exigente. Basée sur les méthodes les moins méthodologiques, Alistair, le concepteur, en dit que si Crystal est moins productif que XP, un plus grand nombre de personnes a les capacités de l’appliquer.
Open Source
Cette méthode est utilisée plus ou moins inconsciemment (aujourd’hui de moins en moins inconsciemment) par la communauté Open Source. Elles est assez peu intéressante dans le cadre d’un projet concernant un nombre réduit de protagonistes, en voici un célèbre résumé : The Cathedral and the Bazar Observer également l’icône franc-maçon du plus mauvais goût dans la barre d’adresse…
Adaptive Software Développement
Cette méthode se base sur des conseils plus que sur des règles strictes, elle met en avant une communication maximum et l’apprentissage afin de résoudre les problèmes lorsqu’ils surviennent. Basé sur la théorie du chaos, il s’agit plus d’une philosophie que de solutions pratiques.
SCRUM
SCRUM tourne avec des itérations de trente jours, appelée “Sprint”. Au début de l’itération, une liste de fonctionnalité à implémenter durant le sprint est fixée. Tout le monde se réuni chaque jour pour une réunion (appelée SCRUM) de quinze minutes. Sans aller plus loin, je pense qu’XP est plus radical, plus intéressant.
FDD (Feature Driven Developement)
Cela me parait être un bon compromis entre une méthode en “V” et une méthode agile en entreprise. Le projet et découpé en cinq processus. Les trois premiers se déroulent une fois en début de projet :
- Développement d’un modèle global
- Concevoir une liste des fonctionnalités
- Faire une planification par fonctionnalités
Les deux derniers processus se répètent à chaque itération :
- Concevoir une fonctionnalité
- Réaliser une fonctionnalité
Chaque processus est ensuite décomposé en tâches. C’est une méthode qui apparaît comme intéressante mais il s’agit peut-être également de la moins innovante, elle semble donc plus facile d’accès.
D’autres méthodes existent encore, mais elles paraissent plus cher, car propriétaire, ou moins intéressante. Sans compter celle que j’ai sûrement loupé.
Manifeste pour le développement Agile de logiciels
Ces méthodes sont finalement très proches les unes des autres, c’est pourquoi ce manifeste à vu le jour. Il rassemble les points essentiels et communs à toutes les méthodes précitées.
ne serais-ce que pour la terrible photo en fond de d'écran. La question étant, le filtre mosaïque de Photoshop (voir de GIMP) est-il la meilleure façon de la rendre historique ? (Il s'agit plutôt d'un mélange en fait, dont un filtre aquarelle.)
Voici une traduction des quatre points édictés par les gourous de la méthode agile :
- l’individu et l’interaction priment sur le processus et les outils
- un programme qui marche est plus important que de la documentions compréhensive
- la collaboration entre le prestataire et le client est préféré à une négociation de contrat
- savoir répondre au changement plutôt que de suivre un plan
Context Driven Testing, un autre point de vue
Cette méthode assez récente présente un concept original, non pas que cela soit incompatible avec les premières méthodes (certaines utilisent ce principe), mais qu’elle se focalise sur un autre aspect du développement. Il s’agit de développer une batterie de test qui validera le bon fonctionnement du programme. Un énorme avantage de cet outil dans l’approche itérative, c’est que l’on ne risque pas de perdre des fonctionnalités en cours de route. Les tests pouvant tous être refait en quelques secondes, il est facile de valider tout le travail déjà effectué à nouveau.
Je pense que ce système peut apporter un plus à mon prochain développement, je vais donc la mettre en pratique.
Le point important et novateur consiste à écrire les tests avant le programme. Il s’agit le plus souvent de testes unitaire qui vérifient le fonctionnement de la plus petite partie possible d’un programme.
Le développement par l’exemple
Proche des tests unitaires, il s’agit plus d’une méthode de planification, toutefois à court terme. Cela permet de parler en terme simple avec le client. Plutôt que de décrire une fonctionnalité en termes abstraits, on décrit un exemple d’utilisation concret. Le but est ensuite de reproduire l’exemple avec le logiciel. Une idée proche des scénarios proposés par XP en réalité. Il s’agit d’un principe intéressant dans un processus itératif, puisque l’on ne cherche pas à faire tout, tout de suite.
On s’assure que l’exemple est rempli généralement par des tests unitaires.
C’est un concept que j’appliquerai car, si je ne suis pas convaincu, ce projet de petite taille constitue une bonne occasion d’essayer.
En conclusion
Pas de grande innovation pour aujourd’hui, toutefois les tests unitaires et le concept ’’test before you code’’ semblent se généraliser. Le problème du contrat, le fait de ne pas pouvoir garantir un prix au départ, constitue toutefois encore une barrière dans un marché ou il faut deviser avant d’obtenir le mandat.
J’espère pouvoir compléter cet article par des informations plus ciblées sur les tests unitaires prochainement.
Liens :
Recent Comments