Étiquette : qualité

DevOps : 3 étapes pour planifier et exécuter un projet réussi

Le par mopertodans best practices, experience sharingLaisser un commentaire

Une préparation diligente, des flux de travail clairement définis et une surveillance vigilante sont essentiels pour livrer un projet DevOps hautement performant. Szymon Piasecki, responsable DevOps chez STX Next.

DevOps: 3 steps to plan and execute a successful project par Szymon Piasecki

https://enterprisersproject.com/article/2023/1/devops-3-steps-plan-execute-successful-project

Bien que DevOps ne soit pas une nouvelle expression ou idée pour quiconque évolue dans l’industrie high-tech, c’est devenu un mot à la mode ces dernières années. Sa popularité est telle qu’il est maintenant crucial de comprendre comment structurer et déployer au mieux une équipe DevOps, et il existe plusieurs points de vue et méthodologies différents sur ce sujet.

En termes simples, DevOps est l’intégration des développeurs et des opérateurs informatiques en un seul groupe, avec l’objectif commun d’améliorer la vitesse et la qualité du déploiement des logiciels. Il a d’abord été créé en réponse aux préoccupations concernant la ségrégation des équipes et la façon dont cela entraînait souvent des ruptures de communication et un manque de cohésion.

Depuis que le terme a été inventé pour la première fois en 1993, DevOps n’a fait que gagner en popularité. 83% des décideurs informatiques en  2021 ont déclaré avoir mis en œuvre ce style de travail sous une forme ou une autre.

Changer l’orientation business de cette manière ne garantit pas un changement immédiat de résultats. Cependant, cette dynamique représente un changement de culture informatique, avec un accent accru sur la collaboration et les compétences relationnelles interpersonnelles. Pour que ce modèle fonctionne à long terme, les ingénieurs doivent être ouverts à cette nouvelle façon de travailler.

Alors, quelles étapes vitales une équipe DevOps doit-elle prendre pour assurer la réussite d’un projet ?

1. Comprendre le pourquoi

Les étapes préliminaires d’un projet DevOps sont cruciales. Sans une direction claire et une compréhension commune au sein de l’équipe, l’initiative est vouée à l’échec.

Pourquoi ce changement ?

L’équipe et le client doivent donc être prêts à consacrer le temps nécessaire pour comprendre les objectifs de chacun et s’assurer que leurs visions s’alignent. Cela peut se faire par le biais de réunions et d’ateliers, où les participants identifient les objectifs et les membres de l’équipe établissent un objectif clair sur ce à quoi le produit final devrait ressembler.

Lorsque cette mise au point est exécutée correctement, l’équipe DevOps quittera la première phase du projet avec un briefing bien défini et une compréhension claire des objectifs du client. Si cette étape est précipitée, les ingénieurs seront gênés par un manque de direction, ce qui augmentera la probabilité que le produit fini ne réponde pas aux exigences du client.

2. Développer

La deuxième phase est celle où le développement de l’application commence. Ceci est généralement facilité par l’utilisation d’une solution basée sur le cloud, où l’équipe commence à préparer l’environnement, à travailler sur les composants qu’il doit contenir et à comprendre comment ils doivent être configurés pour maximiser l’efficacité.

Les meilleures équipes DevOps sont agiles et polyvalentes, avec des membres qui peuvent facilement s’adapter à un nouveau rôle ou aider dans divers domaines.

Pendant cette période, l’équipe doit s’assurer que la version finale de l’application est aussi sécurisée que possible. Pour cette raison, l’équipe DevOps a besoin de compétences diverses, y compris au moins un expert en cybersécurité.

Une phase de développement réussie se caractérise par des flux de travail clairement structurés dans lesquels le projet est décomposé, étape par étape. Tous les membres de l’équipe doivent comprendre où ils s’inscrivent dans le plan et comment ils peuvent contribuer.

Il est important de se rappeler que les projets DevOps sont rarement une promenade de santé du début à la fin. Le développement est souvent entravé par des délais manqués, des bugs et des conflits de priorité qui éloignent les ingénieurs de leurs responsabilités projet. Pour cette raison, les meilleures équipes sont agiles et polyvalentes, avec des membres qui peuvent facilement s’adapter à un nouveau rôle ou aider dans divers domaines. Cette agilité est extrêmement importante pour assurer la continuité lorsque les flux de travail sont perturbés.

3. Tester, surveiller et améliorer

Une fois qu’un produit est mis en ligne, le travail entre dans une nouvelle étape cruciale. Les meilleures équipes DevOps ne se reposent jamais sur leurs lauriers à la fin de la phase de développement. Les développeurs doivent surveiller attentivement l’application à ses débuts afin que tout bug puisse être identifié et immédiatement corrigé.

Des ingénieurs devraient être en place pour surveiller l’environnement, y compris la façon dont il est affecté et comment il réagit aux flux variables de nouveaux utilisateurs. Les données obtenues constituent une ressource précieuse et doivent être traitées comme telles, les équipes triant et étiquetant les résultats dès qu’ils sont collectés.

Une fois les données de référence recueillies, l’équipe doit analyser les résultats pour identifier les parties de l’application qui pourraient nécessiter des améliorations ou une refonte. Après cela, le résultat final devrait être un produit qui fonctionne de manière optimale et répond aux spécifications du client.

Se préparer au succès

Les équipes DevOps qui suivent les étapes décrites ci-dessus auront la certitude absolue que leur projet est sur la bonne voie et qu’il est prêt pour réussir.

Concevoir un produit bien fait est beaucoup plus facile lorsque votre équipe inclut des spécialistes de diverses disciplines qui sont enthousiastes à l’idée de collaborer et de communiquer. Avoir la bonne équipe facilitera également la transition entre chaque étape d’un projet DevOps et garantira que le client est satisfait.

TOP 3 d’Août 2022 sur DantotsuPM, le blog du management de projets

Le par mopertodans pointeurs utilesLaisser un commentaire

Je profite de la trêve de fin d’année pour vous remercier d’avoir particulièrement apprécié ces billets.

L’intelligence émotionnelle : un atout pour les managers de projets comme pour tout autre leader

Qui n’a jamais entendu les phrases :

Les émotions n’ont pas leur place dans le monde professionnel !

ou encore

Quand on vient au bureau, on laisse ses émotions à la maison.

Avez-vous lu ce rapport sur l’état du coaching agile : « 2022 State of Agile Coaching Report » ?

Téléchargez le document

Riche des données de plus de 2 000 coachs agiles professionnels qui ont partagé leurs expériences sur l’impact du coaching agile, le deuxième rapport annuel sur l’état du coaching agile est publié. Le rapport couvre un éventail de sujets liés au coaching agile dans le monde réel, y compris le retour sur investissement, la valeur et les métriques permettant de définir le succès.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

15 avantages que vous apporte le management de projet  

Et vous, en tant que manager de projet, dirigez et menez et vous assurez que l’organisation tire le plein avantage de tout ce que vous faites. Cela vous rend extrêmement précieux pour toute organisation avec laquelle vous travaillez. Du niveau de l’équipe jusqu’au comité exécutif où ils examinent les résultats et les impacts business. Soyez fier de vous. Vous êtes manager de projet.

L’importance d’avoir une philosophie qualité dans l’environnement Agile

Le par mopertodans agile, experience sharingLaisser un commentaire

Cet article passe en revue les principales différences entre la qualité interne et externe et insiste sur l’importance d’avoir une philosophie de qualité dans l’environnement Agile.

The importance of having a quality philosophy in the agile encironment

https://www.agilequalitymadeeasy.com/post/the-importance-of-having-a-quality-philosophy-in-the-agile-environment-david-tzemach par David Tzemach

Les différences entre qualité interne et externe

Pour comprendre le vrai sens de la qualité, vous devez faire la distinction entre qualité interne et externe :

  • La qualité externe fait référence à ce que le client voit lorsqu’il interagit avec le logiciel. Un exemple de mauvaise qualité externe est une interface utilisateur non intuitive qui nécessite une navigation complexe pour utiliser une fonction simple.
  • La qualité interne fait référence à tous les problèmes non visibles pour le client qui ont un impact sur la maintenabilité et la stabilité du système, tels que la conception du code et la couverture des tests.

Quel type de qualité est le plus important ?

Les deux sont importants, en supposant que l’équipe a le temps, les ressources et les connaissances nécessaires pour s’occuper des deux.

Mais que se passe-t-il lorsque vous devez livrer rapidement et que vous devez en choisir un ?

Il n’y a pas de réponse définitive, car chaque type présente des avantages et des inconvénients. D’expérience, un système de forte qualité interne peut être livré même avec une faible qualité externe (nous voyons cela tout le temps dans l’industrie du logiciel). Cependant, un système de faible qualité interne rendra presque impossible la construction d’une qualité externe élevée. Comment pouvez-vous construire un système qui repose sur des fondations défaillantes ?

Qu’est-ce qu’une philosophie de qualité et pourquoi en avez-vous besoin ?

Dans le cadre de tout projet de développement (Agile ou autre), l’organisation doit déterminer le niveau de qualité qu’elle s’attend à délivrer au marché et à ses clients. Le niveau de qualité doit être dérivé de la philosophie de qualité.

La philosophie de qualité est le niveau acceptable de tolérance du projet pour les écarts de qualité (par exemple, la dette technique, la faible couverture de code, etc.) et les problèmes rencontrés après la livraison des produits.

À chaque extrémité du spectre de la philosophie de la qualité, nous avons une tolérance élevée pour la mauvaise qualité et une faible tolérance pour la mauvaise qualité.

Tolérance élevée pour la mauvaise qualité

L’équipe est censée livrer les produits le plus tôt possible, quelle que soit la qualité des livrables.

Relisez ce billet

Cela inclut la fourniture d’éléments présentant des problèmes de qualité importants (par exemple, les tests ne passent pas, plusieurs bogues sont connus, etc.) et même sans tests terminés. C’est parce que la philosophie de qualité de l’organisation est de battre sur les délais la concurrence à tout prix et de combler les lacunes manquantes par la suite.

Faible tolérance pour la mauvaise qualité

Le livre de Phil B. Crosby

L’équipe est censée livrer des produits sans compromettre leur qualité, qui est censée être au plus haut niveau possible. Pour ce faire, les équipes de développement réduisent le nombre d’histoires utilisateur qu’elles peuvent fournir par version pour créer des infrastructures automatisées, en exécutant plus de tests et en passant une grande partie de leur temps à s’assurer que chaque fonctionnalité est produite avec la meilleure qualité possible.

Flux et vitesse

Comme vous pouvez le constater, la philosophie de qualité organisationnelle affecte considérablement le flux de travail et la vitesse de livraison. Par conséquent, elle doit être communiquée aux équipes d’ingénierie, car elle a un impact substantiel sur leur travail quotidien.

Notez que même si votre entreprise a une tolérance élevée pour la mauvaise qualité, cela ne signifie toujours pas que vous pouvez livrer des produits de mauvaise qualité à vos clients.

Cependant, cela permet à l’équipe de réduire la couverture des tests (d’un montant acceptable), de prendre plus de risques et d’investir moins dans la qualité « externe » car la qualité interne reste non négociable.

15 avantages que vous apporte le management de projet (les 15 + conclusion)

Le par mopertodans experience sharingLaisser un commentaire

Le management de projet offre de considérables avantages et bénéfices aux organisations qui ont besoin de livrer des solutions.

Benefits of Project Management par Leigh Espy

#1 – Propriété claire pour la réussite du projet

Les projets reposent sur de nombreuses personnes travaillant vers un objectif commun. Mais le projet et l’équipe ont besoin d’un leader pour faire avancer le projet et adopter une vision plus large.

Les membres de l’équipe examinent leurs responsabilités individuelles d’un point de vue étroit. Mais le/la manager de projet prend en charge l’ensemble du projet. Il ou elle travaille au sein des équipes pour résoudre les problèmes, suivre les jalons et maintenir le projet sur la bonne voie.

#2 – Organisation et planification

Le/la manager de projet travaille avec l’équipe pour créer des échéanciers, des budgets et d’autres composants du plan de projet.

Cela donne à l’équipe une orientation claire et définit les attentes de la direction et des clients concernant chaque livrable du projet.

#3 – Responsabilité de l’équipe

Le/la manager de projet tient les membres de l’équipe responsables d’honorer leurs engagements.

Cela aide le projet à rester sur la bonne voie et à éviter les dérapages de calendrier et les dépendances manquées.

#4 – Champ d’application clairement défini

Le/la manager de projet travaille avec les clients et l’équipe pour s’assurer que la portée est bien définie dès le départ.

Cela permet à l’équipe d’écrire des exigences claires, et tout le monde a la même compréhension de ce qu’il faut livrer à la fin du projet.

#5 – Gestion du budget et des coûts

Le/la manager de projet recueille des informations sur le coût du projet et crée le budget du projet lors de la planification du projet.

À l’avenir, il/elle gère également les dépenses du projet tout au long du projet et s’assure que le projet respecte le budget sans surprise.

Ressource : Comment créer un budget de projet informatique [modèle inclus]

#6 – Gestion des délais / Respect des engagements et des délais envers les clients

Le/la manager de projet aide l’équipe à rester sur la bonne voie. Il/Elle travaille avec l’équipe pour établir le calendrier du projet et identifier les jalons et les livrables.

Il/Elle identifie et travaille avec les parties prenantes pour remédier ou éliminer les obstacles et assurer une coordination et des progrès continus.

Le/la manager de projet gère également les interdépendances entre les équipes afin que toutes les pièces du projet soient réunies pour répondre au besoin.

Il/Elle garde également l’équipe concentrée sur le respect des dates et des jalons clés.

Ce point de contact unique pour l’équipe élimine la confusion quant à savoir qui coordonne et dirige l’effort. Cela garantit une exécution plus réussie du projet.

#7 – Gestion de la portée du projet

Bien qu’il soit important d’avoir une portée de projet clairement définie au début du projet, il est tout aussi important de gérer les dérives de la portée au fur et à mesure que le projet progresse.

Les clients demandent souvent des changements de contenu.

Le/la manager de projet peut aider à montrer comment cela affecte le projet. Si des changements de portée sont effectivement nécessaires, le/la manager de projet peut gérer les impacts sur le planning et le budget du projet.

#8 – Management des risques

Le management des risques comprend l’identification des risques dès le début du processus et leur traitement avant qu’ils ne causent des problèmes. Cela implique également de gérer le changement tout au long du projet en suivant les changements et en les communiquant efficacement.

Le/la manager de projet identifie les risques potentiels au début du projet. Il/Elle travaille avec l’équipe pour manager activement les risques tout au long de la vie du projet.

Grâce à cela, le projet peut aller de l’avant même s’il y a des menaces sur le plan de projet.

Ressource : Comment créer une matrice de management des risques projet (avec modèle)

#9 – Qualité de la solution

Le/la manager de projet travaille avec l’équipe pour intégrer la qualité dans le projet dès le début.

Il/Elle projet s’assure que l’équipe suit les processus appropriés, tels que la collecte des exigences et les tests, le cas échéant. L’équipe peut avoir besoin de suivre les directives de conformité ou les considérations contractuelles. Tout au long de la vie du projet, le/la manager de projet coordonne de multiples activités pour aborder la qualité.

#10 – Tenue des dossiers et responsabilités administratives

Il n’est pas nécessaire d’avoir un/une manager de projet pour créer de la documentation et planifier des réunions.

Mais le/la manager de projet comprend le projet à un niveau supérieur et sait quand planifier une réunion et qui amener à la table. Il/Elle anticipe la nécessité de discussions importantes sur le projet et dirige ces activités pour que le projet continue d’aller de l’avant et sur la bonne voie. Il/Elle s’assure que les documents nécessaires sont créés et stockés à des fins de conformité et d’historique.

#11 – Visibilité de la santé du projet

Le/la manager de projet donne de la visibilité sur l’avancement et l’état du projet. Parce qu’il/elle est responsable de la réussite du projet, le/la manager de projet rassemble toutes les informations et donne de la visibilité sur la santé du projet.

Le logiciel de gestion de projet permet aux équipes de fournir des informations et de fournir une santé de projet en temps réel. Les membres de l’équipe et les parties prenantes peuvent obtenir des mises à jour plus rapides sur l’état et les métriques. L’équipe peut procéder comme prévu ou s’ajuster au besoin en fonction de ces informations. Cela permet à l’organisation d’économiser du temps et de l’argent à long terme.

#12 – Les organisations peuvent entreprendre des projets plus complexes

Les projets plus complexes ont un besoin plus élevé de direction globale et de management d’ensemble.

Avoir un/une manager de projet permet l’exécution réussie de projets plus complexes avec de nombreuses interdépendances et davantage de risques.

#13 – Consolidation d’équipe

Étant donné que le succès du projet dépend de nombreux différents membres d’équipe, vous devez réunir cette équipe de projet pour vous concentrer sur l’objectif commun.

S’il y a des conflits, des agendas personnels ou des désirs contradictoires, le projet pourrait stagner ou se désagréger.

Un/une bon/bonne manager de projet sait comment rassembler l’équipe pour travailler vers un succès commun.

CSP DOCENDI est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.

#14 – Communications

Le/la manager de projet communique avec les parties prenantes et l’équipe tout au long du projet. Il/Elle utilise des méthodes de communication efficaces comme le courrier électronique, les appels téléphoniques et les réunions en face à face pour faire passer le message.

Pour les projets complexes, le plan de communication définit qui gère différents types de communications tout au long du projet.

Le/la manager de projet sert de point de contact principal pour les communications de projet avec divers publics.

  • Communication avec les membres de l’équipe – Le/la manager de projet coordonne les discussions sur les enjeux et les besoins de l’équipe et facilite la communication entre les départements. Il existe de nombreux sujets à aborder tout au long de la vie d’un projet, tels que la conformité, les risques et les interdépendances.
  • Communication avec les parties prenantes – tenir les parties prenantes informées de diverses manières, telles que des mises à jour de statut, des vues et des informations de haut niveau, ou plus de détails sur le projet si nécessaire.  Les managers de projet communiquent avec les parties prenantes internes et externes.
  • Communication client – plutôt que l’équipe de développement parle directement avec le client, Le/la manager de projet gère ces communications. Il/Elle répond aux questions et traduit les exigences et les détails techniques en termes que les utilisateurs non techniques peuvent comprendre. Il/Elle gère également les attentes des clients tout au long du projet et coordonne les activités de management du changement.

#15 – Management du changement

Le/la manager de projet travaille avec l’organisation pour s’assurer que non seulement le travail de projet est effectué, mais que les clients sont prêts à l’adopter.

Le/la manager de projet de projet planifie les changements nécessaires pour une transition en douceur vers la nouvelle solution.

Voici comment il/elle procède :

  • Communications sur l’échéancier et la date de livraison.
  • Formation aux nouvelles solutions ou nouveaux processus.
  • Mise en place un soutien continu.

Cela offre une meilleure expérience client du début à la fin.

Le management de projet offre des bénéfices aux organisations qui ont besoin de livrer des solutions.

Cette valeur s’applique du niveau de l’équipe jusqu’aux parties prenantes et aux dirigeants. Les managers de projet utilisent un logiciel de gestion de projet, d’autres outils de gestion de projet et des compétences en management de projet pour garantir la réussite de la livraison du projet.

Et vous, en tant que manager de projet, dirigez et menez et vous assurez que l’organisation tire le plein avantage de tout ce que vous faites. Cela vous rend extrêmement précieux pour toute organisation avec laquelle vous travaillez. Du niveau de l’équipe jusqu’au comité exécutif où ils examinent les résultats et les impacts business. Soyez fier de vous. Vous êtes manager de projet.

15 avantages que vous apporte le management de projet (7 à 9)

Le par mopertodans experience sharingLaisser un commentaire

Le management de projet offre de considérables avantages et bénéfices aux organisations qui ont besoin de livrer des solutions.

Benefits of Project Management par Leigh Espy

#7 – Gestion de la portée du projet

Bien qu’il soit important d’avoir une portée de projet clairement définie au début du projet, il est tout aussi important de gérer les dérives de la portée au fur et à mesure que le projet progresse.

Les clients demandent souvent des changements de contenu.

Le/la manager de projet peut aider à montrer comment cela affecte le projet. Si des changements de portée sont effectivement nécessaires, le/la manager de projet peut gérer les impacts sur le planning et le budget du projet.

#8 – Management des risques

Le management des risques comprend l’identification des risques dès le début du processus et leur traitement avant qu’ils ne causent des problèmes. Cela implique également de gérer le changement tout au long du projet en suivant les changements et en les communiquant efficacement.

Le/la manager de projet identifie les risques potentiels au début du projet. Il/Elle travaille avec l’équipe pour manager activement les risques tout au long de la vie du projet.

Grâce à cela, le projet peut aller de l’avant même s’il y a des menaces sur le plan de projet.

Ressource : Comment créer une matrice de management des risques projet (avec modèle)

#9 – Qualité de la solution

Le/la manager de projet travaille avec l’équipe pour intégrer la qualité dans le projet dès le début.

Il/Elle projet s’assure que l’équipe suit les processus appropriés, tels que la collecte des exigences et les tests, le cas échéant. L’équipe peut avoir besoin de suivre les directives de conformité ou les considérations contractuelles. Tout au long de la vie du projet, le/la manager de projet coordonne de multiples activités pour aborder la qualité

 

Etes-vous un ingénieur QA, ingénieur QC ou testeur de logiciel ? pa Fidaa Berrjeb

Le par mopertodans experience sharingLaisser un commentaire

Les gens pensent souvent que l’assurance qualité et le contrôle qualité sont identiques.

De plus, ils utilisent souvent l’expression Quality Assurance (QA) pour désigner les tests, mais ce n’est pas exact. Ces expressions sont liées, et il est peut être très déroutant d’essayer de clairement différencier l’assurance qualité (QA), le contrôle de la qualité (QC) et les tests et d’identifier chacune de leurs activités.

Même les gens de ce domaine s’interrogent parfois sur leur intitulé de poste : « Suis-je un testeur de logiciels, un ingénieur QA ou un ingénieur QC ? »

Dans cet article, nous définirons chaque terme et la différence entre eux, et à la fin de celui-ci, vous pourrez aisément répondre à cette question.

Avant de définir ces termes, convenons de la définition de la qualité.

D’après wikipédia :

Au sens large, la qualité est la « manière d’être », bonne ou mauvaise, d’une chose ou d’une personne. Dans le langage courant, la qualité tend à désigner ce qui rend quelque chose supérieur à la moyenne.

Le QA , le QC et les tests sont liés dans un concept plus large appelé gestion de la qualité.

La gestion de la qualité comprend toutes les activités qui dirigent et contrôlent une organisation en matière de qualité. Entre autres activités, la gestion de la qualité comprend à la fois l’assurance de la qualité et le contrôle de la qualité ISTQB CFTL.

  • L’assurance qualité englobe toutes les activités de votre stratégie visant à garantir que les exigences de qualité que vous avez planifiées seront satisfaites au fur et à mesure de la fabrication du produit. Elle intervient à chaque étape du développement logiciel, de la création du cahier des charges à la sortie du produit. L’assurance qualité est la méthode orientée processus et se concentre sur la prévention des défauts.

 

  • Le contrôle de la qualité est la phase d’inspection de l’assurance qualité. Dans le processus de développement logiciel, le QC intervient généralement à la dernière étape. Cela commence une fois qu’un produit est déjà construit. Il s’agit d’une série de procédures de test utilisées pour vérifier qu’un produit est sûr et efficace après la production de masse. C’est une méthode orientée produit qui garantit que le résultat final est le résultat attendu ou que le produit final fonctionne comme prévu.

 

  • Les tests sont un sous-ensemble du QC. C’est l’activité de détection et de résolution des problèmes techniques dans le logiciel. C’est le processus d’examen du logiciel pour détecter d’éventuelles failles. L’idée de base consiste à exécuter le programme ou le logiciel et à observer le comportement ou le résultat. Il peut fournir un niveau de confiance quant à la convivialité, les performances, la sécurité et la compatibilité du produit.

 

Expression Assurance qualité (QA) Contrôle de la qualité (QC) Test
Positionnement Sous-ensemble de SDLC Sous-ensemble de QA Sous-ensemble de QC
Orientation Processus Produit Produit
Qui ? L’équipe projet L’équipe de test L’équipe de test
Quand ? Tout au long du projet Au stade du test Au stade du test
Type de

Processus

 Prévention Vérification Détection
Partenaire de DantotsuPM, visitez le site pour toutes les formations certifiantes proposées

Voici déjà le cinquième billet de Fidaa sur le domaine des tests.

(Re)Découvrez ses 4 premiers billets
Fidaa Berrjeb est Agile QA analyst certifiée ISTQB et Scrum Master.
  1. « La bonne compréhension et l’utilisation des valeurs du manifeste agile et du manifeste du test vous garantit être un bon testeur agile »
  2. Si on vous demandait d’écrire un scénario de test, sauriez-vous quoi faire ?
  3. Le rôle et les compétences d’un testeur dans une équipe agile
  4. Quelle est la différence entre un plan de test et une stratégie de test ?

 

Quelle est la différence entre un plan de test et une stratégie de test ? Quand utiliser l’un ou l’autre ? par Fidaa Berrjeb

Le par mopertodans best practices2 commentaires

Voici déjà le quatrième billet de Fidaa pour vous aider à mieux différencier stratégie et plan de test et quand les utiliser.

Redécouvrez les 3 premiers billets Fidaa Berrjeb :
Fidaa Berrjeb est Agile QA analyst certifiée ISTQB et Scrum Master.
  1. « La bonne compréhension et l’utilisation des valeurs du manifeste agile et du manifeste du test vous garantit être un bon testeur agile »
  2. Si on vous demandait d’écrire un scénario de test, sauriez-vous quoi faire ?
  3. Le rôle et les compétences d’un testeur dans une équipe agile

En ce qui concerne les tests de logiciels, deux termes importants entrent en jeu. Ce sont « Plan de test » et « Stratégie de test ».

Bien que les deux soient des éléments essentiels du processus de QA, ces termes risquent souvent être mal interprétés et utilisés de manière interchangeable.

Alors, quelle est la différence entre un plan de test et une stratégie de test ? Quand devez-vous utiliser un plan et quand est-il préférable d’utiliser une stratégie ?

Plan de test

Un plan de test est un document formel dérivé des documents d’exigences.

  • Ce document décrit les différentes actions qui seront effectuées dans le processus de test.
  • Il définit l’approche, l’estimation, les attentes, les actifs et le calendrier des activités de test planifiées.
  • Il identifie la portée et l’objectif du processus de test logiciel, les différentes fonctionnalités qui doivent être testées, les techniques utilisées pour concevoir les tests et bien plus encore.

Fondamentalement, il enregistre l’ensemble du processus de planification des tests à effectuer sur le produit.

Stratégie de test

Une stratégie de test est un document de haut niveau décrivant la manière dont les tests seront effectués dans une organisation.

  • Elle contient un ensemble d’instructions, de lignes directrices ou de principes qui déterminent la conception du test et la manière dont le processus de test sera effectué.
  • Elle vise essentiellement à fournir une approche systématique du processus de test de logiciels afin d’assurer la qualité, la traçabilité, la fiabilité et une meilleure planification.

Les documents tels que les plans de test tirent leur contenu du document de stratégie de test.

Différence entre plan de test et stratégie de test

Une stratégie de test définit la norme générale pour les activités de test. Un plan de test, d’autre part, définit les détails spécifiques des responsabilités et du processus de QA.

5 façons d’améliorer la qualité des projets

Le par mopertodans best practicesLaisser un commentaire

Une grande partie de la réussite d’un projet consiste à atteindre les objectifs business. La qualité d’un projet est la mesure du degré avec lequel un projet atteint ses objectifs.

5 Ways to Increase Project Quality

http://www.bonniebiafore.com/5-ways-to-increase-project-quality/ par Bonnie Biafore

Voici cinq conseils pour assurer la qualité des résultats de votre projet.

#1 – Ne sautez pas à la solution trop rapidement.

La base de la qualité est de s’assurer que votre projet résout le problème ou soutient l’opportunité ciblée. Pour vous assurer de fournir une solution de qualité, prenez le temps de rechercher les outils, les processus, les forces et les faiblesses actuels dans votre secteur d’activité.

Malheureusement, les projets sont souvent lancés avec une solution spécifique à l’esprit. Par exemple, si votre organisation exécute un projet de mise en œuvre d’un nouveau logiciel financier alors que le manque de contrôle financier est dû à de mauvais processus de contrôle, le projet est une perte de temps et d’argent. Faites vos recherches pour identifier le problème et sa cause racine avant de lancer un projet.

#2 – Renforcez l’engagement client dès le début du projet.

Ecoutez les clients

Vous avez besoin de l’apport des bonnes personnes pour fournir une solution qui répond aux besoins des parties prenantes. Il vous faut non seulement des personnes bien informées mais aussi des personnes de chaque groupe de parties prenantes concerné.

Consultez ces personnes lorsque vous rassemblez les exigences et ne supposez pas que vous comprenez les besoins des parties prenantes. Sinon, les livrables de votre projet pourraient rester inutilisés si les parties prenantes insatisfaites les déclarent inadaptés pour l’entreprise.

#3 – Ne court-circuitez pas les tests.

Les tests sont souvent planifiés à la fin du projet. À mesure que les dates cibles approchent, les tests sont souvent réduits pour tenir les calendriers de livraison.

Bien que cette approche puisse livrer dans les temps, la probabilité de problèmes avec les livrables est élevée. Pour garantir des résultats de projet de qualité, sacralisez le temps de test et incorporez les activités de test tout au long du cycle de vie de votre projet.

Relisez ce billet

Par exemple, des revues de livrables papier, de modèles d’ingénierie, de simulations de procédures commerciales et de prototypes de logiciels vous permettront d’économiser du temps et de l’argent dans le long terme.

#4 – Concentrez-vous sur les processus business.

Deux activités liées aux processus sont cruciales, mais souvent négligées.

Tout d’abord, assurez-vous de capturer les processus actuels afin que votre projet ne néglige pas les activités business qu’il doit prendre en charge.  Deuxièmement, mettre à jour les processus opérationnels à mesure que les livrables sont créés et que les modifications sont prises en compte.

Si vous ne le faites pas, la formation du personnel ne couvrira pas les changements apportés, ce qui pourrait entraîner des malentendus sur ce que votre produit peut et ne peut pas faire. Pour obtenir des résultats opérationnels, mettez en œuvre des activités de projet standard pour capturer et documenter les processus opérationnels tels qu’ils existent au départ et ceux à venir.

Au fur et à mesure que l’équipe produit des livrables, elle doit également créer et documenter les processus métier nouveaux ou modifiés correspondants.

#5 – Tenez compte des facteurs humains.

Les gens ne résistent pas au changement. Ils résistent à être changés. Peter M. Senge

La qualité perçue de vos livrables dépend de votre capacité à accompagner vos parties prenantes dans le voyage du changement de votre projet. Impliquez vos parties prenantes dès le début, tenez-les informées au fur et à mesure que vous progressez, en particulier lorsque des changements sont réalisés.

Ce faisant, vous augmenterez vos chances que vos résultats satisfassent les objectifs de l’entreprise.

Pour en savoir plus sur la qualité des projets, consultez le cours Project Management Foundations: Quality de Daniel Stanton.
QRP est partenaire de DantotsuPM, visitez cette page pour en apprendre davantage

De l’importance de ne jamais confondre investissement et dépense !

Le par mopertodans experience sharingLaisser un commentaire

L’un prend de la valeur, l’autre non. L’un crée de la valeur au fil du temps, l’autre non.

Investments and expenses

https://seths.blog/2021/04/investments-and-expenses/ par Seth Godin

L’un prend de la valeur, l’autre non. L’un crée de la valeur au fil du temps, l’autre non.

Il est amusant d’imaginer que nos dépenses sont des investissements, mais si c’était le cas, nous les appellerions des investissements.

Nos outils peuvent être réutilisés, et nos biens ont de la valeur pour nous et pour les autres. Les compétences peuvent être un investissement, qui prend de la valeur quand elles augmentent. Les dépenses, en revanche, perdent de la valeur.

Il en va de même dans votre projet si vous êtes manager ou sponsor de projet ou membre de l’équipe projet.

Certains coûts sont pleinement justifiés et contribuent à construire un livrable de grande valeur pour votre organisation et vos clients. D’autres tout aussi justifiés permettent de faire grandir les personnes qui travaillent sur le projet, de leur donner les moyens d’évoluer et devenir meilleurs.

D’autres coûts sont bien moins justifiables comme de devoir refaire une tâche parce qu’elle a été mal exécutée la première fois. Il faut alors parfois beaucoup dépenser pour déconstruire avant de reconstruire. Cela coûte en argent mais aussi en confiance chez vos commanditaires et parties prenantes.

Parfois des fonctionnalités que vous avez développé avec l’équipe à grands frais seront inutilisées… d’où les approches hybrides qui essaient de prendre le meilleur de l’agilité en particulier pour ce qui est de développer les éléments de plus grande valeur pour les clients en premier.

Le rôle et les compétences d’un testeur dans une équipe agile par Fidaa Berrjeb

Le par mopertodans agile, best practices, experience sharingLaisser un commentaire

Voici le troisième billet de Fidaa pour préciser le rôle du testeur dans les projets Agiles.

Les 2 premiers billets Fidaa Berrjeb que vous souhaiterez peut-être relire :
  1. Fidaa Berrjeb est Agile QA analyst certifiée ISTQB et Scrum Master.

    « La bonne compréhension et l’utilisation des valeurs du manifeste agile et du manifeste du test vous garantit être un bon testeur agile »

  2. Si on vous demandait d’écrire un scénario de test, sauriez-vous quoi faire ?

Contrairement aux méthodes de gestion de projet traditionnelles, le rôle de testeur dans les projets Agiles dépasse être  simplement un exécuteur. Il comprend des activités qui génèrent et fournissent des retours (feedback) non seulement sur l’état du test, la progression du test et la qualité du produit, mais également sur la qualité du processus en collaborant de façon rapprochée avec toute l’équipe et ses parties prenantes.

En plus de compétences techniques reconnues (les tests d’acceptation, boîte blanche, boîte noire, les automatisations de test …), un testeur agile doit avoir de bonnes compétences interpersonnelles.

CSP est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.

Ayez une attitude constructive et une approche communicative

Une grande partie des problèmes se résument  à un manque de communication. En tant que testeur, impliqué du concept au produit final, il est important de communiquer de manière ouverte et honnête. Il est également important de considérer la façon dont nous disons les choses. Il est préférable de dire  « Je ne pense pas que cela fonctionne comme il se doit, il manque la fonctionnalité X » au lieu de « Cela ne fonctionne pas ».

Une discussion en face à face est souvent plus efficace.

En outre, il est important de déterminer quand utiliser des outils digitaux pour communiquer ou quand une bonne conversation en face à face est nécessaire.

Coachez les autres membres de l’équipe sur les aspects pertinents du test .

En partageant les connaissances de test avec l’équipe, vous leur montrez que, non seulement vous êtes un apprenant passionné, mais vous voulez les aider à apprendre et à améliorer le travail de l’équipe.

L’objectif d’un testeur n’est pas de trouver plus de bugs mais de construire un produit de valeur et de qualité.

Collaborez avec les développeurs,  le Product Owner et  les stakeholders  pour clarifier les exigences, spécialement en termes de testabilité, consistance et complétude.

Le travail d’équipe rend les choses meilleures. Pour les testeurs de logiciels, travailler seul peut devenir la situation par défaut même si vous faites partie d’une équipe. N’oubliez pas que vous n’êtes jamais seul sur un projet.

Les testeurs doivent être impliqués dans les sessions de Pré-planification et de  user stories  grooming (analyse détaillée des besoins des utilisateurs) en ajoutant de la valeur lors de la :

  • Définition des user stories et des critères d’acceptation
  • Participation aux analyses de risques et de qualité de projet
  • Création de tests d’acceptation pour les user stories

Participez pro-activement aux rétrospectives d’équipe, suggérez et implémentez des améliorations .

Soyez impliqué, proactif, coopératif et soyez le membre de l’équipe avec qui vous aimeriez travailler. Soyez un modèle de bon membre d’équipe et, espérons-le, les membres de votre équipe le reconnaîtront et travailleront ensemble, avec vous, pour développer des pratiques de travail d’équipe.

Les testeurs Agile doivent ajouter de la valeur à chaque étape de la livraison du logiciel dans un projet agile.

Reportez les défauts et travaillez avec l’équipe pour les résoudre.

Au sein d’une équipe Agile, chaque membre de l’équipe est responsable de la qualité du produit et joue un rôle dans l’exécution des tâches liées aux tests. Le retour d’information dès que possible vers l’équipe en cas de problème économise  temps et budget.

Si on vous demandait d’écrire un scénario de test, sauriez-vous quoi faire ? par Fidaa Berrjeb

Le par mopertodans best practices, outils et méthodesLaisser un commentaire

Suite à son premier billet sur ce blog « La bonne compréhension et l’utilisation des valeurs du manifeste agile et du manifeste du test vous garantit être un bon testeur agile » Fidaa Berrjeb a reçu des questions sur « le test scénario et le test case ».

  • Si on vous demandait d’écrire un scénario de test, sauriez-vous quoi faire ?
  • Qu’en est-il d’un cas de test ou d’un scénario de test ?
Fidaa Berrjeb est Agile QA analyst certifiée ISTQB et Scrum Master.

La première étape consiste à bien définir ces termes.

Chacun de ces termes implique un niveau de détail différent.

Une fois qu’un testeur sait ce que chacun de ces termes signifie, il peut comprendre comment les utiliser pour décrire le travail de test qui est effectué quotidiennement.

C’est quoi un scénario de test ?

Un scénario de test est essentiellement une documentation d’un cas d’utilisation. En d’autres termes, il décrit la fonctionnalité de l’application à tester. Il est utilisé pour tester de bout en bout une fonctionnalité.

Un même scénario de test nécessitera un ou plusieurs cas de test pour s’assurer que le scénario a été couvert de manière satisfaisante. Par conséquent, un scénario de test a une relation un-à-plusieurs avec les cas de test.

À titre d’exemple, considérons un scénario de test

« Vérifiez que l’utilisateur ne peut pas se connecter avec des informations d’identification incorrectes »

Maintenant, ce scénario de test peut être encore décomposé en plusieurs cas de test comme :

  1. Vérifier qu’un utilisateur avec le bon nom d’utilisateur et le mauvais mot de passe ne soit pas autorisé à se connecter.
  2. Vérifier qu’un utilisateur avec un nom d’utilisateur incorrect et un mot de passe correct ne soit pas autorisé à se connecter.
  3. Vérifier que les utilisateurs avec des noms d’utilisateur et des mots de passe incorrects ne soient pas autorisés à se connecter.

Qu’est-ce qu’un cas de test ?

Le cas de test est un ensemble d’actions exécutées pour vérifier une caractéristique ou une fonctionnalité particulière de votre application logicielle.

Il inclut toutes les entrées possibles positives comme négatives, ainsi que des données de test, des préconditions et des postconditions développées pour un scénario de test spécifique afin de vérifier toute exigence.

À l’aide de ces variables et conditions, le testeur peut comparer les résultats réels aux résultats attendus pour déterminer si un produit logiciel fonctionne conformément aux exigences du client.

Scénario de test VS cas de test

QRP est partenaire de DantotsuPM, visitez leur site et leur blog

 

plan do check act

Rappel de ce qu’est le « Plan Do Check Act », Cycle PDCA pour l’amélioration continue.

Le par mopertodans outils et méthodesLaisser un commentaire

Le Cycle PDCA est une approche compréhensible, répétable pour travailler vers une amélioration continue.

PDCA Cycle for Continuous Improvement

https://projectbliss.net/plan-do-check-act-pdca-cycle/ par  Leigh Espy
plan do check act
Relisez l’article de Jean-Baptiste Jourdant : cultivez vos talents – Projet et qualité, de nombreux points communs !

Les équipes et des organisations s’efforcent constamment de trouver les meilleures façons de travailler. Bien des organisations doivent faire plus avec moins, moins de personnes ou moins d’argent. Et les organisations veulent toujours trouver des façons d’économiser de l’argent, de gagner en efficacité et rendre l’environnement de travail meilleur. Mais souvent la demande par la gestion pour faire ainsi peut sembler accablante.

Mais si vous saviez qu’il existe une approche structurée pour essayer des améliorations possibles, obtenir des retours rapidement et le faire d’une façon qui vous permette d’apprendre dans un environnement contrôlé et de construire sur vos succès, vous seriez probablement intéressés, non ?

Et bien cette approche existe ! Et c’est quelque chose que vous pouvez facilement apprendre et enseigner à votre entourage.

Faites un pas de plus et donnez-lui une chance. Et si vous trouvez une façon d’économiser à votre société de l’argent ou du temps, vous pourriez bien en obtenir un agréable bonus!

Plan Do Check Act – Cycle PDCA

Le Plan Do Check Act – Cycle PDCA est une méthode en 4 étapes utilisée dans le processus d’amélioration continue.

Le livre de Deming sur Amazon

PDCA est aussi connu sous le nom de Cycle de Deming. Dans les années 1920, Walter Shewhart a créé le concept Plan – Do – See (Planifier – Faire – Observer) connu comme le Cycle Shewhart. Edwards Deming l’a ensuite adapté. Une autre variation que vous pouvez rencontrer est le Cycle PDSA : Plan-Do-Study-Act, Planifier-Faire-Etudier-Agir

Mais ils mènent tous à la même chose…

Toutes ces approches s’est concentré sur l’amélioration continue. Et chacun des quatre composants joue un rôle spécifique dans ce processus d’amélioration continue.

Le Plan Do Check Act – Cycle PDCA est une méthode à 4 étapes fréquemment utilisée dans le processus d’amélioration continue. Chacun des quatre composants joue un rôle spécifique dans ce processus d’amélioration continue.

Plan – Préparer, Planifier

Relisez ce billet: Diagramme D’Ishikawa (Fishbone) pour aller chercher la source des problèmes.

En déterminant comment réaliser des améliorations, il est important de comprendre le problème. Vous ne pouvez pas mettre en œuvre des activités d’amélioration si vous ne comprenez pas d’abord le problème. Vous devez comprendre la cause première, dite cause racine, ses impacts et toute autre information appropriée sur le problème.

C’est ce que vous faites pendant cette phase de préparation.

Une fois que vous avez une meilleure compréhension du problème, vous développez alors un plan pour développer des améliorations.

Pour obtenir une approche plus normative de ces activités, les étapes 1 à 5 du papier 7 Problem-Solving approach  peuvent vous être utiles. Elles vous montrent pas à pas comment vous assurer que vous avez une pleine compréhension de la situation, définissez le problème correctement et choisissez la meilleure solution pour la situation. Vous développerez alors un plan pour développer la solution.

Une partie de la planification est comprendre votre ligne de base de départ et savoir quelle métrique utiliser pour mesurer vos progrès. C’est la seule façon pour vous de savoir si vous avez fait des améliorations adéquates.

Avant de passer à l’exécution de votre plan, identifiez clairement à quoi ressemblera le succès et comment vous saurez si votre approche était réussie. Vous devez être capables d’identifier des résultats quantitatifs ou qualitatifs pour savoir si vous avez été gagnants.

Do – Développer, réaliser, mettre en œuvre

Jusqu’ici, vous et votre équipe avez acquis une bonne compréhension du problème et vous avez développé un plan pour l’adresser.

Vous savez quelles sont vos bases de départ et ce que signifie la réussite. 

Maintenant vous exécutez votre plan. Vous pouvez le faire de deux manières différentes.

  • Vous pouvez mettre en œuvre votre plan sur un pilote, testant les réalisations avec un petit groupe avant de dérouler le plan pour tous.
  • Ou vous pouvez exécuter votre plan avec un plus grand groupe, mais vous assurer que le test est contrôlé.

Que vous choisissiez l’une ou l’autre de ces approches, mettez en œuvre les activités que vous avez identifiées pour atteindre des améliorations.

Check – Contrôler, vérifier

Après un délai prédéterminé, mesurez les résultats des changements effectués. Validez si les changements atteignent vos attentes.

Vérifiez par rapport aux mesures de vos lignes de base du départ. Utilisez la métrique que vous avez identifiée avant le lancement.

Vous voulez voir si votre plan a fonctionné et si vous avez obtenu des résultats positifs.

Vous identifierez aussi où vous pouvez encore améliorer le plan. Vous pouvez devoir tordre certaines choses ou modifier le plan en vous vasant sur ce que vous avez appris.

Vérifiez des résultats par rapport à votre ligne de base et voyez si votre plan a marché comme prévu. Vous pouvez vous devoir l’adapter. C’est un cycle apprenant.

Act (ou Adjust) – Agir, ajuster, réagir

Maintenant que vous savez si vos actions ont apporté une amélioration ou pas, exécutez les étapes suivantes appropriées.

Amélioration continue…

Si vous avez mis en œuvre votre amélioration sur un petit groupe pilote avec des résultats positifs, vous pouvez être prêts à lancer les changements sur un plus grand groupe.

Si vous avez exécuté ces changements sur le plus grand environnement et que tout est bon, vous standardiserez alors les changements pour qu’ils deviennent les nouveaux normaux dans l’environnement.

Alternativement, si les changements réalisés n’ont pas fourni les résultats attendus, ajustez le plan.

Et même si vous avez obtenu des améliorations, vous pouvez trouver en avançant que de nouvelles améliorations sont nécessaires. Dans ce cas vous pouvez répéter le cycle.

C’est l’objectif de l’amélioration continue.

Repeat – Répéter

Le Cycle PDCA n’est pas une activité isolée. Les équipes exécutent le cycle à plusieurs reprises pour continuer à améliorer les processus et construire sur des améliorations précédentes.

Votre équipe et environnement se sont améliorés, mais il y a probablement toujours une marge d’amélioration à exploiter.

De nouvelles connaissances, technologies ou approches peuvent survenir qui pourront aider l’équipe à performer encore mieux.

Ou votre nouvelle ligne de base peut vous donner une compréhension sur la façon de s’améliorer encore de différentes façons.

Ou vous pouvez être si inspirés que vous voulez essayer le cycle PDCA sur un autre processus de votre environnement.

Vous n’êtes pas limités sur combien de fois vous pouvez utiliser le cycle PDCA pour continuer à vous améliorer.

Les bénéfices du Cycle PDCA

Il y a de multiples bénéfices au Cycle PDCA :

Boucle de retours continue

PDCA vous donne une grande boucle de retours du terrain pour apprendre rapidement si votre plan fonctionne ou si vous deviez essayer une approche différente.

Perturbation limitée des processus business.

Vous pouvez essayer des solutions potentielles d’abord à une petite échelle avec un groupe pilote. Cela vous permet d’en apprendre davantage sans perturber l’organisation toute entière.

Gagner l’implication d’autres personnes.

Il faut souvent que beaucoup de membres de votre équipe s’engagent et participent dans la résolution de problèmes. S’ils contribuent à travailler vers des améliorations, cela peut les inspirer et les aider à voir le lieu de travail sous un nouveau jour. Ils peuvent même commencer à contribuer davantage à la résolution de problèmes et à l’amélioration continue.

Créer une culture d’amélioration continue.

Vous pouvez créer une culture d’amélioration continue et construire continuellement sur des succès.

Soyez conscients de ces défis

Ce cycle si simple a de super pouvoirs.

Quand vous utilisez le cycle PDCA, il y a plusieurs considérations à prendre en compte :

  • Il faut du temps. Le Cycle PDCA n’est pas une approche qui peut être utilisée sur des problèmes qui doivent être résolus rapidement.
  • Il faut de la discipline. Pour effectuer le cycle de ces activités, vous devez comprendre votre ligne de base, ce que signifie réussir et comment vous mesurerez ce succès.
  • Il faut un environnement contrôlé. Pour savoir si ce sont bien vos activités qui ont apporté le succès, vous devez être capables de contrôler l’environnement en effectuant votre pilote. Sinon, cela pourrait être simplement une corrélation d’autres événements et pas la cause de la réussite. Si c’est le cas, déployer ces changements à l’organisation toute entière pourrait ne pas avoir les résultats positifs vous attendez.

En bref

Vous voici prêts avec votre organisation à aller décrocher une étoile.

Le Cycle PDCA ne saurait être une réparation rapide, mais sa structure est facile à comprendre et à communiquer. Il peut être utilisé dans beaucoup de situations différentes et vous permettre de créer une véritable culture d’amélioration continue.

Et une fois que vous l’avez utilisé pour faire des changements réussis dans un secteur, vous chercherez probablement autre part où l’appliquer pour encore plus d’améliorations !

Kaizen = amélioration continue

Le par mopertodans outils et méthodesLaisser un commentaire

Le livre de Mike Rother Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results

Voici le kata en bref

Livres sur Amazon
  1. Évaluez ce que vous faites et identifiez un but à long terme pour votre amélioration.
  2. Trouvez une étape intermédiaire, quelque chose que vous pouvez réellement accomplir à court terme pour vous déplacer en direction de votre amélioration (pas y parvenir, juste vous déplacer un peu).
  3. Identifiez 3 choses pratiques que vous pouvez faire tout de suite pour atteindre cet emplacement intermédiaire.
  4. Faites-les.
  5. Répéter à tout jamais.

Affichez la liste d’actions concrètes sur un tableau physique et ajoutez une action à chaque fois que vous en retirez une. L’idée est d’entretenir un flux continu de petites améliorations vous déplaçant vers un plus grand objectif.

CSP est partenaire de DantotsuPM

Centre de contrôle : règles 60 à 65 des 100 pour les managers de projet de la NASA: le matériel, les ordinateurs et logiciels

Le par mopertodans best practicesLaisser un commentaire

Voici les règles sur le matériel, les ordinateurs et logiciels

Règles précédentes: le rôle du manager de projet, les aspects communications et l’humain, les revues et rapports de projet, les sous-traitants, Ingénieurs et Scientifiques.

Matériel

La règle #60 : Dans le domaine spatial, il n’y a rien de tel que du matériel ayant précédemment volé. Les gens qui construisent l’unité suivante n’ont probablement jamais vu l’unité précédente. Il y a probablement des changements mineurs (peut-être même des changements majeurs); l’environnement opérationnel a probablement changé; les gens qui vérifient l’unité dans la plupart des cas ne comprendront ni l’unité ni l’équipement de test.

La règle #61 : La majorité des équipements fonctionnent comme construits, pas comme le concepteur l’avait prévu. Ceci est dû à la représentation du design, une faible compréhension de la part du designer ou des spécifications des composants.

Ordinateurs et Logiciels

La règle #62 : La non utilisation de techniques modernes, comme des systèmes informatiques, est une grande erreur, mais oublier que l’ordinateur simule la pensée est une erreur encore plus grande.

La règle #63 : Le logiciel a maintenant repris tous les paramètres du matériel (c’est-à-dire, dérive des exigences, fort pourcentage du coût de la mission de vol, besoin de contrôle de qualité, besoin de procédures de validation, etc.). Il a la caractéristique supplémentaire qu’il est difficile de s’assurer qu’il n’est pas bogué. Faites d’abord marcher le système de base et ajoutez ensuite les options. Ne jetez jamais une version qui marche même si vous avez la plus grande confiance au monde que la version plus récente fonctionne. Il est nécessaire d’avoir des plans de contingence pour le logiciel.

La règle #64 : La connaissance est souvent revisitée avec des simulations ou la mise à l’épreuve, mais des modèles informatiques ont des défauts cachés dont le moindre n’est pas de mauvaises données d’entrée.

La règle #65 : Autrefois, les ingénieurs avaient l’expérience du terrain, les techniciens comprenaient comment l’électronique fonctionnait et ce qu’elle pouvait réaliser et les techniciens au sol le savaient aussi, mais aujourd’hui seul l’ordinateur sait à coup sûr et il ne parle pas.

Méta Projets Management est partenaire de DantotsuPM

Liste complète en anglais sur Geekboss par Matthieu Stibbe

et si les 10 derniers points de pourcentage étaient justement ce qui fait la différence ?

Le par mopertodans experience sharingLaisser un commentaire

Cela en vaut-il vraiment la peine ?

J’apprécie toujours les dires de Seth Godin dans ces livres comme dans ses brefs billets de blog car ils provoquent, par leur intelligence dans l’analyse des situations, leur bon sens et leur humour. En bref, Seth me donne très souvent matière à réflexion.

Celui-ci publié en 2010 est pile dans la ligne éditoriale de DantotsuPM et avec l’objectif de rechercher l’excellence pour dépasser les attentes des lecteurs et en faire ainsi de vrais fans qui recommanderont à leurs amis et collègues de suivre ce blog.

Livre sur Amazon

La qualité des contenus et de leur présentation doit permettre de faire grandir notre tribu comme le dirait Seth : « La tribu des chefs de projet qui cherchent en permanence à s’améliorer ».

Hardly worth the effort (version originale)

Dans la plupart des domaines, il y a une terrible quantité 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 basculer sur une file d’attente.

Faire des pâtisseries comme un  excellent pâtissier demande beaucoup plus de travail que de faire des gâteaux au chocolat à la maison.

Concevoir la présentation d’une page web 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 réside 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 s’empresse déjà de 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. Voici ce pour quoi vous êtes payé.

quels furent les billets DantotsuPM les plus lus en Juin 2017 ?

Le par mopertodans agile, pointeurs utilesLaisser un commentaire

les articles les plus lus sur DantotsuPM de Juin 2017

Ce mois-ci les billets appréciés des suiveurs du blog et autres visiteurs furent ceux liés à l’agilité, aux soft skills et à la qualité. Bonne relecture ou découverte !

15 vérités pas si évidentes sur les compétences relationnelles: les connaissez-vous? qu’ajouteriez-vous?

Les personnes non intuitives et de nombreux professionnels techniques disent que maitriser les aspects pas si évidents des interactions avec les personnes (« soft skills » ou compétences relationnelles) est un grand défi et souvent prise de tête.

certaines relations peuvent être particulièrement frustrantes !

Quelles vérités sur les compétences ces personnes doivent-elles apprendre et utiliser ?

« Peut-on se libérer de sa culture ? » (de waterfall vers l’agilité)

L’un des 2 sujets 2017 du bac S en philosophie: « Peut-on se libérer de sa culture ? » m’a immédiatement rappelé des discussions avec Claude Emond sur la culture Agile et plusieurs billets que nous avons ensemble publiés sur ce blog.

L’Aïkido Verbal est un moyen pacifique de gérer les attaques verbales, basé sur la philosophie de l’aïkido martial.

Pour aller plus loin, le livre sur Amazon

Cet art s’est inspiré de la pratique et de la philosophie de l’aïkido martial, et permet de diriger une agression verbale vers un résultat positif et équilibré. Comme dans l’art martial, l’assaillant et le défenseur sont dits « partenaires » et non « adversaires ». Il n’y a donc pas à proprement parler d’affrontement, ni vainqueur ni vaincu.

Connaissez-vous le nouveau Agile Practice Guide (en anglais) ?

PMI et Agile Alliance se sont mis au travail ensemble pour produire le Agile Practice Guide dans l’intention de forger une meilleure compréhension des pratiques agiles pour les chefs de projet.

la qualité est trop souvent considérée seulement à la fin des projets: les 14 points de Deming sont un guide pour l’obtenir systématiquement

Le livre sur Amazon

La qualité est mal comprise par trop de personnes qui n’y pensent que quand ils touchent au produit final. En réalité, c’est seulement au travers de processus de qualité centrés sur l’efficacité, l’innovation et l’amélioration continue qu’un produit de qualité est réalisé, et ces processus exigent une culture de management de qualité non seulement dans nos projets, mais aussi dans nos organisations.

Dans le chapitre 2 de son livre de 1986, « Out of the Crisis« , Edward Deming a présenté 14 prinipes dont il pense qu’ils peuvent rendre l’industrie plus compétitive grâce à un accroissement de la qualité.

Comment crever le double plafond de l’Agilité ?

Marc-Noël Fauvel

Billet original sur LinkedIn (republié avec l’autorisation de Marc-Noël Fauvel que je remercie)

L’agilité au niveau des équipes de développement a fait ses preuves depuis des années maintenant principalement grâce à SCRUM et XP.

Enregistrer

5 façons de rester proactif pendant des retards de projet

Le par mopertodans best practicesLaisser un commentaire

vous pouvez réduire les effets négatifs des retards de projet par cinq actions clés

5 Ways to Stay Proactive During Project Delays

http://www.ims-web.com/blog/5-ways-to-stay-proactive-during-project-delays par Jeff Collins

Des retards de projet sont une partie inhérente de n’importe quel projet.

waitingDes retards de projet surviennent en conséquence de la piètre planification, de communication inadéquate, de réduction des ressources allouées et de changements dans le contenu du projet. En outre, les retards de projet appauvrissent le moral des collaborateurs et réduisent la vitalité de votre équipe de management de projet.

Heureusement, vous pouvez réduire les effets négatifs des retards de projet par cinq actions clés. Lisez ce qui suit pour voir comment votre équipe de management de projet peut maintenir un environnement positif et rester productive quand des retards de projet arrivent.

1. Tenez des réunions avec les membres de l’équipe et ressources qualifiées

Office workers in meeting --- Image by © Royalty-Free/Corbis
Image by © Royalty-Free/Corbis

Les membres de l’équipe et des ressources qualifiées peuvent ignorer des retards actuels du projet. Donc, entretenez un bon niveau de communication avec les membres de l’équipe et personnes qualifiées est critique pour garantir que des retards dans le projet n’aboutissent pas à l’échec du projet. Tenez des réunions quotidiennes avec tous les contributeurs et membres de l’équipe pendant la durée de ces retards de projet. Sollicitez des retours d’information et options possibles ou façons de réduire les effets négatifs du retard de leur part. En restant connectés, vous pouvez maintenir une relation positive avec toutes les parties affectées.

NQI est Partenaire de DantotsuPM
NQI est Partenaire de DantotsuPM

2. Réévaluez l’état actuel de votre projet et autres retards potentiels

effet domino dans les dérivesLes retards peuvent être un indicateur de problèmes à venir sur votre projet. Quand les retards surviennent, réévaluez l’état actuel de votre projet. Comment ce retard initial impactera-t-il d’autres tâches et activités ? Est-ce que ce retard est raisonnable, ou est-il simplement un moyen de réduire le coût de votre projet ? Ces questions identifieront pourquoi le retard est là et comment des retards semblables pourraient être minimisés dans l’avenir.

3. Réaffectez les ressources à des activités et tâches non-retardées

Si le retard est localisé sur des tâches et activités spécifiques, vous pouvez pouvoir déplacer des travailleurs et des allocations de ressources vers des tâches non-affectées. Bien que ceci change le planning des activités, il permet à votre personnel de rester productif quand votre projet souffre de retards. En outre, vous devez considérer comment les retards affecteront le périmètre global de votre projet.

Essayez Bubble Plan !
Essayez Bubble Plan !

4. Revisitez vos données capturées pour l’analyse de risque

Parfois, les retards peuvent être le résultat de votre équipe projet et l’incapacité des personnes à réaliser dans des délais peu réalistes. Si les retards semblent arriver sans avis du management exécutif, passez en revue les données et facteurs dans votre analyse de risques. Conduisez une session supplémentaire d’analyse de management des risques pour définir pourquoi et comment les problèmes sont survenus. Si le problème réside avec un membre spécifique de l’équipe, envisagez de fournir une formation supplémentaire pour corriger le problème.

5. Conduisez une inspection de la qualité des livrables achevés et en cours

Image courtesy of Stuart Miles / FreeDigitalPhotos.net
Image courtesy of Stuart Miles / FreeDigitalPhotos.net

Certains retards de projet peuvent saper la capacité de votre équipe à compléter un projet dans un délai donné. Cependant, des retards ne peuvent être évités et votre équipe doit rester productive pendant tout le projet. Demandez aux membres de l’équipe et contributeurs de conduire des inspections de la qualité du travail réalisé et rechercher des erreurs. Bien que cette étape soit normalement la dernière partie d’un projet, vous pouvez réduire l’impact global des retards en conduisant des inspections de qualité en continu.

Quand vous ignorez la possibilité de retards de projet, vous allez plus probablement exposer de faibles qualités de leadership et refuser de vous adapter quand les retards arrivent. En prenant ces cinq actions, votre équipe de management peut rester productive pendant ces périodes de retards de projet.

 Retenez ces quelques idées :

  • La communication est l’action la plus importante pour rester productifs pendant des retards de projet.
  • Revoir les échéances de projet et conduire une nouvelle analyse de risque permet d’identifier des retards potentiels dans l’avenir.
  • Commencer à travailler sur d’autres tâches et activités en avance de phase si des retards affectent des parties spécifiques de votre projet.
  • Conduire des inspections de qualité préliminaires si votre équipe est incapable d’exécuter d’autre travail avant que les retards ne soient écoulés.

Enregistrer

Vaut-il mieux un livrable parfait et en retard qu’acceptable et dans les temps ?

Le par mopertodans Non classé2 commentaires

Dans la plupart des sociétés et organisations la réponse est « acceptable et dans les temps ».

Read this master book on the suject
Read this master book on the suject

En effet, les dérives du perfectionnisme peuvent être coûteuses pour l’entreprise car admettons-le, tout livrable : article, email, vidéo, morceau de code, produit… peut toujours être optimisé et amélioré. Cependant, il advient aussi toujours un moment où vous devez le livrer.

Aussi, comme le prônent les méthodes Agile et les concepts tels que le Produit Minimum Viable (MVP), respecter un délai sans être paralysé par la recherche de perfection est vital pour l’entreprise.

Si cette question vous est posée lors d’un entretien de recrutement, il y a de fortes chances pour que la réponse attendue soit « ça dépend… ».

Indiquez certains cas où la recherche de qualité éventuellement poussée jusqu’à la perfection est louable et d’autres pour lesquels le timing est primordial.

Efforcez-vous de puiser vos exemples sur du concret, du vécu lors de projets passés ou d’échecs et succès retentissants.

perfectEn effet, la capacité à prendre du recul et à balancer le pour et le contre en toutes circonstances est une qualité très recherchée chez les chefs de projets et les leaders.

contactez-nous pour publier une annonce
contactez-nous pour publier une annonce

Chef de projet et PMO: Comment définissez-vous le management de la qualité pour un projet ?

Le par mopertodans Non classéLaisser un commentaire

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
contactez-nous pour publier une annonce
  1. 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)
  2. 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
  3. 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
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.

détaillerComme 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.

ne vous précipitez pas sur la dette (technique) par Jeff Ball

Le par mopertodans agileLaisser un commentaire

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.

facturesMS-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:

  • developer womanDocumentation 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
    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
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
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 utiliser Agile?

APMG-AgilePMLes 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
Jeff Ball

Vous ne pourrez probablement pas vous en débarrasser totalement, mais vous devez appliquer ces trois règles d’or :

  1. Commencez dès aujourd’hui à rembourser les anciennes dettes (chaque nouveau projet rectifie des erreurs et confusions passées)
  2. Évitez de nouvelles dettes (bien faire les choses à l’avenir, équilibrer rapidité et qualité)
  3. Si, pour un projet, vous n’avez pas d’autre choix que de générer une dette, éliminez-la le plus vite possible
Institut International de Conseil et de Formation Accrédité aux Bonnes Pratiques PRINCE2® (Gestion de Projet), ITIL® (Gouvernance du SI), P3O® (Management d'un PMO) et MSP® (Management de Programme).
Partenaire de DantotsuPM

© Copyright QRP International 2011. Reproduction in full or part is prohibited without prior consent from QRP International

Pour aller plus loin: