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.

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.

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?

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 

 

Faire le double en moitié moins de temps avec Scrum

Publié par David Beaumier le mardi 3 février 2015 à 18:31

Scrum TwicetheworkhalftimeJ'ai récemment terminé la lecture du plus récent livre de Jeff Sutherland, le co-créateur de Scrum, s'intitulant Scrum: The Art of Doing Twice the Work in Half the Time. L'objectif avoué de Jeff Sutherland avec la publication de ce livre est de faire rayonner Scrum à l'extérieur du secteur des TI et du développement logiciel en particulier. Celui-ci s'adresse donc à des gestionnaires et leaders de tous les horizons. Personnellement, j'ai trouvé qu'il avait atteint son objectif. Il ne peut faire abstraction des succès de Scrum dans le monde du développement logiciel, mais il présente beaucoup d'exemples d'organisations oeuvrant dans d'autres secteurs d'activités qui appliquent Scrum. On voit clairement que Scrum a sa place dans les organisations modernes, particulièrement celles qui font face à des défis créatifs et qui doivent affronter l'incertitude (que ce soit face au marché ou au développement du produit/service lui-même).

D'entrée de jeu, sachez que ce n'est pas un livre pour apprendre comment mettre Scrum en application, il en existe déjà plusieurs qui sont excellents. C'est plutôt un livre qui présente les bénéfices qu'une organisation peut retirer en mettant Scrum en action. Et ça, je trouve que ce livre le fait merveilleusement bien. Jeff Sutherland a écrit ce livre en collaboration avec son fils, un ancien du réseau radiophonique NPR, ce qui n'est sans doute pas étranger au style d'écriture simple, direct et très imagé qu'on y retrouve.

Bien que je ne fasse pas, à priori, parti du public cible du livre, j'ai eu beaucoup de plaisir à le lire. Après plus d'une décennie à mettre en oeuvre les pratiques Agiles et Scrum en particulier, j'ai trouvé cette lecture rafraîchissante et motivante. On s'éloigne parfois de l'essence de Scrum en le pratiquant au quotidien et les aspects mécaniques (telles que les cérémonies ou les artéfacts) peuvent finir par prendre le dessus sur les principes. Parce qu'il doit prouver son affirmation (le double de travail en la moitié moins de temps), Sutherland revient sur les fondements de Scrum et il met l'emphase sur les aspects qui font de Scrum un cadre de travail capable de rendre les individus et les équipes performants: la dynamique des équipes, l'importance accordée au temps, la réduction des gaspillages (sous toutes leurs formes), la visibilité sur la réalité et la gestion des priorités.

Cette lecture m'a aussi permis de prendre conscience de l'arrimage qui existe entre Scrum et le mouvement Lean. À maintes reprises, Sutherland démontre comment tel ou tel aspect de Scrum vient mettre en oeuvre un des principe du Lean. Il consacre même un chapitre entier à l'élimination des gaspillages, un fer de lance du mouvement Lean. Est-ce une stratégie pour favoriser un rapprochement de Scrum avec la communauté Lean et Kanban alors qu'il y a souvent eu des tensions entre ces deux groupes, souvent vu en opposition l'un à l'autre? Je ne sais trop, mais j'ai personnellement bien apprécié qu'on me présente la complémentarité des deux approches.

C'est donc une lecture que je vous recommande même si vous oeuvrez en développement logiciel et ce, quel que soit votre rôle. Je la recommande aussi fortement à tout gestionnaire, peu importe son secteur d'activité. N'hésitez donc pas l'offrir en cadeau à votre patron ou à le laisser traîner dans un endroit stratégique de vos bureaux. Je peux vous affirmer que la couverture attirera l'attention de beaucoup de gens (autant par sa couleur que son titre)!

En terminant, je vous propose cette vidéo d'une quinzaine de minutes où Jeff Sutherland présente plusieurs des éléments qu'il aborde en détail dans son livre.

D'autres billets qui pourraient vous intéresser

Le fléau des cadres agiles

Publié par Philippe Tremblay le mardi 2 septembre 2014 à 13:00

Récemment, Jurgen Appelo exprimait son désarroi face à l’infestation de cadres et méthodologies « agiles » dans le domaine des TI.  La détresse de son appel s’appuie sur l’argumentaire que les cadres tels Scrum, XP, SAFe, DAD et autres acronymes « fastfood »  de notre industrie représentent une prescription de pratiques et de principes qui ne font que diminuer les chances de succès des initiatives de changements.  Puisque chaque contexte requiert son adaptation.

M. Appelo a probablement raison sur l’effet que peuvent avoir les cadres et méthodologies (agiles ou non).  Bien trop souvent, les individus considèrent ces cadres comme des processus et croient que, lorsque bien exécutés, ces processus mèneront aux bénéfices espérés.  Ces attentes et cette perception précipitent invariablement l’organisation vers une approche méthodique plutôt que la démarche empirique nécessaire à transformer un domaine où l’adaptation est gage de succès!

Les cadres agiles ne sont pas ce qui empêche le succès des transitions tentées par les organisations.  Au contraire!  Si les individus ont peine à comprendre, mesurer et adapter les principes ainsi que les pratiques proposées par un cadre, imaginez s’ils devaient le faire à partir de l’ensemble des possibilités d’une transition agile!  Les chances de succès seraient encore plus minces.

« Feel free to ignore the frameworks, but please do consider the practices! » -- Jurgen Appelo

Je suis d’accord avec M. Appelo sur le fait que nous devons absolument favoriser la compréhension et l’adaptation des pratiques derrière les cadres agiles.  Par contre, ce serait une erreur d’ignorer les cadres existants par crainte que leurs utilisations soient déficientes!

Mots-Clés :

Archive