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.

Agile 2015: Nos impressions et les tendances (partie 1/3)

Publié le mercredi 16 septembre 2015 à 08:00

Agile2015

À la fin du mois d’août, Pascal et Félix-Antoine sont allés à la plus grande conférence mondiale sur l’Agilité: Agile 2015 à Washington D.C.

Ils y sont allés pour apprendre, ramener les réponses des plus grands noms aux questions de nos clients, mais surtout pour voir ce qui émerge et y déceler quelques tendances.

Voici donc nos impressions… Évidemment, ceci est notre interprétation, nos hypothèses! Pour des résumés factuels, consultez nos résumés.

 

Le Craftsmanship

La première chose qui nous a frappés est une réémergence du mouvement “Craftsmanship” au sein de la conférence et le thème n’était pas cantonné aux conférences techniques.

Des conférences de coaching ou d’affaires soulignent le fait que, sans une solide compétence technique, toutes les améliorations de gestion ou d’équipes finiront par être un coup d’épée dans l’eau. Certains pionniers comme Robert. C. Martin ou Martin Fowler en ont fait leur cheval de bataille depuis quelques années. Ce qui est plus étonnant, c’est de voir le message se répandre dans la bouche d’acteurs qui ne sont pas associés à eXtreme Programming (XP).

Le message: il faut donc travailler sur le savoir-faire des personnes techniques au même titre que sur l’accompagnement des Scrum Master, gestionnaires, PO, etc. L’Agilité est un tout.

Nous avons assisté à plusieurs conférences sur le sujet et nos résumés sont disponibles.

 

Lean: digestion terminée

Alors qu’ici Lean est à la mode, les conférenciers d’Agile 2015 semblent en avoir terminé avec la digestion. Non pas que l’Agilité abandonne ce rapprochement, bien au contraire! Lean semble avoir été absorbé dans le mouvement et chaque conférence, même technique, reprend des termes et l’essence de Lean sans sentir le besoin d’y dédier de nombreuses présentations particulières.

Notre interprétation est que contrairement à ce que l’on constate ici, il semble que Lean ne soit plus vu comme un concept de gestion, mais plutôt comme des principes valables à tous les niveaux.

 

À suivre...

>> Billet 2 (BDD, Story Mapping et UX)
>> Billet 3 (Valeurs agiles, Excellence technique et Jeux)

Démystifier les rôles Scrum

Publié par David Beaumier le lundi 7 septembre 2015 à 15:48

L’équipe de l’Alliance Scrum a publié au début de l’été un article de référence intitulé Scrum Roles Demystified. J’ai trouvé que cet article présentait fort bien l’essence des trois principaux rôles que l’on retrouve dans le cadre de travail Scrum. Avec l’accord de l’Alliance, je vous propose un résumé de cet article afin d'en faire profiter l’ensemble de la communauté Agile francophone.

Pour les organisations et les équipes qui sont peu familières avec Scrum il est parfois difficile de bien saisir les responsabilités associées aux rôles Scrum. Les trois rôles n’ont pas nécessairement d’équivalents directs dans les approches traditionnelles. Il peut aussi arriver que l’on associe, à tort, certains des rôles avec ceux que l’on retrouve habituellement dans les projets. L'article de Scrum Alliance, et le présent résumé, se veulent donc une façon de clarifier l’essence de chacun de ces rôles.

Scrumroles Infographic FR

Le Product Owner

Le Product Owner (nommé tel quel dans la version française du guide Scrum) est la pierre angulaire du succès d’un projet ou d’un produit. Non seulement est-il responsable de déterminer ce qui doit être fait, mais il se doit de pouvoir démontrer pourquoi ces éléments sont importants et prioritaires. Sa responsabilité va donc bien au-delà d’une simple gestion du carnet de produit.

Dans le cadre Scrum le Product Owner demeure activement impliqué pour la durée complète des travaux. Il s’assure de la cohérence du travail réalisé par rapport aux objectifs d’affaires recherchés. Il est à l’écoute des rétroactions provenant du secteur affaires autant que de celles provenant de l’équipe de développement et apporte les ajustements nécessaires au carnet.

Notez que j'ai choisi le terme fiduciaire car souvent le Product Owner n'est pas réellement le propriétaire du produit à proprement parler. Les parties prenantes (ou fiduciants) lui délègue l'autorité requise pour bâtir le produit, mais ceux-ci demeurent les propriétaires et peuvent prendre action en conséquence.

L’équipe de développement

Une équipe de développement Scrum est habituellement composée de 5 à 9 personnes. Ce groupe possède collectivement les compétences requises pour mener à bien les travaux, avec le soutien du ScrumMaster. Comme Scrum permet le développement de produits de nature très variée, l’expertise de chacun des équipiers peut varier grandement d’une équipe à l’autre.

L’équipe de développement possède un haut degré d’autonomie afin de déterminer comment doivent être réalisés les travaux priorisés par le Product Owner. Cette autonomie vise à créer un solide esprit d’équipe, à développer le travail collaboratif et l’atteinte d’objectifs communs.

Le ScrumMaster

Le ScrumMaster agit sur deux axes principaux. Premièrement, il veille à ce que tous les membres de l’équipe, spécialement ceux de l’équipe de développement, puissent se concentrer sur les travaux. Il aide l’équipe à résoudre les éléments bloquants qu’elle rencontre et la protège des distractions qui pourraient surgir en cours de route.

De par sa connaissance approfondie de Scrum il veille également à l’application du cadre de travail dans l’équipe. Il guide l’équipe à travers les défis associés à l’application de Scrum. Il appui la personne exerçant le rôle de Product Owner afin de l’aider à tirer le maximum de Scrum.

La synergie

C’est la complémentarité qui existe entre les rôles du Product Owner, de l’équipe de développement et du Scrum Master qui permet d’atteindre les résultats exceptionnels que produisent les équipes Scrum. Il est essentiel de soutenir chacun de ces rôles lorsqu’une organisation met en oeuvre Scrum.

Conclusion

Je vous invite à lire l'article orginalement publié en anglais car il contient plusieurs précisions additionnelles qui, je crois, pourront vous aider à bien cerner les subtilités de chacun des rôles.

Aussi, il n’est pas toujours facile d’adapter du contenu anglophone vers une autre langue tout en en préservant le sens original. Surtout lorsqu’on souhaite que les termes utilisés soient appropriés pour les lecteurs des deux côtés de l’Atlantique (et ailleurs aussi). N’hésitez-pas à laisser un commentaire ci-dessous si vous avez des suggestions linguistiques à faire.

* Le matériel original est une propriété de Scrum Alliance et adapté avec permission.

Les résumés d'Agile 2015

Publié le dimanche 23 août 2015 à 00:00

Agile2015

Du 3 au 7 août se déroulait à Washington D.C. la conférence annuelle Agile 2015. Nos collègues Félix-Antoine et Pascal y étaient. À chaud, pendant l'événement, ils ont résumé plusieurs des conférences auxquelles ils ont assisté.

Si vous étiez en vacances et que vous avez raté cela, voici une liste de tous leurs résumés. C'est notre façon de partager avec vous notre passion pour le génie logiciel et l'Agilité.

Notez que nos deux ambassadeurs vont publier dans les prochaines semaines leurs impressions personnelles et ce qu'ils retiennent comme tendance après leur passage au coeur de la communauté. Restez à l'écoute!

Bonne lecture!

 

Professionnalisme et gestion de la dette technique

 

 

Besoin d'affaires, fonctionnalités et User Stories 

 

 

Entreprise et équipes

  

  

Coaching et transition

 

 

Technique 

 

 

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?

Archive