Retour d'expérience méthode SCRUM

Pere Collateur · Le 03/04/2013, à 14:23

Bonjour à tous,

Je m'adresse ici à ceux qui bossent dans des boites d'informatique.

Connaissez vous la méthode de gestion de projet SCRUM:

http://fr.wikipedia.org/wiki/Scrum_%28m%C3%A9thode%29

Est ce que certains ont une expérience sur la mise en place de cette méthode dans leur boite?

Qu'en pensez vous objectivement?

ssdg · Le 03/04/2013, à 21:11

Tu as des questions plus précises? (de quel point de vue, pour quel type de projet, à quel stade de sa vie...)
Par exemple, Scrum est très bien pour:
Un projet ou tu travaille avec des gens impliqués (ou que tu pense pouvoir impliquer)
Un projet en cours de réalisation (pour de la maintenance, c'est plutot du coté de kanban qu'il faut regarder)
Un projet où tu as des utilisateurs finaux qui veulent participer ou une personne qui a une vision du produit final claire.

Si tu as tout (ou partie), les devs s'engageront lors des sprint plannings et des daily meetings. Ils verront que leur travail sert à quelque chose lors des démos. Ils verront qu'ils sont écoutés d'une rétrospective sur l'autre.
Les utilisateurs/ceux qui veulent un produit voient l'avancement du projet et finissent par avoir un produit qui correspond, non pas à leurs attentes, mais à leur besoin. (puisqu'à chaque démo, ils voient ce qui leur est utile et ce qui ne leur servira sans doute pas)
Ton service achat (s'il s'adapte), aura toutes les itérations un "résultat" cohérent et donc pourra stopper le projet ou chercher d'autres prestas, ... (puisque, si tes besoins en qualité du code, qualité de la doc et répartition des connaissances sont biens définis, tes devs ne sont pas indispensables. Mieux, il ne sera pas nécessaire de les déranger pendant leurs congés)

Il y a sans doute bien d'autres avantages, mais je préfère être court

Edit: disclosure, je bosse pour une boite qui "loue" des coachs en agilité. (en plus des ingénieurs en dev logiciel)

Dernière modification par ssdg (Le 03/04/2013, à 21:12)

Pere Collateur · Le 04/04/2013, à 09:48

Disons que j'ai cherché sur le net des témoignages et retours d'expérience sur la mise en place de cette méthode au sein d'entreprises d'informatique.

Je suis tombé sur une écrasante majorité de retours très positifs. Et j'ai trouvé ca un peu suspect tout de même, car depuis 20 ans, des méthodes pour tenter d´améliorer le développement informatique, j'en ai vu passé pas mal, et elles ont toutes, en grande partie, pas été à la hauteur.

Comme cela m'a pas mal étonné, de ne constater que des retours positifs, j'ai creusé et me suis rendu compte que les "témoins" étaient en grande majorité des consultants.
De plus, ils sont très entousiastes sur la méthode, du point de vue conceptuel/intellectuel, mais ils finissent par reconnaitre, du bout des lèvres, qu'ils n'ont pas trouvé comment faire adhérer ceux qui subissent réelement la méthode sur le terrain, à savoir, les devs.

Je suis donc très intéressé par des retours de la part des devs, bref, des techos de terrain, comment ils le vivent, qu'est ce qu'ils en pensent, de la facon la plus objective possible, meme si c'est très très négatif.

En tout cas merci de votre réponse. Je ne pensais pas que ce sujet aurait un echo ^^

The Uploader · Le 04/04/2013, à 12:07

Je te conseille de lire ces trois bouquins :
- KEN SCHWABER, Agile Project Managment With Scrum, Redmond, Microsoft Press, 2004.
- HENRIK KNIBERG, Scrum and XP from the Trenches, Toronto, C4Media Inc, 2007.
- RACHEL DAVIES et LIZ SEDLEY, Agile Coaching, The Pragmatic Bookshelf, 2006.

Avec chacun des vrais bouts de retours sur le terrain dedans.

Évidemment comme toute méthode, quand c'est mal appliqué, pas adapté à la réalité du terrain, voire pas applicable, ça donne de la merde.
Et puis SCRUM seul pour une boîte de dév' ça sert pas à grand chose.

Dernière modification par The Uploader (Le 04/04/2013, à 12:13)

Pere Collateur · Le 04/04/2013, à 14:22

The Uploader a écrit :

Et puis SCRUM seul pour une boîte de dév' ça sert pas à grand chose.

Voulez vous dire que cette méthode n'est pas fait pour un editeur de logiciel? Pourquoi?

The Uploader · Le 04/04/2013, à 14:32

Non, de ce que j'ai vu SCRUM est assez généraliste pour être adapté à peu près partout où cela fait sens d'avoir des retours rapides (en gros).

Mais pour une équipe de dév, ce qui les concerne plus directement c'est XP (eXtreme Programming). Allier SCRUM et XP est mieux dans ce cas.

ssdg · Le 04/04/2013, à 15:06

Pour préciser, je suis consultant dans le sens ou je suis dev, payé par une SSII, détaché dans des entreprises qui elles m'utilisent comme dev.[1]

Ensuite, du point de vue du dev, l'idée est de traiter des itérations définies sur une période donnée (les dates de début et de fin sont connues), que le contenu de ces itérations sont définies par la demande ET les devs. La demande priorise, les devs donnent le temps que ça va prendre et à l'itération contient tout ce qui a pu rentrer avec des journées de taille fixe, des semaines au nombre de jours fixes. Si les devs ne mentent pas à la pondération et que la demande est capable d'avoir confiance en leur jugement, ça marche bien.

Comme le dit The Uploader, Scrum tout seul n'est pas lié au développement logiciel (c'est l'industrie lourde qui l'a mise au point). C'est une partie de la méthodologie, XP apporte d'autres solutions et s'emboite assez bien avec Scrum. (ensuite, rien ne te force à faire du TDD, on te dit juste que c'est un investissement qui paye par la suite.)

[1] Heureusement, je ne me vois comme un morceau de viande que quand je dois décrire le chemin que suis l'argent pour tomber dans ma poche. Le restant du temps, je suis écouté et le jour ou je ne le serais plus, je changerai de mission ou de boite.

Pere Collateur · Le 04/04/2013, à 15:43

La méthode en elle même ne me semble pas déconnante. Je vois par contre en live sa mise en place, et ca coince au niveau de devs.

Autant je vois bien ceci s'appliquer à des débutants qui n'ont pas encore d'expérience, autant avec des équipes très expérimentées (10-15 ans de dev pointu en moyenne) et qui avaient déjà une organisation efficiente et qui produit des logiciels de tres bonne qualité en respectant les délais, j'ai plus l'impression que ca introduit du désordre qui va laminer complètement la productivité...

Je m'intérroge....

The Uploader · Le 04/04/2013, à 15:46

Bah c'est clair que ça n'a pas de sens de changer une équipe/méthode qui gagne.

Le plus souvent dans ce que j'ai lu SCRUM+XP était implémenté lorsque le Cycle en V/Waterfall se casse la figure.

ssdg · Le 04/04/2013, à 15:57

The Uploader > Pas mieux.

J'ajouterai que dans le cadre d'une équipe de 100% devs nouveaux dans le métier, c'est un peu les lancer dans le grand bain, sans flotteurs (mais avec les roulettes arrières pour le lest). Comme l'un des points important est que ce sont les devs qui évaluent le "cout" des demandes du client/métier/... s'ils n'ont pas beaucoup d'expérience, ils risquent de sur/sous-évaluer pendant un bon moment => Stress, perte de confiance du coté client, ...

Ensuite, une équipe 100% jeunes devs me parait une aberration.

Pere Collateur · Le 04/04/2013, à 16:05

En effet, que des débutants, ca n'a pas de sens et pourtant, ca se croise souvent...

Sinon, en ce qui concerne la méthode en elle même, on remarque rapidement une inflation de réunions. C'est un point assez bloquant et qui est pénible pour les devs qui perdent entre 20 et 30 % de leur temps en développement pur.

Je ne vois pas du tout comment rattrapper ce temps perdu, qui est crucial, à part prendre son PC en réunion et continuer à coder...

cervo · Le 04/04/2013, à 16:21

Pere Collateur a écrit :

Sinon, en ce qui concerne la méthode en elle même, on remarque rapidement une inflation de réunions. C'est un point assez bloquant et qui est pénible pour les devs qui perdent entre 20 et 30 % de leur temps en développement pur.

Si tu définies des périodes de 3 (ou même 2) semaines de developpement, une réu de 1h entre chaque itération ce n'est pas aberrant, ça permet de faire un point sur l'état du dev, de réajuster en cas de retard (ou avance, mais ça dans la vraie vie ça n'existe pas ) et surtout de rester au contact des users dont les demandes peuvent changer.

The Uploader · Le 04/04/2013, à 16:25

Pere Collateur a écrit :

Je ne vois pas du tout comment rattrapper ce temps perdu, qui est crucial, à part prendre son PC en réunion et continuer à coder...

Très mauvais pour la communication. Et les dév' ne risquent pas de coder beaucoup en réunion de toutes façons. Et s'ils codent, le code sera surement à jeter.

ssdg · Le 05/04/2013, à 15:53

Inflation de réunions, ça dépend. Les réunions dans scrum c'est:
Daily Stand-up meeting : 5m par jour (généralement rapidement rattrapées quand on met bout à bout le temps passé à crier dans l'open space "tu bosse sur quoi")
Démo et rétrospective: normalement, 1~2 heures. (ensuite, ça peut déraper, mais c'est du dérapage, pas la méthode) Dans la foulée, le dev apprend ce qu'il a raté, comprends un peu mieux le métier et fait généralement de meilleurs choix dans le reste du projet. En plus, il met des visages sur les demandes (et donc s'implique plus)
Sprint Planning: 2~3h, pour les devs, ils s'assurent de bien définir le but avant de commencer à coder (donc... moins de doutes par la suite et sans doute moins de trucs à refaire), s'engagent sur du temps de travail et des délais (encore de l'implication) et tu évite l'effet "évalué par un chef de projet qui ne connait pas les détails de l'appli et/ou les frameworks en oeuvre.)

J'ai du mal à trouver du temps perdu là dedans. (mais je reconnait que les premiers temps, les discutions ont tendance à dépasser le timeboxing.

ssdg · Le 05/04/2013, à 16:09

J'oubliais, ça peut arriver, sur le projet sur lequel je suis, on passe effectivement entre 10 et 20% du temps là dessus, mais:
On ne se demande quasiment jamais s'il faut comprendre comme si ou comme ça . (surtout quand je compare aux projets "en V", là, c'est juste incomparable)
Et j'ai l'impression qu'un temps fou est gagné par ceux qui reprennent le role de chef de projet (pas encore essayé) puisqu'ils n'ont plus à justifier ceci ou cela et que le client sait toujours ou ça en est.

C'est peut être un ressenti personnel, mais être là quand on montre le résultat du travail me pousse à:
tenir les délais, faire les choses sérieusement (par exemple: un "color: rgb(152, 1, 1)" au lieu de "red" dans un css c'est pas beaucoup plus long, mais ça change la vie coté utilisateur). Je ne sais pas pour tes devellopeurs, mais pour ma part, je suis bien plus efficace (plus de fonctionnalités implémentées et du code de meilleure qualité) en scrum qu'en cycle en V.

Pere Collateur · Le 05/04/2013, à 17:26

En fait ca commence à se décanter... Le choix du scrum master est très important apparement. Le jour et la nuit suivant les individualité qui s'y collent.

Du coup, ceux qui préconisent des roulements quasi automatique se fourrent le doigt dans l'oeil. Bon à savoir ca.

Dernière modification par Pere Collateur (Le 05/04/2013, à 17:26)

Ayral · Le 05/04/2013, à 17:43

Je vous lis en souriant. Je ne suis pas développeurs, donc...
Ce qui m'intéresse c'est la facilité avec laquelle chaque métier développe son propre langage.
Je ne comprends pas un traître mot à ce que vous racontez. Et c'est tamt mieux.
C'est du louchébem ? En tous cas je ne veux pas vous déranger.

ssdg · Le 05/04/2013, à 18:26

Pere Collateur a écrit :

En fait ca commence à se décanter... Le choix du scrum master est très important apparement. Le jour et la nuit suivant les individualité qui s'y collent.
Du coup, ceux qui préconisent des roulements quasi automatique se fourrent le doigt dans l'oeil. Bon à savoir ca.

Faire un roulement sur le scrum master n'est pas déconnant. le rôle, s'il est pris à cœur est assez crevant. Mais il faut tenir compte de certains paramètres:
Le Scrum Master potentiel doit être à l'écoute des gens en dessous et ne pas prendre la grosse tête.
L'équipe doit accepter de rendre des comptes à un Scrum Master (si elle a accepté la méthode, elle à accepté de rendre des comptes au PO et à en rendre aux autres membres de l'équipe, le Scrum master en étant un, ça ne devrait pas poser de problèmes)

J'ai eu l'occasion de bosser dans une équipe ou le SM roulait sur 3 personnes, les trois étant des personnes sympathiques et compétentes, ça s'est très bien passé.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 03/04/2013, à 14:23

Retour d'expérience méthode SCRUM

#2 Le 03/04/2013, à 21:11

Re : Retour d'expérience méthode SCRUM

#3 Le 04/04/2013, à 09:48

Re : Retour d'expérience méthode SCRUM

#4 Le 04/04/2013, à 12:07

Re : Retour d'expérience méthode SCRUM

#5 Le 04/04/2013, à 14:22

Re : Retour d'expérience méthode SCRUM

#6 Le 04/04/2013, à 14:32

Re : Retour d'expérience méthode SCRUM

#7 Le 04/04/2013, à 15:06

Re : Retour d'expérience méthode SCRUM

#8 Le 04/04/2013, à 15:43

Re : Retour d'expérience méthode SCRUM

#9 Le 04/04/2013, à 15:46

Re : Retour d'expérience méthode SCRUM

#10 Le 04/04/2013, à 15:57

Re : Retour d'expérience méthode SCRUM

#11 Le 04/04/2013, à 16:05

Re : Retour d'expérience méthode SCRUM

#12 Le 04/04/2013, à 16:21

Re : Retour d'expérience méthode SCRUM

#13 Le 04/04/2013, à 16:25

Re : Retour d'expérience méthode SCRUM

#14 Le 05/04/2013, à 15:53

Re : Retour d'expérience méthode SCRUM

#15 Le 05/04/2013, à 16:09

Re : Retour d'expérience méthode SCRUM

#16 Le 05/04/2013, à 17:26

Re : Retour d'expérience méthode SCRUM

#17 Le 05/04/2013, à 17:43

Re : Retour d'expérience méthode SCRUM

#18 Le 05/04/2013, à 18:26

Re : Retour d'expérience méthode SCRUM

Pied de page des forums