Les Mêlées

mercredi 30 décembre 2009

La puissance du “Time Boxing”

Limiter une activité dans le temps peut paraître frustrant. En effet, si je suis entrain de faire quelque chose et qu’un foutu timer sonne … le premier reflexe sera de le faire taire et de continuer sans se préoccuper du temps qui passe. Agir ainsi est se priver de la puissance d’un tel outil!

 

Contraindre une activité en temps à y consacrer permet de devenir plus efficace

  • Ce qui aura le plus de valeur est abordé en premier
  • La concentration est améliorée car nous voulons un résultat dans le temps fixé
  • La motivation est améliorée car toutes les boîtes de temps sont des défis à gagner
  • Le perfectionnisme avec le bien connu adage “Le mieux est l’ennemi du bien” est limité
  • Les travaux exploratoires, qui par définition peuvent ne pas aboutir rapidement, sont maîtrisés
  • Les tâches rébarbatives deviennent plus agréables car limitées dans le temps
  • Les gros travaux peuvent être découpés en objectifs atteignables dans des temps limités; ceci évite la procrastination –> Fort lien avec le GTD
Comment utiliser le time-boxing
  • Convenir d’un temps pertinent, seul ou en équipe pour les réunions, en fonction de l’importance de la tâche à accomplir
  • Activer un timer visible à tout moment de tous
  • Lorsque le temps imparti est terminé, décider activement si un temps supplémentaire doit être accordé. Il convient de juger si cela en vaut la peine et si le focus doit être redressé pour privilégier ce qui a le plus de valeur

Quand utiliser le time-boxing

  • Pour la gestion des e-mails. Ex : 15 minutes en arrivant le matin
  • Pour la lecture d’articles
  • Pour les recherches exploratoires ou plusieurs voies sont ouvertes
  • Pour l’essai d’un outil
  • Pour les réunions. Souvent, on peut arriver à un résultat pertinent rapidement en se focalisant sur l’objectif à atteindre
  • Pour le ‘Social networking’. Ex : 10 minutes par jour
  • Pour l’écriture de billet sur un blog. Cette fois-ci, je me suis donné 45 minutes!
  • Pour le Daily Scrum meeting.  :o)

Caddie / Coach GTD - Getting Things Done – (V2)

Il y a un an environ, j'ai adopté la méthode d'organisation GTD - Getting Things Done - de David Allen. Un mois plus tard, j'avais fais le point ici même.

Depuis, notre entreprise a développé une initiative permettant de s'améliorer, d'apprendre et développer ses compétences: le CADDYING. Plusieurs volontaires se sont proposés pour travailler sur des sujets techniques tels que le Lean Software Development, les tests "Agiles", la programmation fonctionnelle, etc. Alors je me suis dis pourquoi pas un peu de développement personnel! Le GTD m'a tellement apporté que je trouvais dommage de ne pas en faire profiter mes collègues! Je me suis proposé comme Caddy et rapidement 4 joueurs ont voulu tenter l'expérience.

Le principe que j'ai retenu est basé sur 4 étapes principales:

  • Une prise de contact avec auto-évaluation sur 10 points que la méthode permet d'améliorer : 10'
    • Respecter ses rendez-vous
    • Trouver un document en moins de 2 minutes
    • Ranger un document en moins de 2 minutes
    • Faire tout ce qui doit être fait en temps et en heure
    • Avoir l'esprit libéré pour se concentrer sur sa tâche en cours
    • Ne pas réapprendre les choses
    • Ne pas oublier ses idées et projets
    • Avoir une vue claire sur ses projets à cours terme
    • Avoir une vue claire sur ses projets à moyen terme
    • Avoir une vue claire sur ses projets à long terme

Voici mon évaluation sur ces 10 points:

    • Une explication des principes GTD à l'aide d'un logigramme : 15'

    • Mise en pratique immédiate en rassemblant tout ce qui n'est pas à sa place et création des listes : 3h
    • Suivi régulier de 15' à 30' chaque semaine pour affiner la pratique de GTD

    Le fait d'être Caddie sur ce sujet m'a permis de me perfectionner et de tirer encore plus partie de la méthode. En particulier, j'ai progressé sur la mise en forme de mes projets en formulant mieux mes objectifs et en identifiant les premières étapes atteignables pour que ceux-ci avancent - parfois lentement - mais sûrement!

    Bruno a remarqué que je n'utilise plus mon agenda Filofax pour la gestion des listes au profit d'Evernote sur iPhone et m'a demandé les raisons que voici:

    Le Filofax est un outil qui fonctionne très bien. Il a fais mon affaire pendant 1 année. Néanmoins, ce support avait pour MOI quelques inconvénients:
      • Mes listes devenaient vite brouillon car je n'écris pas très bien
      • Le support, bien que petit prend un peu de place et pèse dans ma sacoche
      • Lors de la revue hebdo, il n'était pas possible de déplacer un élément d'une liste à une autre.
    Lorsque que je me suis procuré un iPhone, j'ai rapidement cherché si un outil gratuit existait pour GTD puisque la pub dit qu'il y a une application pour presque tout! Cette application est "Evernote". Combinée à l'agenda de l'iPhone, j'ai tout ce qu'il me faut. En effet, "Evernote" dispose d'une synchronisation sur le net, de client pour PC et une version mobile pour iPhone. Après 3 mois d'utilisation, je peux dire que les inconvénients cités ci-dessus sont levés.

    mercredi 9 décembre 2009

    3 questions de Dragos Dreptate, Responsable R&D Logiciel

    Dragos, Responsable R&D Logiciel, envisage le passage aux Méthodes Agiles et à se titre se renseigne et se documente sur la question. Je lui ai proposé de partager mon expérience en répondant à quelques-unes de ses interrogations car être Agile, c'est aussi savoir partager sa connaissance. Dragos a accepté la démarche alors que nous ne nous connaissions pas! C'est un signe de confiance "à priori" que je salut; c'est une valeur très importante.

    Voici le contenu de nos premiers échanges:

    [Dragos]

    Ma première question va dans la direction du recrutement. Il est clair, la qualité des membres de l’équipe est primordiale, bonne communication, team player et excellence technique s’imposent. La question : Comment faire pour être sur que la personne qu’on recrute est « agile » ?

    [Luc]

    Chez nous, voici les étapes que nous mettons en oeuvre pour recruter:
    - Rédaction d'une annonce qui souligne les points essentiels sur le contexte de notre entreprise et les valeurs que nous recherchons chez notre futur collaborateur.
    - Nous organisons une session de tests avec une douzaine de candidats où nous décrivons plus précisément notre entreprise. Puis il y a deux heures de tests écris sur des points techniques, logiques, d'Anglais. Ces tests ne sont pas très difficiles et nous permettent de faire un premier filtre.
    - Les 3-4 candidats que nous estimons les meilleurs sont reçus en entretien individuel pour apprendre à mieux les connaître et découvrir leurs motivations et aspirations.
    - Puis nous avons expérimenté une mise en situation dans une équipe sur une "journée accélérée" afin de mieux évaluer les aptitudes des candidats à travailler en équipe. Ce fut assez intéressant pour tester la capacité d'adaptation des candidats!

    Quelques pistes:
    http://www.cio.com/article/print/478106
    http://www.agilex.fr/2009/01/recrutement-agile/


    [Dragos]

    La deuxième question s’attaque aux problèmes de test. L’activité de test est intégrée au sprint. Les méthodes agiles essaient de diminuer le temps alloué a cette activité en accordant plus d’attention a la qualité du design et du codage, en gros a tout ce que tienne de l’ingénierie logiciel, pour produire un meilleur code avec moins défauts. C’est bien, mais parfois pas suffisant. Nos clients, des grands laboratoires pharmaceutiques, utilisent notre application scientifique en phase de recherche de nouveaux médicaments. Une étape très sensible et coûteuse. Nous sommes soumis à des réglementations strictes concernant la qualité logicielle et sommes certifiés ISO9001. Mais au delà des certifications, la qualité du livrable est un engagement très fort que nous avons envers nos clients. Actuellement la phase de test a lieu après la fin du développement et consiste dans de plans de test « statiques », quasiment manuels, de tests qui s’appuient sur de spécifications détaillés écrites après la fin du codage. Très peu de tests unitaires. Et enfin la question : Connaisez-vous des outils de test "agiles", permettant de créer des tests automatisés adaptés aux logiciels avec beaucoup d’IHM et beaucoup d’intervention de l’utilisateur dans les scenarios d’usage ?

    [Luc]

    Avant de répondre à la question j'aimerais revenir sur la notion de test dans un contexte Agile. Tout d'abord, pour fixer le périmètre de mes propos, je vais m'appuyer sur deux méthodes Agiles complémentaires : SCRUM pour la gestion du projet et XP (ExtrêmeProgramming) pour les pratiques de développement. Dans ces méthodes, tout est itératif et incrémental car on recherche le feedback en permanence. Plus tôt est le retour sur les problèmes tels que les défauts où incompréhensions des besoins utilisateurs, moins cher coûtera la correction ou l'adaptation. De ce fait, les tests sont quotidiennement nécessaires à mesure que le développement évolue. Ces méthodes ne diminuent pas le temps alloué aux tests mais au contraire l'augmente. Le principe, c'est de ne pas dire qu'une fonctionnalité est terminée tant qu'elle n'est pas testée et le but recherché est de terminer des fonctionnalités dans les sprints (2-3 semaines). En d'autres termes, on ne repousse pas la phase de tests à la traditionnel Release Candidate pour y trouver des défauts qui prendront plusieurs semaines à corriger. A chaque fin d'itération, on doit avoir un incrément de produit potentiellement livrable au client donc entièrement validé et de qualité irréprochable. Alors évidement, on ne plus se permettre de dérouler des plans de tests pendant des jours entiers alors il faut changer les pratiques de test.

    Il y a plusieurs types de tests à considérer:


    - Les tests unitaires sont écris pendant le développement et se situes au niveau des classes. Idéalement il faut pratiquer le TDD (Test Driven Development) où on écrit toujours un test unitaire avant d'ajouter du code pour une fonctionnalité. De cette façon, on ne développe que ce qui est nécessaire (pas de provision ni de code mort) et ceci permet de faire émerger un design qui soit testable avec peu de couplage, etc. Je vous propose de lire le Tutoriel de Bruno.

    - Les tests d'intégration sont également écris par les développeurs pour s'assurer que les classes fonctionnent bien ensemble.

    - Les tests fonctionnels testent les critères d'acceptation de la fonctionnalité. Il est largement préférable de les automatiser car plus les projets grossissent, plus dérouler l'ensemble des tests fonctionnels en fin d'itération devient long et pénible. Sur des petits projets, il peut être acceptable de garder ces tests manuels.

    Au final, il n'est pas anormal de passer les 2/3 du temps de développement à écrire des tests. Pour que le feedback soit rapide, il faut respecter la pyramide pour la répartition des tests. Les tests unitaires doivent être nombreux et couvrir un maximum de cas possibles. Ils doivent également être très rapides pour pouvoir être exécutés par tous les développeurs, tout le temps, pour vérifier que rien n'a été cassé. Il est très important de comprendre qu'automatiser ces tests permettra d'avoir des tests joués tous les jours. En effet, toutes les nuits, un système d'intégration continue doit construire l'application de A à Z (compilation, setup, etc) et exécuter tous les tests (unitaires, intégrations, fonctionnels). Ainsi, chaque matin, les équipes ont une vue claire sur l'état du projet. Si un test n'est pas passé, la priorité sera de le réparer.

    Quand on travail sur une base de code non couverte par des tests, il faut apprendre à ajouter de la fonctionnalité en ajoutant des tests. Cela peut-être difficile mais plein de techniques existes pour isoler et modulariser la base de code. A ce sujet, je vous recommande la bible en la matière : Working Effectively With Legacy Code

    Concernant les tests d'IHM, la pratique nous a montré que les tests manipulant les IHM sont souvent fragiles. En découplant bien la présentation des données, il est plus efficace de tester la couche juste en dessous. Ceci dit, nous utilisons pour nos projets en C# le framework de tests NUnit avec NUnitForms. Pour les applications Web, il y a Selenium (que je ne connais pas). Je vous propose de lire le billet suivant : http://blog.octo.com/demarches-de-tests-fonctionnels/

    Les tests d'IHM coûtent cher par rapport à des tests plus bas niveau donc nous nous en servons pour vérifier qu'il n'y a pas de bug mais nous comptons principalement sur des tests plus bas niveau pour couvrir l'application et traiter le maximum de cas.

    Il faut aussi donner de l'importance aux tests exploratoires. Ils permettent de challenger le logiciel sur toutes les couches et ne sont pas automatisables. Ce sont des tests structurés mais pas prédéfinis.


    [Dragos]


    J’ai pu trouver pas mal d’informations sur les points forts et les bénéfices que les méthodes agiles apportent mais il me manque une meilleure vue sur les risques engendrés par l’adoption de ces méthodes et sur leurs points faibles en général. Pouvez-vous m’en dire plus à ce sujet ?

    [Luc]

    Voici quelques points à considérer lors d'un passage à Scrum/XP:

    - Scrum, de part sa nature itérative et empirique, ne permet pas de s'engager sur les trois points suivant en même temps

    -> Contenu du produit
    -> Qualité du produit.
    -> Délais

    Le plus souvent, c'est le contenu qui est adaptable car chacun sait qu'une grosse partie des fonctionnalités d'un logiciel ne sont jamais ou très peu utilisé. Donc c'est le jeu, le Product Owner doit faire des choix de priorité en permanence.

    - Les chefs de projets et les représentants de la QA doivent changer de rôle pour laisser les équipes s'auto-organiser. Ils peuvent devenir ScumMaster (facilitateur), Product Owner si ils connaissent bien le métier, expert-technique ou ne pas trouver leur nouvelle place.

    - Les Testeurs ne peuvent plus travailler comme avant. Je vous recommande le livre "Agile Testing: A Practical Guide for Testers and Agile Teams". Ceci dit, personne en ma connaissance ne regrette l'époque cycle en V avec des campagnes de tests de plusieurs semaines.

    - Les équipes, avant de devenir productives, vont traverser plusieurs étapes donc il ne faut pas changer ces équipes trop souvent car le processus peut prendre plusieurs années.
    -> Forming (création de l'équipe)
    -> Storming (turbulence)
    -> Norming (harmonisation)
    -> Performing (performance)

    - Il n'est pas toujours évident d'insérer les contraintes non fonctionnelles telles que l'Architecture et les Performances aux Product BackLog. Les ProductOwners ne sont pas toujours les personnes adaptées pour fournir des critères sur ces points. Le danger, c'est de considérer certains points trop tardivement.



    Chers lecteurs, si vous avez des compléments d'information à partager, n'hésitez pas! Si un échange sur un point particulier vous intéresse, contactez-moi!





    vendredi 4 septembre 2009

    Un test vert sans avoir été rouge sent mauvais (V2)

    Contexte

    Dans un contexte Agile, le développement dirigé par les tests (TDD) est incontournable. Ces tests sont le plus souvent unitaires ou d'intégrations car ils aident à construire l'application et couvrent les fonctionnalités existantes en apportant un feedback très rapide. La règle de base du TDD est l'application du cycle RED / GREEN / REFACTOR. Donc on code d'abord le test puis on le fait passer rapidement et enfin on remanie le code si besoin pour éliminer les duplications et améliorer le design.

    Un test vert sans avoir été rouge ne sent pas très bon

    Un test qui est vert sans passer par l'étape rouge doit interpeller le développeur. En effet, rien ne prouve alors qu'il teste ce qu'il doit tester. Plusieurs scénarios peuvent amener à ce cas :
    • Le cas que je m'apprête à coder est déjà couvert donc mon test passe immédiatement
    • Je code le test après avoir développé la fonctionnalité; ce n'est plus du TDD et on passe son temps à douter de la pertinence de ses tests.
    • Mon test ne teste pas ce qu'il devrait tester

    Dans tous les cas, si le test est vert immédiatement, on doit se poser des questions. Au minimum, Il faut faire une contre vérification pour s'assurer de sa pertinence. C'est très simple, il suffit de modifier volontairement le code "under test".

    Donc pour qu'un test ait de la valeur il doit nécessairement passer par l'étape rouge.

    Et les tests fonctionnels alors?

    Les tests fonctionnels servent à tester les "user stories" dans leur globalité en vérifiant que les critères d'acceptance sont bien remplis. Ces tests ou recettes peuvent être exécutés manuellement et l'oeil averti du testeur permet de vérifier que la fonctionnalité est conforme aux attentes du client. Le problème c'est que sur des projets de taille conséquente, cette approche n'est pas viable car le feedback à beaucoup trop long. A mes débuts de développeur, un des projets sur lesquels j'ai travaillé nécessitait 2 jours de tests à plusieurs personnes. Autant dire que lorsque qu'une régression était découverte, le sprint était compromis.

    La solution est donc d'automatiser les tests fonctionnels. Oui MAIS! Mais alors attention aux tests qui seront verts sans passer par l'étape rouge! Pour factoriser la vérification de critères, mon équipe avait développé un module spécialisé. Ce module a parfaitement bien fonctionné pendant plusieurs mois. Un jour, ce module a du être modifié pour prendre en compte un changement d'architecture. Puis de nouveaux tests fonctionnels ont été ajoutés à la liste. Ces nouveaux tests ainsi que tous les autres étaient verts pendant plusieurs mois ... mais notre module ne testait plus une bonne partie des critères...

    Conclusion

    Un test vert sans avoir été rouge ne peut pas apporter la confiance recherchée et doit interpeller le développeur.

    mercredi 15 juillet 2009

    La gestion des défauts

    Face à la réalité

    Le meilleur des mondes serait celui où les défauts n'existent pas, où les bugs n'empêcheraient jamais nos clients de travailler. En attendant d'en arriver à cet idéal, nous devons apprendre à gérer les défauts que nous produisons.

    Un des piliers de Scrum est la "Visibilité", alors ne pas les gérer devient un péché. Quoi de pire qu'une version de logiciel planifiée sur 6 mois avec, par exemple, une trentaine de défauts à corriger non estimés en effort, et un release burndown qui montre que tout va bien, nous sommes dans les temps? Cela revient à conduire dans le brouillard avec un oeil caché!

    Il y a, selon moi, 3 aspects à considérer pour sortir du brouillard:
    • Est-ce bien un défaut et non une amélioration? Une limitation, bien que gênante, n'est pas un défaut.
    • La criticité pour nos clients. Elle va nous aider à décider quand corriger le défaut.
    • La taille du défaut. Elle va nous donner plus de précision sur l'avancement du projet.
    Chaque projet, chaque équipe doit trouver le moyen le plus adapté à son contexte pour gérer les défauts. Néanmoins, il convient d'avoir les éléments suivant en tête:
    • Il n'y a pas de Scrum sans IPPS (Incrément de Produit Potentiellement Shippable/Livrable).
    • Plus un défaut est corrigé tard, plus il coûte cher.

    Quelques pistes à considérer

    Je trouve intéressante la solution décrite par Mitch Lacey car elle permet une correction plus ou moins immédiate suivant 4 niveaux de criticité P0 à P4 :

    - P0 Catastrophique : Fonctionnalités majeures du système ne fonctionnent pas. Il y a aucun moyen de contourner le défaut.
    - P1 Haute : Fonctionnalités majeures du système ne fonctionnent pas. Il existe un moyen de contourner le défaut.
    - P2 Modéré : Utilisabilité du système diminuée
    - P3 Basse : Peu d'impact; défaut d'aspect, désagrément

    Quand un défaut est identifié, il est rapidement classifié et deux scénarios peuvent être suivis:

    --> Soit c'est un P2 ou P3 et le défaut est ajouté au product backlog avec tous les éléments nécéssaires à sa reproduction afin d'être priorisé par le Product Owner.
    --> Soit c'est un P0 ou P1 et sa correction doit-être entreprise immédiatement. Sachant que certain défauts sont parfois grave mais ne prennent que quelques dizaines de minutes à corriger, la solution décrite permet de ne pas créer de travail administratif si en une heure, le défaut est corrigé.


    J'aime aussi la pratique d'Alexandre Boutin lorsqu'il accupait la fonction de Process Group Manager; je cite : "Si le backlog comptabilise plus de 10 défauts, je vais voir l'équipe et lui demande d'arrêter tous les travaux en cours et de diminuer ce nombre pour qu'il soit en dessous de 10". Cette pratique très Lean, permet de maîtriser le coût des défauts et de les corriger avant que d'autres fonctionnalités soit ajoutées sur une base défectueuse.

    Le coût des défauts

    Pour finir, j'aimerais mettre l'accent sur le coût des défauts. Il est bien connu que plus le défaut est trouvé tard dans le cycle de développement, plus son coût de correction est important. Un bug trouvé lors de la phase de développement sera moins cher à corriger qu'un défaut identifié juste avant le déploiement. Évidemment, chez les clients, c'est encore pire. Ensuite, tout défaut devant être corrigé avant la sortie d'un logiciel va apporter un retard sur l'amortissement de son développement. On peut imaginer la catastrophe si un concurrent commercialise un logiciel similaire pendant que nous corrigeons des défauts ... le coût des défauts devient extrêmement important.

    Une fois le défaut identifié, là encore, nous pouvons faire monter la facture en fonction du délai de correction. La gestion administrative des défauts a un coût, ils "polluent" le backlog, il nous gênent dans l'avancement du projet. Ainsi, un défaut P0 critique corrigé en 2 jours dès son identification pourra coûter moins cher qu'un défaut P3 moins important corrigé en 2 heures mais 10 semaines plus tard. Pour mesurer la portée de ces propos, nous pouvons imaginer une nouvelle unité pour mesurer le coût des défauts : le "$Day". En reprenant l'exemple ci-dessus, en considérant qu'une heure de travail vaut 100$, le défaut P0 vaut 1600 $Day alors que P3 vaut 16000 $Day soit 10 fois plus. Cette unité est à considérer de manière relative comme l'effort des éléments du Backlog, elle reflète un coût mais n'est pas directement convertible en dollars.

    Que pensez-vous de ces approches? Comment gérez-vous les défauts?





    lundi 25 mai 2009

    10 Outils pour booster son efficacité

    Chacun d'être nous a déjà ressenti un état où notre travail avance vite, bien, de façon efficace. C'est ce que l'on appelle l'état de flot. Atteindre cet état n'est pas aisé lorsque les interruptions font rages; il y a celles qui sont utiles et celles que ne le sont pas (voir La séquence homogène de travail). Il convient donc de s'efforcer à ne pas s'interrompre soi même par la lecture des mails par exemple ou tout simplement en ne sachant pas accéder à l'information de façon immédiate. C'est ce dernier point que je souhaite aborder plus en détails dans ce billet. Pour tout ce qui est documents papier, je recommande la méthode GTD . Puis, pour le reste, il existe une multitude d'outils gratuits qui change la vie. Ces outils m'ont pour la plupart été introduit par Bruno avec le concept de boîte à outils. Pour ma part voici ceux que j'utilise de façon quotidienne ou fréquente en développant.


    Cet outil permet de lancer une application ou plus généralement d'ouvrir un fichier en une combinaison de touches. Fini les recherches d'applications par le menu démarrer, sur le bureau ou directement dans l'explorer qui font perdre beaucoup de temps et déconcentre.


    Qui ne perd pas de longues minutes en recherchant un fichier sur son PC? Cet outil permet de retrouver n'importe quel fichier en un clin d'oeil grâce à l'utilisation de la base de données des volumes NTFS. (cf détails ici )


    Nous avons sans cesse besoin du clipboard en développant, or Windows ne conserve que la dernière chaîne copiée. Ditto fait gagner beaucoup de temps en fournissant en une combinaison de touche l'historique du clipboard.


    Lors du développement de certaines applications sans interface utilisateur, l'utilisation des logs est très fréquente. Le pire des outils est probablement Notepad car il ne propose aucun rafraîchissement. Baretail, en plus relire le fichier très fréquemment, permet de filtrer des chaînes de caractères ainsi que de colorer les lignes suivant la présence des chaînes spécifiques.

    Cet outil est le complément de Baretail. Il permet la recherche de chaînes dans un ensemble de fichiers. Il m'est très utile pour analyser des Méga octets de logs.


    Tout le monde a déjà été confronté à des problèmes paraissant mystérieux. Très souvent process monitor m'a sauvé la mise en des temps records grâce au monitoring des accès fichiers et de la base de registres.


    L'utilitaire Windows Regedit permettant de consulter la base de registre est pour le moins poussif. La moindre recherche prend des dizaines de secondes interminables. Registrar Lite permet de faire des recherches très rapides.


    Il est très fatiguant d'exécuter plusieurs fois la même séquence d'utilisation d'un programme. AutoHotKey permet d'automatiser ces scénarios et de faire faire à notre PC les tâches ingrates! Bruno explique plus en détails les possibilités de cet outil ici


    Chaque fin d'itération est synonyme de démonstration du travail terminé à notre Product Owner. Or celui-ci n'est pas sur place alors nous utilisons Ultra VNC comme moyen de partager notre session windows. Cet outil simple et performant permet la prise de contrôle à distance.


    Enfin, pour rester informé sur mes sujets de préférés, j'utilise un aggrégateur de flux rss. Google Reader est efficace et me donne quotidiennement de grandes quantités d'information. En quelques minutes, je fais chaque jour "ma revue du net".


    ... Tous ces outils sont très facilement accessibles sur mon PC grâce à Launchy !



    vendredi 3 avril 2009

    Optimisation globale des équipes SCRUM (V2)

     

    Suite à une réorganisation interne et au départ d'un collègue pour de nouvelles aventures, deux de nos équipes SCRUM ont vu leurs effectifs réduit d'une personne :

    Équipe G:
    • 3 développeurs
    • 2 représentants utilisateurs --> 1 représentant utilisateurs
    • 1 ScrumMaster
    • 1 ProductOwner
    --> Avant le changement, les deux représentants utilisateurs n'étaient pas pleinement occupés sur les projets de leur équipe. Cependant le passage à 1 représentant utilisateurs a inversé les contraintes. Maintenant, les développeurs doivent parfois ralentir leur flux de développement.

    Équipe D:
    • 3 développeurs --> 2 développeurs
    • 1 représentant utilisateurs
    • 1 ScrumMaster
    • 1 ProductOwner
    --> Avant le changement, il y avait un certain équilibre de charge de travail entre les développeurs et le représentant utilisateurs. Le passage à deux développeurs laisserait très probablement du temps libre au représentant utilisateurs.

    Les équipes ont les contraintes suivantes:
    • Le projet D devra être terminé avant l'été, bien qu'il y ait un développeur en moins
    • Le projet D devra être maintenu et nous devrons être réactif aux demandes de nos clients; et ce, même pendant les congés annuels de cet été.
    • L'équipe G doit produire une release du projet G pour mi-mai.
    • L'équipe G doit maintenir d'autres projets : S, P, etc.
    • L'équipe D devra aider l'équipe G une fois le projet D terminé.

    Un brainstorming nous a permis d'imaginer les solutions suivantes:
    1. On ne fait rien, et nous ferrons face aux retards possibles sur Projet D et G
    2. Un développeur de l'équipe G rejoint l'équipe D pour terminer le projet D avant l'été aux frais de l'équipe G et de la release du projet G.
    3. Nous fusionnons le deux équipes pour finir le projet D, terminer la release du projet G et faire au mieux sur les autres projets.

    Toutes ces solutions ont leurs avantages et inconvénients:
    • La première solution à pour avantage de ne pas trop perturber les équipes qui ont un bon équilibre et qui sont devenues performantes mais on comprend bien que l'objectif de date du projet D sera difficile à tenir car le "product backlog" a déjà été sérieusement raffiné. De plus, dans l'objectif de maintenir le produit, concentrer la connaissance sur trois personnes parait une option assez risquée.
    • La deuxième solution serait valable pour terminer le projet D mais ça serait déshabiller l'équipe G déjà réduite pour habiller l'équipe D. D'un point de vu maintenance, cette option est guère mieux que la précédente. De plus, terminer la release du projet G pour mi-mai serait difficile.
    • La dernière solution, quant à elle, a pour inconvénient de bouleverser complètement les deux équipes dont les pratiques au quotidien sont différentes, et dans lesquelles une complicité c'est formée. Cependant, la connaissance de tous les projets se diffuserait vers plus de personnes et le projet D pourrait être privilégié afin d'être terminé avant l'été. Le projet G pourra aussi bénéficier de tous les membres de la nouvelle équipe pour valider la release d'ici à mi-mai. 

    Auriez-vous d'autres idées? Quelle option choisiriez-vous?

    Avec une approche Lean, il faut rechercher une optimisation globale plutôt qu'une optimisation locale. Les deux premières options où rien n'est changé et où un développeur change d'équipe sont des optimisations locales avec au mieux le projet D pouvant être terminé dans les temps. Dans ces options, on refuse de changer radicalement pour ne pas casser les dynamiques des deux équipes. Cependant, on conserve de gros risques sur tous les projets que ce soit sur les dates ou la connaissance commune pour la maintenance. La fusion des deux équipes, aux delà du changement complet des équipes parait une solution plus pérenne dans le temps alors s'il faut changer, autant y aller franchement!

    Nous avons donc choisi la fusion avec une certaine appréhension face à ce changement mais nous sommes convaincus que c'est la meilleure solution.

    Voyons donc maintenant les changements que nous devons mener:
    • Reconstruire une équipe : Cela va prendre du temps car pour arriver à la performance nous devrons passer par une certain nombre d'étapes (http://blog.octo.com/stades-de-developpement-dune-equipe/)
    • Nous allons devoir travailler avec deux ProductOwner tant que le projet D n'est pas terminé
    • L'un des product owner est aux Etats-Unis avec 6 heures de décalage. Les cérémoniesSCRUM vont donc devoir être adaptées en conséquence
    • L'équipe D perd son ScrumMaster
    • Nous devrons faire des choix de pratiques
    • Nous allons devoir fusionner les "product backlogs" (en gardant des sous-projets) pour avoir une meilleure visibilité
    • Chacun va devoir apprendre à travailler sur tous les sous-projets.
    • Nous allons très probablement centraliser les sources des différents projets et fusionner les plates-formes d'intégration continue pour une maintenance plus facile.

    Dans un prochain billet, j'essayerai d'approfondir la théorie des contraintes sur ces deux équipes afin d'expliquer le choix qui a été fait de façon plus analytique. Je ne manquerai pas aussi de vous faire un retour sur ce choix avec les succès et difficultés rencontrés avant l'été ...

    jeudi 26 mars 2009

    Mémo Lean

    La lecture du livre "Implementing Lean Software Development - From Concept To Cash" m'a donné l'envie d'appliquer l'un des conseils exprimé dans le livre : 
    "Le rapport A3"

    Synthétiser un principe ou un concept sur une feuille simple  permet de filtrer et raffiner ses pensées. C'est aussi un très bon moyen de créer de la connaissance dans son organisation.  D'ailleurs certains collègues ont adopté cette pratique suite à la lecture de l'article PRATIQUES D'EQUIPE lors d'un dojo organisé par Bruno

    Voici donc un poster qui a pour but de rappeler en un coup d'oeil les 7 principes du Lean ainsi que les 7 types de gaspillage.








    mercredi 4 mars 2009

    Pair-programming = efficacité + plaisir

    Aujourd'hui, je n'ai pas passé une minute seul devant mon ordinateur; nous sommes actuellement trois développeurs dans l'équipe et j'ai travaillé avec tout le monde, sur chaque ordinateur.

    La matinée a commencé avec un de mes collègues avec l'étude de Simian un outil qui permet de détecter les duplications de code. Nous avons travaillé une bonne heure ensemble avec pour conclusion que l'outil n'était pas forcement le plus approprié à notre langage de programmation Delphi mais que sur le principe, ça serait très intéressant d'intégrer cette métrique à Hutson, notre moteur d'intégration continue.

    Puis, un collègue de l'équipe support en déplacement chez un client pour l'installation de notre logiciel sur plusieurs serveurs a appelé pour que nous cherchions la cause d'une erreur que notre client reproduisait facilement. L'équipe a mobilisé toute son énergie pour d'une part reproduire le problème, d'autre part trouver la solution. Pour l'anecdote, nous n'avons pas eu besoin de modifier notre logiciel car l'erreur provenait d'un champ de la base de données qui était mal dimensionné! La satisfaction collective était extraordinaire; quel plaisir de montrer à notre client que nous savons répondre très rapidement à ses problèmes; de plus, sortir un collègue d'un potentiel embarra renforce grandement le plaisir partagé!

    La journée a continué avec la création d'un nouveau programme d'installation en pair-programming et s'est terminée sur l'automatisation de sa construction. Nous ne créons pas très souvent de nouveau programme de ce type alors le fait d'être en paire nous a permis de ne pas rester bloqué car les idées arrivent beaucoup plus vite à deux que seul.

    La pratique du pair-programming n'est pas naturelle. Elle demande que les membres de l'équipe se fassent confiance car programmer en paire, c'est s'exposer. Il faut donc faire un petit effort au début puis très vite, on se rend compte qu'un travaille réalisé en paire permet d'obtenir des très bons résultats et pour un temps total probablement inférieure au temps qu'une même activité aurait demandé à une personne seule. On peut très vite préférer travailler à plusieurs plutôt que seul.

    Le partage qui résulte du pair-programming a de multiples avantages. Il permet d'aquérir des compétences, d'avoir une bonne propriété collective du code, de trouver les meilleures solutions, d'avoir du fun en partageant les "micro-succès" et j'en oubli !

    Le travail collaboratif est une très bonne étape. Le pair-programming demande encore plus de relations et d'interractions entre les membres d'une équipe; il permet de soutenir la première valeur du Manifeste Agile :
    "L’interaction avec les personnes plutôt que les processus et les outils".


    Portrait Lego



    ManU a décris une excellente galerie de caricatures. J'admire le recul nécessaire à la synthèse de tels profiles. Bravo!

    Du coup, il est impossible de ne pas y chercher son propre reflet et je pense que LE COLLECTIVISTE me correspond plutôt bien!

    Amis lecteurs et bloggers ... à quoi ressemblez vous?

    mardi 13 janvier 2009

    "Getting Things Done" - GTD - Retour d'expérience


    Le constat en décembre 2008

    J’avais :
    - Beaucoup de choses à penser, à faire tant au niveau personnel qu’au niveau professionnel 
    - Des documents à classer qui s’empilent comme le courrier, les factures, les articles etc.
    - Des engagements à respecter
    - Des documents pas toujours facilement retrouvables
    - Beaucoup de documents conservés devenus inutiles
    - Plein de projets en tête mais pas le temps de les réaliser
    - Un stress relatif mais quasi permanent
    - Toujours des idées mais jamais au bon moment pour les concrétiser

    --> Pour résumé, un joyeux bazar dans mes documents et dans ma tête. 

    Avec un tel constat, et je n’ai pas honte de le dire car vous êtes sans doute dans la mêm situation, mon efficacité pouvait être grandement améliorée ! 

    Il y a quelques mois, mon coach informel Bruno m’a indiqué une méthode d’organisation à découvrir afin de devenir plus efficace : « Getting Things Done » de David Allen. En décembre, j’ai décidé de lire le livre afin de trouver une réponse à « Comment s’organiser au quotidien pour devenir plus efficace ? ». Dans ce billet, je vais retranscrire les points qui m’ont le plus marqué sans décrire la méthode car rien ne vaut la lecture du livre pour s’imprégner de la philosophie.

    • L’Analogie aux arts martiaux : Les karatékas, pour casser une brique ont besoin de beaucoup d’énergie et de concentration ; ce n’est qu’en se concentrant sur cet unique objectif et en se relâchant  au maximum qu’ils pourront y arriver. De la même manière, nous devons nous affranchir de « toute pollution cérébrale » pour être efficace, créatif et capable de se concentrer. 
    • Pour arriver à se libérer l’esprit, David Allen nous demande de créer des listes avec tout ce que nous avons en tête:
    o Liste de projets à réaliser (est un projet tout ce qui demande plus d’une action)
    o Listes de premières actions des projets cités dans la liste de Projet (@Home, @Office, @Phone, @Computer)
    o Liste de projets à réaliser un jour / peut être
    o Listes de Contrôle (= check liste pour une activité donnée)
    L’exercice paraît difficile et fastidieux mais lister une centaine de points n’est pas difficile et procure un soulagement immédiat !
    • Afin de provoquer un changement radical, David Allen nous propose de continuer la méthode en rassemblant tout ce qui n’est pas à sa place définitive dans un carton : documents, objets, post-its, dossiers, etc. Donc au final, nous avons place nette si l’on fait abstraction du gros carton qui vient d’être rempli. Puis, il faut prendre les choses une par une dans le carton sans jamais les reposer et prendre UNE DECISION concernant l’objet en question : Si c’est un document à conserver, il faut le classer dans un système de référencement fiable (voir plus loin) ; si c’est une chose inutile, la jeter ; si c’est un post-it rappelant quelque-chose à faire, la faire si ça prend moins de 2 minutes ou l’ajouter dans les listes décrites ci-dessus, etc. L’exercice prend plusieurs heures mais pour l’avoir fait, il donne une immense satisfaction et l’impression de tout maîtriser plutôt que de subir tous ces documents et travaux à faire.
    • Un système de référencement fiable est un système de classement de document qui permet de retrouver en quelques instants tout document classé. David Allen propose l’utilisation de chemises cartonnées classées par ordre alphabétique avec une chemise par thème. Ainsi, nous pouvons avoir des dizaines de chemises toujours facilement retrouvables. Pour mon système, j’ai actuellement une petite centaine de chemises !
    • Afin de gérer les listes au quotidien, il convient de trouver un outil pratique et disponible où que l’on soit car toutes nos premières actions doivent y figurer et pour prendre les bonnes décisions sur que faire à un moment donné, il faut nous y reporter. Il existe beaucoup d’outils logiciels et PDA permettant la gestion de listes de tâches mais après mûre réflexion, mon choix s’est porté sur un Agenda Filofax permettant d’ajouter mes listes d’actions, de projets et également de disposer d’un Agenda où que je sois. 
    • L’Agenda doit être utilisé avec une grande rigueur, ne doit y figurer que des choses où événements devant être faites ou suivis à des dates précises ; tout le reste doit être inscrit sur les listes. Sinon, l’agenda devient non fiable et un fourre-tout.
    • Pourquoi faut-il indiquer la première tâche d’un projet uniquement ? Car pour qu’une action soit faite, elle doit paraître accessible sinon elle sera repoussée et repoussée encore. De plus, la réalisation de la première tâche appelle les suivantes. Par exemple, l’écriture de ce billet figurait dans ma liste de projets et la première action associée était « Décrire un plan pour le billet GTD ». En fin de compte, j’ai réalisé le plan et suis en train d’écrire ces mots ! 
    • Au final, les listes nous indiquent les premières tâches à effectuer afin de voir nos projets se concrétiser et nos engagements se réaliser. Chaque semaine, il faut revoir l’ensemble des listes afin de décider si certains projets doivent être activés, supprimés, ajoutés.

    Le constat un mois après :

    --> Je suis plus efficace et plus performant car j’ai l’esprit libéré grâce aux listes, au système de référencement et mon agenda.
    --> Je suis moins stressé car j’ai une vue d’ensemble de tout ce que j’ai à faire
    --> Je suis plus fiable car tous mes engagements sont gérés et finissent par être honorés.
    --> Cette méthode m’aide aussi bien dans ma vie professionnelle que personnelle.


    samedi 29 novembre 2008

    La confiance


    Qu'est ce que la confiance dans une équipe?

    Il y a plusieurs aspects. Le premier, le plus communément énoncé consiste à laisser carte blanche à une ou plusieurs personnes pour faire une tâche, un travail:

    "Je te fais confiance, la solution que tu choisiras sera très bien".

    Notre métier d'informaticien nous confronte chaque jour à des problèmes de plus en plus compliqués. Une équipe ayant à faire un choix technique pour l'implémentation d'une fonctionnalité complexe dont le développement prendra plusieurs jours doit, je pense, se diriger vers une autre signification de la confiance:

    "Je te fais confiance donc afin de trouver la meilleure solution à notre problématique je te propose d'autres idées; nous pourrons évaluer les avantages et inconvénients de chacune et conclure". 

    La confiance, ici, repose sur le fait que nous ne craignons pas de blesser, de se faire rétorquer. Il n'y a d'ailleurs pas de discussion intéressante sans débat. 

    La capacité de chacun à challenger les idées des uns et des autres au sein d'une même équipe est pour moi la meilleure preuve de confiance à apporter.

    Je vous propose de jeter un coup d'oeil, si ce n'est pas déjà fait sur le billet The Five Dysfunctions of a Team . La confiance est la base de tout bon travail d'équipe alors mieux vaux bien comprendre ce qu'elle signifie!

    Luc



    dimanche 9 novembre 2008

    The Five Dysfunctions of a Team



    Comme l'expliquent si bien le billet d'Emmanuel Chenu et le retour sur la vidéo de Ken Schwaber par Bruno Orsier, être agile ne permet pas d'éviter tous les conflits ... que ce soit pour faire accepter la gestion de projet agile dans une organisation ou dans les équipes aux plus profond des tranchées ;o) !

    J'ai lu il y a quelques temps le bouquin "The Five Dysfonctions of a Team" de Patrick Lencioni. Il donne le ton avec :


    "Si vous pouviez obtenir de toutes les personnes travaillant dans une entreprise qu’elles rament dans la même direction, vous pourriez dominer n’importe quelles industries et n’importe quels marchés contre tous les concurrents et n’importe quand".

    Et là, vous ne quitter plus le livre avant de l'avoir terminé! Il décrit les 5 dysfonctions à l'aide d'une pyramide dont la base est la Confiance. La base car sans elle, il y aura une certaine Peur du Conflit, pas de débat d'idées et de ce fait, tous les membres d'une équipe ne donnerons pas leur point de vue; ce qui va inévitablement conduire à un Manque d'Engagement. Une fois l'engagement acquis, si les membres d'une équipe ne se tiennent pas responsable les uns les autres pour ce sur quoi ils se sont mis d'accord, alors il y a une bonne probabilité pour que le 4ème écueil apparaisse : La fuite des responsabilités. Enfin, le dernier point concerne l'Inattention aux Résultats et pour éviter cela :

    "Nous devons définir les résultats à atteindre de façon si claire à chacun que personne ne considérerait faire quelque chose pour purement améliorer son statut ou son ego individuel parce que cela diminuerait notre capacité à atteindre nos objectifs collectifs. Nous perdrions tous."


    Que ce soit dans les équipes SCRUM, XP ou à d'autres niveaux hiérarchiques, il est bon de garder cette pyramide dans un coin de la tête! Peut-être pourrez-vous résoudre certains de ces troubles afin de faire ramer tout le monde dans la même direction!


    Quelques transparents présentés à mes collègues ScrumMasters et chefs d'équipe :

    ~Luc


    jeudi 6 novembre 2008

    La séquence homogène de travail


    Le but de la Séquence Homogène de Travail est de constater un potentiel dysfonctionnement dans son organisation quotidienne. Elle consiste à compiler toutes les activités d’une journée de travail en incluant toutes les interruptions, qu’elles soient utiles ou inutiles. Dans le domaine de l’informatique, nous pouvons considérer que le temps d’adaptation à une nouvelle tâche ou la reprise d’une tâche interrompue est de l’ordre de 10 à 15 minutes.


    Voici comment calculer votre séquence homogène de travail :

    • Lister toutes les tâches sur une journée… papier + crayon à porté de main !

    Ex : 8h – 8h15 : Lecture des mails
    8h15 – 8h20 : Café avec les collègues
    8h20 – 8h30 : Analyse des résultats d’un test
    8h30 – 8h40 : Conversation téléphonique personnelle
    8h40 – 8h50 : Suite de l’Analyse des résultats d’un test
    8h50 – 9h00 : Étude du sprint BackLog
    9h00 – 9h15 : Daily Scrum meeting
    9h15 – 9h30 : Travail sur storie A
    9h30 – 9h35 : Demande d’un collègue sue une storie B


    • Lister le nombre d’interruptions, les classer en deux catégories et totaliser les heures d’interruption

    - Les interruptions utiles
    Ex : Demande d’un collègue sue une storie B : 5 min

    - Les interruptions inutiles
    Ex : Conversation téléphonique personnelle : 2 min

    Exemple sur la journée : 15 interruptions
    10 interruptions utiles : 2h
    5 interruptions inutiles : 1h

    • Calcul de la Séquence homogène de travail : SHT

    nb heures de travail utiles = nb heures de travail dans la journée
    - nb heures interruption inutiles
    - temps de réadaptation * nb total d’interruptions

    SHT = nb heures de travail utiles / nb total d’interruptions


    Exemple :

    nb heures de travail utiles = 8 h - 2 h -10 min * 15 = 3 h

    SHT = 3 * 60 min / 15 interruptions
    SHT = 12 min

    Si la SHT est inférieure à 15 - 20 min alors des difficultés d’organisation, un certain stress et un efficacité non optimale peuvent apparaître.


    Note : Je n'ai pas trouvé de référence sur la Séquence Homogène de Travail. Cet indicateur m'a été présenté lors d'une formation. Cependant, le plus important est de réaliser qu'une gestion de notre temps limitant le nombre d'interruptions est bénéfique d'un point de vue confort mais aussi de performance.

    mercredi 29 octobre 2008

    La Méthode Coué

    Bien qu'ayant naturellement un tempérament positif, il m'arrive d'avoir un petit coup de blues ou un stress un peu exagéré. Dans ces cas la, notre imagination peu nous faire dériver vers les scénarios les plus fous et notre moral en prend encore un coup!

    Mr Emile Coué, père de la pensée positive incite à répéter 20 fois de suite et 3 fois par jour la phrase suivant :

    "Tous les jours et à tous points de vue, je vais de mieux en mieux"

    Essayez, et vous arriverez à vous persuader que tout va mieux ou bien quand vous pensiez le contraire peu avant!

    Pour plus de détails sur la méthode Coué, je vous propose de jeter un coup d'oeil sur le site suivant : http://www.methodecoue.com/index.htm . Mr Coué est en autre à l'origine de l'effet placebo et de la sophrologie.