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

La conception importe plus que la production

Publié par David Beaumier le mardi 16 juin 2015 à 10:17

« It’s not the production system that matters most, but the design system ». Du moins, c’est le point de vue de Toyota lorsque son système de production (le fameux TPS – Toyota Production System) est comparé à son système de conception, le TPDS pour Toyota Product Development System.

C’est sans doute pour cette raison que Toyota a toujours accepté de recevoir les représentants des autres manufacturiers dans ses usines. Toyota savait que son principal avantage compétitif se trouvait plutôt au niveau du système de conception de ses produits. Et oui, même si la conception est une activité hautement créative, le système à l’intérieur duquel cette conception se fait peut, à plusieurs égards, être standardisé.

It’s not enough to do your best; you must know what to do and then do your best.

- W Edward Deming

En développement logiciel, bien des équipes ont tendances à associer leur processus de développement à un système de production. Je crois qu’elles auraient plutôt avantage à faire comme Toyota et scinder en deux leur processus : la conception du logiciel et la production du logiciel. Ne vous méprenez-pas, je ne vous propose pas de revenir au développement en cascade!

Je vous propose plutôt d’utiliser l’analogie de la chaîne de montage pour regrouper les activités de construction (build), de vérification, de déploiement et de mise en production de votre logiciel. Le fameux DevOps, quoi. Le serveur d’intégration continue, avec son build, ses tests et vérifications et par la création du paquetage applicatif, joue en quelque sorte le rôle de l’usine. La partie déploiement, mise en œuvre et opérationnalisation du produit équivaut cycle de distribution, de vente et de service habituellement associé au réseau des concessionnaires.

Les activités en amont, incluant le « codage », sont en réalité des activités de conception. C’est seulement un fois que le serveur récupère le code depuis votre gestionnaire de sources que l’usine se met en branle. Tout ce qui se fait avant sert à définir les spécifications structurelles et comportementales de l’application (qu’il s’agisse de l’interface utilisateur ou de traitements d’affaires). Le code source, les schémas de bases de données et la configuration représent les spécifications requises pour bâtir le produit.

Ce n’est donc pas suffisant de mettre votre usine en marche. Vous devez vous assurer qu’elle produit la bonne chose! Heureusement, nous avons la chance en développement logiciel de ne pas avoir à gérer les contraintes physiques. Nous pouvons construire une seule fois le produit et le cloner aussi souvent que souhaité. Il nous est possible de changer ses spécifications, le bâtir et l’essayer en peu de temps et pour peu de frais. Cette flexibilité devrait donc nous permettre de nous concentrer sur le produit à bâtir plus que sur sa fabrication. Ce n’est pas que l’aspect DevOps ne soit pas important, c’est juste que ce n’est habituellement pas en premier lieu pour votre efficacité à bâtir et opérer qu’un client va adorer votre produit.

Ne perdez pas de vue le premier des principes du manifeste agile: le client sera satisfait par la livraison de fonctionnalités à valeur ajoutée.

Principe1 Manifesteagile

Un cadre de travail agile, tel que Scrum, a l’avantage d’offre un modèle itératif pour la conception de produits. Jumelé à un système de production efficace ça permet de réduire la boucle de rétroaction afin de valider que vous avez conçu les fonctionnalités requises pour que votre client atteigne ses objectifs d’affaires.

Et vous, est-ce que votre équipe se perçoit comme un groupe de conception de produits ou se voit-elle plutôt comme une équipe de fabrication?

Suggestion de lecture sur le Javascript

Publié par Jean-Francois Gilbert le mardi 9 juin 2015 à 00:00

S'il y a un langage qui est mal compris et parfois mal aimé, c'est bien le Javascript. Il est vrai que quelques particularités du langage peuvent être surprenantes ou même discutables. Lorsqu'on a travaillé un certain nombre d'années avec des langages tels que Java ou C#, certains concepts risquent de nous laisser perplexe. Plus souvent qu'autrement, les développeurs sont mis en contact graduellement avec ce langage. On commence d'abord par ajouter des validations ou de petites fonctionnalités à un formulaire web. Trop fréquemment, on va copier un exemple sur le web ou bien on utilisera une librairie telle que JQuery. On arrive à nos fins sans trop savoir comment ça fonctionne. Mais est-ce la bonne façon de faire ? Il y a tellement d'exemples (et de contre-exemples) sur le web qu'il est difficile de départager les bonnes pratiques des mauvaises. Puis, on utilise de plus en plus le Javascript dans nos pages (MVVM, MVC) et il arrive un moment où nos connaissances du langage montrent leurs limites. La fondation n'est pas assez solide.

Avec la multiplication des frameworks pour le web, l'ascension du Javascript côté serveur, le Javascript isomorphique et même le Javascript au niveau du hardware, on ne peut plus vraiment s'en tirer sans comprendre les principes et le fonctionnement du langage. 

Dans ma longue et difficile quête du savoir en développement, j'ai décidé d'approfondir mes connaissances en Javascript par l'achat d'un livre. L'ouvrage suivant m'a donné beaucoup de "ahhhhhh, c'est comme ça que ça fonctionne !". Il s'agit du livre Professional Javascript for web developpers . J'avoue que ça ne se lit pas comme un roman de gare (certains chapitres sont un peu arides) mais personnellement, ca m'a permis de comprendre des aspects du langage que je ne maîtrisais pas pleinement. Le chapitre sur la programmation orientée-objet m'a beaucoup éclairé sur les possibilités mais aussi les pièges du Javascript.

Bref, je vous le recommande si vous souhaitez maîtriser et exploiter ce surprenant langage dont la popularité ne se dément pas.

 

L'officier dans la tranchée

Publié par Jean-Francois Gilbert le vendredi 5 juin 2015 à 00:00

Trench

THE PORTUGUESE ARMY ON THE WESTERN FRONT, 1917-1918, Imperial War Mueseum (http://www.iwm.org.uk/)

Récemment, j'ai eu une conversation intéressante avec un collègue à propos du rôle d'architecte organique. À son avis, l'architecte organique n'a pas besoin d'être au courant des détails d'implémentation, des dernières techniques ou frameworks. Bref, il n'a pas à "mettre les mains dans le code". Toujours selon lui, une bonne éducation à l'université, une solide compréhension de la programmation orientée-objet, des bases de données et d'UML suffisent pour faire la conception d'un système complexe. Il s'avère que je suis profondément en désaccord avec ces affirmations. Je vais illustrer mon point avec une analogie militaire.

Imaginez un instant que vous receviez les ordres d'un officier. C'est un grand stratège, mais ses derniers faits d'armes remontent à la guerre des Boers ! Il a fait ses preuves avec la cavalerie mais il ne connait rien à la guérilla urbaine et aux drones. Ou encore, il est au fait des avancées technologiques militaires mais il observe toutes les batailles terré dans son quartier général. Il vous a bien indiqué où se trouvent les ennemis et comment les vaincre, mais sa distance du champ de bataille ne lui donne pas la même perspective que vous de l'évolution du combat. De plus, il ne s'est jamais approché d'une tranchée ou tenu une arme dans ses mains.

D'un autre côté, vous avez un officier qui est avec vous dans les tranchées. Tous les jours il combat à vos côtés, sous la pluie, dans la boue, mangeant la même bouffe infecte. Il a utilisé les mêmes armes que vous, a connu la douleur et la peur.

Qui entre ces deux officiers a le plus de crédibilité aux yeux des troupes selon vous ? Qui entre ces deux officiers risque d'avoir le support de ses compagnons d'armes quand une décision difficile sera prise ?

Je sais, l'analogie n'est pas parfaite. En réalité, je crois que ça prend un mélange entre ces deux officiers. Il est important d'avoir un plan d'ensemble. Et le fait d'avoir une perspective différente de celle des développeurs peut s'avérer être un avantage. Cependant, on dit souvent que le diable est dans les détails. C'est tellement vrai en développement logiciel ! Un plan qui, de haut niveau, semble tenir la route peut être bousillé par une petite chose qui s'appelle "la réalité". Une réalité qui se présente sous la forme de problèmes d'intégration avec un système externe, de performances inadéquates, de l’apprentissage difficile d'une nouvelle technologie. Autrement dit, des problèmes qui surviennent au niveau microscopique, au niveau de l'implémentation. Un architecte organique fort techniquement sera en mesure de comprendre et solutionner ces problèmes. Ça lui donnera une valeur bien plus grande aux yeux de l'équipe et de l'organisation. 

Mots-Clés :

Lecture estivale pour Scrum Masters

Publié par Jean-Francois Gilbert le lundi 1 juin 2015 à 00:00

On dit souvent que les développeurs devraient s'évertuer à améliorer leurs techniques et approfondir leurs connaissances. C'est vrai, mais  ça l'est tout autant pour les Scrum Masters. Lire le guide Scrum ou recevoir une formation est un excellent point de départ, mais il faut comprendre que ce n'est qu'une base et qu'il reste beaucoup à apprendre. L'expérience sur le terrain comme Scrum Master vaut de l'or. Par contre, si elle n'est pas appuyée sur une solide fondation, le Scrum Master risque de ne pas exploiter au maximum les avantages que la méthode Scrum peut apporter à son équipe de développement.

Scrum, en tant que cadre de travail est relativement simple. L'agilité à l'origine de Scrum, mais qui également en découle, est un état d'esprit que les équipes ou même les Scrum Masters ne possèdent pas toujours. La méthode Scrum appliquée machinalement sans en comprendre le sens n'a que peu de chance de donner de véritables résultats.

Il existe heureusement une panoplie de ressources disponibles pour quiconque veut approfondir sa maîtrise de Scrum. L'été s'en vient et bien qu'il soit important de décrocher du boulot et de se changer les idées, c'est aussi un temps propice à l'apprentissage. Pourquoi ne pas profiter de la période estivale pour faire un peu de lecture et vous améliorer dans votre rôle de Scrum Master ?

Je me lance à moi-même ce petit défi. Pour ma part, j'ai décidé de relire un excellent bouquin paru en 2013 : Exploring Scrum : the Fundamentals. Bien qu'on retrouve le mot « fundamentals » dans le titre, les auteurs vont en profondeur et se basent sur des expériences concrètes. Le livre explore trois éléments fondamentaux du développement agile : les gens, le produit et les pratiques.

Si vous voulez des suggestions de livres sur le rôle de Scrum Master, sur Scrum ou l'agilité en générale, voici des listes qui vous inspireront peut-être :

Références agiles pour les coachs et Scrum Masters

5 books every Scrum Master should read

Top 100 agile books de Jurgen Appelo 

 

Archive