{"id":230,"date":"2012-10-22T11:20:02","date_gmt":"2012-10-22T10:20:02","guid":{"rendered":"http:\/\/dev.qualilogy.com\/fr\/?p=230"},"modified":"2013-01-08T17:01:10","modified_gmt":"2013-01-08T16:01:10","slug":"delivrer-la-qualite-22","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/fr\/delivrer-la-qualite-22\/","title":{"rendered":"D\u00e9livrer la qualit\u00e9 (2\/2)"},"content":{"rendered":"<p><a href=\"http:\/\/vicken.deviantart.com\/\" target=\"_blank\"><img loading=\"lazy\" decoding=\"async\" class=\"alignleft size-full wp-image-2457\" title=\"QualDeliverQuality2\" src=\"http:\/\/qualilogy.com\/wp-content\/uploads\/2012\/10\/QualDeliverQuality21.jpg\" alt=\"Deliver Quality\" width=\"267\" height=\"401\" \/><\/a>Quels enseignements peut on tirer si l\u2019on applique au domaine de la qualit\u00e9 de code les principes ITIL en mati\u00e8re de Capacity Management ?<\/p>\n<p>Nous avons vu dans <a title=\"D\u00e9livrer la qualit\u00e9\" href=\"http:\/\/qualilogy.com\/fr\/delivrer-la-qualite-12\" target=\"_blank\">le post pr\u00e9c\u00e9dent<\/a> que, selon cette approche, d\u00e9livrer la Qualit\u00e9 dans le respect des accords de niveaux de service, des plannings et des budgets n\u00e9cessitait de conna\u00eetre ce que l\u2019on a, c\u2019est-\u00e0-dire son parc applicatif, mais \u00e9galement la qualit\u00e9 de celui-ci.<\/p>\n<p>Cette connaissance bas\u00e9e sur des m\u00e9triques quantitatives et qualitatives permet de mieux r\u00e9pondre aux besoins des utilisateurs, comme nous allons le voir dans ce second et dernier article de cette s\u00e9rie.<\/p>\n<p><!--more--><\/p>\n<h3><strong>R\u00e9pondre aux n\u00e9cessit\u00e9s des m\u00e9tiers<\/strong><\/h3>\n<p>Faire plus, mieux, plus vite avec moins constitue le d\u00e9fi principal des \u00e9quipes de projet \u00e0 l\u2019heure actuelle. Le management cherche constamment \u00e0 ajuster les ressources au niveau d\u2019activit\u00e9 des projets, notamment chez les outsourceurs, et il n\u2019est pas rare de voir un ou plusieurs d\u00e9veloppeurs passer dans une autre \u00e9quipe \u00e0 la fin d\u2019un projet. La connaissance du code est alors perdue, et avec elle la fiabilit\u00e9 dans la pr\u00e9vision des charges de r\u00e9alisation des \u00e9volutions pour une nouvelle version.<\/p>\n<p>M\u00eame lorsque les sp\u00e9cifications fonctionnelles sont pr\u00e9cises, la charge d\u2019impl\u00e9mentation peut varier du simple au double voire plus encore, en fonction de la taille du code, sa complexit\u00e9, sa lisibilit\u00e9, la difficult\u00e9 avec laquelle introduire une modification sans d\u00e9faut.<\/p>\n<p>Conna\u00eetre l\u2019application et son \u00e9tat d\u2019un point de vue quantitatif et qualitatif permet alors de d\u00e9finir une strat\u00e9gie :<\/p>\n<ul>\n<li>Des changements dans cette zone qui pr\u00e9sente des risques pour la maintenabilit\u00e9 ? S\u2019il faut vraiment toucher \u00e0 un de ces composants, alors pr\u00e9voir de tester de mani\u00e8re exhaustive afin d\u2019\u00e9viter toute r\u00e9gression.<\/li>\n<li>Un refactoring pr\u00e9alable de cette partie de l\u2019application est n\u00e9cessaire car il y a trop de code dupliqu\u00e9 qui va co\u00fbter beaucoup d\u2019efforts pour impl\u00e9menter les modifications demand\u00e9es. Il vaut mieux r\u00e9\u00e9crire certains composants plut\u00f4t que de perdre du temps \u00e0 identifier toutes les portions de code copi\u00e9es-coll\u00e9es dans lesquelles coder les \u00e9volutions. Les charges de test seront \u00e9galement moindres et le risque de bug \u00e9galement.<\/li>\n<li>Cette application est mal document\u00e9e, avec un taux de commentaires tr\u00e8s faible, et il y a trop de nouveaux d\u00e9veloppeurs dans l\u2019\u00e9quipe. Mieux vaut pr\u00e9voir quelques jours suppl\u00e9mentaires de d\u00e9couverte du code, voire de redocumentation, au d\u00e9but du projet. Cela pourra \u00e9viter quelques mauvaises surprises par la suite, et peut-\u00eatre m\u00eame pourra-t-on rattraper le temps perdu, surtout si les sp\u00e9cifications fonctionnelles changent en cours de projet.<\/li>\n<\/ul>\n<p>Il n\u2019est pas possible de d\u00e9finir un plan d\u2019actions, un niveau de ressources n\u00e9cessaires et un planning sans conna\u00eetre ce que vous avez et le niveau de qualit\u00e9 de ce que vous avez.<\/p>\n<h3><strong>Optimiser la prise de d\u00e9cision<\/strong><\/h3>\n<p>Autre enseignement que l\u2019on peut tirer de l\u2019analogie avec le Capacity Management et que je trouve particuli\u00e8rement int\u00e9ressant : la facult\u00e9 \u00e0 orienter la demande des utilisateurs en se basant sur des donn\u00e9es objectives.<\/p>\n<p>ITIL pr\u00e9cise bien que la gestion de l\u2019infrastructure doit \u00eatre r\u00e9alis\u00e9e :<\/p>\n<ul>\n<li>Dans le respect des accords de niveau de service, qui portent le plus souvent sur la disponibilit\u00e9 des ressources.<\/li>\n<li>De mani\u00e8re rentable : une disponibilit\u00e9 de 100% n\u2019est pas l\u2019objectif, car elle serait trop co\u00fbteuse.<\/li>\n<\/ul>\n<p>Un exemple pour concr\u00e9tiser cela.<\/p>\n<p>Au sein d\u2019un service marketing, les utilisateurs d\u2019un progiciel de CRM (Customer Relationship Management) se plaignent de lenteurs et ralentissements lors des f\u00eates de fin d\u2019ann\u00e9e, \u00e9poque \u00e0 laquelle il est le plus utilis\u00e9, et que les SLAs ne sont pas respect\u00e9s. Ils demandent donc un upgrade du serveur \u00e0 la Production, et que celle-ci tienne ses engagements, sans surco\u00fbt pour eux.<\/p>\n<p>Le Capacity Manager se r\u00e9unit alors avec ces derniers et leur explique que la puissance disponible sur le serveur est de 8 000 MIPS, que cette puissance est insuffisante pour une disponibilit\u00e9 optimale pendant les deux derni\u00e8res semaines de l\u2019ann\u00e9e, mais que seulement 6 000 MIPS sont utilis\u00e9s durant les 11 mois et demi restants. Sur l\u2019ann\u00e9e, les accords de niveau de service sont tenus.<\/p>\n<p>En se basant sur cette connaissance, il peut d\u00e9s lors proposer plusieurs solutions :<\/p>\n<ul>\n<li>Upgrader le serveur tel que le souhaitent les utilisateurs, mais avec un surco\u00fbt correspondant aux ressources additionnelles.<\/li>\n<li>Mettre \u00e0 disposition 50 semaines par an la puissance de 6 000 MIPS, ou un peu plus afin de se garder une marge de s\u00e9curit\u00e9, et passer \u00e0 9 000 MIPS les 2 semaines restantes. La facture informatique sera moins \u00e9lev\u00e9e, m\u00eame si un co\u00fbt d\u2019intervention lui sera ajout\u00e9 afin de g\u00e9rer cette flexibilit\u00e9 additionnelle.<\/li>\n<li>Une derni\u00e8re solution possible : downgrader le serveur afin de ne d\u00e9livrer que 6 000 MIPS durant toute l\u2019ann\u00e9e, au prix d\u2019une d\u00e9gradation encore plus forte des ressources pendant les f\u00eates de fin d\u2019ann\u00e9e. Cette solution pourrait s\u2019envisager en p\u00e9riode de restriction de budgets et\/ou si les campagnes de marketing sont revues \u00e0 la baisse.<\/li>\n<\/ul>\n<p>En mati\u00e8re de d\u00e9veloppement applicatif, on part du principe que la qualit\u00e9 est forc\u00e9ment maximale, alors que les priorit\u00e9s vont g\u00e9n\u00e9ralement aux d\u00e9lais et aux budgets qui doivent \u00eatre imp\u00e9rativement tenus. Or l\u2019on sait bien que vite et pas cher ne riment pas avec qualit\u00e9. D\u2019autant que les d\u00e9lais sont le plus souvent d\u00e9cid\u00e9s au d\u00e9but des projets, alors que les sp\u00e9cifications ne sont pas encore fig\u00e9es et que les charges de travail vont bien souvent fluctuer, \u00e1 la hausse bien s\u00fbr.<\/p>\n<p>Si cette situation survient sur un de vos projets et que vous pr\u00e9voyez des retards, l\u2019utilisation d\u2019un outil d\u2019analyse de code au sein d\u2019un processus d\u2019Int\u00e9gration Continue permettra, \u00e0 l\u2019instar de ce Capacity Manager :<\/p>\n<ul>\n<li>De d\u00e9montrer avec des mesures qualitatives (nombre de violation bloquantes, critiques, etc.) que la dette technique est contr\u00f4l\u00e9e et le niveau de qualit\u00e9 du code se maintient.<\/li>\n<li title=\"Permalink to La m\u00e9trique ABC\">De justifier les d\u00e9lais additionnels en montrant l\u2019\u00e9volution \u00e1 la hausse des fonctionnalit\u00e9s impl\u00e9ment\u00e9es dans le code, qui accroissent la complexit\u00e9 des d\u00e9veloppements et les exigences de test (sur ces th\u00e8mes, cf. <a title=\"Complexit\u00e9 et effort de test\" href=\"http:\/\/qualilogy.com\/fr\/complexite-et-effort-de-test\" target=\"_blank\">Complexit\u00e9 et effort de test<\/a> et <a title=\"La m\u00e9trique ABC\" href=\"http:\/\/qualilogy.com\/fr\/la-metrique-abc\" rel=\"bookmark\" target=\"_blank\">La m\u00e9trique ABC<\/a>).<\/li>\n<li>De proposer des solutions.<\/li>\n<\/ul>\n<p>Celles-ci peuvent \u00eatre multiples :<\/p>\n<ul>\n<li>Repousser la date de livraison afin de maintenir la qualit\u00e9 au niveau attendu, par le contr\u00f4le de la dette technique et un plan de tests exhaustif.<\/li>\n<li>Respecter les d\u00e9lais mais en acceptant un risque sur la qualit\u00e9 et les bugs potentiels pour les utilisateurs. Un refactoring sera probablement n\u00e9cessaire ult\u00e9rieurement.<\/li>\n<li>Livrer une premi\u00e8re version de l\u2019application sans toutes les fonctionnalit\u00e9s attendues, mais dans les d\u00e9lais et avec une qualit\u00e9 correcte, sans risque excessif pour les utilisateurs. Une seconde version livr\u00e9e dans un second temps compl\u00e9tera les fonctionnalit\u00e9s, et corrigera les erreurs \u00e9ventuelles de la premi\u00e8re version.<\/li>\n<\/ul>\n<p>\u00ab Plus avec moins \u00bb ne signifie pas de produire plus de code pour moins cher, comme je vois souvent beaucoup de managers ou de clients le penser. Cela signifie d\u2019\u00eatre capable de r\u00e9pondre de mani\u00e8re satisfaisante aux demandes de plus en plus exigeantes des utilisateurs, en mati\u00e8re de fonctionnalit\u00e9s, de d\u00e9lais et de budgets.<\/p>\n<p>Mettez en place un processus d\u2019Int\u00e9gration Continue avec un outil d&rsquo;analyse de code, des Quality Gate au niveau des tests et de la production, des SLA (cf. <a title=\"Cas d'usage\" href=\"http:\/\/qualilogy.com\/fr\/cas-dutilisation-ensemble-et-sans-heurts\" target=\"_blank\">Cas d\u2019utilisation \u2013 Ensemble et sans heurts<\/a>) et vous pourrez disposer des donn\u00e9es objectives qui vous permettront d\u2019offrir des strat\u00e9gies alternatives \u00e0 vos clients et vos managers, sur la base d\u2019une connaissance et d\u2019une ma\u00eetrise optimale de votre portfolio d\u2019applications.<\/p>\n<p>Comme le montre le Capacity Management selon ITIL, mieux r\u00e9pondre aux besoins des utilisateurs et faciliter la d\u00e9cision des managers n\u00e9cessite des donn\u00e9es objectives et la connaissance quantitative et qualitative des applications. Plus et mieux avec moins: d\u00e9livrez la qualit\u00e9 dans les d\u00e9lais et les budgets.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Quels enseignements peut on tirer si l\u2019on applique au domaine de la qualit\u00e9 de code les principes ITIL en mati\u00e8re de Capacity Management ? Nous avons vu dans le post pr\u00e9c\u00e9dent que, selon cette approche, d\u00e9livrer la Qualit\u00e9 dans le respect des accords de niveaux de service, des plannings et des budgets n\u00e9cessitait de conna\u00eetre [&hellip;]<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-230","post","type-post","status-publish","format-standard","hentry","category-qualite-des-applications"],"_links":{"self":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/230"}],"collection":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/comments?post=230"}],"version-history":[{"count":2,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/230\/revisions"}],"predecessor-version":[{"id":267,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/230\/revisions\/267"}],"wp:attachment":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/media?parent=230"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/categories?post=230"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/tags?post=230"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}