Scrum - Méthodes agiles

1. Le mardi 20 février 2007 à 10:56, par Camille Bloch

Je vais dire à ma société de lire ce billet

2. Le mardi 20 février 2007 à 12:05, par Matthieu

Ok, finalement on continue à s'engager sur des estimations lors des daily scrum meetings, car dire ce que l'on va faire d'ici le prochain scrum est bien une forme d'estimation.

Les différences que je vois par rapport aux pratiques "classiques" est qu'on ne s'engage que d'un jour à l'autre (ce qui rend l'engagement plus facile à maitriser que sur du plus long terme) et qu'on s'engage vis-à-vis de ses pairs (et non vis-à-vis d'un manager qui est un peu extérieur à l'équipe et ne comprend pas bien les difficultés)

Et effectivement je peux imaginer que l'engagement est plus fort vis-à-vis de ses pairs que d'un manager plus distant : l'effet de solidarité joue plus car on vit le projet de la même façon... et puis le "pipeautage" devient difficile... ;o)
D'ailleurs j'imagine qu'en cas d'accrochages c'est plus rude entre pairs qu'avec un manager.

3. Le mardi 20 février 2007 à 14:09, par Stéphane Boisson - site

Le but c'est quand même que les membres de l'équipe n'éprouvent pas le besoin de pipeauter à qui que ce soit..
Qu'on ne travaille plus dans une logique d'ordres et de contrôles par la hierarchie mais dans une logique de collaboration..

4. Le mardi 20 février 2007 à 14:11, par claude aubry

Je reviens sur l'engagement d'une personne de l'équipe pendant le scrum quotidien. Quand elle dit j'estime que la tâche t a un reste à faire de 6 heures et je vais finir la tâche t pour demain, l'engagement qui est retenu par l'équipe est de finir la tâche, ce n'est pas d'y passer 6 heures. Comme on ne mesure pas le temps passé peu importe si on y passera finalement 5 ou 8 heures. C'est différent de s'engager à y passer 6 heures.

5. Le mardi 20 février 2007 à 15:23, par Matthieu

Claude, votre distingo me parait artificiel... ou alors c'est que nous n'avons pas la même vision des projets "classiques" (non agile)

Sur un projet "classique", quand un soir j'estime un reste à faire à 1j sur une tâche, ça veut dire implicitement que je m'engage à avoir fini le lendemain soir (à condition de ne pas être sollicité pour autre chose) et ça signifie que :
- si je n'ai pas fini le lendemain soir je reste plus tard pour boucler... ou j'assume le fait de ne pas avoir tenu mon engagement et je ré-évalue mon reste à faire; dans les 2 cas j'essaie de comprendre ce qui s'est passé (mauvaise estimation, mauvaise productivité, problèmes techniques non prévisibles, etc...) et d'en tirer des leçons s'il y a matière à le faire
- si j'ai fini plus tôt que prévu, je passe bien sûr à la tâche suivante sans attendre d'avoir "consommé" le temps estimé

En fait sur nos projets nous demandons déjà aux développeurs de donner leur reste à faire sans tenir compte de ce qui était estimé au départ et de ce qui a déjà été consommé, et les CP savent bien que les reste à faire annoncés sont à prendre avec beaucoup de précautions tant qu'ils ne sont pas à zéro (le fameux syndrome du "presque fini")
Ca me parait déjà relativement proche de ce que vous préconisez. Pour moi les adaptations à apporter pour se mettre en mode Scrum seraient de :
- faire des tâches plus petites : actuellement nous découpons généralement en tâches de plusieurs jours
- faire un suivi quotidien des reste à faire : nous sommes plutôt sur une base hebdo
- faire le suivi d'avancement collectivement : ça arrive que nous le fassions à certaines occasions, mais en général c'est du tête à tête entre le CP et chaque membre de l'équipe
- il faudrait aussi que le CP se mette en retrait, pour que les engagements se fassent vis-à-vis de l'équipe dans son ensemble et non de lui en particulier

6. Le mardi 20 février 2007 à 15:47, par Matthieu

Stéphane, je pense qu'on ne se lève pas tous les matins en ayant une furieuse envie de travailler (il me semble avoir lu à peu près cette phrase dans un doc sur les méthodes agiles d'ailleurs), et si on est censé faire des tâches fastidieuses et/ou qu'on juge inutiles, la tentation peut être grande de faire d'autres choses bien plus intéressantes (venir discuter agilité sur ce blog par exemple... ;o) ) mais qui dégradent la productivité...

Mais bien sûr la vraie bonne solution à ce genre de problèmes est d'éviter que quiconque ait à faire des tâches fastidieuses et/ou qu'il juge inutiles, plutôt que restreindre les possibilités de pipeautage.

7. Le mardi 20 février 2007 à 17:32, par Camille Bloch

Matthieu, concernant l'estimation d'une tache en "reste à faire", je rejoins Claude sur sont apporche. En effet, dans certaines sociétés, essentiellement celles n'ayant pas une culture du "développement informatique", les responsables ont tendance à dire "tu as mis moins de temps pour finir? ben la prochaine fois, j'enlèverais 10% à ton estimation".

C'est malheureusement la réalité pour certains, dont mon équipe. Et cette habitude est dure à oublier, même lorsqu'on le répète aux membres de l'équipe.

Après, il reste à faire admettre aux supérieurs externe au projet que nous nous engageons sur un contenu pour un sprint, et non sur la durée de réalisation de chaque item...

8. Le mardi 20 février 2007 à 17:36, par Stéphane Boisson - site

Matthieu: Je n'ai pas dit qu'on devait se lever tous les matins en ayant furieuse envie de travailler.. Je sais bien que ca peut arriver pour des raisons diverses de motivation, de problèmes personnels, fatigue, maladie..
Mais pourquoi vouloir absolument le cacher?

Quand à la productivité, je ne pense pas qu'il fasse la réduire au seul rendement.. Un peu de mou de temps en temps (venir discuter agilité sur ce blog par exemple... ;o) ) peut améliorer l'efficacité!

9. Le mardi 20 février 2007 à 21:50, par claude aubry

... ou alors c'est que nous n'avons pas la même vision des projets "classiques" (non agile)

Faire entrer les projets dans 2 catégories : ceux qui suivent un processus agile et ceux qui suivent un processus classique, et les opposer sur tout, est évidemment réducteur. Il faudra que je fasse un billet là-dessus.

Il y a de nombreuses pratiques de gestion de projet qui sont utilisées depuis longtemps et qu'on retrouve dans les processus agiles (par exemple le reste à faire). Mais il y en a aussi qui continuent à être utilisées alors qu'elles sont basées sur des théories considérées comme obsolètes depuis longtemps (comme faire un plan détaillé au début d'un projet et essayer à tout prix de le suivre)

10. Le mardi 20 février 2007 à 23:27, par Matthieu

Donc c'est bien ça : en fait je n'ai pas d'expérience du pur prédictif, et les pratiques que je connais intègrent certaines pratiques ressemblant à ce qui se fait en agile, sans en être vraiment.

Par exemple ça fait longtemps que nous découpons les projets en lots (2 mois de dev maxi) pour éviter l'effet tunnel, cad montrer concrètement au client que ça avance, obtenir du feedback avant la fin de projet pour mieux comprendre la façon de fonctionner de notre client et pouvoir rectifier le tir sur les choses qui ne vont pas. On essaie aussi de livrer très rapidement un lot0 très pauvre fonctionnellement, mais qui permet de se caler avec le client en terme d'architecture technique et de process de livraison (packaging, docs d'install,...)
Et puis on planifie tout à l'avance, mais en se ménageant des marges de manoeuvre pour pouvoir absorber un certain nombre d'imprévus sans impacter la date de livraison : ne planifier les gens qu'à 80%, se ménager une semaine ou deux entre la fin des devs et la livraison pour les tests d'intégration et les corrections associées,... c'est une manière d'essayer de prévoir en étant conscient qu'on ne peut pas tout prévoir

En fait c'est une méthode qui ne marche pas si mal... à condition que l'expression de besoin du client soit mûre et cohérente (donc stable), exprimée clairement, et qu'on ait un peu de mou (chiffrage pas trop serré ou client ayant provisionné un budget pour les évolutions) pour absorder sans heurts les quelques ajustements inévitables.
Le problème est que dans la vraie vie les besoins du clients sont rarement stables, qu'il est difficile de les exprimer clairement, en détail, et sans rien oublier, on est obligés de serrer les prix pour gagner les projets, le client a souvent l'illusion qu'à la fin du forfait il aura une appli qui correspond parfaitement à ses besoins... et c'est là que commencent les tensions à tous les niveaux... :o(

11. Le mercredi 21 février 2007 à 10:07, par Camille Bloch

Et c'est donc là que les processus agile prennent toute leur valeur, grace aux cycles itératifs.

En effet, on peut redéfinir les besoins du client entre chaque itération, rajouter, supprimer ou modifier des besoins.

Et le client, quand il a bien prit le pli est lui même plus content comme ca! Mais les mentalités sont dure à changer...