{"id":95,"date":"2011-12-14T10:37:17","date_gmt":"2011-12-14T09:37:17","guid":{"rendered":"http:\/\/dev.qualilogy.com\/fr\/?p=95"},"modified":"2013-01-04T10:38:13","modified_gmt":"2013-01-04T09:38:13","slug":"best-of-both-worlds","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/fr\/best-of-both-worlds\/","title":{"rendered":"Best of both worlds"},"content":{"rendered":"<p><a href=\"http:\/\/vicken.deviantart.com\/\" target=\"_blank\"><img loading=\"lazy\" decoding=\"async\" class=\"alignleft size-full wp-image-311\" title=\"Qual_RedSail\" src=\"http:\/\/qualilogy.com\/wp-content\/uploads\/2011\/12\/Qual_RedSail.jpg\" alt=\"\" width=\"300\" height=\"298\" \/><\/a>A la suite du post pr\u00e9c\u00e9dent <a title=\"Quelle est la premi\u00e8re question?\" href=\"http:\/\/qualilogy.com\/fr\/quelle-est-la-premiere-question\" target=\"_blank\">Quelle est la premi\u00e8re question ?<\/a> au sujet des deux questions majeures &#8211; co\u00fbts vs. risques &#8211; quelqu&rsquo;un m&rsquo;a demand\u00e9 si existaient quelques processus ou best practices qui permettent d&rsquo;atteindre ces deux objectifs.<\/p>\n<p>Existe-t-il un \u201cbest of both worlds\u201d afin de produire du code de qualit\u00e9 sans d\u00e9passer budgets et plannings ?<\/p>\n<p><!--more--><\/p>\n<p>En fait, il n&rsquo;est pas n\u00e9cessaire de rechercher ce meilleur des deux mondes. Par exemple, si je dois r\u00e9aliser un audit d&rsquo;un syst\u00e8me bancaire, je vais d&rsquo;abord v\u00e9rifier que les priorit\u00e9s en termes de business sont:<\/p>\n<ul>\n<li>Asset management: time to market, pas de bugs emp\u00eachant ou g\u00eanant le fonctionnement du syst\u00e8me d\u00e9s le premier jour, pas de souci de performance ou de s\u00e9curit\u00e9 \u00e9videmment. L&rsquo;argent n&rsquo;est pas un probl\u00e8me: on peut doubler l&rsquo;\u00e9quipe afin de respecter le planning. La maintenabilit\u00e9 n&rsquo;est pas vraiment un probl\u00e8me: cette application peut \u00eatre obsol\u00e8te d&rsquo;ici quelques ann\u00e9es. Et dans le pire des cas, on peut la jeter et la r\u00e9\u00e9crire, ou acheter un progiciel.<\/li>\n<li>Bank retail (service aux particuliers): syst\u00e8mes anciens, g\u00e9n\u00e9ralement Mainframe-Cobol, souvent outsourc\u00e9s pour des questions de co\u00fbts. Les utilisateurs ont l&rsquo;habitude de voir une nouvelle release retard\u00e9e de 2 ou 3 semaines, et ne sont pas surpris si certaines fonctionnalit\u00e9s sont d\u00e9faillantes apr\u00e8s mise en production.<\/li>\n<\/ul>\n<p>Il est important de qualifier quel est l&rsquo;alignement business\/IT. Dites \u00e0 la premi\u00e8re \u00e9quipe (Asset management) que vous allez mesurer les d\u00e9rives de maintenabilit\u00e9 afin de contr\u00f4ler le budget ou dites \u00e0 la seconde \u00e9quipe (Bank retail) que vous allez instaurer une politique de tol\u00e9rance z\u00e9ro en mati\u00e8re de non-respect des bonnes pratiques de performance, et vous vous verrez r\u00e9pondre \u201cEt alors? Cela n&rsquo;a aucune importance\u201d.<\/p>\n<p>Je ne crois pas qu&rsquo;il existe une recette-miracle qui conduise au meilleur de ces deux mondes. Cependant, imaginons un instant qu&rsquo;on vous demande de prendre en charge un projet sans conna\u00eetre son \u201calignement\u201d, voici ce que je ferai.<\/p>\n<p>1. \u201cYou cannot control what you cannot measure\u201d (Tom deMarco). Je commencerai d&rsquo;abord par impl\u00e9menter un outil d&rsquo;analyse de code qui permette de tracer une carte de la qualit\u00e9 de l&rsquo;application. <a title=\"Mesurer et contr\u00f4ler\" href=\"http:\/\/qualilogy.com\/fr\/mesurer-et-controler\" target=\"_blank\">Mesurer et contr\u00f4ler<\/a>.<\/p>\n<p>2. Je d\u00e9finirai une strat\u00e9gie pour cette application, avec les experts sur ce projet. Cette zone pr\u00e9sente des risques : \u00e9vitons de la modifier. Mais s&rsquo;il faut vraiment toucher \u00e0 un de ces composants, alors tester de mani\u00e8re exhaustive toute \u00e9volution. Il va falloir r\u00e9\u00e9crire cette partie de l&rsquo;application car il y a trop de code dupliqu\u00e9 qui va nous co\u00fbter beaucoup d&rsquo;effort pour la maintenir. C&rsquo;est une priorit\u00e9 de la red\u00e9velopper sous forme de composants r\u00e9utilisables. Documenter cette partie ? Ok, cela peut attendre. Combien de temps pour faire tout cela ?<br \/>\nCeci m\u00e9nera \u00e0 un plan d&rsquo;actions avec diff\u00e9rentes priorit\u00e9s \u00e0 diff\u00e9rents co\u00fbts \u00e0 court \/ moyen \/ long terme. Il faut conna\u00eetre quel est \u201cl&rsquo;alignement\u201d de l&rsquo;application pour construire ce plan.<\/p>\n<p>3. Les d\u00e9fauts de programmation sont faciles \u00e0 identifier et \u00e0 r\u00e9soudre. R\u00e9alisez r\u00e9guli\u00e8rement des analyses de code \u00e0 l&rsquo;aide de l&rsquo;outil mis en place et d\u00e9finissez un processus de r\u00e9solution de ces violations auquel vous int\u00e9grez votre plan d&rsquo;action. Ces mesures constituent un premier pas vers un processus de Continuous Inprovement. Sur ce sujet : <a title=\"Am\u00e9lioration continue de la qualit\u00e9\" href=\"http:\/\/qualilogy.com\/fr\/amelioration-continue-de-la-qualite\" target=\"_blank\">Am\u00e9lioration continue de la qualit\u00e9<\/a>.<\/p>\n<p>4. Les d\u00e9fauts de sp\u00e9cifications (absentes, erron\u00e9es ou mal comprises) sont les plus co\u00fbteux mais aussi les plus difficiles \u00e0 identifier. Mettre en place une m\u00e9thodologie \u00e0 base de revues utilisateurs, prototypage, agile, etc. Celle que vous pr\u00e9f\u00e9rez mais, selon moi, elle doit:<\/p>\n<ul>\n<li>Impliquer l&rsquo;utilisateur : il doit valider \u00e0 la fois l&rsquo;interface (utilisabilit\u00e9) et les fonctionnalit\u00e9s. Ce peut-\u00eatre des utilisateurs finals ou une ma\u00eetrise d&rsquo;ouvrage, peu importe, mais ils doivent \u00eatre int\u00e9gr\u00e9s au projet. Combien de &lsquo;d\u00e9fauts fonctionnels&rsquo; sont en fait des sp\u00e9cifications qui ont \u00e9volu\u00e9 en phase de projet ? En tant que responsable de celui-ci, je veux qu&rsquo;il soit bien clair que je n&rsquo;en assumerai pas les co\u00fbts.<\/li>\n<li>Etre compatible avec la technologie : je ne vois pas beaucoup de Scrum ou de m\u00e9thodes agiles sur des projets Mainframe-Cobol.<\/li>\n<\/ul>\n<p>5. Tests. Ils p\u00e8sent beaucoup sur le budget et le planning. D&rsquo;abord, d\u00e9finir le niveau de QA requis. Si l&rsquo;application n&rsquo;est pas tr\u00e8s volumineuse ni tr\u00e8s complexe, des tests unitaires et d&rsquo;int\u00e9gration peuvent s&rsquo;av\u00e9rer suffisants. En fait, la difficult\u00e9 provient des applications lourdes et complexes : combien investir dans la r\u00e9alisation des plans de test, en charges de test et en outils ?<br \/>\nC&rsquo;est l\u00e0 que la collaboration entre l&rsquo;\u00e9quipe de projet et les \u00e9quipes de QA prend toute son importance. Par exemple, un client souhaite un audit sur la scalabilit\u00e9 d&rsquo;une de ses applications : les donn\u00e9es et le nombre d&rsquo;utilisateurs vont \u00eatre multipli\u00e9s par 3. Une premi\u00e8re analyse de code identifie les &lsquo;fuites&rsquo; potentielles de performance, que l&rsquo;on corrige. Le r\u00e9sultat des analyses ult\u00e9rieures est partag\u00e9 avec l&rsquo;\u00e9quipe de QA pendant la phase de d\u00e9veloppement, afin de les assister dans la d\u00e9finition de leurs plans de test. Il est d\u00e9cid\u00e9 d&rsquo;automatiser les tests de performance et de concentrer les tests manuels sur les nouvelles fonctionnalit\u00e9s utilisateur. Une Quality Gate est mise en place, afin de garantir la qualit\u00e9 du code livr\u00e9 et autoriser un &lsquo;GO&rsquo; pour la phase de tests.<br \/>\nVous pouvez perdre beaucoup de temps et d&rsquo;argent en tests: essayer d&rsquo;obtenir le maximum de visibilit\u00e9 sur la qualit\u00e9 de l&rsquo;application afin de concentrer les efforts sur les zones qui permettront d&rsquo;optimiser votre investissement.<\/p>\n<p>6. Un retour du terrain est toujours appr\u00e9ciable. R\u00e9cup\u00e9rez les d\u00e9fauts rencontr\u00e9s en production et corr\u00e9lez ce nombre avec celui des d\u00e9fauts rencontr\u00e9s lors des analyses de code. Montrez les r\u00e9sultats \u00e0 votre \u00e9quipe mais aussi aux utilisateurs\/la ma\u00eetrise d&rsquo;ouvrage et votre management. Normalement, vous devez pouvoir d\u00e9montrer que cela va dans le bons sens et tout le monde est content de savoir que cela va dans le bon sens.<\/p>\n<p>7. Munissez vous d&rsquo;un outillage ad\u00e9quat. Un outil d&rsquo;analyse de code connect\u00e9 \u00e0l&rsquo;outil de d\u00e9veloppement et de gestion des changements\/des versions, et des outils de tests. Cela d\u00e9pend des technologies.<\/p>\n<p>8. Il faudra une \u00e9quipe avec un certain niveau de maturit\u00e9.<\/p>\n<p>Cela peut prendre des ann\u00e9es avant de mettre en place un tel processus qui optimise les co\u00fbts en limitant les risques. Donc il est souhaitable de prioriser ces actions en fonction des objectifs et de l&rsquo;alignement business\/IT plut\u00f4t que de viser de prime abord un \u201cbest of both worlds\u201d.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>A la suite du post pr\u00e9c\u00e9dent Quelle est la premi\u00e8re question ? au sujet des deux questions majeures &#8211; co\u00fbts vs. risques &#8211; quelqu&rsquo;un m&rsquo;a demand\u00e9 si existaient quelques processus ou best practices qui permettent d&rsquo;atteindre ces deux objectifs. Existe-t-il un \u201cbest of both worlds\u201d afin de produire du code de qualit\u00e9 sans d\u00e9passer budgets [&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-95","post","type-post","status-publish","format-standard","hentry","category-qualite-des-applications"],"_links":{"self":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/95"}],"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=95"}],"version-history":[{"count":1,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/95\/revisions"}],"predecessor-version":[{"id":96,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/95\/revisions\/96"}],"wp:attachment":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/media?parent=95"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/categories?post=95"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/tags?post=95"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}