Tôt ou tard, nous procrastinons tous. Nous remettons cette tâche importante à demain, en nous convainquant qu’il reste encore beaucoup de temps. Un petit retard n’a jamais fait de mal à personne, n’est-ce pas ? Malheureusement, la procrastination est plus qu’une mauvaise habitude. Au fil du temps, cela peut éroder discrètement notre productivité, nuire à notre réputation et nous priver de tranquillité d’esprit.
Si vous ne pensez pas que c’est vrai, il est probable que vous êtes dans le déni de ce que vos retards vous coûtent. Comprendre les conséquences réelles de la procrastination est la première étape pour vous libérer de son emprise.
Occasions manquées
La procrastination nous fait souvent manquer de précieuses opportunités. Qu’il s’agisse de postuler à un emploi, de soumettre une proposition ou de lancer une idée d’entreprise, les retards peuvent fermer des portes qui pourraient ne jamais s’ouvrir à nouveau. Les opportunités urgentes n’attendent pas, et lorsque vous reportez une action, vous êtes souvent perdant par défaut.
Augmentation du stress et de l’anxiété
Le fait de remettre les choses à plus tard les fait rarement disparaître. En effet, plus une tâche est retardée, plus elle pèse sur votre esprit. Ce qui commence comme une petite chose à faire peut rapidement devenir une source de stress accablante. Les échéances s’allongent, les responsabilités s’accumulent et la charge mentale devient plus difficile à porter. La procrastination chronique entraîne un état d’anxiété constant qui affecte à la fois votre travail et votre vie personnelle.
Baisse de la qualité du travail
Lorsque les tâches sont réalisées dans la précipitation à la dernière minute, la qualité en souffre. Vous ne vous donnez pas assez de temps pour planifier, penser de manière critique ou faire les modifications nécessaires. Le résultat est souvent un travail médiocre qui ne reflète pas votre véritable potentiel. Au fil du temps, cela peut nuire à votre crédibilité et limiter vos opportunités de croissance. Maintenant, certains d’entre vous diront qu’ils travaillent mieux sous pression : Il n’y a aucune évidence dans la recherche pour étayer cette affirmation. Vous vous trompez peut-être.
Relations endommagées
La procrastination n’affecte pas seulement vous-même, elle affecte les gens qui vous entourent. Lorsque vous retardez des tâches dont d’autres dépendent, vous les laissez tomber. Vos engagements manqués et promesses non tenues peuvent mettre à rude épreuve vos relations avec vos collègues, amis et famille. La confiance est facile à perdre et difficile à reconstruire.
Diminution de la confiance en soi
Chaque fois que vous procrastinez, vous renforcez un cycle d’évitement et de regret. Cela peut conduire à une image négative de vous-mêmes, où vous commencez à vous considérer comme peu fiable ou incapable. Au fil du temps, cela sape votre confiance en vous et votre motivation, ce qui rend encore plus difficile d’agir à l’avenir.
Retard de croissance personnelle et professionnelle
Le progrès exige des efforts constants. Lorsque vous procrastinez, vous freinez votre développement. Vos objectifs prennent plus de temps à atteindre, s’ils sont atteints. Vos compétences ne sont pas améliorées et votre potentiel reste inexploité. La procrastination est un voleur silencieux de temps et de croissance.
Brisez le cycle
La bonne nouvelle, c’est que la procrastination n’est pas un trait de caractère permanent, c’est une habitude qui peut être changée.
Commencez par de petites étapes :
Divisez les tâches importantes en sous-tâches gérables.
Fixez-vous des dates limites claires, même celles que vous vous imposez à vous-même.
Éliminez les distractions de votre environnement.
Récompensez-vous pour vos progrès.
Pratiquez l’autocompassion et ne laissez pas la procrastination passée vous définir.
Plus tôt vous agissez, plus vous reprenez le contrôle de votre temps, de votre énergie et de votre avenir.
La procrastination peut sembler inoffensive sur le moment, mais avec le temps, ses conséquences s’aggravent. En reconnaître le coût est la première étape vers la récupération de votre élan et de votre vie.
partagez ce billet avec vos amis, collègues et relations professionnelles
Il y a des endroits où la perfection est un prérequis. Mais la plupart du temps, c’est la variabilité et la texture de ce que vous créez qui en fait la magie.
Pour une chaussée parfaite, le pavage du sol pourrait être une option.
Le revêtement de la chaussée est invisible pour le conducteur. C’est attendu, doux, résistant et on l’oublie. Vous ne remarquez une route que lorsqu’elle n’a pas un bon revêtement.
La nature, en revanche, n’est jamais parfaite. Toutes les forêts intactes sont naturelles, mais chacune est différente. C’est là le sujet.
La dureté peut être parfaite. Vous pouvez la mesurer. La douceur, en revanche, est multidimensionnelle.
Il y a des moments dans nos engagements avec les clients où nous voulons que les étapes soient pavées. Un itinéraire simple d’ici à là. Si vous allez paver quelque chose, assurez-vous que ce sera parfait.
Mais le reste du temps, la texture et la variabilité de ce que nous créons font partie de la magie.
partagez ce billet avec vos amis, collègues et relations professionnelles
Un retour d’expérience concret sur l’analyse de risques dans les projets internationaux.
J’ai été impliqué dans un projet de fabrication de machines, d’expédition, d’installation et de mise en service de dix énormes moulins à riz pour le gouvernement fédéral d’un pays africain. Le contrat a été mis en place de telle sorte que nous fabriquions les machines en Inde et que nous créions une société sœur dans ce pays pour gérer les formalités locales, dédouaner tous les conteneurs et gérer le génie civil et la construction de toutes les installations.
Impact de la corruption dans certains pays.
Au total, 250 conteneurs ont été expédiés et la chose la plus surprenante à propos des autorités portuaires sur place est qu’il y a toujours un certain niveau de corruption dans le processus de dédouanement des conteneurs alors que sur le papier, il n’y a aucun coût. Dans les faits, il s’agit d’un pays importateur important et ses ports sont toujours occupés et surchargés, ce qui entraîne un pouvoir de négociation accru des agents de dédouanement et des autorités portuaires alors qu’il ne devrait même pas exister. Certaines parties prenantes de ce projet ont insisté pour payer tout ce qui est nécessaire pour garder les conteneurs sous notre contrôle, mais l’une d’elles a refusé de payer quoi que ce soit et, malheureusement, les conteneurs (pas tous, mais certains critiques) se sont retrouvés coincés au port et ont commencé à accumuler des frais de surestaries*. Dans cette situation, les coûts de récupération, dont les surestaries, sont devenus insoutenables et nous avons dû attendre la fin d’une période de 90 jours avant de pouvoir les racheter lors d’une vente aux enchères publiques, ce qui a considérablement retardé nos projets.
Planification et qualité.
Une seconde erreur, cette fois-ci de planification, s’est produite lorsque sur certains des dix sites du projet, la construction réalisée était insuffisante pour stocker les conteneurs qui ont été dédouanés du port. De plus, dans certains cas, en raison du stockage des conteneurs sur des sites moins bien protégés, il y a eu des dommages causés par la pluie à certaines machines. Dans d’autres situations, il y a eu des vols de petits équipements.
Nous avons maintenant établi une politique stricte selon laquelle un entrepôt verrouillable sera construit dès le tout début afin que les matériaux et les machines placés dans les conteneurs puissent être stockés avant que d’autres constructions puissent être réalisées.
Leçon apprise : Rien ne remplace l’expérience locale.
Ainsi, un élément sous-jacent majeur que nous avons constaté est que lorsque nous travaillons dans un pays étranger, nous devons toujours être prêts à faire face à des risques inattendus de retards et des ruptures de processus. Cette analyse de risques ne peut être faite de manière adéquate qu’avec quelqu’un qui vit ou qui a travaillé dans ce pays. Elle ne peut pas être réalisée avec une garantie de 100 %, mais peut être faite suffisamment bien pour prévenir des risques majeurs.
* Les frais de surestaries sont les coûts associés à la conservation des conteneurs au port au-delà de la période gratuite autorisée pour le chargement ou le déchargement. Cela se produit généralement lorsqu’il y a des retards dans le dédouanement ou lorsque le fret n’est pas récupéré rapidement au terminal.
Je m’appelle Kripansh, j’ai 27 ans et j’ai la nationalité indienne. J’ai toujours été intéressé par le dessin, la géographie et la lecture de livres depuis mon plus jeune âge et l’obtention de mon diplôme en génie mécanique.
Après cela, j’ai travaillé dans l’industrie de la transformation des aliments et j’ai été en poste en Afrique en tant que manager de projet pour le gouvernement fédéral de l’un des pays. Ce projet était multiforme avec un large éventail de configurations industrielles en interne sur chaque site et il m’a beaucoup appris sur le génie industriel car j’y gérais les domaines du génie mécanique, électrique et civil.
À l’heure actuelle, je termine mes études de MBA en France et j’ai récemment obtenu ma certification PMP®. J’apprends le français en ce moment et je suis enthousiaste à l’idée d’obtenir un poste de manager de projet en Europe dans les mois à venir !
partagez ce billet avec vos amis, collègues et relations professionnelles
Vous pouvez gérer les risques de votre projet autant que vous le souhaitez, mais si vous ne tenez pas compte de la façon dont vous allez évaluer et manager la qualité, ces efforts risquent d’être vains.
Balancing risk and reward in fast-paced project delivery par Quay Consulting
Ces stratégies efficaces de management de projet basées sur les risques vous aideront à prendre des décisions éclairées lorsque les choses deviennent urgentes, garantissant ainsi la qualité et la réussite de vos projets dans des environnements dynamiques.
Il y a un dicton célèbre parle d’agir à la hâte et se repentir à loisir, ce qui signifie essentiellement que si vous agissez toujours trop vite, il y a beaucoup plus de possibilités d’erreurs.
Pour la plupart des professionnels de projet, c’est une bonne idée, mais quelque peu difficile à traduire en actions significatives. Après tout, beaucoup d’entre vous opèrent dans un environnement où les choses semblent changer sur une base quotidienne (voire horaire), et tout est toujours une haute priorité. Vous pouvez même avoir l’impression de devoir agir à la hâte ou de risquer d’être laissé pour compte.
Voici le problème :
Dans le monde de la livraison de projets, vous n’avez parfois pas d’autre choix que de prendre des mesures urgentes.
Il se peut que vous ayez une vulnérabilité importante à laquelle vous devez remédier rapidement, qu’il s’agisse du déploiement d’un correctif logiciel critique ; ou le déploiement d’un programme de vaccination majeur face à une pandémie mondiale.
Alors que la plupart d’entre nous devront prendre des décisions urgentes à de nombreuses reprises au cours de leur carrière professionnelle sans conséquences connues importantes, de temps en temps, il y aura une action ou une décision qui enverra des ondes de choc à travers votre projet ou votre organisation. Dans le pire des cas, il peut même y avoir un impact plus large sur votre secteur ou peut-être même sur le monde (il suffit de poser la question à CrowdStrike).
Dans de nombreux cas, la différence entre le succès et l’échec se résume presque toujours au fait que le programme a adopté ou non une approche d’exécution fondée sur le risque. Tenez toujours compte du rapport risque/récompense de la livraison de votre projet.
Posez-vous la question, demandez à votre équipe :
Si nous avons raison, qu’avons-nous à gagner ? Si nous avons tort, qu’avons-nous à perdre ? Et surtout, comment équilibrer le risque et la récompense pour prendre des décisions judicieuses ?
N’évitez pas les risques liés au projet, équilibrez-les
Il n’y a pas de projet parfait – en fait, chaque transaction commerciale que vous entreprenez est essentiellement un transfert de risque d’une partie à une autre. Plutôt que de chercher à éviter tous les risques, une approche plus saine consiste à accepter qu’il s’agit d’une partie fondamentale de ce que vous faites et à équilibrer les risques en conséquence. Cela pourrait être aussi simple que de cartographier les différents chemins que le projet pourrait emprunter par rapport au triangle délais/coût/qualité pour comprendre les risques associés à chacune.
Par exemple:
L’option A est plus rapide et beaucoup plus rentable, mais la qualité peut être considérablement affectée.
L’option B sera rentable et donnera un résultat de haute qualité, mais il faudra plus de temps pour y parvenir (ce qui la rendra moins risquée que l’option A).
L’option C peut être livrée rapidement et avec une meilleure qualité, mais elle coûtera plus cher (elle peut présenter des risques importants, bien que différents de ceux de l’option A).
Une fois ces options présentées, et avec une transparence totale sur les risques et les opportunités de chaque option, les dirigeants peuvent prendre une décision sur le chemin à suivre en fonction de l’appétit actuel pour le risque de l’organisation par rapport à chacun de ces paramètres.
Si cela représente un risque majeur pour votre entreprise, par exemple, il y a une faible tolérance pour un délai de livraison plus long ou une sortie de qualité inférieure, l’option C pourrait être la voie la plus acceptable. D’un autre côté, si le budget est la priorité absolue et que vous avez une certaine marge de manœuvre pour tolérer des ajustements et des retouches à la fin du projet, alors l’option A peut cocher toutes les cases de management des risques.
À ce stade du projet, il est relativement simple de capturer ce que nous appelons les « risques de cause spéciale » (c’est-à-dire des événements très irréguliers et percutants tels que des changements réglementaires inattendus ou la défaillance d’outils ou de processus critiques). Il faudra peut-être réfléchir davantage au danger des « risques de cause commune » (ceux auxquels on peut raisonnablement s’attendre, comme la disponibilité du personnel et les problèmes techniques mineurs).
Faire des hypothèses raisonnables et contextuelles
Les hypothèses sont notre meilleure arme lorsqu’il s’agit de gérer les risques et les récompenses. Tous les projets commencent par des hypothèses. En fait, c’est le signe d’un projet sain que d’avoir de nombreuses hypothèses de départ.
D’après notre expérience, le profil idéal de livraison de projet doit capturer de nombreuses hypothèses dès le départ, alors que votre équipe a une connaissance expérientielle minimale. Partant du principe que le progrès crée la connaissance, ces deux paramètres (hypothèses et connaissance) doivent évoluer au fur et à mesure de l’avancement du projet, pour devenir inverses l’un de l’autre. Les hypothèses tomberont au fur et à mesure que le projet sera livré et vous acquerrez des connaissances grâce aux progrès, à l’expérience et aux réalisations.
C’est là le cœur d’une approche véritablement fondée sur les risques. Un plan n’est qu’un grand ensemble d’hypothèses – si nous faisons cela, nous pensons que ceci sera le résultat. Chaque étape comporte des risques et des opportunités. Ce n’est qu’en les équilibrant que vous êtes susceptible d’assurer le succès global.
L’importance du contrôle de la qualité
Si les protocoles de management des risques sont l’un des aspects de l’approche « fondée sur les risques » du management de projet, le contrôle de la qualité est l’autre côté de la médaille. Vous pouvez gérer les risques de votre projet autant que vous le souhaitez ; Cependant, si vous ne tenez pas compte de la façon dont vous allez évaluer et manager la qualité, ces efforts risquent d’être vains.
Nous pensons parfois que le contrôle de la qualité est un peu comme voir avec du recul : Tout mérite 20/20 (Il est facile de voir vos erreurs après qu’elles aient été détectées par quelqu’un d’autre). Il est toujours préférable de ne pas être la cible de ce traitement, alors assurez-vous de lire nos stratégies pratiques pour vous assurer d’avoir pris en compte le contrôle de la qualité dans votre projet , du début à la fin.
Quay Consulting est une entreprise de services professionnels spécialisée dans le monde des projets, transformant la stratégie en une mise en œuvre adaptée. Rencontrez leur équipe ou contactez-les pour en savoir plus sur la façon dont Quay Consulting peut aider votre organisation.
partagez ce billet avec vos amis, collègues et relations professionnelles
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 ?
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 !
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.
Partenaire de DantotsuPM, CERTyou est le spécialiste des formations certifiantes
partagez ce billet avec vos amis, collègues et relations professionnelles
Une équipe stable est une équipe dans laquelle la composition de l’équipe ne change pas souvent et est, au contraire, cohérente au fil du temps. Pourquoi devriez-vous vous en soucier ?
In Agile, Where Change is Valued, Why Is a Stable Team So Important? par Mark Levison
Une équipe stable est une équipe dans laquelle la composition de l’équipe ne change pas souvent et est, au contraire, cohérente au fil du temps.
Pourquoi devrions-nous nous en soucier ? Scrum n’est-il pas comme le basket-ball où vous pouvez changer les joueurs sur le terrain à chaque fois qu’il y a une interruption ? Découvrons-le…
Les équipes très performantes, ou les équipes qui font des choses avec une qualité incroyablement élevée, est l’objectif de beaucoup de ceux qui arrivent dans Scrum en s’attendant à obtenir des performances incroyables de leur système. Mais construire une équipe performante à partir de zéro prend du temps. L’image populaire du modèle de formation d’équipe de Tuckman montre une équipe passant par les étapes de formation/constitution à tension à normalisation puis exécution/production. (Mise en garde : l’image existe pour simplifier la compréhension. La dynamique d’une vraie équipe sera plus désordonnée qu’on ne le montre ici).
Il est facile de former une équipe, puis de passer à toute vitesse à travers la phase de tension. La phase de tension est caractérisée par des conflits, car les gens appréhendent les rôles et les relations.
La normalisation et l’exécution sont considérablement plus difficiles dans les équipes instables, et elles s’y produisent à plusieurs reprises. Chaque fois qu’il y a un changement dans la composition de l’équipe, il y a de fortes chances de revenir à la phase de tension en raison de la nouvelle dynamique interpersonnelle. J’avertis les organisations que, lorsqu’elles doivent apporter des changements, il y a un risque que le changement les renvoie non seulement à la tension, mais qu’il soit également suffisamment dommageable pour que l’équipe ne s’en remette pas du tout. Combien de fois voulez-vous tenter la chance ?
La plupart des travaux de la littérature académique traitent de la familiarité, et non de la stabilité. Grosso modo, cela signifie « nous avons suffisamment travaillé ensemble dans le passé pour nous comprendre en tant qu’individus ». Que vous l’appeliez familiarité ou stabilité, la prémisse est la même : Les gens ont besoin de temps pour apprendre à se comprendre et à communiquer efficacement, la clé est que la familiarité est plus faible que la stabilité.
Lorsque les membres de l’équipe se connaissent, vous en voyez les bénéfices dans le niveau de qualité du travail de cette équipe. Prenons, par exemple, la chirurgie. J’espère que la plupart des équipes Scrum font un travail moins risqué que les interventions chirurgicales, mais la chirurgie (pour des raisons évidentes) est bien étudiée, ce qui nous donne une bonne source de données.
Il y a un chirurgien orthopédiste qui opère plus de 500 chirurgies du genou par an, soit 2,5 fois plus que n’importe qui d’autre dans son hôpital. Il a mis en place des dizaines de techniques pour améliorer ses interventions. Au lieu de travailler avec un groupe changeant d’infirmières et d’anesthésistes, il dispose de deux équipes dédiées et il dit que « peu des méthodes qu’il a mises au point seraient pratiques si elles n’étaient facilitées par la familiarité de travailler avec les mêmes personnes tous les jours ».[1]
Tuer le patient est l’erreur ultime. Ne pas les tuer est une barre assez basse de succès côté qualité. Néanmoins, les chirurgiens cardiaques qui travaillaient dans plusieurs hôpitaux mais maintenaient des équipes stables avaient un taux de mortalité plus faible, même avec davantage d’opérations chirurgicales effectuées. Les auteurs de l’étude ont attribué ce niveau de qualité du travail en partie à la familiarité de l’équipe.[2]
L’aviation et l’aéronautique sont également des domaines largement étudiés avec des données qui soutiennent l’importance d’équipes stables. « 73 % des accidents pour lesquels des informations étaient disponibles se sont produits le premier jour où le commandant de bord et le copilote ont volé ensemble. »[3]
Une étude de la NASA a révélé que les équipages fatigués qui avaient l’habitude de travailler ensemble commettaient environ deux fois moins d’erreurs que les équipages composés de pilotes reposés qui n’avaient jamais volé ensemble avant.[4]
Et pour redescendre sur terre, une étude de la société d’externalisation de logiciels Wipro a révélé qu’une familiarité accrue réduisait les défauts de 19%.[5]
Comment les équipes stables affectent-elles la prévisibilité ?
Il n’y a pas de données sur la prévisibilité des chirurgiens, ce qui, à mon avis, pourrait être une bonne chose.
L’étude de Wipro a montré que « les écarts par rapport au budget ont diminué de 30% ». Ignorons l’accent mis sur le budget, alors qu’il devrait s’agir de la construction du bon produit, mais cela montre que la familiarité facilite la prévisibilité.
Dans l’étude « Impact of Agile Quantified »[6], Larry Maccherone a montré que les équipes stables avaient une prévisibilité supérieure de 40%.
Incidence des équipes stables sur la productivité
Nous ne devrions pas vraiment courir après « plus de fonctionnalités produites plus rapidement » comme résultat. Au lieu de cela, nous devrions nous concentrer sur une meilleure valeur et de meilleurs résultats. Cela dit, je n’ai jamais rencontré quelqu’un qui ne voulait pas voir son équipe réaliser plus de choses.
Chez Wipro, « nous avons également constaté que la familiarité était un meilleur indicateur prédictif de performance que l’expérience individuelle des membres de l’équipe ou des managers de projet ». Des données plus impressionnantes du « The Impact of Agile Quantified » ont montré que les équipes stables sont 60% plus productives. Dans de nombreuses organisations, c’est le levier qui nous permet d’aller vers les équipes stables.
N’oubliez pas de vous concentrer sur les résultats plutôt que les productions.
Pourquoi les équipes stables fonctionnent-elles ?
L’esprit d’équipe (ou modèle mental partagé). Nous savons ce que les autres savent et sur qui on peut compter pour faire certaines choses.
La coordination et une meilleure collaboration sont plus faciles lorsque nous nous connaissons bien.
Flexibilité. L’esprit d’équipe et la capacité à collaborer permettent à l’équipe de s’adapter plus facilement lorsque des changements plus importants dans les produits se matérialisent.
L’amélioration continue nécessite les mêmes personnes, ainsi nous ne continuons pas à réexaminer des choses que nous avons apprises il y a des mois.
L’esprit d’équipe et le processus d’apprentissage continu approfondissent la connaissance de l’équipe de son domaine de travail, ses compétences techniques et sa connaissance de sa base de code.
Pourquoi les équipes stables peuvent-elles être difficiles ?
Donc, si les équipes stables sont une bonne chose, qu’est-ce qui rend difficile de les atteindre ?
Organisation matricielle. Lorsque les membres de l’équipe relèvent de différents managers, chaque manager aura des agendas/besoins différents. Par conséquent, les membres de l’équipe peuvent être réaffectés, même si une solution plus élégante pourrait fonctionner et leur permettre de rester dans l’équipe.
Dépendance à l’égard d’experts externes. Lorsqu’une équipe fait appel à une aide extérieure pour acquérir des compétences spécialisées, elle essaie souvent d’inclure « l’expert » dans l’équipe. Cela fonctionne rarement bien. Une meilleure solution est de les utiliser comme consultant/coach, mais de ne pas leur faire faire le travail pratique. Au lieu de cela, ils enseignent aux membres de l’équipe comment effectuer le travail en question, en maintenant la dynamique de l’équipe et en améliorant les compétences en même temps.
Politique organisationnelle. Berk. J’en ai assez dit.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
Quand des équipes stables ne sont-elles pas souhaitables ?
Dans certains cas, lorsque la complexité du problème (voir : La complexité et le cadre Cynefin) est telle que les compétences des membres de l’équipe évoluent rapidement, les équipes stables peuvent ne pas être une priorité. Dans ce cas, nous pourrions sacrifier les performances, la réduction des erreurs, etc., pour avoir une chance de nous attaquer d’abord au problème. Les problèmes de cette nature sont incroyablement rares. S’il vous plaît contactez-moi si vous pensez en avoir trouvé un, je veux vérifier.
Reconstruire les équipes
Parfois, le produit sur lequel on travaille n’est plus aussi important et l’organisation doit réduire les coûts et déplacer les membres de l’équipe. Redgate Software a mis au point une technique permettant d’équilibrer la stabilité et l’adaptation à l’évolution des conditions du marché [7], où l’organisation prend chaque année des décisions stratégiques quant aux domaines sur lesquels se concentrer. Une fois les décisions prises, les membres de l’équipe peuvent choisir eux-mêmes l’équipe dans laquelle ils souhaitent travailler.
Préférez une appartenance stable à une équipe plutôt qu’un assemblage changeant de personnes. Lorsque vous n’avez pas le choix, examinez les circonstances et assurez-vous que l’organisation comprend ce à quoi elle renonce.
[1] The Firm Specificity of Individual Performance: Evidence from Cardiac Surgery – Robert S. Huckman and Gary P. Pisano
[2] A Review of Flightcrew-Involved, Major Accidents of U.S. Air carriers 1978 Through 1990 – NTSB
Faire des recherches sur les clients est une perte de temps pour un développeur. (N’hésitez pas à remplacer « développeur » par cadre exécutif, Analyste Qualité, etc.).
L’argument se poursuit avec
Nous avons embauché nos développeurs pour écrire du code et que tout ce qui les éloigne de cette tâche est une distraction à minimiser.
Un bon code est bien plus que des bogues ou des performances
Cet état d’esprit trahit une croyance organisationnelle selon laquelle fournir du code est la même chose que fournir de la valeur aux clients. Il n’y a que deux choses que la livraison de code vous garantit d’obtenir : (1) plus de code et (2) plus de dette technique. Chaque ligne de code écrite par un développeur vivra pour toujours dans les systèmes que vous construisez. Le code nécessitera de la maintenance. Il accumulera de la dette au fil du temps. Si nous ne pouvons pas garantir que chaque ligne apportera quelque chose de valeur à nos utilisateurs et à l’entreprise, nous ne devrions pas l’écrire. À tout le moins, nous ne devrions pas la pousser en ligne.
Bien sûr, nous avons besoin que le code soit exempt de bogues, performant, sécurisé et évolutif. Un bon code devrait avoir toutes ces qualités. Mais toutes ces qualités ne valent rien si la fonctionnalité que nous avons livrée n’améliore pas l’expérience de l’utilisateur. Trop souvent, nous poussons les fonctionnalités précisément pour la croyance organisationnelle que les développeurs doivent livrer quelque chose à un moment donné. Mais avec un petit investissement de temps, nous pouvons considérablement améliorer les chances que le code de haute qualité que nous expédions ait réellement un impact significatif sur nos clients.
Les développeurs qui parlent aux clients écrivent un meilleur code
Les ingénieurs qui ont des contacts réguliers avec les clients comprennent les problèmes qu’ils résolvent pour leur public. Ils ont une idée claire de ce qui empêche les utilisateurs de réussir en ce moment. Ils peuvent même apprendre ce que nos clients font en ce moment pour atteindre cet objectif particulier. Toutes ces informations donnent un sens et un but au code écrit par ces développeurs. Cela les pousse à créer des logiciels qui vont bien au-delà du « fonctionne tel que conçu ». Les informations obtenues en écoutant les clients incitent les développeurs à affiner une expérience à un niveau supérieur à celui du code qui n’a pas bénéficié de la connaissance utilisateur.
Comprendre ce qu’un utilisateur essaie d’accomplir signifie que les fonctionnalités que vous livrez ont plus de chances de réussir. Cela se traduit directement par moins de refactorisation, moins de refonte et une utilisation et un succès accrus pour ces idées. Les développeurs impliqués dans ces fonctionnalités réduisent en fait le codage inutile en ne créant pas de fonctionnalités dont personne ne veut ou qui ne résolvent pas le problème réel de nos utilisateurs.
Davantage de connaissance des clients signifie un meilleur code, moins de gaspillage
Les principes Lean nous apprennent à éliminer les déchets du processus. Tout ce que vous faites qui ne génère pas de valeur pour le client doit être retiré du processus. Écrire du code pour des fonctionnalités dont personne ne veut est du gaspillage. Maintenir des fonctionnalités que personne n’utilise est du gaspillage. Ajouter de l’embonpoint à un produit est du gaspillage. Passer du temps à négocier des priorités sans contexte fondé sur des données probantes est du gaspillage. Tout cela peut être minimisé si vous amenez votre développeur à parler aux clients car c’est la voie de la moindre résistance.
Ce n’est pas un concept difficile à mettre en œuvre, mais il faut un changement fondamental de mentalité dans ce qu’un développeur devrait faire au travail et ce que l’organisation définit comme « valeur ».
partagez ce billet avec vos amis, collègues et relations professionnelles
Au cœur de la méthodologie Lean Six Sigma se trouve une feuille de route disciplinée en cinq phases connue sous l’acronyme DMAIC qui identifie chaque phase : Définir, Mesurer, Analyser, améliorer (Improve) et Contrôler.
Dans cet épisode de la série « Lu pour vous », Christian Hohmann, nous fait part de ses remarques sur à un document de 2 pages intitulé : “15 phases of DMAIC Roadmap”
Visualisez cette vidéo qui revient sur le document et ses sources, puis offre une revue détaillée des 15 étapes avant de considérer les outils suggérés pour chaque phase.
partagez ce billet avec vos amis, collègues et relations professionnelles
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
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.
partagez ce billet avec vos amis, collègues et relations professionnelles
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
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.
partagez ce billet avec vos amis, collègues et relations professionnelles
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
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.
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
#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.
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.
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 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.
Le/la manager de projet sert de point de contact principal pour les communications de projet avec divers publics.
Communication avec lesmembres 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.
partagez ce billet avec vos amis, collègues et relations professionnelles
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 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é
partagez ce billet avec vos amis, collègues et relations professionnelles
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é.
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.
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.
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
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.
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.
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
partagez ce billet avec vos amis, collègues et relations professionnelles
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 :
Vérifier qu’un utilisateur avec le bon nom d’utilisateur et le mauvais mot de passe ne soit pas autorisé à se connecter.
Vérifier qu’un utilisateur avec un nom d’utilisateur incorrect et un mot de passe correct ne soit pas autorisé à se connecter.
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
partagez ce billet avec vos amis, collègues et relations professionnelles
Si vous ne pensez pas que c’est vrai, il est probable que vous êtes dans le déni de ce que vos retards vous coûtent. Comprendre les conséquences réelles de la procrastination est la première étape pour vous libérer de son emprise.
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 
DantotsuPM.com 