Bienvenue sur Développement Agile

Référence sur le développement logiciel Agile. Nous traitons de conception, de programmation, de pratiques de génie logiciel, d'essais et d'autres sujets connexes.

L'application rigoureuse de la méthode 5S

Publié par David Beaumier, Jean-Francois Gilbert le mercredi 15 juillet 2015 à 17:05

Dans ce dernier billet sur l’application de la méthode 5S en développement logiciel nous abordons l’opération suivre (ou Shitsuke en japonais). Cette 5ième opération vise à contrôler l’application rigoureuse des 4 premiers « S ». En anglais, le terme sustainable est utilisé. L’objectif est donc de s’assurer d’une adoption durable de la méthode.

Sans cette étape de vérification, votre équipe court le risque de revenir à ses vieilles habitudes et de perdre tranquillement les bénéfices qu’elle a obtenu en mettant en œuvre la méthode. Cette opération apporte à la méthode 5S l’aspect contrôle et adaptation qu’on associe fréquemment aux pratiques agiles, telles que Scrum.

Cycle 5S

On doit graduellement apprendre à identifier des façons de ne pas retomber dans ses ornières. Comment peut-on faire pour ne pas qu’un problème ne puisse se produire de nouveau? Par exemple, comment s’assurer que le client ne puisse pas entrer une valeur de configuration qui rende le logiciel instable? Il y a autant de solutions que de problèmes, mais j’aime beaucoup utiliser la photo ci-dessous pour illustrer comment il est possible de mettre en place un mécanisme (simple) pour empêcher le contournement d’une consigne qui pourrait avoir d’importantes conséquences.

5S Suivre

Les pratiques de développement qui peuvent vous aider

Plusieurs des pratiques proposées par eXtreme Programming visent justement à s’assurer que l’équipe puisse mettre en place un cycle de développement qui soit réellement incrémental (pas de régression entre les livraisons fréquentes). Parmi celles-ci on retrouve la programmation pilotée par les tests (TDD), la programmation en paire, les tests d’acceptation par les clients et l’intégration continue.

Si vous n’avez pas déjà une solution d’intégration continue en place, ou si celle-ci laisse à désirer, je vous suggère la lecture de Continuous Integration: Improving Software Quality and Reducing Risk. Une fois un serveur d’intégration continue en place il devient beaucoup plus facile d’automatiser la prise de mesures et de publier les résultats de façon centralisée, pour le plus grand bénéfice de l’équipe.

Livre CI

Une autre suggestion est d’automatiser toutes les vérifications qui peuvent l’être. C’est un des avantages du développement logiciel : nos activités sont généralement vérifiables et on sait comment automatiser (enfin, j’espère)! Par exemple, est-il possible d’écrire un test pour vérifier que personne n’introduise par inadvertance un nouveau schéma dans la base de données? Peut-on valider la valeur saisie dans le fichier de configuration et donner un message d’avertissement si elle n’est pas conforme, évitant ainsi un problème à l’exécution?

Les outils d’automatisation de la configuration comme Chef ou Puppet permettent de gérer la configuration de vos environnements sous forme de cible, réduisant ainsi les risques d’introduire un problème lors d’une manipulation manuelle.  Une liste de vérification c’est bien, mais si on peut l’automatiser c’est mieux!

Intégrer le suivi à votre cadre de travail

Pour ceux qui utilisent Scrum comme cadre de travail, n’hésitez pas à adapter la cérémonie de la revue de sprint pour y inclure un suivi de vos initiatives 5S. C’est un bon moment pour faire le point sur celles en cours, celles qui sont complétées (et les bénéfices que vous en retirez) et pour en proposer de nouvelles. Si vous utilisez une approche Kanban en flux tiré, pourquoi ne pas prévoir une rencontre hebdomadaire de quelques minutes pour discuter des opportunités d’amélioration en cours? Nous sommes certains que 10 à 20 minutes investis à ce niveau permettront à l’équipe de faire le point sur les initiatives en cours et d’identifier celles qui seraient bénéfiques à entreprendre.

Pour mesurer l’impact de chacune de vos initiatives nous vous recommandons premièrement d’identifier le point de départ (état initial) et la cible que vous poursuivez. Ensuite, déterminez quelles mesures vous permettront de vérifier l’atteinte de votre cible (diminution de 7% des appels de service, augmentation de 5% de la satisfaction des clients, etc.).

Vue externe

Si votre équipe le souhaite, et qu’elle possède la maturité suffisante pour le faire, il peut être intéressant de faire appel de façon sporadique à un « vérificateur externe ». Celui-ci aurait comme rôle de valider que l’équipe est en mesure de démontrer qu’elle applique les façons de faire qu’elle prétend avoir mis en place et qu’elle est en mesure de s’auto vérifier. Il est important de voir ce suivi comme une opportunité de développer les gens et améliorer les façons de faire pour le bénéfice du produit et de l’organisation et non comme une façon de les contrôler ou d’évaluer leurs performances.

Pour cette raison, le rôle du vérificateur aura avantage à être exercé par une personne d’une autre équipe. En plus, cela permet un partage intéressant sur les façons de faire à l’intérieur de l’organisation.

Conclusion

Tel que le mentionne le manifeste Agile, il est préférable de « valoriser les individus et leurs interactions plutôt que les processus et les outils ». L'utilisation de la méthode 5S ne devrait pas vous en écarter. Gardez en tête que 5S n’est qu’un moyen parmi d’autres pour améliorer vos façons de faire. En fin de compte, c’est l’implication et la passion de votre l’équipe qui assurera le succès de vos projets!

Travailequipe

Mise à jour

Voici les liens pour consulter les autres articles.

D’autres billets qui pourraient vous intéresser

Leçon de vie

Publié par Jean-Francois Gilbert le lundi 9 mars 2015 à 00:00

Il y a quelques temps, j'ai commencé à travailler sur une preuve de concept relativement complexe. Au départ, je n'avais qu’une vague idée des outils et de l’architecture que j’allais utiliser. Il y avait tellement d'inconnus que je ne savais pas trop par où commencer. 

J'ai donc avancé le projet un peu à tâtons. Je m’efforçais de répondre aux exigences fonctionnelles complexes tout en explorant une plateforme que je connaissais peu. Bref, j'en avais un peu par-dessus la tête. Pour sauver du temps et parce que je croyais tout jeter à la poubelle de toute façon, j'ai commencé à coder sans écrire de tests unitaires. Je vois d’ici vos hochements de tête désapprobateurs. Mais je croyais que les chances que mon code puisse être réutilisé plus tard étaient tellement minces que ça me ralentirait d’écrire des tests tout de suite. Oh, mais quelle erreur !

Au début, je dois avouer que ça allait plutôt bien. J'essayais des choses, je changeais d'idée, j’effaçais le code, j’essayais autre chose. Pas de temps à perdre, je produisais du code à la vitesse grand V ! Étant habitué à programmer presqu'exclusivement en mode TDD, je ressentais quand même un certain malaise. Je n'avais pas mon filet de sûreté habituel et je n’étais pas particulièrement fier du design de mes classes. Mais bon, mon prototype fonctionnait, non ?

A un certain moment j’ai réalisé que globalement, la piste que je suivais depuis plusieurs jours était la bonne. Il y avait bien quelques inconnus ici et là, mais je commençais à avoir entre les mains quelque chose d’intéressant. Or, puisque j'avais codé un peu en cow-boy, le design n'était pas génial et ma solution commençait à être sens dessus dessous. J'ai donc commencé à faire du réusinage pour être capable de mieux me retrouver. C'est à ce moment que des bugs ont commencé à faire surface. Je me suis mis à perdre un temps fou. Les modifications étaient suivies par des séances de débogage dans Visual Studio et je maudissais les dieux de la programmation, mais surtout moi-même. Au lieu d'avancer, je faisais des pas en arrière à chaque fois que je modifiais du code.

Je n'ai eu d'autre choix que de recommencer du début. Mais cette fois, j'ai bâti mon code comme je suis habitué de le faire : en TDD. J’ai quelque fois eu le goût de prendre le code du prototype et le copier dans mes nouvelles classes, mais j'ai presque toujours résisté à la tentation. Bien sûr, j'ai gardé certains concepts mais le fait de recommencer du début a fait émerger un design différent et surtout meilleur.

En bref, soyez plus brillants que moi. Prenez le temps de bien faire les choses dès le début et en bout de ligne vous gagnerez du temps. Je crois qu'on peut se permettre d'expérimenter de nouveaux outils sans faire de tests unitaires exhaustifs. Mais il faut savoir identifier le moment où on a une assez bonne idée de la solution et reprendre les bonnes pratiques de développement.

En terminant, voici quelques billets qui pourraient vous intéresser concernant le TDD et les tests unitaires.

Jusqu'à quel point dois-je tester mon code ?

TDD : comment partir du bon pied ?

Comment rendre vos tests plus propres grâce aux builders ?

 

Vos casseroles sont-elles propres ?

Publié par Jean-Francois Gilbert le dimanche 30 novembre 2014 à 00:00

Source: https://www.flickr.com/photos/nicholassmale

Lors de son son keynote présenté à l'Agile Tour de Québec le 5 novembre dernier, Michael Feathers comparait le code à une cuisine. Avant de préparer de nouveaux plats, il va de soi de nettoyer les ustensiles, poêles et casseroles. Idéalement, on le fait au fur et à mesure qu'on les salie. De cette façon, on n'accumule pas une montagne de vaisselle et la cuisine reste relativement propre en tout temps. 

C'est une analogie intéressante mais le principe n'est pas toujours évident à appliquer dans notre code. Ce n'est pas qu'on ne veuille pas nettoyer au fur et à mesure, mais plutôt qu'on ne réalise pas toujours que le code est sale. L'idée même de code propre ou sale varie d'un programmeur à l'autre. Oui il y a de nombreux livres et articles publiés à ce sujet. Cependant, le pourcentage de développeurs qui ont lû sur le sujet ou qui prennent le temps d'appliquer les bonnes pratiques demeure trop bas. 

Encouragez le réusinage du code et discutez des bienfaits dans votre équipe. Décidez ensemble de ce qui est acceptable et ce qui ne l'est pas, mais visez haut en termes de qualité. Si votre cuisine est sale, peut-être serait-il temps d'y remédier. 

Il y a certainement plus d'une façon de sensibiliser vos collègues à ne pas la salir davantage et à commencer à la nettoyer. Une piste de solution possible serait de créer une "check list" des choses à vérifier une fois que le code est terminé. Avant d'archiver du code, un développeur devrait consulter la liste et s'assurer que le code rencontre les standards de qualité établis par VOTRE équipe. 

Je vous suggère de commencer modestement avec quelques éléments de base en expliquant bien la raison de leur présence sur la liste. Bonifiez-là à mesure que les bonnes pratiques sont ancrées dans les mœurs de votre équipe. 

Alors, dans votre cuisine, les casseroles sont-elles propres ?

  • Plus récents
  • 1
  • Plus anciens

Archive