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?

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 :

Une roche dans le soulier

Publié par Jean-Francois Gilbert le jeudi 23 avril 2015 à 00:00

Course

Vous courez depuis un bon moment déjà et vous avez atteint votre vitesse de croisière. L'endorphine et le vent chaud du printemps provoquent en vous une douce euphorie. Tout va bien, vous filez le parfait bonheur! Soudain, vous la sentez vous piquer. Une petite roche s'est glissée dans votre soulier, puis à l'intérieur de votre bas. Au début, vous la remarquez à peine. Mais après un moment, l'inconfort fait place à la douleur. Vous pourriez décider de l'endurer et de continuer à courir. Après tout, vous avez la moitié du chemin de parcouru. Mais vous savez que la roche risque de vous couper. En modifiant un peu votre foulée, vous vous rendez compte que la roche se fait plus discrète. Cependant, après quelques kilomètres de plus, votre démarche inhabituelle créé une douleur musculaire pire que celle causée par la roche ! Parfois, la seule idée de prendre une pause de 2 minutes pour détacher notre soulier, retirer le bas et enlever le caillou nous horripile. Le rythme est bon, il ne faut surtout pas s'arrêter de courir ! Pourtant, on risque une blessure qui va nous ralentir encore plus.

Je vois souvent le même comportement dans des équipes de développement logiciel. On accumule de la dette technique. Le build fonctionne une fois sur deux. Des tests intégrés sont instables et on commence à les ignorer sans essayer de comprendre la cause du problème. Comme le coureur, l'équipe risque d'en souffrir beaucoup plus à long terme. Les tests n'étant plus fiables, on ignorera des symptômes évidents et la stabilité du logiciel s'en ressentira. Parfois ce sont des problèmes humains : l'ambiance dans l'équipe n'est plus bonne ou encore on accepte sans rien dire des comportements néfastes.

Ce n'est pas toujours plaisant de faire une pause dans le développement. Parfois on subit beaucoup de pression de nos supérieurs pour soutenir la cadence. Mais il faut vraiment le faire lorsque ça devient nécessaire. Les problèmes se règlent rarement d'eux-mêmes et il ne faut pas attendre que ça fasse mal pour s'y attarder. La rétrospective du sprint est le moment tout indiqué pour mettre en lumière les problèmes à corriger. On a souvent tendance à faire cet exercice un peu vite et à la légère. Il n'y a pourtant pas de meilleur moment pour discuter des embûches, que lorsque toute l'équipe est présente. C'est l'occasion de se questionner en tant qu'équipe et de relever les points agaçants qui vous empêchent de bien travailler. 

Une fois les irritants énumérés, c'est le moment de passer à l'action afin de les éliminer. À mon avis, ces actions devraient se retrouver dans le carnet du sprint autant que possible. Il faut les rendre visibles, les prioriser et les attaquer rapidement. L'équipe devrait s'engager à régler les problèmes de la même façon qu'elle s'engage à livrer de la valeur au client. Autrement, après quelques sprints une vilaine roche risque de réduire la capacité de l'équipe à satisfaire le client.

D'autres billets qui pourraient vous intéresser

 

Agile comme un enfant

Publié par Marc Allard le mardi 14 avril 2015 à 08:12

Quand il était responsable de l’«expérience des usagers» chez Palm, l’entreprise pionnière de l’ordinateur de poche, Peter Skillman a inventé un exercice de design surnommé le «challenge de la guimauve». Le défi consiste à bâtir la plus haute tour possible avec 20 spaghettis, un mètre de ruban adhésif et un bout de ficelle. Les participants disposent de 18 minutes pour construire la tour, sur laquelle ils doivent être capables de faire tenir une guimauve. 

Durant cinq ans, au début des années 2000, Skillman a observé des tas de groupes, divisés en équipes de quatre, se livrer à l’exercice. Il a notamment réuni des ingénieurs en télécoms taïwanais, des étudiants en administration et des enfants de la maternelle. Sans trop de surprise, les ingénieurs se sont distingués et les étudiants en administration se sont plantés. 

Mais devinez qui a fait mieux que tout le monde? Les enfants, qui ont réussi à bâtir une tour de 1 pouce plus élevé que les ingénieurs.

Skillman a raconté cette anecdote lors d’une présentation filmée qu’il a donnée dans une conférence sur la création technologique en 2007. Dans la salle se trouvait Megan McCardle. Cette journaliste, auteure et ex-étudiante en administration a écrit un livre publié en 2014 intitulé «The Up Side of Down», dans lequel elle entame son premier chapitre en revenant sur le challenge de la guimauve.

Comment les enfants ont-ils réussi à battre les ingénieurs ? nous demande McCardle. «Par le simple processus de l’expérimentation et de l’itération, écrit-elle. Ils ne se sont pas laissé freiner par des assomptions sur les règles du jeu — ils ont été le seul groupe à demander plus de spaghetti. Et parce qu’ils avaient plus de spaghettis, ils n’ont pas eu à perdre du temps à réfléchir au look de la tour ou à qui devrait écrire l’énoncé de vision. Ils se sont juste lancés et ont commencé à créer, laissant de côté tout ce qui ne marchait pas.» 

D’une certain façon, les enfants se sont montrés très agiles. Ils ont épousé la philosophie du kaïzen, cette pratique japonaise de l'amélioration en continu qui mise sur de petits changements fréquents plutôt qu’une longue planification élaborée à partir d’une idée unique. Quand on y pense, les jeunes enfants sont des adeptes naturels du kaïzen. Avant de comprendre le langage, les bébés sont l’incarnation même de l’amélioration en continu, se développant essentiellement à coups d’essais et d’erreurs. Les tout-petits bénéficient des enseignements de leurs parents, mais leur inclinaison pour l’expérimentation reste intacte, comme en témoignent tant de traces de crayon-feutre sur des murs blancs. 

En fait, cette inclinaison ne s’effrite qu’à mesure où les enfants commencent à craindre ce qui n’effrayait pas encore trop nos champions de la tour en spaghetti : la peur de l’échec.

The Up Side Of DownComme l’explique Megan McCardle, dans la vie ou au travail, c’est souvent cette peur qui est le plus gros obstacle à l’amélioration. Or, le challenge de la guimauve le montre bien : «si tu n’as pas beaucoup de temps de devant toi, le plus important c’est que tu échoues», dit Skillman à son audience. «Tu échoues plus tôt pour pouvoir réussir plus rapidement». L’essai/erreur est le style naturel d’apprentissage du cerveau, qui forge des connexions efficaces une fois qu’il a éliminé toutes celles qui ne le sont pas, explique McCardle.

J’ai lu quelque part qu’un génie, c’est quelqu’un qui déjà a commis toutes les erreurs. Bien sûr, précise McCardle, il ne s’agit pas d’échouer pour le plaisir d’échouer ou de prendre des risques inconsidérés. L’idée est de prendre beaucoup de petits risques calculés, parce que ça reste la seule façon de voir ce qui fonctionne vraiment. 

C’est ce qui j’ai essayé récemment avec ma fille de 4 ans, qui n’arrivait pas à zipper son manteau. Durant une semaine, je lui ai laissé le temps chaque matin d’essayer de le faire toute seule. Ensemble, on a pris le risque qu’elle s’impatiente et se fâche et qu’on arrive beaucoup plus tard à la garderie — ce qui est effectivement arrivé. Mais au bout d’une semaine, à force d’essais et d’erreurs, elle a compris le fonctionnement du zipper et, depuis, c’est un dossier clos! 

La semaine prochaine, je pense qu’elle sera mûre pour la tour de spaghettis.

D'autres billets qui pourraient vous intéresser

 

Archive