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?

La puissance des scénarios d’acceptation

Publié par David Beaumier le lundi 22 décembre 2014 à 13:08

Source: specflow.org

Récemment, j’avais comme tâche de préparer les scénarios d’essais pour un récit (User Story) que l’équipe devait réaliser. Il faut savoir que l’équipe utilise des scénarios basés sur la syntaxe Gherkin (avec l'outil SpecFlow) pour définir le comportement attendu de l’application. Le récit en question étant très simple (il concernait l’accès une fonctionnalité selon les permissions de l’utilisateur), je vous avoue que je me suis demandé avant de débuter si ça valait la peine d’écrire ces quelques scénarios. Dans le fond, il y a seulement deux cas possibles : l’utilisateur a accès ou non. Simple n'est-ce pas?

Et pourtant, dès que j’ai entamé la rédaction du premier scénario, les questions fonctionnelles se sont mises à surgir… Par exemple, comment réagir si l’utilisateur n’a pas de droit d’accès à la fonctionnalité : désactiver l’écran, le vider ou bien rediriger l’utilisateur vers la page principale du module? Devrait-on arrimer la structure des permissions de ce module avec le nouveau modèle maintenant utilisé dans l’application? Cela a rapidement suscité un échange avec les collègues sur ce qui est facilement faisable, sur les standards dans l’application pour ce type de cas et sur l’expérience utilisateur. Tout ça pour en venir à la meilleure option en fonction des critères d’acceptation du récit.

Évidemment, les discussions n’ont durées que quelques minutes. Comme on le dit en anglais, ce n’était pas du « rocket science »! Par contre, l’écriture de ces scénarios a permis de clarifier en amont plusieurs aspects qu’il aurait fallu éclaircir de toute façon. Nous avons pu le faire en amont, en prenant le temps nécessaire et en impliquant toutes les personnes concernées. L'introduction des scénarios d'acceptation dans le cycle de développement permet d'avoir ce genre de discussions (en général plus poussées, mais vous voyez le genre) et évite les attentes implicites inconnues de l'équipier qui implémente la fonctionnalité.

Et vous, utilisez-vous les scénarios d'acceptation dans votre équipe? Quels sont les principaux bénéfices que vous en retirez? Je vous invite à partager votre expérience avec nos lecteurs en utilisant la section commentaire ci-dessous.

D'autres billets qui pourraient vous intéresser

Pour aller plus loin

Si vous songez à introduire les scénarios d'acceptation dans votre équipe je vous suggère fortement la formation Tests d’acceptation: introduction à ATDD et au BDD. En plus d'introduire les concepts associés aux essais d'acceptation, cette formation vous permettra de prendre conscience des impacts que cette pratique pourrait avoir au sein de votre équipe et de votre organisation.

La valeur des actifs logiciels

Publié par David Beaumier le mercredi 26 novembre 2014 à 09:39

J’ai beaucoup apprécié l’allocution d’ouverture du dernier Agile Tour de Québec par Michael Feathers. J’ai trouvé qu’il abordait des aspects souvent négligés en développement logiciel. Une des choses qui m’a particulièrement accrochée c’est lorsqu’il a mentionné que les organisations devraient devenir plus consciente de la valeur et de l'état de leurs actifs logiciels.

Aujourd’hui combien d’organisation seraient en mesure de fonctionner normalement sans utiliser une solution logicielle? J’en connais bien peu. La plupart des organisations ont des besoins assez élaborés : outils de collaboration, suivi des opérations, relation clientèle, gestion financière, partage de fichiers, systèmes de téléphonie, etc. Qu’elles aient acquis et piloté un progiciel ou investi dans le développement d’une application sur mesure, des ressources importantes ont été engagées dans ces  solutions logicielles.

Malheureusement, la nature même d’un logiciel (ne dit-on pas justement software en anglais) vient fausser la perception que peuvent en avoir les différentes fonctions de l’organisation. En comptabilité on inclut les logiciels dans la catégorie des « actifs incorporels », aussi appelée « capital immatériel ». Bien qu’il existe des façons de déterminer la valeur financière courante de ces actifs, ça se corse lorsqu’il vient le temps de planifier les investissements futurs requis pour maintenir ceux-ci dans un état permettant d’apporter de la valeur à l’organisation.

Avouez que c’est plus simple de déterminer que l’entrepôt vaut 250 000$ et de prévoir un montant annuel pour couvrir les taxes foncières, les assurances, etc. Un gestionnaire attentif remarquera probablement aussi que la toiture commence à être endommagée et qu’il faudra envisager son remplacement d’ici 2-3 ans.

L'hypothèque logcielle

Est-ce que le même gestionnaire sera en mesure de se rendre compte que le moteur de base de données de son système d’expédition s’apprête à être dépassé en fonction du volume projeté des ventes des prochains mois? Est-ce que les parties prenantes ont pris la peine d’inclure la capacité du système dans leurs analyses?  Pas certain. En contrepartie, est-ce que l’équipe de développement a communiqué le vieillissement de la technologie? A-t-elle mis en place ce qu’il faut pour mesurer les performances du système en production?

HypothequeLogicielleLe jour ou le système deviendra si lent qu’il ne sera quasiment plus utilisable (sans doute pendant la période la plus active de l’année) est-ce que l’organisation aura le luxe de procéder à une mise à jour tout en douceur? L’équipe de développement pourrait devoir prendre certains raccourcis pour livrer rapidement une solution corrigée. C’est une approche tout à fait acceptable si elle permet à l’organiser de retrouver sa vitesse de croissance. Par contre, toutes les parties impliquées doivent être conscientes de l’hypothèque logicielle qui grève maintenant le système.

Prenons l’exemple du camion de livraison d’un marchand de meubles pour illustrer cette situation. Si ce marchand néglige l'entretien de son camion en évitant de procéder à un changement d’huile pour pouvoir effectuer plus de livraisons, il risque d’en payer le prix s’il ne planifie pas un autre moment pour faire cet entretien. Une panne lors d'une grosse journée de livraisons risque lui coûter cher et lui causer bien plus de souci qu’une période d’entretien planifiée.

Feathers a mentionné dans son allocution que certaines organisations rendent ces hypothèques visibles et incluent dans le plan de produit les activités requises pour s’en libérer. En procédant au remboursement, l’organisation réduit la possibilité de se retrouver dans une situation où sa dette logicielle l’empêche de saisir une opportunité d’affaires.

C'est, à mon avis, un devoir qu’ont les professionnels du développement logiciel de garder l'organisation dans son ensemble informée de l'état de leurs systèmes. L’information doit pouvoir remonter de l’équipe de développement jusqu’aux parties prenantes. Il faut travailler pour éviter les situations où un gestionnaire se fait dire un bon matin « Votre logiciel est désuet. Il faut le réécrire et on en a pour x mois et ça vous coûtera x centaines de milliers de $ ».  En même temps, les organisations doivent devenir plus sensibles à l’égard de leurs actifs logiciels, poser des questions aux équipes et prévoir un plan pour limiter le gonflement de l’hypothèque logiciel. 

Pour en savoir plus

D'autres billets sur le même thème

L'impact positif d'une certification PSM

Publié par Vincent Crépin le mercredi 6 juin 2012 à 06:30

J'ai participé dans les dernières années à l'implantation progressive de techniques agiles chez un de mes clients. Nous avons débuté tranquillement en décidant d'utiliser Scrum pour la réalisation de certains projets. Progressivement, l'idée a fait son chemin et maintenant, la plupart des nouveaux projets se réalisent en utilisant Scrum. Je suis très satisfait du chemin parcouru. L'équipe qui a été mise en place se familiarise de plus en plus avec les concepts agiles et en comprend maintenant les bénéfices principaux. Le chemin parcouru est attribuable à la bonne volonté des membres de l'équipe qui ont accepté d'embrasser de nouvelles méthodes et se sont formés « sur le tas » afin d'approfondir leurs connaissances. Malgré tout cela, un cadre de travail aussi simple soit il (Scrum) comporte son lot de pièges et d'astuces qui n'étaient pas nécessairement connus des membres de l'équipe puisque personne ne possédait les bases théoriques nécessaires.

Récemment, 2 membres de l'équipe (des employés permanents chez mon client) ont décidé de leur propre initiative de suivre la formation Professional Scrum Master (PSM). Les impacts de cette décision sont considérables. Depuis quelques semaines, de nombreux ajustements ont été apportés par ces personnes (la Scrum Master et la Propriétaire de produit) qui possèdent maintenant de très solides bases théoriques sur Scrum. Elles ont entre autres modifié la façon de conduire les réunions quotidiennes, la teneur des rencontres de rétroaction et les rencontres de planification. Le tout est maintenant beaucoup plus efficace et l'équipe se fait ramener constamment dans le droit chemin afin qu'aucun temps ne se perde inutilement.

Alors bravo à ces personnes pour leur initiative très profitable à leur entreprise!

Archive