Tuesday, December 1, 2015

Résumé de l'activité Formation TDD

Le 25 novembre 2015, il y a eu  l'activité  «TDD (Test Driven Development)» ou plus précisément «Les bases de DGT (Développement Guidé par les Tests)».  L'activité a été réalisée dans les locaux de SherWeb.

Le but principal de l'activité fut de présenter, le plus simplement possible, comment effectuer un Développement Guidé par les Tests.

La présentation a été subdivisée en 6 sections :

1. Activité 1. La qualité dans un développement logiciel.

2. Définition de DGT.

3. DGT et l'eXtreme Programming.

4. Activité 2 L'application de DGT

5. Activité 3 Rétroaction sur DGT

6 Une Conclusion

Dans l'activité 1, nous avons constaté que tous les participants font face à des bogues. Ceci ne fut pas une surprise, mais soulève une question: comment éviter les bogues ? Cette question resta pratiquement sans réponse, mais quelques-uns ont répondu timidement «Avec les tests».

Nous avons poursuivi la présentation par l'énoncé de la "définition classique de DGT", qui fut présentée selon le cycle suivant :

1. Rouge: Écriture d'un test qui échoue.

2. Vert: Écriture d'un code afin que le test passe.

3. Réusinage: Remanier le code afin qu'il soit de qualité sans briser les tests.

Cette étape nous a permis d'établir un lexique commun et faciliter la compréhension des points subséquents de la présentation.  Par la suite, nous avons discuté de XP (eXtreme Programming) qui a permis l'introduction du DGT, ainsi qu'énoncé que l'instigateur du DGT a également participé à la création du manifeste Agile.

L'activité 2 était le cœur de la présentation. La première question qui se pose est de savoir par où commencer pour appliquer le DGT? Puis comme pour tout développement logiciel, répondre aux questions: quoi faire? et comment le faire?

D'abord, une phase d'analyse (rapide) est nécessaire pour trouver les classes et leurs responsabilités requises. Ensuite, on applique le DGT.

Nous avons présenté un exemple très simple en utilisant une classe Contact, contenant les informations d'une personne, et une autre classe nommée Contacts, servant à la gestion d'une liste de contacts.

Nous avons débuté par une revue des premières étapes de création d'un projet Java en Eclipse (ajout de packages et classes). Puis poursuivi par l'intégration d'une classe de tests pour chaque classe de développements. Une classe TestExemple a été ajoutée au projet pour introduire les asserts : assertEquals, assertFalse et assertTrue (qui sont des méthodes de l'API  JUnit). Tel que stipulé dans le cycle de DGT, nous avons commencé par l'implémentation de tests qui échouent,  pour passer ensuite à la correction des assertions afin que les tests passent. 

L'exécution de tests avec Eclipse et JUnit a été illustrée, en démontrant comment faire passer la barre rouge (échec des tests), à la barre verte (réussite des tests). Ce qui consiste à présenter la mécanique de base pour effectuer un test et la démarche à suivre afin qu'il passe.


Nous avons poursuivi par un aperçu de la couverture des tests avec l'outil EclEmma, soit: comment le lancer, comment obtenir le pourcentage de couverture et comment interpréter la couverture des chemins d'exécution.

Ensuite, de façon interactive, nous avons débuté l'écriture de tests dans la classe TestContact, afin de vérifier le bon fonctionnement du constructeur de la classe Contact. Pour ensuite, programmer le constructeur de la classe afin que les tests passent.


Enfin, nous avons réalisé l'activité 3, qui fut de lancer une discussion sur les trois points suivants :

1. Quelle est votre réaction sur DGT (TDD)?

2. Restera-t-il des bogues si DGT (TDD) est appliqué aux développements?

3. Y aurait-il des obstacles à prévoir si le DGT (TDD) était à implanter dans votre équipe?


Pour conclure, la présentation sur le DGT se termina par l'énoncé des points suivants  :

1. Le plus difficile est de commencer.

2. Il faut le pratiquer pour se convertir.

3. La pratique va augmenter la qualité des logiciels.

Merci à tous pour votre participation active et contribution à la communauté Agile de Sherbrooke!

Ruben Gonzalez-Rubio et Eugène Morin
G enie electrique et g enie informatique
Groupe Xit
Université de Sherbrooke
ruben.gonzalez-rubio@usherbrooke.ca
eugene.morin@usherbrooke.ca

Tuesday, October 6, 2015

La rétrospective - Agile Sherbrooke

Le 30 septembre se déroulait l'activité "La rétrospective Agile" organisée par Agile Sherbrooke dans les locaux de l'Université de Sherbrooke.  Durant cette activité, les participants on pu vivre une cérémonie classique du Scrum, la rétrospective.

La rétrospective est une occasion pour les équipes Agiles de s'inspecter et de créer un plan d'amélioration qui sera mis en place au cours de la prochaine itération de l'équipe. Elle est habituellement tenue à la fin de chaque itération, avant la prochaine réunion de planification d'iteration.  Contrairement au post-mortem de projet qui se déroule seulement à la fin du projet, la rétrospective s'effectue à des intervalles réguliers tout au long du projet.  L'équipe peut donc bénéficier immédiatement des améliorations apportées.

Il existe une grande variété d'activités de rétrospectives parmi lesquelles l'équipe peut choisir.  Afin de garder l'équipe vigilante d'une rétrospective à l'autre, il est fortement recommandé de varier la méthode régulièrement.  Le site Agile Retrospective Resource Wiki est une bonne ressource pour en découvrir des nouvelles.  L'activité qui a été proposée durant la rencontre est un hybride de la méthode des Sept piliers de l'Agilité.  Cette méthode amène les équipes à évaluer leur niveau de maîtrise sur les sept grand fondements qui sont gages du succès de l'Agilité.  Voici comment se déroule une activité de rétrospective typique et les ajustements que nous lui avons apporté avec les sept piliers.

Pour commencer, la méthode de rétrospective est présentée et l'animateur explique le déroulement.  Ensuite, les participants sont invités à inspecter la manière dont s'est déroulé la dernière itération et à identifier un élément qui s'est bien déroulé et deux éléments à améliorer. Quand tous les participants ont terminé leur réflexion, ils passent à tour de rôle pour présenter leurs points au groupe et les positionner sur le tableau.  Les points sont regroupés ensemble dans des catégories qui sont déterminées à mesure selon les grand thèmes des éléments relevés.




Pour notre activité,  nous avons pré-déterminé les catégories avec les sept piliers de l'Agilité. Nous avons expliqué les piliers aux participants au début de l'activité pour leur donner des points de référence.  Nous leur avons demandé de relever des élément positifs et à améliorer concernant l'état de ces piliers dans leur entreprise.

Une fois que tous les points sont présentés, les participants passent ensuite à tour de rôle pour distribuer 3 votes sur la ou les catégories qu'ils veulent le plus améliorer.



Voici les piliers qui ont été votés les plus prioritaires par nos membres avec quelques-uns des points soulevés:
  • L'excellence technique
    • La couverture de tests
    • Les niveaux d'expertise différents dans une même équipe
    • La conception itérative de logiciel
    • Le niveau d'analyse nécessaire pour démarrer le travail
  • La valeur d'affaires
    • La priorisation des différentes demandes
    • La gestion d'une grande quantité de demandes
    • La capacité d'atteindre des dates cibles
    •  La capacité de livrer tout le travail commis dans une itération
  • La collaboration
    • L'engagement d'équipe
    • L'implantation des différentes rencontres



Finalement, pour faire un plan d'action, la catégorie ayant amassé le plus de votes est sélectionnée et les participants sont invités à proposer des actions concrètes pour améliorer ce point.

Par exemple, pour le pilier de l'excellence technique, voici les idées discutées:

  • Améliorer la couverture des tests avec le TDD
  • Utiliser une méthode de design par contrat
  • Avoir un expert de l'application dans l'équipe
  • Avoir une méthode pour limiter la dette technique
    • Prévoir du temps pour les refactors
    • Faire les refactors soulevés dans une itération dès la prochaine itération
  • Utiliser un outil pour mesurer la qualité du code (Sonar + link)


Habituellement, ceci détermine un plan d'action clair à l'équipe qui pourra être entamé dès le début de la nouvelle itération.

Dans le contexte de la communauté Agile, cette rétrospective nous a permis de mieux comprendre la réalité des gens de la communauté.  Nous pourrons ainsi préparer notre "backlog" de sujets à traiter en priorisant ceux qui vont apporter le plus de valeur aux gens de la communauté.  Surveillez notre site Agile Sherbrooke ou inscrivez vous à notre info-lettre pour être tenu au courant des nouvelles et prochaines activités de la communauté Agile.

Merci à tous pour votre participation active et contribution à la communauté Agile de Sherbrooke!

Tuesday, June 30, 2015

Résumé du premier évenement de AgileSherbrooke


Le mercredi 17 juin dernier se déroulait le tout premier évènement dans la jeune existence d’AgileSherbrooke.  Plus de 40 personnes se sont rencontrés dans les locaux de Sherweb afin d’assister à une présentation au sujet de l’estimation initiale des projets Agile.


Les participants, principalement en provenance des compagnies de la région telle que la Ville de Sherbrooke, l’Université de Sherbrooke, CGI, Acceo et Sherweb ont bien appréciés la présentation ludique et interactive de Mathieu Boisvert. 

Les 4 membres fondateurs de Agile Sherbrooke ont pu présenter la mission de l’organisme, ainsi que de faire valoir leurs motivations et leurs objectifs aux gens présents.  De plus, la soirée a permis à tous de dialoguer sur l’agilité et sur les réalités organisationnelles de chacun.

Suite au succès de cet évènement, nous planifions de prendre l’été pour régler certains détails administratifs et d’établir une structure organisationnelles avec des membres intéressées à se joindre au mouvement.   N’hésitez donc pas entrer en contact avec nous via notre site web à http://www.agilesherbrooke.ca/contact.html si vous êtes intéressés à participer en tant qu’administrateur, membre ou commanditaire, ou pour soumettre des articles de blogues ou autres liens intéressants.

Surveillez-notre site d’ici l’automne pour être au courant de ce que nous planifions.

Vous pouvez revoir la présentation de Mathieu en visitant le lien ci-dessous :



Bon été!

Tuesday, April 14, 2015

Scrum 101: Aperçu général de l'approche Agile/Scrum

Si vous cherchez de l’information sur internet, sur Agile ou sur Scrum, vous allez trouver une documentation très riche et variée. Par contre, c’est difficile de trouver un résumé simplifié qui vous présente une vue globale sur le sujet. Dans ce blog, j’ai regroupé les éléments clés que vous devriez savoir pour bien comprendre le modèle Scrum  sans lire les nombreuses pages et livres sur le sujet.

Scrum est une des implémentations de la philosophie Agile qui préconise le développement par itération selon les 4 valeurs suivantes :
  1. Les individus et leurs interactions plus que les processus et les outils.
  2. Du logiciel qui fonctionne plus qu’une documentation exhaustive.
  3. La collaboration avec les clients plus que la négociation contractuelle.
  4. L’adaptation au changement plus que le suivi d’un plan.


Scrum est un modèle d’organisation de développement de produit qui s’appuie principalement sur le concept de la responsabilisation des équipes («Empowering Teams») avec des équipes multifonctionnelles et localisées dans le même espace.

Valeurs Scrum
  • Focus : l’équipe se concentre sur un ensemble d’activité à compléter pendant une période de temps.
  • Courage : l’équipe travaille ensemble, ce qui lui donne le courage de surmonter les obstacles.
  • Ouverture : l’équipe communique bien ensemble avec une transparence réelle, ce qui permet d’identifier et de régler plus facilement les problèmes rencontrés dans un sprint.
  • Engagement : l’équipe contrôle la quantité du travail à faire dans un sprint, ce qui lui permet de s’engager à respecter les objectifs d’un sprint.
  • Respect : l’équipe partage le succès et l’échec, les membres de l’équipe se respectent et s'entraident pour atteindre leurs objectifs


Piliers Scrum
  • Transparence : permet d’établir une confiance entre les membres de l’équipe et les observateurs externes. Cela va aider à avoir une vue rapide et juste de l’état du projet.
  • Inspection : permet de faire un retour périodique sur le fonctionnement de l’équipe afin de détecter les points à améliorer
  • Adaptation : Ajustement continue du fonctionnement de l’équipe basé sur l’inspection.


Le graphique ci-dessous représente un exemple de l’organisation dans le temps des différentes activités utilisées dans SCRUM:



Les principaux Artefacts
  • Product Backlog : liste des items (user-stories et epics) priorisés par le Product Owner en fonction des besoins des clients. Un item de backlog représente un besoin client avec des critères d’acceptation. La user-storie est décrite sous le format : En tant que…, j’aimerai avoir.., pour que…
  • Sprint Backlog : liste des items à réaliser dans une iteration
  • Product Increment  : livrable à la fin de chaque iteration


Les principaux rôles
  • Product Owner :  responsable de maintenir et de prioriser le  « product backlog »
  • Scrum Master : responsable du bon fonctionnement du processus Scrum. Il est facilitateur et aide l’équipe à régler les bloquants qui empêchent l’équipe d’atteindre ses objectifs. Il ne doit pas avoir un lien d’autorité avec les membres de son équipe.
  • Team : Équipe multifonctionnelle, localisée dans le même espace, auto-organisée et composée de 3 à 9 personnes. Assure la réalisation pour  livrer le produit par petits incréments à chaque sprint.


Les cérémonies obligatoires
  • Sprint Planning : planification et engagement sur le travail à livrer dans un sprint.
  • Daily Meeting: rencontre quotidienne pour synchroniser les membres de l’équipe
  • Sprint Review: présentation par l’équipe de l’incrément de produit livré dans le sprint
  • Sprint Rétrospective : retour sur ce qui s’est passé dans le sprint précédent pour identifier ce qui a bien été, mal été et à améliorer dans les prochains sprints.


Il y a également quelques cérémonies optionnelles comme le backlog grooming et Release planning workshop qui sont nécessaires pour estimer périodiquement le backlog et avoir un plan pour les livrables client qui nécessitent plusieurs sprints (voir le chapitre 18 du livre de Kenneth S. Rubin,  Essential Scrum).

Autres points SCRUM:
 
  • Sprint :  itération qui dure de 1 à 4 semaines.
  • Velocity : nombre de point qu’une équipe peut réaliser dans un sprint.
  • Done-done : contrat établi entre l’équipe et le Product Owner par backlog. L’équipe doit respecter ce contrat pour déterminer si la Story est complétée à la fin d’un sprint
  • Release burndown : indicateur qui permet d’avoir une vue et une progression sur une release.
  • Sprint Burndown: une représentation graphique des heures restantes versus temps restant dans un sprint
  • Scrum of Scrum meeting: rencontre périodique de synchronisation entre les représentants des équipes Scrum


Comme vous l’avez remarqué, il y a plusieurs éléments à maîtriser dans le processus pour bien réussir la transition vers l’agilité/Scrum. C’est pour cela qu’un accompagnement d’un expert interne ou externe peut aider à réussir plus rapidement cette transition et à éviter d’avoir des interprétations différentes de toutes ces pratiques.

La mise en place de SCRUM dans votre organisation doit tenir compte de votre réalité et s’assurer que les concepts de base Agile/Scrum sont bien compris par les acteurs, parties prenantes et le management.

Je recommande de commencer par identifier une personne interne ou externe qui maîtrise le processus Scrum pour assister les gestionnaires et les équipes à mettre en place la première itération du processus avec les éléments principaux: longueur de sprint, type de sprint planning, type de démo, équipe multifonctionnelle, Product Owner, Backlog de produit ou Backlog de projet. Par la suite, à travers les expériences, vous pourrez ajuster le processus en fonction de votre réalité.

Idéalement, pour que les intervenants du processus adhèrent aux concepts SCRUM et comprennent le pourquoi des pratiques, une formation de base SCRUM devrait leur être donnée au début de la mise en place de cette nouvelle organisation.

Si vous avez des questions ou besoin de plus d’information sur une pratique spécifique, faites-le moi savoir dans les commentaires, je pourrai approfondir le sujet dans un prochain article.

Références :

Monday, April 13, 2015

La conception dans le monde agile


Contrairement aux méthodes traditionnelles de développement logiciel (waterfall, en V, RUP, etc), un projet agile préconise l'élimination de la phase de conception en début de projet et la remplace par une conception juste-à-temps intégrée dans les sprints.  Ceci est logique, puisque sans la phase d'analyse de tous les requis du système,il ne serait pas possible de faire la conception d'un système dont les besoins et les contraintes ne sont pas connus
Par contre, en mode agile, l'équipe doit accomplir une story dans un temps limité (timebox) donc le focus est important.  Il faut donc trouver un équilibre entre faire la conception d'une solution qui répond au besoin actuel dans le temps demandé, mais qui pourra également être facilement adapté dans le futur pour répondre aux besoins qui surviendront à ce moment.

Principes de la conception agile
L'atteinte de cet équilibre dans la profondeur de la conception dépend fortement de la taille du système, du niveau d'expérience des membres de l’équipe et du niveau de qualité nécessaire.  Les principes suivants peuvent nous aider à guider nos choix:

Simplicité
En mode agile, il s'agit d'en faire juste assez pour répondre au besoin de façon simple, afin de respecter le temps qui est prévu à cet effet tout en rendant le code et le design facile à comprendre pour les autres.  Chaque décision qui demande du temps supplémentaire pour faire du code plus générique peut se baser sur la croyance de XP (Extreme Programming) qui stipule que "ça ne servira pas de toutes façons" ("You Ain't Gonna Need It Anyway" - YAGNI).  En effet, sans connaître les besoins futurs, il est difficile de prévoir le code qui y répondra.  Le livre Lean Software Development: An Agile Toolkit présente également le principe “Think big, act small, fail fast, learn rapidly”.  Ceci signifie de faire des petites actions concrètes afin de prouver ce qui fonctionne et ce qui ne fonctionne pas, tout en ayant la vue d’ensemble.

Facilité de changement
Le principe Open-Closed de SOLID, qui représente un design où il est facile de changer des comportements sans impacter ce qui est déjà là (Open for extension, but Closed for modification) explique bien l'objectif à atteindre.  Ce principe est très important car il permet d'étendre des fonctionnalités rapidement avec un risque de régression réduit.  Dans cette catégorie, on peut aussi penser aux principes de cohésion et de couplage, qui favorise les changements futurs en créant des classes avec une seule responsabilité, avec peu de dépendances et logiquement regroupées entre elles.  Ceci permet donc des modifications à des endroits bien ciblés et avec peu d'impact sur le code existant.

Testabilité
Lorsqu'il n'est pas possible d'implémenter une nouvelle fonctionnalité sans affecter le code existant, il devient essentiel de faire du réusinage ("refactoring").  Ceci implique de modifier l'architecture actuelle afin de la rendre prête à recevoir des changements pour mieux répondre aux nouveaux besoins, ou pour mettre en commun des fonctionnalités.  À ce moment, la façon la plus efficace de valider que la fonctionnalité existante n'a pas régressée est par les tests unitaires.   Il est impératif d'avoir une couverture de test suffisante, ainsi que d'avoir des bons tests pour éviter de devoir réusiner les tests aux aussi.  De bons tests ont les caractéristiques suivantes:
  • Robustes, c’est-à-dire qu’ils passent toujours et ne dépendent pas de l’environnement
  • Isolés, soit qui ne sont pas dépendants d’autres tests
  • Boîte grise, qui permettent de tester la fonctionnalité de l’extérieur, tout en sachant comment elle est faite à l’intérieur.
Par contre, il n'est pas toujours nécessaire de faire le réusinage au moment où le changement est requis; des fois il peut être plus approprié et plus efficace d'implémenter la solution autrement, comme par exemple:
  • quand les changements peuvent être combinés dans un plus grand réusinage
  • lorsque le changement est trop risqué (de causer des anomalies, ou d’empêcher de compléter la story)
  • il est possible de remplacer le code par une autre “route” créée à côté du code existant, ce qui permet de réduire les effets du changement, puis de transitionner progressivement vers le nouveau code
Dans ces cas, un user story peut être créée afin de documenter le réusinage qui doit être fait, ce qui a pour effet de faire ressortir la dette d'architecture du système.

Architecture cible
Sans la phase de BDUP (Big Design Up-Front) des méthodologies classique, le design d'un système qui utilise une méthodologie agile est dit "émergent", c'est-à-dire qu'il évolue itérativement en fonction des besoins réels, au fur et à mesure que les fonctionnalités sont ajoutées.  Ceci corresponds directement à la philosophie même de Agile.
Par contre, lorsque la complexité du système ou encore le nombre d'équipes qui travaillent dans le même système augmente, ce principe atteint ses limites.  Aucune équipe ne maîtrise le système dans son entièreté, et peut difficilement prévoir les changements qui arriveront dans le futur.  De plus, à cause du focus précis de l'équipe sur le sprint en cours, il y a un risque pour plusieurs équipes de résoudre les mêmes problèmes de façon différentes, ou voir même contradictoires.
Ainsi, arrivé à une certaine échelle, il est important de définir un guide afin d'orienter et de supporter la conception au fur et à mesure de l'évolution du système.  Ce guide est connu sous le nom d'architecture cible, ou architecture intentionnelle.  
L'architecture cible détermine donc certaines technologies, certains patrons de conceptions ou encore d'outils et  frameworks qui vont ajouter des contraintes aux équipes agile lors de l'implémentation des solutions sans les limiter dans leur recherche de solutions.  Cette dernière partie est importante, car il ne faut pas perdre l'avantage que procure le mode agile, avec ses équipes auto-organisées à qui on donne le pouvoir de choisir et de se débrouiller.
L'architecture cible doit être définie dès le début d'un projet afin d'orienter le développement des équipes lors des premiers sprints.  Par contre, comme toute chose agile, elle doit aussi pouvoir évoluer en fonction de l'utilisation et des besoins qu'en font les équipes ainsi que pour les changements au niveau des technologies et des requis de l'entreprise.  Il devient donc nécessaire d'identifier et gérer des user stories d'architecture, qui ont pour but d'adapter l'architecture en fonction des facteurs exprimés précédemment.  La définition des stories et leur implémentation est plus complexe en terme d'architecture qu'il ne l'est en terme de code fonctionnel, parce que les changements sont situés au niveau structurel à la base du système et ils ont des impacts sur tout le système.  En effet, un changement majeur au niveau de la base de données par exemple pourrait briser le concept de "système fonctionnel en tout temps" pendant plusieurs sprints, le temps que tous les modules s'adaptent à la nouvelle architecture.  Ainsi, lorsque possible, ces changements devraient être faits de façon itérative, en implémentant des couches de conversion ou en supportant l'ancien système en parallèle avec le nouveau.
L'important c'est l'équilibre.  En utilisant un bon mélange de simplicité, de design émergent et de tests robustes, l’équipe peut atteindre l’équilibre entre prévoir le futur et le faire maintenant.  L’identification des réusinages à faire et une bonne définition de l’architecture cible va aider l’équipe à atteindre l'équilibre entre encadrer le développement et le limiter.  C'est le défi qu'apporte l'agilité!
Références:

Friday, April 3, 2015

Concilier développement et Scrum Master

Définition d’un Scrum Master
Selon la méthodologie Agile, un bon Scrum Master se doit d’être un bon joueur d’équipe! C’est à dire une personne qui a autant à coeur le succès de ses coéquipiers que son propre succès personnel. Il est d'abord et avant tout considéré comme un “facilitateur” entre le Product Owner et son équipe. Il n’est pas considéré comme un supérieur hiérarchique et n’a aucune autorité supplémentaire face aux membres de son équipe.

En d’autres mots, le rôle du Scrum Master est de s’assurer du bon succès de son équipe en éliminant tout ce qui pourrait faire obstruction à la productivité de celle-ci. Si les développeurs se plaignent que la température est trop haute dans la pièce, c’est le rôle du Scrum Master de trouver un moyen pour réduire celle-ci. Si une personne externe interrompt ou distrait l’équipe, c’est le rôle du Scrum Master de les intercepter et les rediriger vers les bonnes personnes.


Conciliation développement et Scrum Master

Avec le temps, une équipe Agile va développer des aptitudes à régler les situations problématiques d’elle-même et va petit à petit devenir ce que l’on appelle une équipe “auto-organisée”. Par conséquent, après un laps de temps, les responsabilités du Scrum Master, bien que très importantes, pourraient ne plus combler un poste à temps plein au sein de son équipe. Or, comment concilier Scrum Master et développeur en même temps? C’est ici que ma récente expérience entre en jeu!

Être à la fois Scrum Master et développeur au sein d’une même équipe offre un grand avantage au niveau technique. En effet, le fait d’être plongé dans le même environnement, le même code et dans les mêmes problématiques que les développeurs facilite la communication et la compréhension entre le Scrum Master et son équipe. Ce dernier devient alors mieux outillé pour adresser les bloquants et répondre aux questions des intervenants.

Par contre, il faut faire attention à ne pas tomber dans le piège de faire passer le travail du développeur avant celui de Scrum Master. Même si vous êtes concentré ou à quelques doigts de terminer un travail de développement, en tant que Scrum Master vous ne devez pas perdre de vue l’objectif d’aider votre équipe dans l’atteinte des objectifs fixés pour le sprint : vous êtes le facilitateur! Cette contrainte peut parfois être un peu frustrante en vous donnant l’impression de ne pas coder suffisamment, ou que votre travail de programmation prend plus de temps qu’il ne le devrait. Comme la plupart des développeurs aiment être reconnus et sentir que leur travail fait une différence, cette situation peut être brimant pour la fierté personnelle.

Répartition des responsabilités
En tant que Scrum Master et développeur, il est parfois difficile de changer de chapeau d’un rôle à l’autre pour ne pas apporter de conflit d’intérêts. Rappelez-vous qu’un bon Scrum Master doit aider les autres membre de l’équipes avant tout et non pas passer son succès personnel en premier plan. Voyez l’envers de la médaille, vous aidez votre équipe d’une différente manière; tout comme Batman, vous êtes le héro dans l’ombre! Ne jouez pas de fausses modesties et acceptez les compliments et surtout n’ayez pas peur d’en donner à votre tour. Vous augmenterez ainsi la confiance et garderez une bonne harmonie avec les membres de votre équipe.

Être Scrum Master ne signifie pas avoir de plus grande connaissances techniques que les membres de l’équipe. Si c’est le cas, le Scrum Master doit également savoir faire bénéficier son équipe de son expertise au même titre que les autres développeurs. Celui-ci ne doit pas effectuer tout le travail technique pour l’équipe et devenir un “bottleneck” mais plutôt enseigner ce qu’il sait. Rappelez-vous le principe “ne donnez pas de poisson a ceux qui ont faim mais apprenez leur plutôt à pêcher”!

En tant que développeur, il est toujours intéressant de participer aux différentes rencontres décisionnelles et aux meeting techniques. En tant que Scrum Master, sachez répartir cette charge aux travers les différents membres de votre équipes et ne gardez pas sur vous le besoin d’être partout à la fois. Sachez conserver vos bon joueurs sur le terrain, là où ils sont efficace et où ils peuvent supporter l’équipe au meilleur de leur expérience et avec leurs connaissances.

Finalement
Il est important pour le Scrum Master de gérer son rôle en priorité sur le rôle développeur. Rappelez-vous qu'il n’y a qu’un seul Scrum Master par équipe mais plusieurs développeurs.

Il faut souligner que la force du Scrum Master demeure sans aucun doute son impartialité. C’est à dire sa capacité à faire rayonner tous les membres de son équipe, de ne pas se mettre en premier plan même s’il est en quelque sorte la “voix” de son équipe en tant que représentant.