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

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.

L’art perdu de demander de l’aide.

Les gens attendent bien trop longtemps avant de demander de l’aide !

Lost Art of Asking for Help

https://rgalen.com/agile-training-news/2021/2/16/lost-art-of-asking-for-help par Robert Galen

J’ai été impliqué dans Agile depuis environ 20 ans et j’ai remarqué un anti-modèle répétitif qui semble ne jamais changer.

Les gens attendent trop longtemps pour demander de l’aide !

Je l’ai remarqué dans mon activité de coach. D’habitude, au moment où je suis appelé dans une organisation qui essaye de mettre en œuvre Agile, la situation est (j’ose le dire) que les wagons sont sortis des rails. Bien sûr, une partie de moi pense que c’est une chose bonne ou normale. Mais c’est seulement la partie de génération de revenus qui parle.

La partie principale de moi qui est coach agile regrette toujours qu’ils ne se soient pas venus plus tôt. Ceci aurait évité tant d’aggravation et de frustration, de gaspillage de temps et d’efforts et de coûts en bout de ligne.

Mais ce n’est pas seulement en tant que coach. Ceci s’applique aussi à mon expérience de leader.

Si un projet avait déraillé ou qu’un engagement était manqué, je le découvrais le plus souvent à la dernière minute. Bien plus tard que quand j’aurais encore pu faire quelque chose ou aider. Je travaille toujours dur comme leader pour créer de la sécurité pour l’annonce de mauvaises nouvelles, être accessible et être reconnaissant de cela. Très dur. Mais cela me choquait toujours de constater combien de fois les gens attendaient trop longtemps pour partager quelque chose avec moi. Je me demande souvent, que devrais-je faire pour créer une culture où le partage des problèmes serait récompensé, serait la norme et ne serait pas craint ?

au secoursCela s’applique même à mon coaching et à mes collègues agiles dans les diverses communautés agiles dont je fais partie. Je m’assimile souvent “à un coach de coaches” et c’est ce que je suis. Mais de nouveau, presque 100 % des gens attendent trop longtemps pour m’appeler à l’aide.

Je ne leur dis normalement rien directement parce qu’il est trop tard pour cela. Mais je pense souvent par devers moi que les résultats pourraient être significativement différents s’ils étaient seulement venus me voir plus tôt. Mon coaching, ou celui de qui que ce soit, pourrait avoir évité tant de frustrations et d’aggravation en évitant des erreurs coûteuses.

Vous m’avez compris. Avant que nous n’allions plus loin, je souhaiterais partager avec vous l’une de mes métaphores préférées autour de ce sujet …

Le Statut Pastèque

Je ne peux pas me rappeler la première fois quand je l’ai entendu mais j’aime la notion de « statut pastèque ».

C’est un projet qui est vert à l’extérieur (annoncé comme étant sur les rails, excellent) et rouge à l’intérieur (déraillé, en retard sur les délais, dépassant le budget).

Une fois que j’ai entendu cette métaphore, elle a résonné sur CHAQUE projet que j’avais mené comme leader. 90 % du temps, les membres de mon organisation annonçaient un statut pastèque.

Et, vous découvrez que c’est rouge SEULEMENT à la toute dernière minute. Au point que, en tant que leader, vous n’avez que très peu d’options pour aider ou faire quoi que ce soit.

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

Les Raisons Possibles

J’ai alors mis mon chapeau remue-méninges / brainstorming et essayé de penser à toutes les raisons pour lesquelles on pourrait ne pas vouloir demander de l’aide.

  • Optimisme – Espoir
  • Crainte …
    • D’échec, de ramifications, de sembler mauvais, de perdre son travail, ou d’être rétrogradé
  • Ignorance
  • Sentiment de propriété – c’est mon travail
  • Apathie
  • Réparer, c’est mon défi …
  • Manquer de …
    • Compétences, connaissances, expériences, sécurité, ou courage
  • Orgueil ou Obstination
  • Budgets serrés
  • Timidité
  • Ne pas vouloir « déranger » qui que ce soit
  • Responsabilité ou Devoir
  • Recherche d’un nouveau travail
  • Sabotage

Voici certaines raisons qui me sont venues à l’esprit. Mais je suis sûr qu’il y a d’autres et j’espère que vous en ajouterez dans les commentaires.

Certaines d’entre elles sont liées à nos opinions ou à des bagages historiques et d’autres plus dépendantes de notre culture actuelle. Quoi qu’il en soit, j’ai voulu illustrer un large spectre de raisons et que je me rends compte que ce sujet est complexe et nuancé.

Je veux rediriger cette discussion sur un jeu de 5 leçons durement apprises que j’ai expérimentées dans ce domaine. J’espère que vous pouvez les prendre avec vous et qu’elles pourront vous servir d’encouragement pour à aller chercher plus d’aide.

#1 – Typiquement, le temps n’améliore pas les choses …

Laisser-faire est rarement une bonne approche. (relisez ce billet)

Une de mes leçons apprises à travers toute ma carrière est que quand vous faites face à un challenge :

  • Challenge de client;
  • Challenge de personnel;
  • Challenge de projet;
  • Challenge personnel;
  • Challenge de direction;
  • Presque n’importe quel Challenge …

Attendre ne semble pas aider. Cela rend typiquement les choses plus mauvaises. Bien pires !

Leçon : N’attendez pas trop longtemps pour demander de l’aide. Faites-le maintenant!

#2 – Comment vous commencez est critique

Rappelez-vous pourquoi vous avez commencé.

Le début de toute entreprise est critique. C’est là que votre stratégie est définie. C’est là que le pourquoi et les objectifs sont établis. S’il y a un meilleur moment pour demander l’aide, c’est au début d’un effort. Et plus l’effort est important (dans sa portée, sa valeur, son impact, etc.), plus critique il est de demander de l’aide au commencement.

Leçon : quoi que ce soit qui mérite d’être fait, particulièrement dans des initiatives critiques, il vaut mieux bien démarrer. Commencez en ayant la finalité à l’esprit.

#3 – Trop d’espoir et d’orgueil …

L’espoir n’est pas une stratégie et il y a trop d’orgueil dans le monde. Ces deux-là empêchent de demander de l’aide. Vous devez regarder au-delà de votre propre personne quel sera l’impact de ce challenge sur les autres. Autrement dit, rendez-vous compte que ce n’est pas de vous qu’il s’agit. Il en va de votre équipe ou de votre organisation toute entière.

J’ai constaté que de me rappeler à moi-même la portée et l’impact d’un défi (au-delà de ma personne) pouvait servir à me motiver à demander/trouver de l’aide. Montrez plus de vulnérabilité.

Leçon : Regardez au-delà de vous-même quel sera l’impact (si cet obstacle est incorrectement traité) sur votre univers au sens le plus large. De cette perspective, demandez-vous ensuite si vous avez besoin d’aide …

#4 – Plus haut vous êtes, plus dur il y parait …

J’ai aussi remarqué que plus votre position dans l’organisation est élevée (promotion, niveau, titres etc.), plus il semble difficile de devoir demander l’aide.

Et pas seulement de consultants/coachs externes, mais pour que quelqu’un à l’intérieur de l’organisation puisse aussi vous aider.

Leçon : Peu importe notre titre, nous avons tous besoin de l’aide, alors demande-la. C’est en réalité un signe de force, pas de faiblesse et cela fait grandir votre organisation …

#5 – Le budget semble toujours être un challenge …

money, money, money...Nous ne pouvons pas nous le permettre. Je n’ai pas le budget pour cela. Si je leur demande de l’aide, ils me la feront payer. Beaucoup de leaders manquent du courage de défier le statu quo quand on en vient aux contraintes. Je soutiendrais qu’il y a d’habitude davantage de capacité et de flexibilité dans les organisations pour dépenser de l’argent pour des initiatives critiques ou résoudre des problèmes critiques. Cela demande seulement à certains de lever la main et de demander, de demander de l’aide.

Leçon : Vous ne pouvez pas vous permettre de ne pas payer pour l’aide dont vous avez besoin. Demandez-vous quel sera le coût de l’échec ? De ce point de vue, il est souvent meilleur marché de demander l’aide…

En conclusion

Dans le doute… demandez de l’aide!

Je veux demander à chaque lectrice et lecteur de ce billet de l’aide.

S’il vous plaît, réfléchissez à cet article et comment il résonne avec votre voyage personnel et professionnel. Puis, partagez s’il vous plaît des commentaires pour complémenter ce billet.

J’aimerais entendre vos histoires, vos perspectives et vos diverses réactions.

Restez agile mes amis,

Bob.

Post-scriptum

Il y a un point de vue intéressant dans cette vidéo de Richard Sheridan où il explore le fait de dire la vérité dans ses projets. Je pense qu’il est parfaitement en ligne avec le thème de ce billet…

Amplifiez les succès et les réussites de vos projets Agiles

Les sociétés n’augmentent pas le succès d’Agile ou de Scrum, elles en amplifient le succès.

Scaling Success

https://agile-scrum.com/2021/02/05/scaling-success/ par Zuzi Sochova

Dans notre voyage vers Agile, nous nous demandons souvent par où commencer, quels pratiques, outils et processus devrions-nous nous utiliser ?

Ce que j’ai appris pendant mon propre voyage est que nous n’avons pas besoin d’une « autre » méthode. Aucune de celles-ci n’est une solution miraculeuse de toute façon. Elles sont toutes formidables pour entamer comment changer la façon dont vous travaillez et les mentalités.

Mais la partie la plus importante de votre voyage est le succès.

  • Pouvez-vous partager une histoire de réussite ?
  • Pouvez-vous utiliser vos propres mots pour décrire comment votre propre environnement a changé et montrer l’impact de ces nouvelles manières différentes de travailler ?

Si oui, les gens vont s’y mettre et essayer d’atteindre un impact similaire.

Les transformations agiles les plus réussies que j’ai vues ont commencé exactement comme cela. Avec une petite équipe expérimentant de nouvelles pratiques et partageant l’impact observé avec d’autres. Selon le point de départ, ces équipes partagent des histoires de réussite différentes et diverses, comme. 5 fois moins de bogues reportés par des clients, 3 fois plus de valeur livrée sur une période donnée (ce n’est pas la même chose que plus de fonctionnalité, mais souvent le contraire), un délai de mise sur le marché significativement plus rapide, une motivation plus élevée et un meilleur niveau d’engagement, plus d’innovations qui aboutissent à une satisfaction client meilleure… l’impact varie en fonction de l’environnement.

Pour nous, il y a quelques années c’était plus de flexibilité, apprendre plus rapidement et une meilleure satisfaction client.

Partager sur les succès n’a rien de nouveau dans le management du changement. C’est l’une 8 étapes dans Conduire le changement: Feuille de route en 8 étapes de John Kotter que pour quelque raison on ne connait toujours pas assez largement dans la communauté agile, donc j’ai pensé à vous les rappeler ici .

#1 – Créez le sens de l’urgence

Sur Amazon

À moins que vous ne sachiez pourquoi vous changez la façon dont vous travaillez (pour être plus agiles, Scrum ou Kanban), ne le faites pas. Ni Agile, ni Scrum, ni Kanban ne sont votre but. Ce sont juste des ‘béquilles’ vous aidant dans votre voyage vers la réussite. Vous devez avoir un objectif plus élevé défini qui sera plus fort que les objectifs individuels et unifiera donc les personnes.

#2 – Construisez une coalition de direction

Vous ne pouvez jamais changer l’organisation si vous êtes seul. Vous devez trouver des partisans (des enthousiastes agiles dans votre cas) qui créeront une équipe qui vous aidera à changer le système. Ainsi, au minimum deux personnes complémentaires qui sont de vrais aficionados agiles, car trois personnes constituent l’équipe la plus petite. Les autres vous rejoindrons en observant des résultats.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

#3 – Formez une vision et des initiatives stratégiques

Parfois avoir d’un but n’est pas suffisant car les gens ne voient pas de manière d’y arriver et le changement dans sa globalité est trop abstrait. C’est un espace où les structures, les méthodes et les pratiques sont utiles.

#4 – Enrôlez une armée de volontaires

Recrutez des enthousiastes.

Finalement, c’est le moment de le rendre plus grand. Faites-en un mouvement, pas juste un autre projet. Faites-y adhérer un plus grand groupe. Faites-les s’impliquer. De nouveau, si vous sautez certaines des étapes précédentes, cela ne pourra pas grandir.

#5 – Permettez l’action en faisant tomber les barrières

Libérez les énergies.

Maintenant, une fois que vous avez l’énergie de votre côté, vous devez l’aider et éliminer les barrières (hiérarchie, silos, positions détaillées, KPIs individuel, …), sinon, tout l’enthousiasme initial va s’évaporer avant que vous ne le compreniez.

#6 – Générez des victoires dans le court terme

Célébrez toutes les avancées.

Générez du succès rapidement et souvent et rendez-le visible à toutes et tous. Partagez des histoires d’améliorations, célébrez même de petits pas de progrès. Le succès est un moteur puissant pour le changement. Accélérez, multipliez les succès. Sans cela, tout changement mourra.

#7 – Soutenez l’accélération

pousser les gens dans la bonne direction
Continuez tout le temps de pousser.

Vous pouvez la célébrer, mais vous ne pouvez pas arrêter de pousser après la première victoire, ne soyez pas trop satisfait. Il y a toujours une meilleure manière. Trouvez un autre défi, découvrez une meilleure façon de travailler jusqu’à ce que la vision de la nouvelle façon de travailler définie par le but original devienne vraie.

#8 – Institutionnalisez le changement

Utilisez ce levier pour accélérer.

Finalement en créant des liens entre la nouvelle façon de travailler et le succès vous tenez le levier du changement.

Ces liens sont la glu qui empêche l’environnement de retomber en arrière dans l’ancienne façon de travailler.

Agile est un changement majeur et sans le conduire comme un changement vous aurez beaucoup de mal à réussir.

N’oubliez donc pas de définir à quoi ressemble le succès, célébrez-le et rendez-le meilleur au fil du temps.

Les exigences SMART sont Agiles

Des approches SMART sont utilisées pour évaluer les exigences dans les projets en cascade, prédictifs. Elles s’appliquent aussi aux projets agiles.

SMART Requirements are Agile

http://www.bonniebiafore.com/smart-requirements-are-agile/ par Bonnie Biafore

Spécifique

Dans Agile, des exigences spécifiques documentées n’existent pas au départ. Spécifique se rapporte au livrable final. En Agile, les exigences sont capturées pendant le développement, pas documentées à l’avance. Cependant, le résultat final va typiquement au-delà du détail et de la spécificité d’exigences traditionnelles. Quand de grandes exigences ne sont pas spécifiques, elles sont typiquement décomposées en plusieurs histoires utilisateur en Agile, dont chacune fournit une fonctionnalité spécifique et peut être plus facilement produite.

Mesurable.

La construction et l’évaluation de chaque fonctionnalité se concentrent sur la mesure de l’efficacité. Un des bénéfices les plus significatifs d’Agile est que cette exécution et ces mesures de pertinence sont construites et mesurées durant le processus de développement. Avec une mentalité de prototypage, des fonctionnalités Agiles peuvent être évaluées par des utilisateurs avant leur mise en œuvre. Quand cela ne peut pas être fait directement, par exemple, quand un processus commercial totalement nouveau est créé, l’association développeur-utilisateur utilisée pour construire les fonctionnalités Agile réduit le risque de livrables ne réussissant pas à atteindre des objectifs business mesurables.

Atteignable

Le classement par taille de fonctionnalité et la priorisation assurent que la faisabilité est régulièrement évaluée. Les fonctionnalités sont examinées pour leur intégrité et capacité à être produites en un sprint. De plus grandes fonctionnalités sont décomposées en morceaux qui sont plus facilement créés, augmentant la faisabilité.

Quand les fonctionnalités ne peuvent pas être décomposées en parties gérables, c’est un signe qu’elles ne sont pas réalisables.

Les développeurs et les utilisateurs peuvent examiner ces fonctionnalités en temps réel pour déterminer à quel point elles sont critiques et explorer d’autres façons d’adresser le besoin business.

Réaliste

Une approche pratique de comment planifier et implémenter le changement

En Agile, les fonctionnalités sont développées et acceptées itérativement et en temps réel, par rapport à des semaines ou des mois après que les exigences soient documentées dans l’approche traditionnelle prédictive.

Agile se prête aux résultats réalistes et peut intégrer les derniers changements aux besoins business.

La nature d’Agile signifie que l’équipe entre plus profondément dans les fonctionnalités et leurs capacités, permettant aux utilisateurs de rendre les livrables plus faciles à utiliser. Les fonctionnalités présentent une plus grande intégrité et supportent de meilleurs processus business.

Temporel – contraint par le Temps

L’approche par sprints est idéale pour s’assurer que les contraintes de temps soient placées sur la création de fonctionnalités. De plus, il y a la valeur supplémentaire de pouvoir facilement changer les durées quand des priorités business changent. La re-priorisation et la planification de fonctionnalités avant chaque sprint fournissent un focus soutenu sur les périodes de développement. Bien que cette approche de gestion des délais ne soit pas parfaite, les fonctionnalités qui exigent plus de temps que prévu à développer sont réévaluées et reportées aux sprints suivants comme décidé au sein de l’équipe Agile.

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

Un projet pilote n’est pas toujours la meilleure façon de commencer votre voyage Agile

Commencer petit pour mettre en œuvre un grand changement est presque toujours une bonne idée… et le mot « presque » y tient une grande importance.

A pilot project is not always the best way to start your agile journey

https://kbondale.wordpress.com/2021/01/24/a-pilot-project-is-not-always-the-best-way-to-start-your-agile-journey/ par Kiron Bondale

Beaucoup d’entre nous s’accorderaient sur le fait que si vous essayez de mettre en œuvre un grand changement, commencez petit. De même qu’il est plus facile d’avaler une petite pilule qu’une énorme, la capacité d’adopter et de supporter le changement est souvent plus simple quand le changement implique des pas de fourmi.

Cette approche des petits pas/changements progressifs s’applique aussi à Agile.
premiers pas
l’approche dite « à pas de bébé » ou baby steps

Par exemple, les expériences d’amélioration qu’une équipe identifie pendant une rétrospective de sprint devraient être petites pour fournir des retours rapides sur si vraiment cela vaut la peine d’aller plus loin.

Mais quand j’ai lu un récent article HBR de Ron Ashkenas et Nadim Matta sur les challenges à reproduire en plus grand un projet pilote réussi, cela m’a rappelé que ce principe de commencer petit pourrait ne pas fonctionner avec des transformations Agiles.

Dans l’article, les auteurs listent quelques défis à appliquer avec succès les leçons d’un projet pilote sur un plus grand contexte
  • résistance au changementLa résistance de la masse des parties prenantes auxquelles on demande de travailler de façon différente alors que la cible des personnes impactées pour le pilote est probablement plus réceptive aux changements proposés. C’est le problème de “franchissement de l’abîme”.
  • Éviter des éléments bloqueurs dans l’organisation ou des obstacles est relativement simple dans le contexte d’un projet unique, mais cela devient exponentiellement plus difficile quand le périmètre des changements augmente.
  • La difficulté à essayer de faire appliquer et évoluer des pratiques et des apprentissages du projet pilote aux contextes variés de multiples projets différents.

À cette liste, j’ajouterais encore un défi.

Avoir les meilleurs sur le projet reste bien sûr souhaitable

La première source d’incertitude de livraison dans la plupart des projets basés sur la connaissance est la prévisibilité de disponibilité des bonnes personnes avec les bonnes compétences et au bon moment. Dans un pilote, il est possible d’améliorer la dotation en personnel en notre faveur en allant extraire des gens compétents de leurs rôles normaux pour travailler sur le projet.

Si nous ne remplaçons pas ce personnel avec des ressources temporaires, cela a des impacts sur la capacité de chacune des équipes dont ils faisaient partie et ça n’améliorent probablement pas nos relations avec les leaders de ces équipes.

Mais tous les utilisateurs seront-ils aussi des « cadors » ?

Mais encore pire, quand le projet pilote est fini et que nous commençons à nous congratuler des résultats, la raison principale n’est pas parce que nous étions Agiles, mais parce que nous avons permis à des gens compétents de se concentrer sur un travail précis du projet plutôt que les garder dans leur niveau habituel de multitâches

Quand nous essayons ensuite d’étendre notre approche sur de multiples projets, les résultats sont moins prometteurs parce que nous n’avons pas adressé combien ce travail habituel simultané sur de multiples tâches consomme de temps et de ressources.


Cela ne devrait pas vous décourager de lancer une approche projet pilote dans votre transformation Agile

Cependant, avant de faire la promotion des leçons de ce projet pilote, abordez d’abord les questions fondamentales de la gestion du travail si vous voulez réaliser des bénéfices durables.

Un référentiel sur l’hybridation des modes projet est en marche au PMI France

Des nouvelles du Lab Hybrid, projet mené par Stéphane Derouin et supporté par le PMI France et en particulier son Président Ricardo Naciff .

Tout d’abord, un énorme bravo aux 29 bénévoles qui travaillent à la réalisation du guide des bonnes pratiques hybrides.

La phase idéation des trois thèmes : Gouvernance, cadre méthodologique, dimension humaine, et leurs sous thèmes est terminée.

La phase construction et rédaction du guide des bonnes pratiques démarre en janvier 2022 pour se terminer en juin 2022.

Stéphane Derouin constitue dès maintenant deux équipes pour la rédaction de ce guide pratique et opérationnel en charge de :

  1. La rédaction du document et de sa structure de narration.
  2. La collecte :
    • de retours d’expériences,
    • de bibliographie,
    • de témoignages,
    • de documents,
    • ou de contenus théoriques en rapport avec l’hybridation.

N’hésitez-pas à contacter Stéphane si vous souhaitez vous aussi contribuer à ce travail. Merci encore à toutes et à tous !

PMI Disciplined Agile de Poche par les volontaires du PMI France !

La team PMI Disciplined Agile de Poche, composée des bénévoles Claudine Blanquier, Laurent Thomas, Frédéric Martin et Selim Khaldi, facilite la découverte de Disciplined Agile avec des mémentos de poche résumant les fondamentaux de Disciplined Agile, EN FRANCAIS !

Le PMBOK V7

Le PMI, à travers la septième édition du PMBoK, a su prendre en compte l‘évolution de l’environnement de la conduite de projet : les approches adaptatives, dont font partie les démarches Agiles, sont identifiées et décrites dans le cadre général porté par des principes de conduite de projet.

De manière pratique, l’acquisition par le PMI en 2019 de la boîte à outils Disciplined Agile (DA), traduit tout l’intérêt qui est porté à ces approches.

À partir de ce constat, une équipe pluridisciplinaire de bénévoles du « Disciplined Agile Special Interest Group » du Chapitre PMI-France a décidé de faciliter la découverte de Disciplined Agile en produisant des mémentos de poche résumant les fondamentaux de Disciplined Agile, en français !

Un superbe travail de synthèse de l’essence de cette approche et une traduction compréhensible par tous les francophones.

3 mémentos de synthèse: https://www.pmi.org/disciplined-agile/posters

  1. PMI DA poche – boîte à outils, panorama de ce que DA peut vous apporter
  2. PMI DA poche – Choose your WoW, comment choisir votre manière de travailler en équipe ou avec plusieurs équipes.
  3. PMI DA poche – cycle de vie, les différentes modélisations des cycles de vie projet ou produit en fonction de votre contexte d’activités.

Ce travail est mis gracieusement à votre disposition sur le site PMI France

Et pour aller plus loin dans la découverte de Disciplined Agile et le partage d’expérience adhérez à la communauté LinkedIn francophone “Disciplined Agile, échangeons et partageons.

QRP est partenaire de DantotsuPM

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

Dans ce billet, Fidaa explique les 4 valeurs du manifeste agile ainsi que chaque valeur du manifeste de test.

Le manifeste agile

1. Les personnes et les interactions plus que les processus et les outils

La méthode agile privilégie l’individu et lui donne le plus d’importance. Il est facile de comprendre les personnes plutôt que les processus ou les outils, car ce sont les personnes qui répondent aux besoins de l’entreprise et pilotent le processus de développement.

« Quand les entreprises prennent de l’ampleur, elles cherchent à reproduire leur succès initial. Elles confondent bien vite le processus et le contenu ». Steve jobs dans une interview en 1995.

2. Des logiciels opérationnels plus qu’une documentation exhaustive

L’approche Agile se concentre sur la production de valeur. La documentation reste nécessaire à la continuité et à la maintenabilité du projet, mais n’apparaît pas comme une priorité. Auparavant, l’équipe passait des heures sur la rédaction de documents et cela empêchait l’avancement des livrables.

3. La collaboration avec les clients plus que la négociation contractuelle

Le message ici n’est pas que les contrats doivent être jetés par la fenêtre mais que vous devriez collaborer plus souvent avec vos clients. L’approche Agile demande la collaboration continue avec le client et son implication dans toutes les phases du projet pour collecter ses retours et donc construire des produits de valeur.

4. L’adaptation au changement plus que le suivi d’un plan

Les méthodes traditionnelles considéraient le changement comme une dépense, il fallait donc l’éviter. L’intention était de développer des plans détaillés et élaborés. L’agilité nous invite à mettre en place un fonctionnement flexible capable d’absorber les changements et de redéfinir les objectifs et les priorités. Avec ce mode de fonctionnement, tout changement apporte une valeur ajoutée au lieu d’un obstacle à éviter.

Le manifeste du test

1. Tester au fil d’eau plus que tester à la fin

Traditionnellement, les gens considèrent les tests comme une phase qui se produit à la fin du développement. En revanche, en Agile, les tests sont une activité qui doit se produire parallèlement au développement .

2. Éviter les bugs plus que trouver les bugs

Il serait beaucoup plus productif de clarifier les spécifications avant de commencer à écrire une seule ligne de code, et de s’assurer que tout le monde, du client au développeur et au testeur, a exactement la même compréhension de la façon dont quelque chose doit fonctionner.

3. Tester la bonne compréhension plus que vérifier la fonctionnalité

En Agile, les testeurs doivent devenir des ambassadeurs du client; Ils doivent comprendre en profondeur qui sont leurs utilisateurs et ce qu’ils essaient de réaliser avec le produit. Les testeurs doivent être les représentants de ce client dans chaque décision de conception, en veillant à ce que la fonctionnalité réponde aux besoins réels des clients, pas seulement aux spécifications.

4. Construire le système plus que casser le système

Bien qu’il existe une croyance commune que les testeurs sont exclusivement engagés dans la destruction, ce n’est qu’à moitié vrai. Il ne faut pas oublier l’objectif principal de créer un produit de valeur et qui fonctionne bien. C’est pourquoi la reproduction des actions réelles d’un utilisateur est de la plus haute priorité.

5. La responsabilité de l’équipe sur la qualité plus que la responsabilité du testeur

Les testeurs ne peuvent pas améliorer la qualité, leur rôle est de déterminer le niveau de qualité et d’en informer les parties prenantes. Vous ne pouvez améliorer la qualité que par les efforts conjoints de toute l’équipe.

Fidaa Berrjeb est Agile QA analyst certifiée ISTQB et Scrum Master.
Fidaa Berrjeb

Après ce premier billet qui, nous l’espérons, vous aura intéressés, Fidaa va essayer de s’orienter sur l’aspect Quality Assurance (QA) dans ses prochains billets car les sujets sont nombreux qui couvrent Agilité et QA.

Toutes ces choses

All the stuff

https://seths.blog/2021/12/all-the-stuff/ by Seth Godin

Les marchés vous persuadent souvent que vous n’en avez pas assez.

Vos communautés vous rappellent que si.


Il en est très souvent de même pour les fonctionnalités demandées par les parties prenantes dans vos projets !

A force d’empiler les fonctionnalités, on risque fort l’indigestion !

Jamais assez, ne rien perdre par rapport au produit précédent, bénéficier de toutes les fonctionnalités de tous les concurrents…

N’est-ce pas la beauté, la force de l’approche Agile que de se recentrer sur la valeur business de chaque fonctionnalité demandée pour les prioriser ?

Puis n’en réaliser qu’un relativement faible nombre des plus bénéfiques avec une équipe et un temps limité. Observer et apprendre du résultat. Puis, répéter l’exercice de priorisation jusqu’à ce que la valeur de la prochaine itération soit plus faible que celle que l’on pourrait tirer d’une initiative et/ou projet concurrents.

En bref, stop au gâchis !

Dans les transformations agiles, pensez de haut en bas et de bas en haut à la fois.

Quel est le meilleur endroit pour commencer une transformation agile dans une société ?

Think top-down and bottom-up for agile transformations

https://kbondale.wordpress.com/2020/10/18/think-top-down-and-bottom-up-for-agile-transformations/ par Kiron Bondale

Une question que l’on me pose régulièrement pendant mes formations est : « Quel est le meilleur endroit pour commencer une transformation agile dans une société ? ».

Si j’avais le choix, je préférerais utiliser la réponse échappatoire (mais correcte) “ça dépend”, mais sinon je réponds d’habitude que vous voudriez mener les deux approches simultanément, de haut en bas et de bas en haut.

Une approche pour des changements organisationnels majeurs est fréquemment de commencer par le haut avec la direction exécutive, créant une coalition d’engagement et de support vers une vision partagée de l’avenir.

Ceci est critique dans les transformations agiles pour certaines raisons
  • Les équipes de développement ne travaillent pas de manière isolée et gagner l’adhésion pour changer comment les choses sont faites sera nécessaire de la part de tous les secteurs de support dont les ressources humaines, les finances et les achats.
  • Il y aura le besoin de financer des investissements comme la formation, le coaching, l’outillage et potentiellement même la dotation en personnel sur de nouvelles positions.
  • Sans changement dans les pratiques de management de portefeuilles de projets existantes et les métriques d’exécution (par exemple passer d’un focus sur maximiser l’utilisation à maximiser la valeur), il sera difficile d’obtenir les pleins bénéfices de la transformation.
  • Pour changer des comportements établis de cadres intermédiaires vers une mentalité agile, l’équipe de direction a besoin de modéliser d’abord les comportements cibles désirables. Les managers vont devoir être formés pour y parvenir et ils doivent aussi consentir à se tenir mutuellement responsables de cette nouvelle façon de travailler.
  • Il doit y avoir une vision fédératrice pour la transformation ainsi qu’un plan sur la façon d’y arriver. L’équipe de direction doit être entièrement engagée dans la création de ces livrables clefs.

Mais il y aura aussi besoin d’avoir l’engagement au niveau de l’équipe de développement. Si les membres individuels de l’équipe sont à l’aise avec comment les choses fonctionnent mais n’ont aucun sens d’urgence sur le besoin du changement, leur appui sera superficiel.

Leur pleine adhésion est nécessaire
  • Développez les détails des nouvelles façons de travailler et revoyez et adaptez celles-ci au fil du temps.
  • Soyez confortable sur imaginer et conduire des expériences avec les échecs occasionnels de celles-ci.
  • N’hésitez pas à prendre de nouveaux rôles et responsabilités.
  • Soyez ouvert et fournissez aux parties prenantes le plus fort niveau de transparence sur leur travail et le workflow qu’elles ont utilisé jusque-là.
  • Collaborez avec les parties prenantes d’autres domaines fonctionnels avec lesquelles vous pourriez précédemment avoir seulement coopéré.
CSP est partenaire de DantotsuPM, Découvrez tous leurs ateliers

Ces résultats sont nécessaires et un avantage clef de prendre les 2 approches en même temps, de haut en bas et de bas en haut, consiste en ce que cela crée un “effet sandwich” coinçant ceux du middle management qui ne voudraient pas changer comment ils travaillent.

Sans cela, il est peu probable qu’une transformation agile réussira.