Les fondamentaux du développement logiciel agile
Le développement logiciel agile est, à l'exception mentionnée ci-dessous, itératif. Une itération est une courte période allant d'un mois à seulement une semaine. D'après mon expérience, la durée moyenne d'une itération selon les équipes varie d'un mois (le standard Scrum) à une semaine, ce que je recommande pour un cycle XP. Je pense que la tendance actuelle est de deux semaines.
Mais je m'éloigne du sujet. L'élément le plus important en Agile, la Conditio sine qua non, la condition nécessaire, le prérequis, ce que tu dois absolument faire, c'est :
L'équipe doit livrer à la fin de chaque itération un logiciel fonctionnel, testé et intégré ; en Scrum, on dirait qu'il doit être « done-done »
Il n'y a pas moyen d'y échapper. Vous ne pouvez pas livrer quelque chose seulement une itération sur deux. Vous ne pouvez pas non plus livrer un logiciel presque terminé pour le corriger ensuite lors de l'itération suivante. N'essayez même pas de vous y soustraire. Vous devez livrer du logiciel.
Une exception
Si vous pensiez trouver ici un moyen d'y échapper, vous vous êtes trompé. La seule exception à la livraison de logiciels fonctionnels à chaque itération est de livrer encore plus souvent. Certaines équipes de pointe travaillent actuellement dans une sorte de mode Kanban, où elles livrent essentiellement des fonctionnalités en continu, généralement tous les quelques jours.
Désolé, il n'y a pas moyen d'y échapper
Un logiciel réel, fonctionnel, intégré, testé, vraiment terminé – et ce à chaque itération, ou tout simplement en permanence. En chemin, tu devras apprendre ce que tout cela signifie, et tu rencontreras certainement des difficultés. Mais tu remarqueras aussi que « done » signifie bien plus que tu ne le pensais. Bien sûr, cela inclut aussi le mode d'emploi. Bien sûr, cela inclut aussi la formation des utilisateurs. Bien sûr, cela inclut tout ce que tu pensais impossible.
Personne n'est parfait
Votre équipe n'est pas parfaite et n'arrivera probablement pas à accomplir tout cela à chaque itération. Ce que vous devriez absolument faire cependant, si vous avez encore une marge de progression, c'est quelque chose qu'on appelle « Inspect & Adapt » en Scrum. Kent Beck l'a formulé ainsi un jour : « Trouve ton plus gros problème, résous-le à la manière XP, et recommence. »
Si vous avez besoin d'aide, n'hésitez pas à la demander.
Et maintenant, commencez à livrer ce logiciel !
Ce texte provient du blog de Ron Jeffries et a été traduit par nos soins.
