Tag Archives: qualité

May 15 – Webinar – Get The Most Out Of Your Software Risk Management Strategy This Year

8 mai

Register now to hear CAST SVP & Chief Scientist, Dr. Bill Curtis, discuss the current state of the IT software industry and it’s impact on your software risk management strategy.

CRASH - Security Scores per Technology

CRASH 2012 – Security Scores per Technology

Every week CIOs are seeing the staggering costs and business consequences of software problems in their critical applications. Consequently they are placing greater emphasis on their software risk management strategy.

Did the switch to Agile reduce defects and cost of ownership? Should we stick with our existing outsourcer? Is there a quality difference between domestic and offshore development? And, lastly, did we reduce our technical debt overall?

Traditionally these types of decisions were made by an in-house tech guru who — through experience and gut-instinct — dictated where their IT’s strategy and risk management were headed.

But now, CIOs have access to the single largest software structural quality dataset in the IT industry.

Join CAST on Thursday, May 15, 2014 as we examine the findings from the 2014 CRASH Report, looking at trends in technical debt, sourcing choices, development methods, and other factors that affect the structural software quality of business critical applications. CAST’s Appmarq Repository now encompasses over 1300 large IT applications written to support all sorts of enterprise business processes in 11 industry sectors such as finance, retail, telecommunications, and government.

Register now for our 30-minute webinar on the state of the IT Software Industry.

Date:  May 15, 2014 at 17:00 CET/France

Partenaire de DantotsuPM

Partenaire de DantotsuPM

votre Projet est-il un succès ? comment jugez-vous si un projet est réussi ?

2 sept

Is Your Project a Success?

http://www.pmhut.com/project-management-foundations-is-your-project-a-success Par Steve Hart

Beaucoup de chefs de projet déclareront fièrement, "Ce projet est un succès majeur : nous avons livré à l’heure et dans le budget". Quand vous prenez le temps de parler à certains des clients de ces projets, vous entendez une version différente. Dans des nombreux cas, le client décrit un produit livré qui ne répond pas à ses attentes. Dans d’autres cas, le client décrit des processus de projet peu collaboratifs ou peu orientés clients. Je me réfère ici aux cas où vous atteignez finalement les objectifs du projet mais, en fait, des parties prenantes ne sont pas contentes de la façon  dont vous l’obtenez.

S’il y a plus au succès d’un projet que la livraison dans les limites de la triple contrainte (temps, coûts et contenu), comment jugez-vous si un projet est réussi ? Selon mon expérience, ces paramètres sont un bon point de départ, mais elles ne dépeignent pas "l’image totale". Le succès de projet devrait aussi prendre en considération l’impact que le projet a sur l’organisation, les processus utilisés pour livrer le projet et ce que les clients pensent des résultats du projet.

Ce billet couvre mes idées sur que l’on devrait considérer quand on définit le succès de projet, ainsi que les responsabilités du chef de projet et des responsabilités liées au succès du projet.

Votre réussite passe par la performance de vos projets !

Partenaire de DantotsuPM

À quoi le succès ressemble-t-il ?

Dans le contexte de livraison de projet, le succès est généralement défini en termes d’atteintes d’objectifs définis au préalable. On juge souvent que des projets sont réussi en se basant sur davantage que les buts/objectifs établis dans la charte de projet ou le plan de management de projet et les chefs de projet s’en plaignent. Ci-dessous sont les facteurs que je considère quand j’évalue le succès de projet.

  • Temps et Coût

balance temps vs ressourcesLa date de livraison effective du projet et les coûts sont-ils plus faibles et plus tôt (en prenant en compte l’impact de tous les changements approuvés) ? Le temps et le coût sont les facteurs de succès dont les chefs de projet parlent le plus. Ceux-ci sont les facteurs que les chefs de projet sont directement responsables de manager. De plus, ces facteurs de succès sont relativement faciles à mesurer et à montrer.

  • Contenu

Le projet a-t-il livré ce qui devait être livré ? Le contenu n’est pas limité aux fonctionnalités et fonctions du produit. Le contenu inclut aussi les livrables qui assurent que le produit est correctement implémenté et supporté. J’ai vu mon quota de projets considérés comme des échecs en raison du manque d’attention aux livrables comme la formation, le marketing/adoption du produit et les processus de support.

  • Qualité

cadeauxLe produit livré exécute-t-il la fonction qu’il était sensée exécuter ? Beaucoup d’équipes projet tombent dans le piège de juger la qualité de produit seulement basée sur le nombre de défauts identifiés. Il ne faut qu’un ou deux défauts pour empêcher le produit de fonctionner comme prévu. Les mesures de qualité sur lesquelles on devrait juger du succès devraient être basées sur la capacité à atteindre les objectifs opérationnels (par exemple, le nombre de transactions traitées, le nombre moyen d’appels par heure) et la capacité de répondre aux problèmes liés au produit.

  • Processus

Les processus ont-ils été efficacement utilisés pour livrer les éléments clés du projet ? Les processus comme le contrôle des changements, les communications et le management de ressources peuvent significativement influencer la perception de réussite du projet. Les buts prédéfinis du projet peuvent avoir été achevés, mais s’il a été livré sans collaboration ou avec une flexibilité limitée, les parties prenantes peuvent ne pas voir les résultats de façon positive.

  • Significativité

Le projet a-t-il livré a-t-il eu un impact positif sur l’organisation ? Les projets qui ont peu ou pas d’impact sur l’organisation devraient-ils être considérés comme réussis ? En tant que chef de projet, vous pouvez dire, "ce n’est pas ma faute si le projet n’a pas livré les bénéfices escomptés par l’organisation". Ceci peut être vrai, cependant j’ai vu beaucoup d’exemples de projets où ce qu’a été livré, ou comment cela a été livré, avait un impact direct sur les bénéfices réalisés. J’ai aussi managé les projets qui ont été livrés en retard ou en dépassement de budget, mais qui ont fourni des bénéfices qui ont de loin dépassé des attentes et ont donc été considérés comme des succès.

  • Parties prenantes

customer satisfactionLes parties prenantes sont-elles satisfaites des résultats du projet ? Les parties prenantes sont les personnes qui ont été impliquées ou ont été impactées par le projet. C’est un problème si l’ensemble de la communauté des parties prenantes, ou de grands segments de la communauté des parties prenantes, ne parlent pas positivement du projet. Le retour d’information peut être une mesure très subjective de succès, mais je crois vraiment que comment les gens "ressentent" le projet est un composant valide du succès du projet. Dans la plupart des cas, des actions spécifiques peuvent être prises pour changer la nature du retour d’information reçu des parties prenantes. Ne prenez pas ce retour d’information à la légère.

6 Façons d’améliorer le succès du projet

Je suis un ferme partisan du fait que le rôle du chef de projet influence significativement le succès du projet. Ci-dessous sont six domaines de bonnes pratiques de management de projet qui ont un impact direct sur le succès du projet.

1. Organisation de Projet

les communications dans l'équipeLa formation de l’équipe projet semble assez basique, mais il est étonnant de voir combien d’équipes projet lancent leur projet sans analyse performante des parties prenantes et définition de l’organisation de projet. Les éléments importants de l’organisation de projet incluent les sponsors de projet, l’équipe principale et comprendre quelles sont les autres parties prenantes clés. Obtenir les "bonnes" personnes sur les "bons" rôles a un impact significatif sur la capacité des équipes projet de répondre aux besoins de l’organisation.

2. Plan de référence de base

En tant que chef de projet on vous présente tout le temps de nouvelles situations (de nouveaux clients et de nouveaux projets) et il est extrêmement important de rapidement donner aux équipes la bonne direction dans le processus de planification. Adapter une approche de planification cohérente de client en client et de projet en projet, améliore significativement les résultats du processus de planification de projet (tant les délais de livraison que la qualité des plans). Des plans de référence forts représentent la fondation d’un processus de livraison fructueux de projet.

3. Mesure de la performance de projet

avis perso KPIsCe domaine de bonnes pratiques implique de garder vos yeux sur les mesures de performance appropriées pour le projet afin d’identifier proactivement des problèmes potentiels et mettre en route l’équipe pour identifier et implémenter des actions rectificatives. L’utilisation efficace de métriques de performance de projet (les KPIs) aide le chef de projet à identifier et implémenter les ajustements d’exécution appropriés au projet avant qu’ils ne deviennent "de gros problèmes" que les parties prenantes ne seraient pas prêt d’oublier.

4. Collaboration

L’engagement actif des parties prenantes dans des activités de projet a un impact significatif sur comment les gens se sentent à la fin du projet. Les chefs de projet améliorent la collaboration sur le projet en facilitant des rencontres d’équipe efficaces, en implémentant des outils et processus de collaboration et fournissant des mises à jour de projet cohérentes et utiles.

5. Gestion du changement

unexpected eventLe changement est un composant inévitable de manager un projet : rien ne se déroule jamais exactement comme planifié. Le chef de projet effectif gère le changement en maintenant l’équilibre approprié entre contrôle et discipline pour réussir à tenir les lignes de référence et la flexibilité à adapter les plans et respecter les attentes des clients. Le niveau de contrôle et de rigueur autour de l’analyse et l’approbation de changements devrait être convenablement "taillé" pour l’organisation et pour le projet.

6. Clôture de projet

À la fin d’un projet, beaucoup de chefs de projet sont occupés à préparer leur projet ou le client suivant et manquent une opportunité majeure de laisser un impact durable sur l’organisation client. La clôture de projet commence effectivement par la fermeture des activités de projet, la validation que tous les livrables produits sont complets et que les problèmes clés sont clos et la transition en souplesse des ressources vers de nouveaux rôles. Le deuxième aspect de ce domaine de bonnes pratiques est de préparer un rapport sur la performance du projet (aussi appelé évaluation post-projet). La création du rapport de performance projet inclut la collecte des retours des parties prenantes principales et l’identification d’actions d’amélioration à implémenter pour terminer ce projet ou pour des projets futurs. Ces actions d’amélioration peuvent influencer significativement la perception des parties prenantes du succès du projet.

Vos commentaires seraient comme toujours fort appréciés. Quelle est votre expérience sur juger du succès de vos projets ?

Campana & Schott

Partenaire de DantotsuPM

Tout savoir sur les plans (qualité) projet, Synthèse Synertal

9 juil
Vincent Iacolare

Vincent Iacolare, Synertal

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/….)

Votre réussite passe par la performance de vos projets !

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)

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

Sources :

  • retours d’expérience Synertal.com et beeznet.fr
  • FD ISO 10005 :2005  Systèmes de management de la qualité – Lignes directrices pour les plans qualité
  • ISO 10006:2003  Systèmes de management de la qualité — Lignes directrices pour le management de la    qualité dans les projets
  • ISO 21500 :2012 – Lignes directrices sur le management de projet
  • Formation « Qualité dans les projet », V. Iacolare, Afnor compétences (code stage 556)
Campana & Schott

Partenaire de DantotsuPM

5 actions qui vous aideront à vendre ce projet si compliqué

15 mar

5 Actions That Will Help You Sell That Complicated Project

http://www.pmhut.com/5-actions-that-will-help-you-sell-that-complicated-project par Michael Greer

7 traits de personnalité des meilleurs commerciaux

relisez ce billet sur les 7 traits de personnalité des meilleurs commerciaux

Reconnaissons-le. Vous ne seriez pas chef de projet si vous vous étiez imaginé en personnel commercial. En effet, la plupart des chefs de projet, particulièrement ceux qui sortent des rangs des équipes projet et des experts techniques, détestent tout le "cinéma" qu’implique la partie vente de leurs projets.

Mais la vérité est il n’y a simplement personne que vous qui soit dans une meilleure position de mettre en évidence les capacités techniques étonnantes de votre équipe et la valeur qu’elle apporte à votre organisation à travers votre projet. Qui plus est, comme votre projet progresse, vous allez avoir besoin du support enthousiaste de la direction pour vous aider à obtenir les fonds, les personnels, les installations, l’équipement et la participation des experts métier qui amèneront au succès. Donc c’est à vous et aux actions spécifiques que vous entreprenez de construire cette vente et de générer cet enthousiasme si nécessaire du management.

Alors, par où commencer ? Voici 5 actions qui peuvent vous aider à vendre votre projet à la direction :

1. Prouvez que vous comprenez le problème business qu’adresse votre projet.

cliquer pour lire l'artice de PM Network

cliquer pour lire l’artice de PM Network

Spécifiquement, vous devez expliquer (ou encore mieux, démontrer par la preuve, les chiffres du retour sur investissement, etc) comment vos livrables élimineront une zone de douleur de votre organisation, augmenteront son efficacité, feront économiser de l’argent et auront un impact tangible.

2. Montrez comment chaque livrable ajoutera de la valeur.

Spécifiquement, vous devez faire la connexion entre chaque item que vous créerez et comment il contribue à la valeur de la solution finale. (Et non … vous ne pouvez pas assumer qu’ils peuvent déjà voir ces connexions simplement parce qu’elles vous sont évidentes!). Donc, vous devriez rapidement passer à travers la liste de vos livrables et aider le sponsor à voir comment chacun est essentiel à la qualité de la solution complète. Ceci devrait inclure les livrables de projets intermédiaires comme des graphes de flux, de premiers jets de livrables, etc. Si possible, montrez des modèles, des maquettes, des démonstrations, ou quoi que ce soit qui puisse le matérialiser et produire cette étincelle d’enthousiasme qui gardera votre sponsor à vos côtés dans les jours potentiellement difficiles à venir.

3. Connectez tout le processus de travail à la qualité (y compris les cycles de revue/approbation).

inspecter les livrablesEn langage clair, montrez comment le processus de travail est aussi "Lean" qu’il peut l’être, tout en fournissant les contrôles essentiels (revue d’expert et de management, participation collaborative, etc.) qui garantiront la qualité. Si approprié, montrez comment votre processus de travail est en phase avec les "bonnes pratiques" de l’industrie ou des concurrents.

4. Démontrez comment chaque membre de votre équipe projet fournit une valeur unique.

Eclairez-les sur l’expertise étonnante que vous avez rassemblée et comment chaque membre de votre équipe apportera une contribution unique à la qualité du produit final. Ceci est particulièrement important pour les membres de l’équipe qui demanderont éventuellement au sponsor l’accès à des ressources clés et autre support quand le projet avance. Cela aide vraiment si, quand le membre de l’équipe frappe à cette porte pour demander de l’aide ou un retour d’information, il le fait en tant que membre "pré-valorisé" de l’équipe projet.

5. Distinguez votre projet de projets apparemment similaires, mais moins complexes ou apportant moins de valeur.

approter des différencesQu’est-ce que cela signifie ? Simplement ceci : les Sponsors voient et approuvent des tas de projets. Et, après peu de temps, ils commencent à voir des modèles qui se répètent dans la façon dont ces projets se déroulent. Éventuellement, ils développent des attentes sur les processus de travail et les délais qui amènent à des types semblables de livrables. Étant donné ces attentes, les cadres supérieurs les plus durs et expérimentés voudront presque toujours connaître votre réponse à ce défi : "j’ai vu que des équipes projet semblables créent des résultats similaires en utilisant les processus qui étaient beaucoup moins compliqués. Alors pourquoi vos gars prennent-ils si longtemps et dépensent-ils tant de temps pour réaliser les mêmes sortes de résultats que le Projet XYZ ?". Si vous voulez emporter la vente (et le support enthousiaste de votre sponsor) tout en restant fidèle à vos bonnes pratiques, vous devrez avoir une bonne réponse à cette question!

23 janvier – Paris – Séminaire "Normes et Référentiels… le ticket gagnant pour manager les projets !"

11 jan

Journée entière !

Afitep Dico management de projetISO 21 500, ISO 10 006, PMBoK, ICB, textes normatifs français, allemand, anglais, Prince2, Hermès, etc. les référentiels et les normes relatifs au management de projet sont nombreux et divers !

De quoi rendre perplexe tout chef de projet , responsable Qualité, manager de Bureau des Projets, lorsqu’il faut choisir le ou les cadres de référence les plus adaptés aux besoins de leurs projets. Pourtant, les normes et référentiels peuvent vous faire gagner un temps précieux et améliorer l’efficacité de vos équipes projets, que vous disposiez ou non d’un référentiel de management de projet interne à votre organisme.

Au cours de ce séminaire vous pourrez faire le point sur les normes et référentiels existants, leurs spécificités, complémentarités…et leur probable évolution.

Avec : Martine MINY, Présidente AFITEP, Présidente de la Commission AFNOR « Management de projet » d’octobre 2000 à juin 2012
et Hervé COURTOT, Vice-Président AFITEP en charge des référentiels, Président de la Commission Terminologie

une stratégie simple pour gérer la dette technique

19 nov

A simple strategy for managing technical debt

http://madebymany.com/blog/a-simple-strategy-for-managing-technical-debt par James Higgs

Auparavant, j’ai essayé d’expliquer le concept de dette technique. Aujourd’hui, j’essayerai de suggérer une façon pratique de la suivre à la trace et de la traiter dans votre projet.

dettes techniquesComme 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.

paiementPartagez 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"

faire la somme des dépensesSi 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.

le test est mort par Alberto Savoia

26 sept

"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.

les geek games : la bataille pour la dernière place

21 août

CAST Software futur partenaire de DantotsuPM

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!

"CRASH Report" – Chefs de projets informatiques ne ratez pas cet immanquable rapport gratuit sur la qualité logicielle

23 juil

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.

Que nous révèle le CAST Report on Application Software Health (CRASH) ?

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

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

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é
  • CRASH - Quality onshore vs offshoreLes 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 !
The Crash Report 2011-2012

Téléchargez ce rapport gratuit en cliquant sur cette image

les coûts intangibles de la (non) qualité dans les projets

20 juin

The Intangible Costs of Quality

http://www.pmhut.com/the-intangible-costs-of-quality par Michael Donahoe

"Personne ne s’efforce de faire un mauvais travail. Parfois nous le faisons."

Il y a beaucoup de façons de mesurer le coût de qualité sur vos projets. Il y a les coûts de conformité, soit Coûts préventifs et Coûts d’évaluation. Il y a aussi les mieux connus Les coûts de non-conformité qui se répartissent entre Coûts d’échec internes et Coûts d’échec externes. Tous ces coûts ont très bien été étudiés et il y a beaucoup de livres les concernant. Je voudrais les passer en revue et en vous donnant un éclairage sur une valeur cachée que j’appelle Les coûts intangibles de la qualité.

D’abord discutons le coût de conformité : coûts préventifs et coûts d’évaluation.

Coûts de prévention

risk managementCeux-ci sont des coûts encourus lors des actions de formation, des évaluations de risques et la création de contrôles des systèmes et processus. Ces actions supporte le mantra de la qualité, "Faites le bien dès la première fois et vous n’aurez pas y revenir."

Tout sur les coûts de prévention est relativement intangible à un certain degré. Essentiellement, vous devinez, surtout en faisant des suppositions bien informées, sur comment éviter de faire une erreur. Nous regrettons tous de ne pas avoir de boule de cristal pour prévoir à l’avance les problèmes du projet, mais malheureusement elle n’existe pas.

L’intangible coté prévention est que quoi que ce soit que vous fassiez ici entre dans les frais généraux et faire des suppositions mal informées peut être très coûteux. La meilleure méthode est d’avoir un bon retour d’information en provenance de vos systèmes d’évaluation.

Coûts d’évaluation

inspecter les livrablesC’est principalement le surveiller et contrôler de votre projet. Les coûts d’évaluation sont ces coûts relevant des inspections de projet (comme les vérifications sur le produit et/ou le travail effectué). Ils représentent essentiellement le coût de votre service qualité (l’analyse exécutée pour déterminer si la qualité est réalisée et suivie).

Le coût intangible est ici quand une société devient intelligente sur les centimes et stupide sur les euros par une sur-analyse dans laquelle elle dépense beaucoup trop sur la collecte de données plutôt que mettre place des actions de prévention. La meilleure méthode ici pour les organisations est d’appliquer des méthodes d’échantillonnage afin de découvrir si l’analyse exécutée vaut le temps et les coûts impliqués. Le coût d’évaluation ne devrait jamais dépasser celui des coûts de non-conformité ou des échecs.

Les coûts de non-conformité sont composés tant des coûts d’échec internes, que des coûts d’échec externes.

Coûts d’échec internes

Ils sont typiquement causés par des échecs dans votre processus. Jeter par exemple du matériel pour avoir trop commandé. Refaire une chose déjà faite est ici le grand coupable. Si vous devez refaire quelque chose pour respecter le contenu attendu par le client alors c’est un échec.

Comme je l’ai dit que ceci est l’un des coupables les plus connus des personnes réalisant l’étape de mise en œuvre de tout projet. Je suggérerais que dans la plupart des cas, ce n’est pas en raison des individus exécutant la mise en œuvre au plus bas niveau, mais en raison d’une des choses suivantes : une faible communication, de pauvres spécifications sur que les besoins à satisfaire, un problème de temps ou de budget (qui est souvent le coupable pour la pauvre spécification), ou une prévention inadéquate (la formation, le processus, Etc.). L’intangible est ici que ceux-ci démoralisent les personnes impliquées dans le déploiement de vos projets, s’ensuit un jeu de recherche de qui blâmer, les boîtes de courrier électronique explosent soudainement, des silos départementaux se crééent diminuant les communications, les données pour la prévention et l’évaluation deviennent difficiles à acquérir et une ambiance défavorable est créée, tout ceci accroissant de plus en plus les frais généraux.

La réponse facile est ici de passer du temps en amont sur l’étape de prévention. Mais comme mentionné précédemment, il n’est pas toujours possible de capturer toutes les  éventualités. La clé est de  garder une vue d’ensemble du projet. Comprenez qu’il y a un effet boule de neige et faites fondre cette boule de neige pour atteindre la réelle cause racine. Des outils comme les 5 why’s, les leçons apprises et appliquez ceux-ci à votre prévention pour une meilleure analyse de la globalité afin que vos "suppositions" soient plus précises. Faire cela va automatiquement empêcher des Coûts d’Échec Internes.

Coûts d’échec externes

Ils font plus qu’affecter votre résultat final. Ils amenuisent votre réputation en tant que société, probablement même en tant que personne. Ce sont les défauts qui ont un impact sur le résultat final et vous parviennent de vos clients comme des réclamations. Rappels, Garanties, Mauvais Résultats d’Enquêtes de satisfaction, Etc.

L’intangible est voici la perte potentielle d’opportunités futures d’être retenus en raison de piètre qualité. Ces sortes de coûts n’apparaissent pas sur votre bilan financier, mais ils ont un impact certain sur votre déclaration de revenus.

La meilleure méthode est ici, bien sûr, la prévention pour les empêcher de survenir. Évaluation : s’assurer que ces problèmes n’atteignent pas votre client. Réduisez vos échecs internes afin d’ils ne se transforment pas en échecs externes. L’objectif principal cependant, si vous rencontrez vraiment un échec externe est d’agir vite. J’ai lu un livre une fois qui disait que résoudre un problème pour un client est la meilleure méthode de réaliser un bon service clients et de fidéliser ce client. Il semble étrange que cela soit possible à partir d’une erreur, mais c’est en réalité grâce à la communication directe avec ce client. Cet avantage se réduit avec sa fréquence, trop d’erreurs et cette opportunité est perdue.

Pour conclure

plan do check act

Relisez l’article de Jean-Baptiste Jourdant : cultivez vos talents – Projet et qualité, de nombreux points communs !

Nous avons discuté des coûts de conformité, de prévention et d’évaluation et des coûts de non-conformité, internes et externes ainsi que les coûts intangibles qui se produisent avec chacun. Les coûts intangibles pour la conformité sont causés par trop de sur-analyse, de sur-échantillonnage, aussi bien que l’échantillonnage sans données appropriées (sous-analyse). Le but est de considérer les coûts de réduction d’erreurs en rapport des coûts en temps et ressources pour empêcher ces erreurs. Les coûts intangibles de non-conformité diminuent la valeur de votre société à travers une mauvaise réputation, un personnel démoralisé et une diminution massive d’efficacité. Le remède est ici la prévention et l’évaluation intelligentes en considérant la vue d’ensemble et en faisant une analyse en profondeur des causes premières pour prévenir les futurs problèmes. Ceci est réalisé par une bonne communication et un bon contrôle de processus.

CSP Formation

Partenaire de DantotsuPM

Suivre

Recevez les nouvelles publications par mail.

Rejoignez 1 081 autres abonnés

%d bloggers like this: