Avec le temps, nous tentons de réduire au maximum le délai des mises en ligne de notre plateforme, et donc d'en augmenter la fréquence dans une année. Nous en sommes actuellement à environ 1 version tous les 2-3 mois, et nous ressentons les bien-faits de cet effort. On pourrait descendre en-dessous de la barre des 2 mois, c'est du moins, notre objectif.
Quelles avantages nous tirons de cette méthode de déploiements avec de courtes itérations, quelques retours ayant une valeur ajoutée bien réelle :
- en 2 mois, les fonctionnalités sont plus réduites que si on mettait une version tous les 6 mois : qui dit moins fonctionnalités, dit moins de bugs, c'est imparable,
- comme il y a moins de fonctionnalités, c'est plus rapide et moins rébarbatif à recetter, la version est de fait plus stable (même si on a toujours notre lot de petits soucis à chaque livraison),
- à chaque version, on a un retour de remarques, commentaires des utilisateurs (si, si, ça arrive), on a le moyen de corriger le tir le cas échéant dans un relativement court délai (on peut donner une réponse
dans la prochaine version, environ dans 2 mois
, et c'est toujours mieux que dans 6, 10 mois...sic), - à chaque release, un effort est fourni pour refactorer l'existant : soit simplification de code, revue, voire refonte : cela correspond à des chantiers techniques, qu'il faudra recetter. C'est moins stressant de le faire avec des mises en ligne courtes dans le temps, le refactoring étant parfois délicat,
- nous prenons des apprentis d'une école (BAC+5), et l'alternance est 2 mois à l'entreprise, 2 mois à l'école. Cette contrainte nous oblige à repenser la manière dont les projets sont développés et mis en ligne : là encore, de courtes itérations (et incrémentales) apportent une réponse,
- dans cette même idée, nous retrouvons le côté incrémental de l'agilité : avoir des dates fixes (ou presque), cela permet d'être raisonnable dans son expression de besoins, et surtout, de nous donner une certaine légitimité dans la demande l'ordonnancement ou la priorisation de ces besoins.
Think big, start small
, mon leitmotiv pour illustrer les propos. En gros, cela signifie que je prends bien en compte TOUS tes besoins (nécessaires ou pas à l'heure actuelle), mais ce n'est pas pour autant qu'ils seront développés lors de la prochain version, à toi, MOA, de me dire, avec le temps imparti connu (2 mois), ce que tu souhaites voir dans cette version. Pour le reste de tes besoins, nous verrons lors d'une version suivante, etc, etc...je schématise bien entendu, - toujours du côté de l'utilisateur, cela permet de voir ou plutôt de s'apercevoir qu'on se dirige vers une mauvaise direction, et le cas échéant, de réorienter le besoin et les dév. ad-hoc. Si une version sortait tous les 6 mois voire 1 an, cela serait beaucoup (mais beaucoup) plus difficile de le faire.
Les objectifs de tout ça :
- répondre au plus près aux attentes des utilisateurs (besoins, taux de bugs, performances),
- être pro-actif pour innover et proposer de nouvelles techniques Web pour le plaisir de tous (utilisateurs et ingénieurs),
- garder une maintenabilité suffisante du système, ceci pour le faire évoluer plus facilement et durablement,
Adaptées à notre environnement, ces quelques bonnes pratiques sont évidentes tellement on en tire des avantages, suffisait d'y penser !