Discussion :

[Indoril]

Bonjour,

Je suis en train de me renseigner sur la méthode de développement SCRUM

J'ai compris que le rôle su SCRUM-Master est de veiller au bien être de l'équipe, d'empêcher tous les éléments perturbateurs et de veiller à ce que les principes de SCRUM soit appliqués.

Le Directeur de produit représente le client et/ou l'utilisateur du logiciel à créer, il détermine ce qui doit être fait et dans quel ordre. Il surveille également l'orientation du projet.

L'équipe se charge du développement et s'auto-gère sans rôle prédéfinie ni de hiérarchie interne.

Voici donc mes questions :

Dans un premier temps, ai-je bien tous compris dans les grandes lignes ?
Et enfin quel peut être le rôle d'un chef de projet dans la méthode SCRUM ?
Quel peut être ou doit être sa place ?

J'entre actuellement dans ma dernière année d'étude et je vais être formé à la gestion de projet et au management et trouvant la méthode SCRUM intéressante je me pose donc ces petites questions.

Merci de vos futures réponses.

[Heziva]

Bonjour !
Je n'ai pas LA réponse sur la méthode Scrum, mais quelques éléments.

J'ai compris que le rôle su SCRUM-Master est de veiller au bien être de l'équipe, d'empêcher tous les éléments perturbateurs et de veiller à ce que les principes de SCRUM soit appliqués.

Effectivement, le Scrum master est un coach. Il veille au bon déroulement du projet. Il aplatit les causes externes et internes de ralentissement. Il organise les réunions.

Le Directeur de produit représente le client et/ou l'utilisateur du logiciel à créer, il détermine ce qui doit être fait et dans quel ordre. Il surveille également l'orientation du projet.

Effectivement, le "Product Owner" a la responsabilité du produit. Il choisi à chaque itération ce qui entre et ce qui sort du projet. Il observe les démo, et vérifie que les spécifications ont bien été suivies (attention à la notion de spec dans scrum)

Dans le cycle en V...
- La MOA est généralement une entité qui a la charge de la phase de recette. C'est la phase où le produit est testé, les bugs sont remontés aux développeurs. Cette même entité a la charge de demander des modification. Elle est a mettre en mirroir avec le PO Scrum
- Le chef de projet a le rôle d'aplanir les difficultés. Il est à mettre en mirroir avec le SM Scrum. Note cependant que généralement, le chef de projet a également la charge de rédiger les spécifications depuis l'expression de besoin, d'attribuer les tâches aux développeurs, etc. Ce n'est pas le cas pour le SM Scrum.

Est ce que cela répond à tes questions ? Quelles attributions a ton chef de projet ? Lesquelles manquent dans la vision PO + SM ?

Si la gestion de projet t'interesse, je te recommanderai de participer à l'évenement gratuit sur octobre Agile Tour.

[Indoril]

Bonjour, tout d'abord merci de ta réponse.

Est ce que cela répond à tes questions ? Quelles attributions a ton chef de projet ? Lesquelles manquent dans la vision PO + SM ?

Et bien en fait durant mes stages je suis rarement tombé sur des chef de projets, ou je bossais seul sur des petits projets, ou bien comme actuellement il n'y pas vraiment de chef de projet désigné et donc le projet accuse un certain retard

En fait dans ma vision du chef de projet, ce dernier est censé établir le planning des tâches, gérer les relations avec le client et rédiger les spécifications comme tu l'a dit.

Hors dans Scrum, ce n'est pas vraiment une seule personne qui fais sa, du coup je me demande si cette méthode a besoin d'un chef de projet ou non et si oui doit-il faire partie de l'équipe ou bien doit-il devenir Scrum-master bien que je trouve leur rôle assez différent) ou bien autre chose encore.

Merci bien

[chemanel]

N'oublie pas qu'une personne peut prendre également plusieurs roles. Dans l'idéal appliquer la méthode Scrum au pied de la lettre serait le mieux. Mais dans le monde réel, on se retrouve souvent avec un mélange un peu mic mac de plusieurs choses... (malheureusement )

[nico1407]

Bonjour,

Je suis actuellement chef de projet dans une société où l'on a appliqué SCRUM.

Avant, j'étais responsable de toute l'application, à savoir recueil des besoins, réaction des spec (fonctionnelle et technique), gestion du temps de travail, developpement et tests. Je faisais beaucoup d'heures mais le projet avancé.

Depuis 3 mois, nous avons appliqué SCRUM. Et bien depuis 3 mois, il ne se passe plus rien. Mes responsabilités de chef de projet ont considérablement été réduites (spec technique et dev).

Le gros avantage de SCRUM et qu'il n'y a plus de responsabilité, les estimations de charge et la planification des "ressources" (desole j'aime pas le terme) ne m'est plus attribué et cela devient n'importe quoi.

Les jours/hommes sont soit divisés par le nombre de "ressources", soit pris tels quels pour calculer un délai. Les diagrammes de GANTT ont disparu aussi.

Pour conclure, je pense que cette méthode peut être pas mal mais il est difficile de trouver le bon "coach" sans pénaliser tout le monde.

[Indoril]

Donc en fait si je comprend bien le rôle du chef de projet se perd avec SCRUM, ou alors il est plutôt éclaté et réparti sur plusieurs personnes, sa ne risque pas d'entrainer des mésentente ? Par exemple un chef de projet qui perd des ses fonctions pourrais le prendre mal non ?

Après au niveau des "mic mac" et de la planification des ressources je pense que c'est pareil partout, des que l'on change de méthode il faut un temps pour ce réadapter et on fais des erreurs avant que tout fonctionne parfaitement.

Tous ne peut pas bien marcher et du premier coup, se serai pas marrant sinon

Merci de vos réponses.

[Patriarch24]

Le gros avantage de SCRUM et qu'il n'y a plus de responsabilité, les estimations de charge et la planification des "ressources" (desole j'aime pas le terme) ne m'est plus attribué et cela devient n'importe quoi.

En clair, vous (toi + ton équipe) n'avez pas comprit l'esprit de ce genre de méthode ! Au contraire, tout le monde devient responsable du projet, sans être le "chef-tout-puissant-qui-régit-la-vie-des-ressources" ! Quant aux estimations des charges, et des plannings, elles sont le fait de l'Equipe, qui connaît ses compétences et sa vélocité, ou qui apprend à la connaître.

Les jours/hommes sont soit divisés par le nombre de "ressources", soit pris tels quels pour calculer un délai.

On ne calcule pas les points de cette manière dans une méthodologie agile...

Les diagrammes de GANTT ont disparu aussi.

Ca c'est normal. Il ne servent pas à grand chose. Ils sont remplacés plus qu'avantageusement par le Burndown chart, qui se focalise sur les fonctionnalités effectivement réalisées, par rapport à celles qui restent à faire, concernant toute l'Equipe, en se basant sur du réel plutôt que sur du spéculatif.

Pour conclure, je pense que cette méthode peut être pas mal mais il est difficile de trouver le bon "coach" sans pénaliser tout le monde.

Evidemment, on ne peut pas se lancer dans une telle entreprise sans accompagnement. Ca se fait en douceur, la transition vers une méthode agile est un projet en elle-même !

Pour terminer et répondre en même temps à la question initiale et au post précédent, je donnerai comme conseil la lecture de "Gestion de projet : Vers les méthodes agiles" de Véronique Messager Rota, qui donne une excellente vision du rôle de chef de projet dans le cadre des méthodes agiles, en plus de conseils pratiques et d'expériences vécues pour la transition vers ces méthodes.

[nico1407]

En revenant sur le premier post

J'ai compris que le rôle su SCRUM-Master est de veiller au bien être de l'équipe, d'empêcher tous les éléments perturbateurs et de veiller à ce que les principes de SCRUM soit appliqués

le su SCRUM-Master, c'est une personne qui fait le role de responsable des AMOA et des AMOE en meme temps. Il est super baleze car il a les 2 facettes.

Donc pour répondre à Patriarch24, sur :

sans être le "chef-tout-puissant-qui-régit-la-vie-des-ressources" ! .

Ce poste existe toujours il a juste été renforcé au dépend des personnes "compétentes" dans leur domaine. Si un AMOA était AMOE ou vis versa ca se serait. Donc de là à être chef des deux, moi je dis "Chapeau Monsieur".

Concernant SCRUM, contrairement à un cycle en V, j'aimerais bien savoir ce qui se passe quand la recette n'est pas bonne. On repart dans un autre sprint?

[hugo123]

Le scrum master n'est absolument pas MOE + MOA, c'est uniquement un "facilitateur", c'est la personne qui permet a une équipe de travailler en résolvant les impediments et en permettant d'éviter les distractions extérieures.
On lui demande uniquement de surveiller la bonne application de la méthodologie, c'est tout.

(Cf. http://fr.wikipedia.org/wiki/Scrum#ScrumMaster)

Concernant la recette, les méthodologies agiles pronent effectivement des cycles itératifs de développement. Les tests unitaires sont en théories joués chaque jour (et/ou a chaque commit). Les recettes dites "classiques" interviennent en fin de sprint et/ou sur des releases intermédiaires (Release candidate). Les méthodes agiles considèrent que plus un bug est détecté rapidement moins il coute cher.

[nico1407]

Le scrum master n'est absolument pas MOE + MOA, c'est uniquement un "facilitateur", c'est la personne qui permet a une équipe de travailler en résolvant les impediments et en permettant d'éviter les distractions extérieures.
On lui demande uniquement de surveiller la bonne application de la méthodologie, c'est tout.

(Cf. http://fr.wikipedia.org/wiki/Scrum#ScrumMaster)

Mea culpa, le role de scrum master est effectivement sans responsabilité.

Desole si je suis aigri, mais c'est que les postes bien payés sans responsabilités c'est jamais pour moi.

Et il est vrai que le SCRUM est mal fait dans ma société étant donné que les MOA et MOE sont toujours séparés dans différentes équipes au lieu d'en former qu'une seule.

Donc desole d'avoir eu une mauvaise experience de SCRUM alors que cela vient d'une mauvaise mise en place effectuée par un consultant hors de prix.

[hugo123]

"sans responsabilité", non ^^ Il n'est pas si simple d'applanir les difficultés administratives ou d'empêcher la hiérarchie d'imposer son petit besoin urgent au dernier moment etc... Les perturbations extérieures sont pour moi l'une des premières causes des échecs de ce type de méthodologie. Sans adoption par tous les intervenants, c'est difficile à mettre en place.

En tout cas si tu es curieux, lis le pdf que j'ai mis plus haut. Il se veut comme un retour d'une vraie expérience, c'est intéressant.
Et puis qui sait, si ta société veut vraiment jouer le jeu de l'agile, elle devrait se remettre en cause en théorie a chaque fin de sprint pendant la phase de retrospective. Et c'est l'occasion pour toi d'apporter des idées pour remplacer ce fameux consultant hors de prix ^^

[michel.di]

Bonjour à tous,
J'ai trouvé votre conversation très intéressante.
Ces deux points de vue différents montrent l'application d'une méthode agile dans des environnements différents et qu'il ne s'agit pas de claquer des doigts pour pouvoir appliquer une méthode. Scrum est avant tout un travail d'équipe et si toute l'équipe ne s'implique pas, le projet est voué à l'échec

[JKane]

Un livre très intéressant pour mieux comprendre SCRUM :
« SCRUM ET XP depuis les tranchées
Comment nous appliquons Scrum» !

[Bruno Orsier]

Je trouve aussi cette discussion très intéressante.

Dans une implémentation réussie de Scrum, je pense que l'ancien rôle de chef de projet a vocation à disparaître... j'écris bien le rôle, pas la personne ! L'expérience de cette personne reste précieuse pour l'organisation, mais il faut l'exercer autrement.

Dans mon cas, de chef de projet je suis devenu ScrumMaster sur un premier projet, puis à la demande des équipes j'ai pris en charge leur support technique, afin d'enlever un de leurs obstacles. Et en effet ils peuvent se focaliser entièrement sur leurs projets. Je n'étais pas forcément ravi de faire le support (ce qui me passionne c'est le développement de nouveaux produits), mais les projets avancent sans obstacles "extérieurs" maintenant.

Ce travail de support technique a permis d'identifier des erreurs récurrentes, qui me servent de support dans des formations internes. Cela contribue à augmenter la qualité de ce que nous produisons.

D'autre part, je peux maintenant passer du temps à organiser des ateliers sur le TDD, des dojos, faciliter des réunions, etc.

Donc mon rôle évolue de plus en plus vers la formation, le développement de compétences, la facilitation. De plus je peux partir en vacances sans aucun souci, mon absence n'a aucun impact immédiat sur un projet...

Bruno