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.

[chemanel]

Par exemple un chef de projet qui perd des ses fonctions pourrais le prendre mal non ?

Je crois que c'est ce qui est arrivé ) nico1407 !

[nswarte]

Une des caractéristiques de SCRUM est de pourvoir s'adapter en cours de sprint (temps donné pour accomplir un nombre de fonctionnalités donné par le product owner). En fonctions des difficultés rencontrées, l'équipe peut réorganiser les taches. Le travail de planification fait en amont par le chef de projet n'a plus trop d'utilité dans ce genre de fonctionnement.

[hugo123]

Petit feedback d'un utilisateur de SCRUM (et chef de projet)
Tout d'abord pour reprendre un point qui a été dit plus haut, changer de méthodologie c'est déjà un projet en soi et et il faut bien appréhender le concept avant de se lancer. Apparemment on a un contre exemple plus haut ^^

Ensuite être chef de projet c'est toujours être le contact avec la hiérarchie, c'est toujours le communicant avec l'équipe, celui qui remplit les taches administratives (demande d'achat de serveurs, de licenses) etc...

Très important, ne pas oublier que dans méthodologie agile, il y a "agile". Et être agile ca veut dire être capable d'adapter sa façon de travailler. Si vous ne vous sentez pas d'adhérer a tout les concepts, faites des feedbacks réguliers pour les changer à votre sauce.

Au passage, un lien vers un PDF intéressant sur l'adoption de SCRUM et un vrai retour d'expérience : Scrum et XP depuis les tranchées
a+

[nico1407]

tout le monde devient responsable du projet

Quant aux estimations des charges, et des plannings, elles sont le fait de l'Equipe

Je suis d'accord avec ca mais on n'est pas dans le monde des bisounours.

Patriarch24, tu as peut etre la chance de travailler dans un environnement où personne n'est ambitieux, mais par expérience il y a toujours quelqu'un qui veut tirer la converture pour lui.

Et il ne faut pas oublier qu'aux yeux de la hiérarchie s'il y a un problème il faut un responsable. Je ne crois pas que tout le monde va assumer les retards prit par une personne.

[Patriarch24]

Je suis d'accord avec ca mais on n'est pas dans le monde des bisounours.

Patriarch24, tu as peut etre la chance de travailler dans un environnement où personne n'est ambitieux, mais par expérience il y a toujours quelqu'un qui veut tirer la converture pour lui.

Et il ne faut pas oublier qu'aux yeux de la hiérarchie s'il y a un problème il faut un responsable. Je ne crois pas que tout le monde va assumer les retards prit par une personne.

Dans ce cas j'ai bien raison : pourquoi mettre en place une méthode agile dans un contexte aussi peu propice ? Parce que cela concerne la hiérarchie aussi, ainsi que l'ensemble des parties prenantes. Si quelqu'un ne suit pas, ou n'est pas sur la même longueur d'onde, ça ne peut pas fonctionner !

[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 ^^

[Maximil ian]

Et il ne faut pas oublier qu'aux yeux de la hiérarchie s'il y a un problème il faut un responsable. Je ne crois pas que tout le monde va assumer les retards prit par une personne.

Scrum ne consiste absolument pas à se défausser de toute responsabilité :

• Le Product Owner est propriétaire du produit logiciel et garant du retour sur investissement du client. S'il fait de mauvais choix stratégiques (mauvaise priorisation des items, mauvais plan de release...) c'est lui le responsable.
  
• L'équipe de développement s'engage à terminer un certain nombre d'items pour la fin du sprint, elle est redevable de cela.

Le Scrum Master est quant à lui propriétaire du process Scrum (et pas du produit logiciel). Comme ça a été dit, il est garant du respect de l'esprit de Scrum par l'équipe, organise les réunions et protège l'équipe des interférences extérieures. Il cherche à améliorer continuellement le process Scrum.

Ce n'est pas un chef de projet car :

• Ce n'est pas un chef. Il n'a pas de position hiérarchiquement supérieure.
• Il n'affecte pas les ressources à des tâches.
• Il ne décide pas du planning.

A l'extrême limite, dans un monde de bisounours avec une équipe 100% auto-organisée, un environnement parfait et aucune nuisance extérieure, le Scrum Master n'a plus de raison d'être. Ce cas de figure ne se produit jamais, bien sûr.

Un chef de projet peut devenir Scrum Master à condition d'épouser la philosophie agile de Scrum et de faire table rase de ses habitudes de chef de projet (micromanagement, "convaincre" les développeurs et le client...)

[LittleBean]

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.

Au contraire les retours d'expériences qui se sont mal passés sont souvent autant voir plus instructif que ceux qui se passent nickel.

Pour ma part j'ai pas d'expérience réelle du SCRUM, juste ce que j'en ai lu et entendu beaucoup de bien peut être même trop :p

Pour moi la différence Scrum/classique est :
scrum : coopératif
classique : conflictuel

Le chef de projet dans un projet classique est là pour prendre des décision/résoudre les conflits : vs le client pour qualifier anno ou evo; vs le développeur pour les charges; vs le systeme pour avoir du matos ....

Dans scrum :
vs le client => product owner
vs le dev => eux même en auto gestion
vs le sytem => scrum master


En gros le rôle du chef de projet est dispatché sur plusieurs rôles en fonction des responsabilités.


nico1407 tu as des exemples précis de ce qui s'est mal passé;
genre le passage de patate chaude pour prendre une décision ?

[hugo123]

Pour moi la différence Scrum/classique est :
scrum : coopératif
classique : conflictuel

Attention scrum n'évites pas le conflit ^^
Le product owner peut être en conflit avec l'équipe sur des priorisations de backlog. La présence/absence même du product owner aux réunions de début de sprint peut être source de conflit...
Et puis les estimations étant du fait de l'équipe entière, il peut y avoir des conflits sur la facon de faire...

[Patriarch24]

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

Tu n'es pas fautif, on t'en voudras pas. Par contre, le consultant en question, je pense que tu peux lui faire de la pub ! Il n'a manifestement pas analysé la situation, ni fait les choses de manière progressive : échec (quasi-)assuré !

Le product owner peut être en conflit avec l'équipe sur des priorisations de backlog.

Normalement pas. Il décide dans quel ordre les choses doivent être faites, du point de vue des fonctionnalités. L'équipe doit elle gérer les risques + la priorité établie par le Product Owner. Si celui-ci réfute systématiquement l'avis de l'équipe, alors le contexte est malsain.

La présence/absence même du product owner aux réunions de début de sprint peut être source de conflit...

Le Product Owner ne saurait être absent d'une telle réunion. Encore une fois, cela mène à un contexte malsain (il faut s'arranger pour trouver un créneau). C'est de l'organisation, c'est évident, mais pour fonctionner, il ne faut pas juste donner un coup de baguette magique en disant "hop, on fait du Scrum" et puis ça roule... La réalité est bien différente !

Et puis les estimations étant du fait de l'équipe entière, il peut y avoir des conflits sur la facon de faire...

Il faut mettre en place des règles. Le planning poker, jeu que je trouve génial, permet de discuter sur les estimations de manière ludique mais sérieuse, et on obtient en général de très bon résultats, après deux ou trois sprints (itérations) seulement. Maintenant, faut savoir mettre son égo de côté, mais si on veut mettre en place une méthode agile, c'est un pré-requis.