Démarche légère de résolution de problèmes

De Wiki Agile du @GroupeCESI
Aller à : navigation, rechercher

Auteur : Henrik Kniberg
Source : Light-weight problem solving template
Date : 23/08/2012


Traducteur : Fabrice Aimetti
Date : 24/08/2012


Traduction :

Voici la méthode que j'emploie par défaut pour la résolution de problèmes et le changement dans l'organisation. C'est fondamentalement une version légère du A3 de résolution de problème et de Toyota Kata.

Au fait, la keynote que je ferai la semaine prochaine à ALE2012 est sur un sujet similaire: "Tout le monde veut le Changement, mais personne n'aime Etre Changé".

1. Nommez le problème. Par exemple "bugs en production". Vous pourrez le renommer plus tard. Restez neutre, sans désigner du doigt quelqu'un.

2. Identifiez les différents points de vue sur le problème. Par exemple, d'un point de vue développeur, testeur, exploitant.

3. Essayez de réunir des personnes clés représentatives de ces différents points de vue (les personnes qui sont impactées par le problème et qui s'en préoccupent), et d'avoir une discussion informelle devant un tableau blanc. Par exemple : un développeur, un testeur, une personne de l'exploitation ou du support, ainsi que le product owner. Nous souhaitons avoir un petit nombre de personnes, couvrant un large spectre.

4. Décrivez le problème, assurez-vous que tout le monde est d'accord sur le fait que c'est un problème. Renommez-le peut-être.

5. S'il y a une solution simple évidente, mettez-la juste en oeuvre. Parfois, réussir à réunir les bonnes personnes dans la pièce peut constituer davantage que la moitié de la solution. Si le problème est complexe ou récurrent, ou qu'il n'a pas de solution évidente, alors continuez :

6. Confirmez ensemble que ce problème mérite d'être résolu. Vous ne pouvez pas résoudre tous les problèmes en même temps. Il est donc intéressant de se demander si c'est bien là un problème sur lequel vous avez raison de vous concentrer en ce moment. Si c'est le cas, continuez :

7. Faites une analyse des causes racines en utilisant la technique des 5 Pourquoi ou un Diagramme de cause à effet ou autre chose du même genre, pour comprendre la nature du problème, et réduire le risque de simplement résoudre les symptômes au lieu de résoudre le vrai problème.

8. Discutez de ce que "parfait" veut dire ("Définition de la Perfection"). Si nous n'avons plus du tout ce problème, à quoi cela ressemblerait-il ? Exemple : "Zéro bug en production". Il n'est pas nécessaire d'être réaliste : la perfection est une direction, pas un lieu.

9. Discutez de ce à quoi ressemblerait un pas audacieux vers la perfection. Exemple : "50% de réduction des bugs en production, et lorsqu'un bug est trouvé, il est résolu en 1 heure". C'est sûrement difficile, mais pas impossible.

10. Brainstormez sur un tas de changements que vous pourriez faire, qui pourraient vous permettre d'atteindre cette première étape. Soyez créatif. Prenez en compte les idées de contournement du problème aussi bien que des idées extravagantes, farfelues.

11. Pour chaque idée, listez les avantages et les inconvénients les plus évidents.
12. Décidez d'un changement à mettre en oeuvre. Considérez-le comme une expérimentation. Si vous avez du mal à en choisir un, procédez à un vote par points ou un vote par consensus (tout le monde écrit un nombre entre 1 et 5 à côté de chaque idée, pour montrer son appréciation de chaque idée). Ne passez pas trop de temps à décider, vous ne savez pas à l'avance ce qui va fonctionner de toute façon. Sortez juste les idées qui vont rater de façon évidente.

13. Faites ressortir ceux qui vont être affectés par le changement, obtenez leur soutien. Si vous n'obtenez pas leur soutien, découvrez ce qu'il faudrait faire pour l'obtenir. Ou alors revenez en arrière et choisissez une des autres idées qui remporterait une meilleure adhésion. Le changement dans l'organisation ne fonctionne pas vraiment sans adhésion.

14. Expérimentez-le ! Et planifiez une date pour le suivi.

15. ... (expérimentation) ...

16. Lors de la réunion de suivi : apportez des données et évaluez ce qui s'est passé. Exemple: combien de bugs en production avons-nous eu ? Combien de temps a-t-il fallu pour les résoudre ?

17. Discutez des leçons apprises, et décidez si le problème est toujours un problème. Si c'est le cas, retournez à l'étape 10 ou 11 et itérez à nouveau.

Vous souhaiterez peut-être prendre quelques notes pendant que vous suivrez toutes ces étapes. Restez synthétique. Dessinez. Ça y est, vous avez votre A3 :o)