parallèle Sudoku et résolution de problèmes

Peut-on faire un parallèle entre les jeux comme le sudoku et les problèmes de la vie courante ?

Liste d’affirmations :

1. La difficulté d’un problème est liée aux informations en entrée pour l’analyser
   Sudoku : Plus le niveau du sudoku est élevé, moins de chiffres sont présents sur la grille
   c’est vrai et faux, la position ou la valeur des chiffres, influence aussi sur la difficulté.
2. Plus un problème à de solutions, moins il est difficile à résoudre.
   Sudoku : Plus le niveau augmente, plus en général, il y a de solutions. du coup, un doute persiste, car à priori on pense qu’il n’y a qu’une solution
3. Il y a des problèmes sans solution
   Sudoku : sauf erreur au moment de la conception, il y a toujours au moins une solution
4. La solution peut-être trouvé par hasard
   Sudoku : Au regard des combinaisons, sans raisonnement logique, il y a peu de chance de trouver la solution (du moins au début).
   En fait c’est vrai et faux, car si deux solutions sont possible, à un moment donné il faut prendre au hasard, un des chiffres possible (restant) pour s’orienter vers une des solutions

Maintenant, prenons comme hypothèse que les problèmes de la vie, professionnelle ou personnelle, sont comme des Sudoku, que peut-on en déduire ?

1. La difficulté d’un problème n’est pas toujours liée au peu d’information à notre disposition, mais à la variété de celle-ci. Il faut donc augmenter le nombre de ces sources, les angles d’attaques et les points de vus
2. Il est plus simple de résoudre un problème avec une solution unique, qu’un problème avec plusieurs solutions. Car pour faire le choix d’une des solutions, il faut vérifier qu’aucune autre alternative est possible et qu’aucune erreur d’analyse, de raisonnement nous oriente vers une mauvaise solution.
3. « Un problème sans solution est un problème mal posé. » Albert Einstein.
   Ce grand homme considère donc que tout problème a bien une solution =D
4. Sauf problème simple, le hasard ne permet pas de résoudre un problème complexe. Mais il faut à un moment accepter le fait que l’on a :
   1. plusieurs solutions qui existent et qu’elles sont toutes acceptables
   2. faire un choix, ne veut pas dire pour autant que la solution prise est le fruit du hasard, mais qu’après avoir éliminé différentes alternatives, il peut en rester plusieurs, toutes acceptables
   3. à se faire confiance

Ce raisonnement est simpliste, mais il doit au moins permettre de s’interroger sur le sujet.

En fait, il est notamment faux pour tous les problèmes où le résultat attendu peut-être différent de la problématique initiale, je pense notamment à un raisonnement agile. Il est faux aussi dans bien d’autres cas que je vous laisse le soin de découvrir…

Je finirais cette réflexion par une nouvelle citation d’Albert Einstein  : « En plein cœur de toute difficulté se cache une possibilité ».

 

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…