Voici une nouvelle question qu’un recruteur pourrait vous poser sur le thématique de la qualité dans vos projets.
Le management de la qualité couvre les processus requis pour s’assurer que le niveau exigé de qualité est intégré dans chaque aspect du projet :
contactez-nous pour publier une annonce
Planifier pour la qualité nécessite de définir précisément la ligne des références de base du niveau de qualité requis (en s’appuyant si possible sur des normes ou standards)
Mettre en place l’assurance qualité pour prévoir les activités, outils, techniques à utiliser pour s’assurer proactivement qu’une qualité conforme aux exigences soit respectée
Mettre en place le contrôle qualité pour établir les tests et actions de vérification et de contrôle des livrables produits par le projet.
Attention à la « sur-qualité »
plaquer à l’or fin – gold plating deliverables
S’il y a une chose sur laquelle insister, je pense que c’est de ne pas systématiquement chercher à produire des livrables qui dépassent la qualité requise, faire de la sur-qualité, aussi appelé le « plaqué or » (Gold Plating), est non seulement souvent inutile mais aussi préjudiciable à la réussite de tous les autres paramètres du projet (Temps, Coûts, Contenu).
Il s’agit donc de bien définir des normes ou standards de qualité agréés pour les livrables du projet, de bien les partager, puis de ne pas oublier de les respecter.Il faudra donc déterminer et mettre en œuvre des procédures pour les implémenter et les garantir ET, en dernier, de mettre en place des mécanismes de vérification.
Comme l’on peut aisément le comprendre, trouver des défauts pendant la toute dernière phase de vérification est onéreux, aussi les efforts se positionneront-ils le plus tôt possible, dans la définition des normes et procédures à respecter pour les atteindre.
partagez ce billet avec vos amis, collègues et relations professionnelles
Bien faire ou faire vite? Il y a parfois un prix à payer quand on “fait vite”. C’est ce qu’on appelle la Dette Technique.
MS-DOS est probablement l’exemple le plus connu de Dette Technique. En 1981, IBM demanda à Bill Gates de développer un système opératif pour son nouveau PC. Pour respecter les délais, il prit le QDOS (Quick and Dirty Operating System, Système Opératif Vite fait Mal fait) et le renomma MS-DOS. Bâclé et grossier, MS-DOS a été alourdi par une dette dès sa conception, il était doté d’un ensemble de commandes qui laissaient à désirer et de caractéristiques limitées.
Dans le monde de la gestion de projet, le respect des délais est un point clé pour mesurer la réussite de la plupart des projets. En vous pressant pour respecter les délais, il se peut que vous accumuliez une dette sans vous en rendre compte, silencieusement… mais de manière constante.
La Dette Technique peut prendre les formes suivantes:
Documentation ou manuel d’utilisation inexistants
Programmation de mauvaise qualité (non structurée, avec peu de commentaires, codage en dur)
Bases de données mal structurées (données redondantes, erreurs de données)
Mauvaise conception (mauvaise architecture, non modulable)
Mauvais processus (inefficaces, entraînant une perte de temps, sujets à erreurs)
Habituellement, on parle de dette pour des projets de développement de logiciels, mais elle ne s’applique pas uniquement au software – toutes sortes de projets peuvent générer une dette.
Souvent, la Dette Technique est issue de la pression exercée pour respecter les délais, mais ce n’est pas seulement une question de précipitation.
Plusieurs facteurs peuvent être source de dette :
Image courtesy of ambro / FreeDigitalPhotos.net
La vitesse: la précipitation est probablement la première cause de Dette Technique
Vision à court terme: rapiéçage et raccommodage. Solutions dénuées d’architectures
Contre-la-montre: efforts concentrés sur le retard accumulé (au lieu de penser au futur)
Innovation de pointe : apprentissage sur le tas
Manque de compétences: assignation de personnel n’ayant pas les bonnes compétences (ou pas de compétences du tout) à des tâches complexes.
Pourquoi s’en inquiéter?
La Dette Technique est comme la dette financière… vous pouvez l’ignorer pendant un temps, mais l’accumulation de dette reviendra vous hanter. En présence de dette, le résultat final sera chaotique – un patchwork ou un sac de nœuds difficile à comprendre ou à changer.
Partenaire de DantotsuPM
Ce sera une surcharge potentielle pour tout ce qui sera entrepris par la suite – la Dette Technique peut ralentir et compliquer des projets futurs. Elle peut aussi engendrer un vieillissement prématuré – l’accumulation de dette peut raccourcir la durée de vie de votre solution.
Ne vous précipitez pas sur la dette.
le livre de Chris Sterling
La principale source de dette est la précipitation. Certaines méthodes de gestion de projet se basent sur la rapidité ; c’est le cas de la plupart des variantes légères d’Agile. Ces dernières, comme Scrum, généreront nécessairement une dette si l’on se focalise trop sur la rapidité. Les délais seront peut-être respectés, mais si c’est au prix d’autres facteurs de bonnes pratiques, tels que le design, la planification ou la qualité, alors il se peut que vous accumuliez une dette.
Il existe deux façons de contourner ce problème pour les projets Agile : essayer de rendre cette méthode légère plus robuste (comme décrit dans le livre « Managing Software Debt » de Chris Sterling) ou utiliser une solution Agile.
Pourquoi utiliserAgile?
Les méthodes Agile telles que DSDM Atern (parfois appelée AgilePM) permettent de combiner agilité avec architecture et design. Atern possède également un ensemble d’outils assurant une approche à long terme (plans, étude de rentabilité, etc.) – qui aident aussi à établir le compromis entre rapidité et dette (et par conséquent à éliminer ou réduire la dette).
Quelle que soit la solution que vous choisissiez, que vous utilisiez Agile ou non, vous devez garder cette notion de dette à l’esprit.
Jeff Ball
Vous ne pourrez probablement pas vous en débarrasser totalement, mais vous devez appliquer ces trois règles d’or :
Commencez dès aujourd’hui à rembourser les anciennes dettes (chaque nouveau projet rectifie des erreurs et confusions passées)
Évitez de nouvelles dettes (bien faire les choses à l’avenir, équilibrer rapidité et qualité)
Si, pour un projet, vous n’avez pas d’autre choix que de générer une dette, éliminez-la le plus vite possible
Cet article de Jeff Ball, formateur-consultant PRINCE2, MSP, MoP et P3O chez QRP International, propose une idée intéressante, aller chercher l’inspiration là où peu auraient l’idée d’aller voir : votre voiture.
Si vous êtes un chef de projet en mal d’inspiration et devant livrer un produit de qualité, jetez un coup d’œil à votre voiture. Votre automobile est un produit de haute qualité qui devrait vous inspirer dans votre gestion de projet…
Les voitures d’aujourd’hui sont d’une qualité indéniable, ont une grande espérance de vie et sont très utiles. Les constructeurs automobiles (Toyota, Renault, Ford, etc.) ont travaillé d’arrache-pied pendant plusieurs décennies afin d’améliorer la qualité de leurs automobiles. Pensez-y, si vous comparez la qualité de deux voitures, l’une de 1964 et la seconde de 2014, vous vous rendrez compte facilement du fossé qui les séparent. La voiture de 1960 avait une durée de vie limitée en général de moins de 10 ans, sa structure rouillait avec les années et son moteur s’usait rapidement. La voiture d’aujourd’hui au contraire peut rouler pendant plusieurs milliers de kilomètres et rester exempte de rouille durant toute sa durée de vie. Et ne parlons pas des équipements de la voiture d’il y a 50 ans. Elle ne disposait ni de radio, ni de chauffage ni encore simplement de ceinture de sécurité. Aujourd’hui tous ces équipements sont considérés comme du standard pour une voiture.
Par conséquent, lorsque vous admirez votre voiture, vous devriez admirer ce produit de haute qualité et vous demander ce que vous pouvez apprendre des constructeurs automobiles en tant que chef de projet.
Dans l’industrie manufacturière, la qualité peut se définir de deux façons : « conforme aux spécifications » et « adapté à l’usage ».
Les constructeurs automobiles ont répondu à ces deux exigences à travers la voiture du 21ème siècle :
les normes de fabrication se sont largement élevées (meilleure peinture, moteurs plus robustes, etc.)
la satisfaction client s’est beaucoup améliorée (voiture plus adaptée à l’utilisateur, contrôle de la température, installation audio, sécurité,…)
Partenaire de DantotsuPM
Chacune de ces définitions arrive du monde de l’industrie mais peut être appliquée aux projets.
Dans l’industrie automobile, la voiture est un produit. Toyota, Renault et Ford se concentrent sur la livraison d’un produit de haute qualité
Dans la gestion de projet, votre projet a un “produit” qui correspond à votre livrable ou votre solution. C’est ici que votre attention sur la qualité doit être placée.
Il y a deux définitions de qualité et donc deux façons de mettre l’accent sur la qualité des produits :
1. En utilisant l’approche « conforme aux spécifications » , le point de départ est de définir (i.e. décrire) votre produit final puis de le décomposer en plusieurs sous-produits. Afin de documenter cette action, vous pouvez simplement faire usage du schéma « Product breakdown structure » qui montre les 15 ou 20 livrables qui composent votre produit final. Vous pouvez ensuite vous concentrer sur chacun de ces livrables et particulièrement sur comment livrer une bonne qualité pour chacun d’entre eux, pris un par un. Si chacun des livrables est de haute qualité alors votre produit final sera de haute qualité.
2. En utilisant l’approche « adapté à l’usage » , vous commencez avec un produit final moins bien défini. Vous disposez d’une liste de besoins de l’utilisateur ou de fonctionnalités demandées (elles sont parfois exprimées sous forme de « user stories »). Vous travaillez alors de manière itérative en essayant de converger vers une solution qui répond aux besoins de l’utilisateur. Chaque itération est une meilleure version du produit de la version précédente, un pas de plus vers le produit final et, idéalement, une solution de travail partielle. Cette procédure permet de travailler en étroite collaboration avec le consommateur ou l’utilisateur, lui présentant chaque itération afin d’obtenir un retour et qu’il puisse juger si le produit est adapté à l’usage. Vous convergez de façon itérative vers une solution de haute qualité.
Ces deux approches correspondent à deux méthodologies en gestion de projet :
PRINCE2 : l’approche fondée sur les spécifications correspond à la manière dont la méthode PRINCE2 prend en compte la qualité. PRINCE2 dispose d’une « démarche qualité ».
Agile PM : l’approche itérative est une façon Agile de travailler supportée par des méthodes comme DSDM (qui est la base pour la certification Agile PM). DSDM déclare « ne jamais compromettre la qualité ».
Quel que soit votre méthode, il est temps de prendre des mesures sur la qualité dans votre gestion de projet.
Le livre de Phil B. Crosby
Le fameux livre “Quality is Free” affirme que gérer la qualité correctement ne coûte ni temps ni argent mais permet au contraire d’en sauver.
L’absence d’une approche robuste à la gestion de la qualité vous fera probablement perdre du temps car vous découvrirez les défauts du produit en aval et les attentes qualité de l’utilisateur au moment de livrer. Vous trouverez sans doute une solution pour répondre à chaque problème mais réparer des défauts de qualité une fois le produit livré peut prendre beaucoup de temps. Vous pourriez même devoir faire le même travail une deuxième fois… une pour créer le produit, la seconde pour le corriger.
Prendre en compte la qualité dans votre gestion de projet vous aide à gagner du temps, à améliorer la satisfaction client et apporte une valeur ajoutée certaine. Sans frais.
Il est peut-être temps de faire un tour dans votre garage admirer votre voiture et de trouver l’inspiration pour votre prochain projet.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
En matière de plans de projet, chacun y va de sa définition. L’exploration des normes et référentiel en la matière nous éclaire sans forcément nous donner le Saint-Gall. Mais avec du retour d’expérience terrain, chacun arrive à avoir une vision claire.
C’est le but de ce billet. Peut-être pas juste ou incomplet aux yeux des uns et des autres.. mais qui se tient et pourra constituer une base de travail, de réflexion et d’échange.
Quels sont tous les plans du projet et les liens entre eux ?
Il faut d’abord préciser que peu importe le nom et le contenu précis de chaque plan. Ce qui compte c’est que tout y soit pour une bonne maîtrise et mise en œuvre de nos projets.
Pour parler des plans du projet, il faut prendre conscience de trois mondes :
* le système de management de l’entreprise : organisation, processus, procédures permettant d’atteindre la stratégie et les objectifs de l’entreprise. Selon iso 9000, « ensemble d’éléments corrélés ou interactifs permettant d’établir une politique et des objectifs et d’atteindre ces objectifs »
* le management de projet : ensemble des activités de management permettant la maîtrise du projet (management des coûts, management de délais, management des risques…). Ces activités ne consistent pas à réaliser le projet mais à le manager (gérer, maîtriser) Selon ISO10006, « planification, organisation, suivi, maîtrise et compte-rendu de tous les aspects d’un projet et de la motivation des personnes impliquées pour atteindre les objectifs du projet »
* la mise en œuvre du projet : ensemble des activités du projet visant à atteinte les livrables du projet : faisabilité, définition du contenu du projet, planification du projet, avancement, contrôle et surveillance (définition et suivi des coûts/ délais/ risques/….)
Partenaire de DantotsuPM
Listons les différents plans du projet
* Plan projet (monde de la « mise en œuvre du projet » ): contient les références de base pour la mise en œuvre du projet (qualité, contenu, performance, échéancier, coûts, risques, ressources…) sur toutes ses phases (lancement, préparation, réalisation et contrôle, clôture)
* Plan de management du projet (monde du « management de projet » ) : contient les dispositions de management du projet (la manière dont le projet est entrepris, suivi et maîtrisé. Définit les rôles, les responsabilités, l’organisation et les procédures pour chacun des processus de management de projet). Selon ISO 10006, document qui spécifie les éléments nécessaires permettant d’atteindre l’(les) objectif(s) du projet (Il convient que le plan de management du projet comprenne le plan qualité du projet ou s’y réfère)
* Plan qualité (entre les deux monde du « système de management » et du « management de projet » ) : c’est l’application / la déclinaison du système de management qualité à un projet un produit, un processus ou un contrat particulier. Pour un projet, c’est pour ainsi dire le système de management particulier pour le projet. Selon ISO 10005, ISO 10006, ISO 9000, « document spécifiant quelles procédures et ressources associées doivent être appliquées par qui et quand, pour un projet un produit, un processus ou un contrat particulier (Ces procédures comprennent généralement celles faisant référence aux processus de management de la qualité et aux processus de réalisation de produits. Un plan qualité fait souvent référence aux parties du manuel qualité ou à des documents de procédure) »
* Plan d’assurance qualité (monde du « management de projet » ) : c’est la partie du plan de management de projet dédié à l’assurance qualité, c’est à dire aux dispositions permettant de donner confiance a priori de la réponse aux exigences du projet. Selon iso 9000, « partie du management de la qualité visant à donner confiance en ce que les exigences pour la qualité seront satisfaites ».
Liens entre les plans
Source : formation « Qualité projet », V. Iacolare, Afnor Compétences (code stage 556)
Quel est le contenu des plans du projet ?
Chacun des plans ci-après comprend également d’autres plans ou y fait référence (par exemple le plan de management de projet comprend le plan d’assurance qualité).
* Plan projet : présentation du projet (contexte , objectifs, planning directeur & livrables…), organisation du projet, , structure technique du projet (AP, OT …), logique de déroulement du projet (ordonnancement, jalons, revues …), réseau des contributeurs (SDC, OF, ressources …), coûts et budgets, logique d’avancement du projet, risques (univers , fiche de risques, suivi et capitalisation des risques), documentation de management du projet (liste des documents, état, …), mesure et amélioration de la qualité…
* Plan qualité (selon ISO10005) : Domaine d’application , Éléments d’entrée du plan qualité, Objectifs qualité, Responsabilités de la direction, Maîtrise des documents et des données , Maîtrise des enregistrements , Ressources , Exigences , Communication avec les clients , Conception et développement., Achats, Production et préparation du service, Identification et traçabilité, Propriété du client, Préservation du produit , Maîtrise du produit non conforme, Surveillance et mesures, Audits.
* Plan qualité projet : appliqué à un projet, le plan qualité s’apparente au plan de management de projet s’il décrit les dispositions spécifiques pour un projet donné. Il s’apparente à une procédure du système de management qualité s’il décrit les dispositions génériques applicables à tous les projets.
* Plan de management du projet (selon RG Aero 0040) : dispositions de gestion de l’organigramme des tâches, l’organisation du programme, la logique de déroulement et suivi de programme, la maîtrise des coûts et des délais, la configuration, la performance et la sûreté de fonctionnement, le soutien logistique intégré, l’assurance qualité, la documentation,
* Plan d’assurance qualité : Standards / Référentiels du projet, Méthodes et outils à appliquer pour le projet , organisation d’AQ et lien avec l’organisation du projet, actions d’assurance qualité projet (Inspections, contrôles, traçabilité, revues, audits…) y compris la planification & coûts des actions d’AQ projet, dispositions d’amélioration
Comme avec une dette dans le monde réel, le truc avec la dette technique est de suivre vos dettes à la trace et de vous assurer que vous avez un plan pour les régler. Autoriser les dettes à croître sans réfléchir à ce que vous faites est une façon épouvantable de diriger vos finances personnelles comme votre projet de développement logiciel.
Tant que vous prenez des décisions informées et délibérées sur quand encourir de la dette et quand la rembourser, vous n’avez pas nécessairement besoin d’un plan pour éliminer totalement votre dette. Vous devriez plutôt aspirer à la garder à un niveau acceptable pour que vous puissiez ajouter de nouvelles fonctionnalités à votre produit relativement facilement et sans trop d’effets secondaires.
tenir un registre
Mon conseil numéro un avec la dette technique est de tenir un registre dans un format simple dans votre bibliothèque de code source et avec celui-ci. Un document « Markdown » est une façon simple et facilement compréhensible de faire ceci.
ajouter les nouvelles dettes
Assurez-vous que chaque développeur de l’équipe connaît et comprend ce registre. Chaque fois que vous ajoutez à la dette, ajoutez une ligne correspondante dans votre registre dans le même « commit » que le code en cause.
Parfois vous réalisez que vous ayez contracté une dette seulement après coup, peut-être parce qu’une bibliothèque que vous utilisez n’est pas aussi puissante que vous l’aviez pensé, ou parce que les besoins changent inopinément (ce que nous appelons ici ‘un changement explosif ‘). C’est OK, ces choses arrivent dans les projets logiciels. La chose importante est d’acquérir une bonne idée de la taille de la dette aussitôt que vous le pouvez et de vous assurer que vous la saisissez dans le registre.
retirer les dettes remboursées
Quand vous réglez à nouveau la dette, enlevez l’entrée correspondante du registre et replacez le registre dans la bibliothèque de code.
Faites une routine de conduire des revues régulières du registre de dettes et de vous assurer que vous avez un plan actif pour adresser chaque ligne. Une fois par itération est probablement une fréquence raisonnable pour faire cette passe.
Partagez le registre avec votre client et assurez-vous qu’il comprend la raison pour encourir toute nouvelle dette et la taille du remboursement probable. Cela signifie que vous devez les aider à comprendre la motivation d’une mise en œuvre sous-optimale, les effets secondaires qui vont probablement produire, aussi bien que le coût prévu pour perfectionner la solution mise en œuvre quand la dette sera réglée.
Vous le devez à vos clients pour les aider à comprendre l’impact de votre prise de décision collective sur un projet. Pas assez de personnes le comprennent. Tous les systèmes sont une collection de compromis et la dette technique est une des expressions de telles prises de décision. Ceci peut souvent être une conversation difficile si le concept de dette technique est nouveau pour votre client, mais votre honnêteté paiera sur long terme.
La chose la plus importante à comprendre pour des clients est qu’ils doivent avoir un budget pour le développement continu de leur projet. Trop de projets sortent et sont ensuite autorisés à se dégrader et dans des nombreux cas le client n’aura pas été mis au courant des conséquences d’une telle approche. Donc, ils peuvent s’attendre à ce que vous puissiez tout simplement reprendre là où vous vous étiez arrêtés, peu importe combien de temps a passé. Les aider à comprendre comment fonctionne le développement logiciel fait partie de votre travail si vous êtes technique.
« Grade Two debt: Developers making themselves feel more comfortable »
Si vous traitez avec de la dette de Catégorie 2, une dette de « confort », quand vos développeurs vous disent que vous devez récrire votre système, la meilleure chose à faire pour désamorcer les émotions inhérentes est de leur faire créer un registre de dettes pour vous. Chaque entrée dans le registre devrait être clairement compréhensible par des développeurs et des personnes non techniques également et elles devraient toutes être actionnables.
Demandez-leur d’évaluer l’effort impliqué dans la résolution de chaque ligne du registre dans un jeu de planification et comparez ce coût au coût de reconstruire en repartant de zéro. N’oubliez pas que si vous les laissez reconstruire le système, ils construiront un système qui inclut aussi une nouvelle dette car le système sans dette n’existe pas. Alors, factorisez aussi cela dans le coût de remboursement.
Il est presque certain que vous constaterez qu’il est plus efficace financièrement de modifier le système existant que de le reconstruire.
pour conclure
La dette technique judicieusement encourue et bien gérée peut faire partie d’une approche raisonnable du développement logiciel. Simplement, n’oubliez pas d’avoir un plan de remboursement de la dette avant que les gros bras récupérateurs de créances ne viennent vous voir avec leurs barres de fer et portent in intérêt tout particulier à vos genoux.
partagez ce billet avec vos amis, collègues et relations professionnelles
« Test is Dead » était le titre provocateur de la présentation d’ouverture à la 6ème Conférence Annuelle d’Automatisation de Test chez Google (GTAC) en 2011 par Alberto Savoia
La façon dont la plupart des logiciels sont conçus, développés et lancés a radicalement changé au cours de la dernière décennie, mais qu’en est-il du test ? Alberto Savoia croit que le test de logiciel tel que nous le connaissions est mort, ou du moins moribond. Sur cette idée directrice, Alberto lapide la vieille mentalité de test et donne son meilleur pour vous faire réfléchir et vous convaincre que, de nos jours la plupart des testeurs devraient adopter une nouvelle mentalité de test. Celle-ci changera leur focus et leur priorité du « construisons-nous bien ? » vers le « construisons-nous la bonne chose ? ».
Le sous-titre de GTAC 2011 était « nuageux avec une chance de tests » (« »cloudy with a chance of tests »), or, si quelqu’un peut rassembler les nuages pour en faire un ouragan c’est Alberto !
Alberto Savoia
Alberto Savoia est le Directeur d’Ingénierie et l’Agitateur d’Innovation à Google (« Director of Engineering and Innovation Agitator at Google »). En plus de supporter plusieurs efforts de développement de produits majeurs (incluant le lancement de Google AdWords), Alberto a été un partisan perpétuel, un champion, un innovateur et un entrepreneur dans le domaine du test et des outils d’automatisation de test. Il est un orateur de talent dont vous apprécierez certainement en autres les formules « Waterfall ou Waterfail? » et « Agile ou FR-Agile » ou encore le concept de prEtotyping. Son travail sur les outils de développement logiciels lui a valu plusieurs récompenses incluant le Technical Innovator Award 2005du Wall Street Journal , la Technologiede l’année chez InfoWorld et pas moins que quatre Award du Magazine de Développement Logiciel Jolt.
Alors appréciez la première demi-heure de sa présentation dont la mise en scène est de nature à capturer immédiatement l’attention du public.
partagez ce billet avec vos amis, collègues et relations professionnelles
Il y a une grande différence entre une équipe d’athlètes qui perd et une équipe de développement qui perd : Personne ne se rappelle des athlètes arrivés en dernière position, mais tout le monde se souvient quand l’application délivrée par une équipe logicielle échoue spectaculairement et fait la une des journaux et blogs dans le monde entier.
De même que les athlètes ne gagnent pas de médailles d’or d’un jour à l’autre, les équipes de développement de logiciels très performantes ont besoin d’expertise, de discipline et d’un engagement à l’excellence. CAST a rassemblé certaines de ses meilleures ressources pour vous aider à vous assurer que votre équipe est parmi les meilleures, parcourez leur tout nouveau « infotoon » (illustrations amusantes de plusieurs papiers blancs sur ces sujets) pour aider votre équipe à concourir pour l’or!
partagez ce billet avec vos amis, collègues et relations professionnelles
Que vous soyez chef de projet informatique ou responsable de tout projet qui comporte une partie d’informatique, ce rapport est à lire pour mieux comprendre certains des challenges liés à la qualité des logiciels applicatifs.
Bien que ce ne soit une surprise pour personne je l’espère, le CAST Report on Application Software Health (CRASH) a confirmé que les organisations gaspillent des millions de dollars dans la dette technique en raison de problèmes avec leurs logiciels applicatifs, problèmes qui auraient pu être éliminés pendant la mise en production si les évaluations structurelles techniques appropriées avaient eu lieu.
Bill Curtis
Selon le Docteur Bill Curtis, le scientifique en chef chez CAST Software, la plupart des sociétés ne prévoient pas suffisamment de budget pour la maintenance de leurs applications et ceci nuit gravement à leur compétitivité dans leurs marchés.
Cette étude est la plus grande analyse automatisée jamais conduite et utilisée pour mesurer la qualité structurelle de 365 millions de lignes de code dans 745 d’applications informatiques utilisées par 160 sociétés partout dans 10 industries.
La prochaine édition du rapport doublera pratiquement le nombre d’applications analysées.
5 “facteurs de santé” des applications informatiques ont été passés en revue pour déterminer leur bonne santé structurelle : sécurité, performance, robustesse (c’est-à-dire, temps de disponibilité) et la facilité à faire évoluer et à transférer le logiciel. Malgré des estimations conservatrices, telle que les 75 $ de l’heure pour réparer les logiciels qui ne prennent pas en compte le coût business d’indisponibilité des applications et éventuelles pénalités commerciales, les chiffres parlent d’eux-mêmes : une grande partie des applications étudiées excèdent les $3M de dette technique !
Peut-être même plus inquiétant, plus d’un tiers (35 %) des problèmes rencontrés auraient un impact direct sur le business. Ces problèmes se répartissent majoritairement entre les domaines de la performance, la sécurité et la robustesse et fournissent la confirmation que les sociétés doivent prêter une bien plus grande attention à la qualité structurelle des logiciels sous peine de faire face à des aléas très coûteux qui affecteront défavorablement leur réputation.
CRASH – Security Scores per Technology
Points saillants de l’étude:
La qualité structurelle est la plus faible pour les applications ayant 6 versions ou plus déployées chaque année (1 version tous les 2 mois)
Les applications avec le plus grand nombre d’utilisateurs sont aussi les mieux notées sur l’aspect maintenabilité
Les vieilles applications COBOL sont mieux sécurisées que celle en .NET qui ont reçu les plus faibles scores coté sécurité
Les applications externalisées et développées en interne ne sont pas très différentes quant à la qualité de leur structure. Il en va de même pour les développements Onshore et offshore.
Des méthodes de développement bien établies comme agile et « en cascade » obtiennent des résultats significativement meilleur sur la qualité structurelle que les méthodes propriétaires.
La méthode développement « en cascade » donne les meilleurs scores de transférabilité et de facilité d’évolution.
Coté performance, les applicatifs en Java se situent bien au-dessous des COBOL !
Téléchargez ce rapport gratuit en cliquant sur cette image
partagez ce billet avec vos amis, collègues et relations professionnelles
En détaillant ce schéma, nous voyons qu’il évoque des concepts communs au management de projet :
• PLAN : un projet se caractérise par un planning, la définition d’objectifs et une analyse des risques
• DO : un projet « produit », des fonctions issues de l’expression de besoins, sous forme de livrables, de solutions, de propositions, etc.
• CHECK : un projet se pilote notamment avec des revues de projets, des indicateurs, des audits.
• ACT : un projet fait l’objet d’un bilan pour le retour d’expérience et déclencher, si besoin, des actions d’amélioration.
Au final: de nombreuses convergences entre la logique qualité et celle des projets.
Ceci a conduit à des travaux normatifs sur la qualité dans le domaine des projets que nous allons résumer ci-dessous :
• NORME ISO 10006de 2003 : lignes directrices pour le management de la qualité dans les projets : cette norme donne des indications pour avoir une démarche qualité dans les projets. Il n’y pas de certification par tierce partie ISO 10006 mais des audits (internes ou externes) peuvent être conduits par rapport à ce référentiel.
• Projet de NORME ISO 21500 sur la gestion de projet : en cours d’élaboration avec d’âpres discussions. Sa publication est prévue en 2012.Cette norme permettrait une certification par tierce partie comme pour l’ISO 9001.
Des documents AFNOR existent sur le management de projet :
• FD X 50-115 de 2001 : management de projet : présentation générale
• FD X 50-116 de 2003 : management de projet : management par projet : présentation et recommandations de mise en œuvre
Des documents spécifiques à certains points du management de projet complètent ces normes générales :
• ISO/CEI 62198-2002: Gestion des risques liés à un projet : lignes directrices pour l’application
• Projet FD X 50-047 : expertise de projet
• FD X 50-117 : management des risques dans les projets
• FD X 50-118 : recommandations pour le management d’un projet
• FD X 50-137 : management des coûts
• FD X 50-138 : management des délais
En conclusion, la gestion de la qualité et des projets ont beaucoup de points communs et peuvent s’aider mutuellement pour garantir et améliorer les performances d’une organisation.
Article écrit par Jean-Baptiste Jourdant, consultant-formateur et Responsable du département Management de projet pour CSP Formation et partenaire de DantotsuPM. Retrouvez cet article sur le blog Management de Projet de CSP Formation à l’adresse suivante : http://management-projet.cultivezvostalents.fr
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
J’apprécie très souvent les billets de Seth Godin. Ils sont à la fois provocants et pleins d’intelligence, de bon sens et de malice. En bref, ils donnent à réfléchir.
Celui-ci est dans la ligne de pensée de ce blog DantotsuPM et de la recherche de l’excellence pour constamment dépasser les attentes des clients et en faire ainsi de vrais fans de nos produits et/ou services. Des membres de notre tribu comme le dirait Seth. La tribu des chefs de projet qui cherchent en permanence à s’améliorer.
Dans la plupart des domaines, il y a une quantité terrible de travail mise dans les dix derniers pour cent de qualité.
Amener votre score de golf de 77 à 70 est bien plus difficile que de l’amener de 120 à 113 ou même de 84 à 77.
Répondre au téléphone à la première sonnerie coûte deux fois plus cher que de le laisser entrer dans une file d’attente.
Faire des pâtisseries comme un excellent restaurant demande beaucoup plus de travail que de faire des gâteaux au chocolat à la maison.
Concevoir la présentation d’une page ou d’une brochure qui ressemble à celle d’un pro demande environ dix fois autant de travail que d’utiliser simplement les modèles gratuits incorporés dans Microsoft, et le message est presque identique…
Sauf qu’il ne l’est pas. Bien sûr que non. Le message n’est pas identique.
Les dix derniers pour cent sont le signal que nous recherchons, la manière dont nous communiquons le soin, l’expertise et le professionnalisme. Si tout que vous faites est de niveau standard, tout ce que vous allez obtenir est une rétribution standard. La partie difficile est dans les dix derniers pour cent, bien sûr, voire même le tout dernier pour cent, mais c’est la partie difficile parce que tout le monde est déjà occupé à faire la partie facile.
Le secret est de rechercher le travail dont la plupart des personnes pensent qu’il ne sera pas valorisé en rapport de l’effort. C’est pour cela que vous êtes payé.
partagez ce billet avec vos amis, collègues et relations professionnelles
Cet article de James T. Brown, PhD, PE, PMP sur PMI.ORG (original full article in English here) pose un problème que nous rencontrons trop souvent sur le poids de la qualité dans le sacro-saint triptyque des projets: coût, qualité, délais.
Chacun aime prendre de la fierté dans son travail. Cela inclut les chefs de projet et les équipes projet. Souvent cette fierté est mise à mal parce que la pression pour tenir les délais et le coût aboutit à des sacrifices sur la qualité.
Ironiquement cela aboutit fréquemment à des dépenses supplémentaires, des retards de planning importants ou des projets “suite” pour adresser les manques de qualité. Un centre sur la qualité est le bon sens et mieux à long terme.
Malgré cela, c’est un problème organisationnel très commun de renoncer à la qualité pour atteindre des cibles de coût et de planning. Dans l’environnement économique d’aujourd’hui, la pression sur les coûts est énorme. Une fois que quelques leaders commencent à se concentrer sur le coût, cela peut devenir tout ce dont ils se soucient.
Cette attitude, répétée pendant la durée des cycles de projet ou des années, s’enracine. Comme un collègue me l’a récemment fait remarquer, “Nous l’avons fait encore…dans les temps…dans le budget…pauvre qualité.”
En fin de compte, la mauvaise qualité des livrables du projet a ses racines dans un manque de responsabilité pour cet aspect du projet. On juge régulièrement les sponsors de projet sur ce qui est facilement quantifiable, comme les coûts et l’atteinte des cibles planifiées, tandis que la qualité est juste assumée être délivrée. C’est amplifié s’il y a un manque de communication et/ou un lien de responsabilité faible entre utilisateurs ou clients et les sponsors de projet.
Le chef de projet peut faire plusieurs choses pour améliorer la qualité des livrables pour des projets dans des environnements où les coûts et les délais sont rois.
Identifiez les Joueurs Clefs
Pour améliorer la qualité, il est impératif d’identifier qui sont les sponsors de projet et ce qui pilote leur comportement. Qui (ou quoi) fait que le sponsor soit centré sur les coûts et les délais ? Comment le sponsor est-il personnellement impacté par la mauvaise qualité des livrables ? Qui sont les utilisateurs et les clients ?
Le rapport entre l’utilisateur, le client et le sponsor devrait aussi être compris et documenté. Comment l’utilisateur du livrable du projet communique-t-il (ou pourrait-il communiquer) des problèmes de qualité au sponsor ? Les sponsors sont souvent à un tel haut niveau dans l’organisation par rapport aux utilisateurs qu’il n’y a aucun canal de communication.
Rassemblez des Données
Ma définition de geindre est se plaindre sans données. Chaque fois que la qualité n’atteint pas l’objectif défini pour une quelconque raison, l’impact de cette non-conformité doit être documenté.
À la fin d’un projet, les chefs de projet se concentrent souvent rapidement sur le projet suivant. Ils peuvent rater l’occasion d’échanger avec les utilisateurs ou de faire un suivi efficace pour identifier les dépenses dues à une mauvaise qualité sur des livrables précédents du projet. Ces informations sont essentielles pour construire un argument fort de créer à l’avenir un focus sur la qualité.
Souvent, des leaders organisationnels regarderont une livraison de projet qui n’a pas atteint les pré-requis de qualité comme une anomalie ou ils auront le sentiment qu’il y avait des circonstances spéciales sur ce projet. Mais quand vous pouvez présenter des données de plusieurs projets ou celles de tous les projets sur une longue période, cela renforce le fait qu’il faut faire quelque chose.
Exploitez les opportunités
Le chef de projet a maintenant des données sur le coût d’une mauvaise qualité. Lui ou elle doit en faire comprendre l’impact aux sponsors et développer les arguments pour la nécessité de changement.
Le fait que ce problème et cette culture existent dans des organisations indique que c’est au moins en partie de nature politique. Cela signifie qu’il ne suffit pas d’avoir raison. Il ne suffit pas d’avoir des données. Vous devez analyser l’organisation et la politique pour identifier quand et comment faire progresser votre sujet.
Il y a des circonstances et des moments où l’organisation peut être plus réceptive. Quand cette occasion surgit, vous devez être prêts à intervenir avec les données qui montrent l’impact du problème et aussi proposer des solutions.
Mon expérience est qu’un “ papier de position” professionnel, écrit de manière persuasive, qui encapsule le problème et la solution, est essentiel. Il devrait être écrit dans des termes et dans le contexte qui sont importants pour les joueurs clefs. Une présentation peut accompagner le papier de position, mais le papier de position peut être envoyé aux joueurs clefs que vous avez identifiés et qui sont essentiels pour exécuter un changement.
En surface, le problème de renoncer à la qualité pour atteindre le planning et les cibles de coût semble simple à réparer — mais il ne l’est pas.
Des réparations simples ou rapides ne fonctionnent pas et aboutissent à de la frustration. Si vous voulez être un champion de la qualité dans un environnement centré sur les coûts, acceptez le fait que vous exécuterez un marathon et non pas un sprint et que ce sera une course que vous devrez répéter de nombreuses fois.
partagez ce billet avec vos amis, collègues et relations professionnelles
Comme l’on peut aisément le comprendre, trouver des défauts pendant la toute dernière phase de vérification est onéreux, aussi les efforts se positionneront-ils le plus tôt possible, dans la définition des normes et procédures à respecter pour les atteindre.
DantotsuPM.com 