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.

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 

 

 

Agile comme un enfant, 2eme partie

Publié par Marc Allard le mardi 5 mai 2015 à 12:39

Enfants

La Anderson School, à New York, est une école pour les enfants surdoués. Même pour être admis à la maternelle, les jeunes candidats doivent se farcir deux tests d’intelligence et l’institution ne retient que ceux qui se classent dans le top 4 %.

Il y a quelques années, j’ai lu un reportage qui s’amorçait avec l’histoire de Thomas, un élève de cinquième année de cette école ultra-compétitive. Thomas avait éclipsé la concurrence à l’épreuve d’admission. Même dans le top 1% des candidats, il avait obtenu un des meilleurs scores. 

Le gamin savait qu’il était intelligent. Question de renforcer son estime de soi, ses parents et son entourage lui avaient répété depuis tout jeune à quel point il était «smart». Avec un tel cerveau athlétique et des éloges à répétition, on se serait imaginé que Thomas allait déborder de confiance en soi, s’attaquant sans peur à la matière scolaire qui se trouverait sur son chemin.

Mais non. Son père observait le contraire : «Thomas ne voulait pas essayer des choses où il ne réussirait pas. Certaines choses lui venaient très rapidement, mais quand ce n’était pas le cas, il abandonnait presque aussitôt, se disant "je ne suis pas bon dans ça"».

Dans mon dernier billet, je vous parlais d’un groupe d’élèves de la maternelle qui avait réussi à battre des ingénieurs chevronnés à un défi de construction d’une tour de spaghettis. J'expliquais cet étonnant résultat en pointant, à l’image du livre de la journaliste Megan McCardle, le principal responsable : la peur de l’échec (et son meilleur ami, la peur du risque). Vous avez été plusieurs à réagir et à vous demander si cette peur n’avait pas quelque chose à voir avec notre système d’éducation?

L’histoire du petit Thomas est révélatrice à cet égard. Ce n’est pas tant le système d’éducation que les éloges constants à propos de son intelligence qui l’ont rendu aussi effrayé d’échouer.

Au Québec, les enfants reçoivent, comme leurs voisins américains, de constants éloges. La plupart des parents ont le réflexe du «Bravo, mon champion» très généreux, même quand ce n’est pas mérité. C’est la même chose à la garderie, à l’école ou dans l’équipe de soccer : il n’est pas rare que tout le monde ait droit à un collant ou à une médaille, peu importe le résultat.

Or, il s’avère que ces éloges continuels nuisent plus aux enfants qu’ils ne les aident. Carol Dweck, psychologue à l’Université Stanford, aux États-Unis, a consacré l’essentiel de sa carrière à cette question. Dans une de ses expériences les plus célèbres, elle a testé l’effet de deux types d’éloge auprès de 400 élèves de 5e année d’une école primaire régulière de New York. Après avoir effectué un casse-tête plutôt facile, la moitié du groupe s’est fait complimenter sur son intelligence («you must be really smart at this») et l’autre s’est fait complimenter sur son effort («you must have worked really hard». Ensuite, l’équipe de Carol Dweck a demandé aux mêmes élèves de choisir entre deux nouveaux tests : un plus difficile, où ils auraient l’occasion d’apprendre, et un autre plus facile, comme le premier. Parmi le groupe qui s’était fait louanger pour son effort, 90% ont choisi le test difficile, et parmi le groupe louangé pour son intelligence, la majorité a choisi le test facile.

«Quand on félicite un enfant pour son intelligence, on lui dit que c’est comme ça que ça fonctionne dans la vie : aie l’air intelligent, ne risque pas de faire des erreurs», écrit Dweck dans le résumé de sa recherche

Dans son livre Mindset, traduit en français en 2010, la professeure explique qu’il y a deux façons de voir ses habiletés : avec un état d’esprit «fixe» (fixed mindset) ou un état d’esprit «de développement» ou «incrémental» (growth mindset). Thomas, qui avait un état d’esprit fixe, était convaincu qu’il y avait deux sortes de défis : ceux où il était naturellement bon, et ceux où il ne l’était pas — donc pas la peine d’essayer.  Les jeunes champions de la tour de spaghettis, eux, se disaient que chaque tour qui s’écroulait était une occasion d’apprendre à coiffer des ingénieurs. 

Je vous laisse deviner dans quel état d’esprit l’agilité peut fleurir... 

D'autres billets qui pourraient vous intéresser

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

 

L’engagement : Un des piliers de votre transition agile

Publié par Philippe Tremblay le vendredi 7 février 2014 à 11:00

L’engagement des employés est au cœur du succès des entreprises depuis très longtemps.  C’est l’une des caractéristiques qui se dégage de la réussite de Toyota et son système Lean.  Les valeurs et principes agiles sont eux aussi étroitement liés à l’engagement des employés.  En fait, la relation est telle qu’il est difficile d’identifier la cause et l’effet lorsqu’on parle d’engagement et d’adoption agile.  Est-ce l’engagement des employés qui permet de réussir   la transition ou plutôt l’adoption des principes agiles qui favorise l’engagement des employées?  Explorons tout d’abord l’effet de l’engagement des employés sur une adoption agile.

La courbe d’adoption

L’adoption des principes agiles dans une organisation demande un effort soutenu et une persévérance pratiquement sans limites afin d’introduire un changement durable dans les façons de faire (les pratiques) et d’être (la culture) de l’organisation.  Une analogie représentant bien ce parcours de transformation agile est celle de la courbe d’adoption des technologies présentée par Geoffrey A. Moore dans son livre Crossing the Chasm.

 Crossing +the +Chasm +-+Intel +IT+Center

Lors d’une adoption agile, le rythme de progression au départ est généralement rapide puisque les petites victoires apparaissent dès que certains principes de base sont appliqués.  Bien qu’encore embryonnaire en début de transition, les principes tels l’auto-organisation et la communication face à face pointe habituellement leurs bénéfices à la surface du statuquo assez rapidement.  De plus, les organisations débutent souvent l’adoption sous forme de projet pilote ou en canalisant les apprentissages de l’approche empirique à un sous-groupe de l’entreprise.  Ce qui a pour effet de mettre sous la loupe l’apparition de bénéfices… et des défis.

Après un certain temps, l’adoption des principes et valeurs agiles est confrontée aux diverses difficultés d’un tel changement.  Que ce soit la culture, les pratiques existantes (souvent implicites), les enjeux personnels ou tout simplement les défis techniques, la vitesse de progression n’est définitivement plus la même.  C’est ici que le parallèle au « Chasm » (gouffre) prend tout son sens.  Pour traverser ce gouffre, vous devrez équiper votre initiative d’un nombre plus substantiel de « visionnaires » et pour ce faire, le niveau d’engagement que vous avez su (ou saurez) créer représentera le secret de votre succès.  Cette étape critique pourrait bien être le point où le vent tourne, le moment où ce sera la façon de faire traditionnelle qui commencera à être vue comme « étrange » et moins fréquemment les pratiques agiles.

Agile comme catalyseur de l’engagement

Il est à la fois très difficile et assez simple de stimuler l’engagement dans une organisation.  La difficulté est souvent causée par les pratiques développées dans les organisations lors de leurs croissances.  Ces pratiques parfois explicites par des règles, des processus sont maintes fois beaucoup plus implicites.  Implicite de par les interactions informelles entre les individus, les « façons de faire les choses » qui ont émergé pour contourner les dysfonctions du système ou la perte du sentiment d’accomplissement dans le travail des gens causée par la surspécialisation et la division du travail.

La simplicité des éléments propulseurs d’engagement est parfois désarmante pour les organisations.  Elle l’est encore plus lorsque ces éléments sont mis en relation avec la complexité des défis mentionnés ci-haut.  Une adoption progressive et adaptée des principes Lean et Agile suscitera indéniablement l’engagement présent de la part des gens d’une organisation.  Voici quelques-uns des principes à l’œuvre dans ce « mécanisme humain » :

  • Amélioration continue : Augmente le sentiment d’accomplissement et de maitrise de sa profession
  • Respect pour les gens : Responsabilisation et implication directe dans les résultats de l’entreprise
  • Travail d’équipe : Favorise le développement des gens et l’apprentissage exponentiel par l’échange continu et ouvert des membres d’équipe
  • Collaboration avec les clients : Rends très explicite la contribution du travail des gens dans la satisfaction du client
  • Philosophie long terme : Augmente le sentiment d’appartenance, car les décisions d’aujourd’hui ne sont pas prises au détriment des intérêts long terme de l’organisation et de ses gens
  • Améliorer la source des problèmes : Aucun diachylon n’est posé sur les symptômes.  Les gens savent qu’ils peuvent soulever des problèmes et que ceux-ci seront adressés, améliorés

Voici un autre billet présentant un rapport sur les facteurs qui influencent l’engagement dans les organisations ainsi qu'une série de recommandations pour propulser l'engagement des individus.

Archive