Après l'entrée en matière que j'ai faite ici, c'est plus facile de décrire les méthodes agiles.
Ces méthodes sont nées des problèmes récurrents des projets informatiques :
- résistance aux changements de direction
- dérapages de délai
- dérapages de coût
Elles se sont organisées et affinées surtout par la pratique depuis plus de 10 ans et se propagent petit à petit à coup de bon sens et d'efficacité.
On peut les présenter justement à travers ces problèmes qu'elles ont voulu résoudre.
Je prends ci-dessous l'exemple d'une création de produit web, mais ces méthodes collent à tous types de projet.
1. Le plus simple pour rester ouvert aux évolutions, c'est d'admettre dès le début qu'on changera d'avis souvent.
L'agilité part du principe que le client ne sait pas ce qu'il veut.
Evidemmnent ça fait sourire mais la réalité n'est pas loin : vous ne savez pas ce que vous voudrez la semaine prochaine. Une rencontre, un changement de budget, de stratégie, un nouveau client... Faites le test, vous verrez que votre besoin ne sera pas exactement le même dans une semaine que ce qu'il est aujourd'hui.
Dans ces conditions, est-ce donc bien utile de charger vos développeurs comme des mules pour deux ou trois mois de boulot ?
Ca y est, même si ce n'est pas souvent expliqué comme ça, vous avez compris le premier intérêt des méthodes agiles : caler l'horizon de travail des développeurs sur la visibilité du responsable produit.
Attention !
Ca ne veut pas dire qu'on peut changer d'avis tout le temps.
Ca ne veut pas dire non plus qu'on n'a pas besoin de savoir en permanence plus ou moins où on va à long terme.
Ca veut dire en revanche qu'on découpe son projet en plein de petits morceaux, et qu'on se donne la peine de décider dans quel ordre on va en avoir besoin. L'exercice fonctionne bien quand on se demande ce qu'on ferait réellement avec 2000 € maxi, puis 5000€ maxi, etc.
Ces petits morceaux, on les appelle des user stories, par exemple "le user s'inscrit sur le site avec son email".
Pour les user stories à livrer la semaine prochaine, c'est trop tard pour changer d'avis ! pour les suivantes, changez un peu tout ce que voulez, c'est le but.
2. Le plus simple pour éviter un retard monstre au bout de 6 mois, c'est d'être livré toutes les semaines de quelque chose qui marche.
Disons tous les 15 jours maxi, vous avez entre les mains un vrai produit. Sûrement incomplet, mais il tourne, vous pouvez le montrer et le confronter à la vraie vie.
Cette période courte, on appelle ça le plus souvent un sprint.
Ca tombe bien, comme vous avez priorisé les user stories, vous avez donc très vite entre les mains les fonctionnalités clefs à montrer à vos clients pilotes.
Croyez-moi, un vrai morceau de produit qui tourne, ça vaut 20 comités de pilotage à la sauce "si si rassurez-vous, on gère".
3. Le plus simple pour éviter d'exploser le budget, c'est d'avoir en permanence la possibilté d'arrêter là et que ça ne soit pas un drame.
Ce produit tourne, il fait déjà la toute petite partie vitale de votre service, et même si il est incomplet vous avez déjà beaucoup de choses à en apprendre.
Vous êtes en position de force pour choisir le tempo de réalisation et donc le tempo des dépenses. Vous pouvez faire une pause le temps d'y voir plus clair sur votre produit ou votre financement, de recruter une équipe pour continuer en interne, etc.
Voilà pour les grandes lignes, si il faut en retenir moins de 10 mots, retenez l'agilité comme ça :
=> Livrer du concret. Livrer vite, régulièrement. Accepter le changement.
Dans les posts suivants je rentrerai dans le détail de ces méthodes, les différentes écoles, la théorie, les difficultés possibles quand on les met en place, les dangers de la "fausse agilité", etc