Pensée Design et méthode Agile

Inscrit sur un Mooc sur la « pensée Design« , j’ai découvert des liens forts avec les méthodes agiles. L’objet de cet article est de voir les similitudes entre ces deux mondes.

En premier une petite définition du « Design ».

Le terme design, vient du verbe anglais « to design », ce n’est donc pas un adjectif mais un verbe. Dire « cet objet est design », ne veut donc rien dire. C’est comme si on disait il a été conçut… 😉 Si je le vois c’est que probablement il l’a été créé …

La pensée design est une méthode

Cette méthode est en 5 étapes :

– L’étape 1 l’empathie consiste à favoriser une démarche permettant de se mettre à la place du consommateur final et comprendre ses besoins.
– L’étape 2 définir le problème à sa source, par notamment la technique des « 5 pourquoi »
– L’étape 3 l’idéation (Processus de création d’une idée) , l’objectif de cette phase étant de générer un maximum d’idées pour solutionner notre problématique initiale , On pratiquera alors le brainstorming
– L’étape 4 le prototypage, c’est à dire le travail consistant à donner une forme physique à notre idée retenue.
– l’étape 5 une phase de test celle consistant à recueillir un maximum de feedbacks par l’utilisateur final.

Une boucle naturelle existe alors entre les étapes 4 et 5.

Maintenant petit parallèle entre les deux méthodes

1. Le client est au centre des deux méthodes : Dans les méthodes agiles, le client est au cœur du développement, il est même idéalement au milieu de l’équipe de développement. Dans la pensée design, dès l’étape 1, il est sollicité, à s’exprimer, à décrire son problème, il va tester et commenter le prototype etc…
2. La notion de prototype : En Pensée design, on concrétise ses idées par des prototypes que l’on présente au client, idéalement pour qu’ils puissent les tester. En méthode agile, on fait des itérations rapides, dans le but de livrer, et de permettre au client d’utiliser son produit dès que possible. Dans les deux méthodes, le client va effectuer des feedbacks, de commentaires, qui vont modifier le produit final.
3. La notion de test et d’itération : En méthode agile on développe par tranche de 10 à 15 jours (en faisant le cycle complet de développement, jusqu’à la livraison), tout cela en développement par les tests : test de non régression, test fonctionnel, test unitaire etc.. En pensée design, le processus n’est pas aussi poussé, mais il y a biens des tests pratiqués sur les prototypes qui vont au fil des itérations se rapprocher du produit final.

Ce parallèle effectué entre ces deux méthodes, peut se faire aussi avec d’autres méthodes.

Si je prends par exemple la phrase de la méthode de management Kaizen « Fais-le mieux, rends-le meilleur, améliore-le même s’il n’est pas cassé, parce que si nous ne le faisons pas, nous ne pouvons pas concurrencer ceux qui le font. »

Reprenons dans les méthodes agiles les concepts de « refactoring » &  « faire le plus simple », on est bien dans des méthodes très similaires.

Ma conclusion, si nous voulons progresser en méthode agile, soyons curieux, et regardons les autres méthodes et techniques qui existent.

quelques liens :

1. mooc pensée design
2. Wikipédia pensée design
3. Wikipédia Kaisen
4. Wikipedia 5 pourquoi

à bientôt..

5 ans de développement en méthode Agile, retour d’expérience

Pourquoi cet article ?

Tout ce que j’ai lu et appris sur le sujet concerne des équipes qui sont sur un seul projet, ce qui n’est pas notre cas. Il m’a semblait intéressant de partager cette expérience très différente du mono-projet.

En plus de lire sur le sujet, nous sommes allés à plusieurs reprises aux conférences proposées dans le cadre de l’Agile tour : http://at2013.agiletour.org/fr/at2013_bordeaux.html

Cela fait environ 5 ans que l’on travaille en méthode agile, mélange d’EXtrême Programming (XP), scrum et sauce maison.

Voici le contexte :

• Service informatique dans une société qui n’est pas une SSII, l’équipe est composé de 15 développeurs
• il y a en parallèle une dizaine de projets, avec des équipes de 3 développeurs, jusqu’à 1/4 de développeur
• Les développements concernent en grande partie les besoins internes à l’entreprise
• Développement en C#, l’équipe de développement à une moyenne d’age de 27 ans (je ne me compte pas dedans .. heureusement pour la moyenne…)

Nous avons au fil du temps testé différents aspects :

• Le management visuel
• les planning poker
• les post-it
• le travail en binôme
• les tests unitaires
• les tests fonctionnels
• les points quotidiens avec le client
• Le refactoring de code
• etc..

Les points positifs qui dans le temps tiennent :

• le travail en binôme, qui apporte un plus réel au niveau polyvalence, formation, arrivé de nouveaux développeurs
• le planning poker, qui en comparant l’estimation et le réel donne d’excellent résultat. Des alertes naturelles sont faites, afin d’éviter de refaire un code déjà réalisé sur un autre projet
• les test fonctionnels, mais qui restent difficiles à automatiser, au regard de nos applications (clients lourds et clients légers, contexte parfois difficile à reproduire etc…)
• La notion de fiche scénario courte, qui donne un sentiment, pour le développeur d’une bonne journée. On essai de faire des fiches d’une 1/2 journée et pas de 5 jours.
• l’effet tunnel qui n’existe plus

Les points négatifs :

• l’utilisation des post-it, qui n’a pas de sens en multi-projet, qui tombent, qui sont trop petits pour tout écrire dedans etc..
• le travail en binôme, si décalage important de niveaux ou dans un contexte de développement simple
• la notion d’itération qui ne peut être unique si multiples projets
• l’ambiance de l’équipe par des pastilles de couleurs, n’a pas marché, même si cela donnait une bonne vision par jour et dans le mois du ressenti de l’équipe.
• Les points quotidiens avec le client, sont difficiles à faire, en raison notamment de la charge de nos clients internes. Ceux qui peuvent jouer le jeu ont de meilleurs développements, c’est indéniable.

Même si on peut voir que tout n’est pas utilisé les grands concepts sont compris et appliqués, par exemple :

• En parallèle nous faisons les tests, les développements et le manuel de référence. Il y a donc 3 lectures différentes de ce qui doit être réalisé.
• la part de test a explosé et à permis d’avoir des développements plus fiables
• On ne développe plus que ce qui est demandé par le client
• On ne pose plus de questions au client du type « est que cela pourrait vous intéresser ? »
• Le client est plus en avant qu’avant.. ce qui est l’essentiel, pas de surprise pour lui ..

En espérant que cet article aidera des équipes de développement comme la notre…