Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

12 juillet 2010

L'équipe décide de la solution

Au dernier Agile Development Practices West 2010, j'ai observé un pattern de réponses à la question : comment régler tel ou tel problème dans un contexte agile. La réponse est venue, en autre, dans le contexte d'une présentation de Johanna Rothman, intitulée "Overcoming the pitfalls of agile transitions". Essentiellement la réponse est, "laissez l'équipe trouver la meilleure façon de faire."

 

J'en parle ici, car c'était la réponse qu'offraient, presque mot pour mot, la plupart des conférenciers lorsqu'un participant demandait "que faites-vous lorsque vous rencontrez telle situation…". Ce fut la réponse de Jean Tabaka et Bill Wakeman lors de "System think", de Jennifer Bonnie pendant "Managing change", et de Christine Del Prete lors d'un panel de discussion. Après quatre fois, quand Johanna Rotham a prononcé les mots magiques, j'ai finalement reconnu le pattern! Bien sûr, je le connaissais déjà, pour l'avoir expérimenté avec des équipes et déduis du concept d'équipe autogérée, mais de l'entendre si clairement exprimé et à répétition pendant quelques jours, ça donne encore plus de force au message.

 

J'ajouterais qu'en mode transition, il ne suffit pas de laisser l'équipe trouver la solution, de leur "dumper" le problème. Souvent, de mon expérience, les équipes ne sont pas prêtes à décider du chemin à prendre, en tout cas, pas initialement. Après des décennies à se fier au chargé de projet, au boss, pour prendre les décisions, pour savoir quoi faire, l'équipe ne sait pas par quel bout prendre ce nouveau pouvoir. C'est donc le rôle de la personne en charge de guider l'équipe vers ce nouveau mode de fonctionnement en déterminant les attentes, en supportant l'équipe et en facilitant le travail. En deux mots, devenir ce que l'on nomme un "servant leader".

 

Ce mode de fonctionnement est peut-être plus long au départ, mais il est plus payant à long terme. Il permet d'abord d'avoir plusieurs têtes pour trouver des pistes de solutions et on sait que plusieurs têtes valent mieux qu'une!

 

La réflexion impliquant toute l'équipe, donne à chacun une meilleure compréhension du contexte, de la démarche de solution et finalement du choix de solution qui sera mise en œuvre. Elle permettra ainsi à l'équipe de réagir et de s'adapter plus rapidement dans le futur, si la situation change. On élimine aussi un goulot d'étranglement au niveau des décisions, car on ne dépend plus d'une seule personne. On augmente aussi le sentiment de contribution des membres de l'équipe au travail réalisé.

 

Outre l'apprentissage, on va aller chercher un bien meilleur engagement de l'équipe par rapport au travail à faire. Cette approche permet aussi de bâtir un esprit d'équipe, de souder un groupe de personnes en une équipe concertée.

 

Cette approche va dans le sens du Nemawashi, un concept des entreprises japonaise, dont Toyota, qui vise à obtenir un consensus, celui des participants affectés, avant de passer à l'action.

 

Il faut faire confiance à l'équipe, car ce sont des professionnels et on est en droit de s'attendre à ce qu'ils jouent leur rôle (voir http://agile.blogspirit.com/archive/2010/07/07/etes-vous-un-developpeur-professionnel.html )

 

Pour en savoir plus :

Servant leadership : http://www.ianrpubs.unl.edu/epublic/live/g1481/build/g1481.pdf

Exemple : http://blog.agilebuddy.com/2010/01/sprint-start-and-stop-days-whats-best.html

Nemawashi : http://www.kirainet.com/english/nemawashi-%E6%A0%B9%E5%9B%9E%E3%81%97/

07 juillet 2010

Êtes-vous un développeur professionnel?

Le titre du keynote de Robert "unclebob" Martin, lors du dernier Better Software Conference", était provocateur. Bien sûr que je suis un professionnel! Je ne suis pas un amateur. Mais entre les deux Martin introduit le "laborer", que je traduis librement par: ouvrier. Le titre aurait donc pu être "Êtes-vous un développeur professionnel ou un ouvrier?".

Qu'est-ce qui distingue l'ouvrier du professionnel? Il est clair que je me comporte parfois comme un ouvrier. Quand je fais ce qu'on me dit (sans trop réfléchir), que j'applique la recette que je connais (indépendamment du contexte), que je dis oui (mais que je devrais dire non). Quand je prends un raccourci pour gagner du temps (quand je sais que quelqu'un d'autre va payer pour, plus tard). Quand je reste dans ma zone de confort. Quand je fais juste mes 35 heures/semaines.

J'ai observé ce comportement au sein de notre entreprise, pas seulement chez moi, Robert Martin l'observe dans notre industrie et Seth Godin, dans son livre Linchpin, l'observe dans toutes sortes de domaines et d'industries. Le phénomène est donc largement répandu. Alors, où sont les professionnels, qu'est-ce qui les distingue?

Uncle Bob dit que les professionnels répondent à des "standards de la profession ". Pensons à l'ingénieur, ou au médecin qui doit exercer leur métier à l'intérieur de normes et de règles reconnues. Un ingénieur professionnel n'acceptera pas de concevoir une structure en coupant les coins ronds. Un médecin n'acceptera pas que le patient écrive sa prescription.

Un professionnel demeure calme sous pression. On a qu'à penser au plombier, à l'avocat qui plaide un cas difficile ou au commandant Piché lorsque son Airbus A-330 s'est trouvé en perte de moteur complet au large des Açores.

Robert Martin nous a présenté son "serment du développeur professionnel", à la manière du serment d'Hippocrate pour les médecins .

Ne nuis pas au fonctionnement du système
Essentiellement, soyez certain que le système fonctionne correctement. Et quel meilleur moyen pour s'en assurer que d'exécuter les tests automatisés. Selon Martin, l'équipe d'assurance qualité ne devrait pas trouver de bugs et s'ils en trouvent ils devraient en trouver la cause (dans le code et dans le processus de développement). J'ajouterais qu'on s'attend au même comportement des équipes de maintenance. Martin indique qu'on devrait viser un taux de couverture d'essais de 90 à 95% ("code coverage").

Ne nuis pas à la structure du système
Ici il faut s'assurer de ne pas introduire, ou laisser, du mauvais code, du code qui sent ("code smell") dans le système. Il faut aller rapidement, en progressant sur des fondations solides. Le truc est de refactoriser constamment et sans pitié afin d'obtenir du code simple et facile à modifier. Pour refactoriser sans merci, il faut des tests automatisés.

Maîtrise ton métier
Un professionnel connaît son métier et reste à jour. Je préfère un médecin qui connaît les derniers médicaments ou traitements à celui qui connaît ceux qui existaient lorsqu'il a fait ses études. Notre domaine évolue constamment. Au cours des cinquante dernières années on est passé de la modularité, aux gros programmes, à la programmation structurée, à l'orienté objet, aux design patterns et aux approches agiles. Pourtant, l'essence même du métier reste assez stable. Comme professionnel, maîtrisez-vous UML, les designs patterns, plusieurs langages, un langage dynamique, les diagrammes de flux de données, le principe de substitution de Liskov?

Comme un médecin, un musicien, il faut apprendre et pratiquer de façon continue (voir mon article sur les coding dojos). C'est notre responsabilité d'apprendre, pas celle de notre employeur (tant mieux s'il nous supporte dans cette démarche). Selon Martin il est de notre responsabilité d'investir 20 heures par semaine dans ces apprentissages!

L'importance des essais
Robert Martin, a insisté tout au long de sa présentation sur les tests (je ne rajoute pas "automatisé", car ça devrait être implicite). Pour le développeur, les tests automatisés sont comme les méthodes utilisées par les comptables pour s'assurer qu'ils ne font pas d'erreur. En informatique, on écrit deux fois du code, une fois pour le test et une autre pour la fonctionnalité. En comptabilité, ils écrivent les montants deux fois, une première fois dans les débits et l'autre dans les crédits.

Martin mentionne un phénomène que j'ai observé avec le TDD. J'ai développé des applications Groovy/Grails en TDD et quand j'ai fait une démonstration à des collègues, rapidement ils m'ont demandé comment fonctionnait le débuggeur. Je dois admettre que je ne comprenais pas pourquoi ils étaient aussi préoccupés par la présence d'un débuggeur. Après plusieurs mois de développement, je n'avais jamais senti le besoin d'utiliser un débuggeur. Comme moi, Robert Martin observe que l'utilisation du TDD et du développement par petit pas réduit l'utilisation du débuggeur par un facteur de dix.


Pour en savoir plus :

Keynote de Robert Martin
http://www.agilejournal.com/day-1-agenda/3050-keynote-are-you-a-development-professional (requiert inscription)
http://www.viddler.com/explore/oredev/videos/125/ (même présentation faite en 2008)

Podcast de Robert Martin sur sa présentation http://perseus.franklins.net/hanselminutes_0171.wma


http://fr.wikipedia.org/wiki/Serment_d%27Hippocrate
http://fr.wikipedia.org/wiki/Principe_de_substitution_de_Liskov


06 juillet 2010

Le glas sonne pour les environnements d'essais traditionnels

Au Better Software Conference 2010, à Las Vegas en juin dernier, j'ai assisté à une présentation de Ken Johnston, le gestionnaire des essais pour l'engin de recherche Bing de Microsoft.

 

Essentiellement, Johnston nous dit que l'avènement du "cloud computing" sonne le glas de nos laboratoires/environnements d'essais traditionnels. Dans le contexte actuel, où ces environnements sont dispendieux et jamais exactement comme ceux de production, il est opportun de se questionner sur leur avenir. Les architectures de services, qu'il s'agisse de SaaS, PaaS ou de IaaS implanté sur un nuage public, privé ou communautaire ou hybride complique les essais. De plus en plus, nos solutions vont utiliser des services de tiers pour lesquels on a pas d'environnement d'essais. Alors, pourquoi ne pas tester directement en production?

 

A tout le moins, on peut considérer le cloud pour héberger les environnements d'essais traditionnels. En effet, pourquoi acheter des machines physiques quand on peut les obtenir dans le nuage sous forme de IaaS (infrastructure as a service).

 

Johnston mentionne que nos pratiques d'essais s'appliquent aussi aux services et au cloud, parfois sous un angle différent. Il indique que les principaux impacts se font sentir sur les environnements d'essais (virtuel), sur le fait que les déploiements doivent être eux-mêmes testés, qu'il faudra parfois utiliser des approches d'émulation et éventuellement gérer des essais directement en production.

 

Johnston insiste beaucoup sur le fait que le déploiement doit être automatisé et doit se faire essentiellement avec une ligne de code. Cette pratique est supportée par l'intégration continue utilisée en développement.

 

Les pratiques d'essais en production sont nouvelles dans le monde informatique, mais on les retrouve aussi dans d'autres domaines, on pense par exemple aux essais cliniques des médicaments conçus par les pharmaceutiques, aux essais en vol effectué par les pilotes d'essai, où aux modifications apportées aux réseaux de télécommunication cellulaire.

 

Johnston offre 12 conseils pour tester en production :

à        Mettre la machine de test dans le centre de traitement

à        Faire des beta en production (beta perpétuel)

à        Plusieurs versions en production, en parallèle

à        Expérimentation avec groupe de contrôle (A/B test)

à        Tester de façon continue

à        Tester et monitorer

à        Tester l'intégration en production

à        Tester la performance et la capacité en production

à        Tester le centre de traitement

à        Tester la continuité de service

à        Rouler la couverture de code sur une partie de la prod

à        Inclure des hooks de test en production

 

Pour en savoir plus :

Chapitre 14 de son livre "How we test software at Microsoft", disponible sur le web : http://www.docstoc.com/docs/23309271/How-We-Test-Software-at-Microsoft

 

http://blogs.msdn.com/b/kenj/archive/2009/11/24/tip-ing-services-testing-blog-1-the-executive-summary.aspx

 

http://exp-platform.com/Documents/2009-09%20ExP%20SeattleTechStartup.pdf

15:45 | Lien permanent | Commentaires (0) | Tags : test

05 juillet 2010

Gérer et éliminer la dette technique

Au dernier "Agile Development Practices" de juin dernier à Las Vegas, j'ai assisté à une session de Lee "AgileDad" Henson intitulée "Managing and eliminating technical debt". Lee est un présentateur très dynamique qui est aussi un excellent pédagogue qui a débuté par expliquer ce qu'était la dette technique. C'est comme la dette financière. Une petite dette momentanée est acceptable, mais une dette plus importante peut nous conduire à la faillite.

 

Comme consommateur nos habitudes face à l'endettement ont changé au cours des dernières décennies. Je me souviens que quand j'étais plus jeune, l'endettement était socialement mal vu. Il semble bien que nous ayons transposé ces mauvaises habitudes dans le monde logiciel. Qu'elle soit intentionnelle ou non, la dette technique augmente de façon composée avec le temps. On paie de l'intérêt sur la dette, qui augmente qui notre dette. Il faut briser ce cercle vicieux.

 

Selon Henson, la dette technique peut prendre différentes formes :

à        Des bogues et problèmes connus, mais non réglés;

à        Des travaux planifiés qui ne se feront jamais;

à        Du code qui n'a pas de tests de régression automatisés;

à        Des interruptions non planifiées du travail;

à        Du code qui n'est jamais exécuté;

à        L'absence de limite au "work in progress";

à        La non-reconnaissance par l'organisation de l'existence de la dette technique.

 

Un des symptômes pour reconnaître l'endettement technique, selon moi, c'est lorsqu'on décide d'ajouter des "features", plutôt que d'améliorer l'existant. J'ai vu ça à maintes reprises et notamment dans un cas où on ajoutait de nouvelles fonctionnalités aux deux semaines depuis plusieurs années, sans adapter le code existant à la nouvelle réalité. À un point tel, qu'il était très difficile d'ajouter ou de corriger des choses simples. Dans le cadre de ce projet, j'avais décrit la situation comme une maison à laquelle on ajoute des pièces, sans changer les fondations, ou refaire la toiture ou la peinture de temps en temps. Lee avait une phrase similaire :

 

"Fix the foundation, then build the palace."

 

Henson recommande d'avoir un plan qui vise l'élimination de la dette technique. D'abord, arrêter d'ajouter de nouvelles fonctionnalités, plutôt que de "payer " la dette. Utiliser une méthode de priorisation simple qui quantifie les efforts en fonction de la douleur qu'entraîne chaque élément de dette.

dettePriorites.png

Ensuite, donner de la visibilité, assurer le plus de transparence possible, en s'assurant que chacun est bien au fait de la dette technique, du plan pour l'éradiquer. Une fois le plan identifié, s'y conformer!

 

Finalement, éviter à tout prix l'ajout de nouvelle dette technique, surtout lorsque la dette actuelle est importante.

 

Annoncer à nos clients qu'il faut gérer la dette n'est jamais facile. Cependant, notre succès conjoint en dépend. Alors, prenons notre courage à deux mains et agissons maintenant, c'est le meilleur moment pour le faire.

 

Le blog de Lee Henson sur cette présentation :

http://blog.agiledad.com/2010/06/agileroots-is-happening-now.html#links

 

Pour en savoir plus sur la dette technique :

http://www.agiledad.com/Documents/2009/AgileMentorOctober2009.pdf

http://fr.wikipedia.org/wiki/Dette_technique

http://c2.com/cgi/wiki?TechnicalDebt

http://msdn.microsoft.com/en-us/magazine/ee819135.aspx

http://msdn.microsoft.com/en-us/magazine/ee335722.aspx