Raccourcir la queue de release

((/dotclear/public/photos/.jim-highsmith_t.jpg|Jim Highsmith|L|Jim Highsmith))Je rentre de la plage et je tombe sur ce billet de __Jim Highsmith__ : ++[« Shortening the Tail »|http://www.jimhighsmith.com/2011/07/14/shortening-the-tail/|en]++ que j’ai traduit dans la foulée en attendant l’apéritif dînatoire :)%%% > [((/dotclear/public/traductions/.Shortening_Tail_s.jpg|Raccourcir la queue de release|R|Raccourcir la queue de release))|/dotclear/public/traductions/Shortening_Tail.jpg]Dans mon livre ++[Agile Project Management|http://www.amazon.com/Agile-Project-Management-Creating-Innovative/dp/0321658396/ref=ed_oe_p|en]++, j’ai écrit un court chapitre sur un indicateur de performance que j’ai appelé « raccourcir la queue de release ». J’aime utiliser cet indicateur, la longueur de la queue de release, car elle est facile à calculer et en dit beaucoup sur la mise en œuvre de l’Agile dans une organisation. Ce n’est pas un joli indicateur qui ne vous donne aucun élément de décision$$Vanity metric$$, comme par exemple le nombre de développeurs qui participent à un séminaire de refactoring, mais un véritable indicateur qui vous permet d’en apprendre plus et qui se concentre sur un point clé du développement et du test logiciel en Agile. C’est aussi un indicateur qui peut aider une organisation à se rapprocher de la la notion de Livraison Continue$$Continuous Delivery$$.%%% > %%% > La queue de release est la période qui s’étend entre le « la soupe de code »$$code slush$$ (le vrai gel de code$$code freeze$$ reste rare) ou « gel des fonctionnalités »$$feature freeze$$ et le déploiement effectif des fonctionnalités. C’est la période pendant laquelle les entreprises font tout ou partie des activités suivantes : bêta-tests, tests de non régression, intégration de produits, tests d’intégration, documentation, corrections d’anomalies. La pire « queue de release » que j’ai rencontrée était de 18 mois – du gel des fonctionnalités à la livraison du produit – et la plus grande partie du temps était consacrée à la QA. Régulièrement, je rencontre des sociétés de logiciels dont la queue de release est de 4 à 6 mois pour un cycle de version de 12 mois. Après, il y a d’autres sociétés, et un nombre croissant dans le logiciel, qui ont optimisé leurs processus pour obtenir une queue de release de longueur zéro, elles réalisent vraiment une Livraison Continue et un Déploiement Continu$$Continuous Deployment$$. Utiliser l’indicateur longueur de la queue de release, en particulier pour les produits ou les applications qui disposent d’un grand patrimoine de code, peut aider les organisations à mesurer leur progrès vers un Déploiement Continu.%%% > %%% > Il y a plusieurs années, j’ai travaillé avec une organisation qui avait une queue de release de 6 mois dans un cycle de version de 12 mois et la queue devenait progressivement de plus en plus longue à chaque nouvelle version. La queue de release était passée de 4 à 6 mois au cours des 3 derniers cycles de version. La société s’était fixée l’objectif d’atteindre une queue de 1 mois et a travaillé avec assiduité pour atteindre cet objectif au fil du temps.%%% > %%% > Raccourcir la queue de release est un moyen simple, un indicateur puissant pour mesurer les progrès vers l’agilité. L’objectif des équipes agiles est de produire des logiciels déployables à chaque itération, mais la plupart sont loin de cet objectif, surtout si des équipes héritent de patrimoines de code conséquents et anciens. Pensez à tout ce qu’une entreprise peut avoir à faire pour réduire une queue de six à trois mois puis à un mois puis finalement à un jour. Elle devra apprendre à faire de l’intégration continue pour l’ensemble de ses produits. Elle devra améliorer son niveau de tests automatisés pour conduire des tests de non régression et d’intégration dans chaque itération. Elle devra améliorer le niveau de tests unitaires automatisés faits par ses développeurs pour réduire les temps de test à la fin des itérations et des versions. Elle devra impliquer ses clients beaucoup plus tôt dans le processus de développement, en n’attendant pas jusqu’au dernier moment pour les bêta-tests. Elle devra intégrer des spécialistes de la documentation dans l’équipe et produire de la documentation en continu pendant les itérations. Elle devra investir dans le refactoring systématique pour réduire la dette technique et donc réduire le temps consacré aux activités de tests et de corrections d’anomalies.%%% > %%% > Vous pouvez probablement penser à d’autres choses que l’entreprise devra faire. Chacun de ces éléments contribuera d’une certaine façon, grande ou petite, à la réduction de la longueur de la queue de release en nombre de jours ou de semaines. Pour les gros produits, la queue de release ne sera jamais nulle, mais elle pourra être de petite taille. Pensez juste au désavantage concurrentiel dont souffre une entreprise quand sa queue de release est de 18 mois, voire 6 mois. Cela signifie que pendant les 6 ou 18 mois précédant la livraison, aucun changement dans l’environnement concurrentiel ne pourra être incorporé dans ses produits. Si la Livraison Continue semble un trop grand pas en avant, commencez sur cette voie en réduisant d’abord la longueur de la queue des versions de votre produit, petit à petit la Livraison Continue ne vous semblera plus aussi inaccessible.%%% —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes traductions sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start|fr]++.

Une réflexion au sujet de « Raccourcir la queue de release »

  1. Certes, il faut réduire ce temps. mais à mon avis le problème vient de ce que j’explique ci-dessous : aujourd’hui dans tous les projets et quelque soit la méthodologie (Cycle V, W, méthodes empiriques, stochastique, organiques, ou agile), le problème réside toujours dans l’estimation correcte (voire exacte) des périodes des itérations, des releases, des versions pendant toutes les phases de développement (conception, codage, test unitaires, tests d’intégration et de non régression, packaging, déploiement, etc). Il y a toujours un ou plusieurs cas qui sont sous-estimés pour différentes raisons ou causes qui entraînent souvent le chevauchement entre les jalons. Je pense que le travail consiste à appliquer des modèles micro-plannings et macro-plannings en intégrant des coefficients de sécurité dus aux risques qui permettront de façon naturelle à diminuer ou à tendre cette notion vers un epsilon acceptable. Mon interrogation : existe-il vraiment ce type de modèles ?

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *