Travailler dans un cadre Scrum ?
Dans la boîte où je fais de la prestation informatique, ils sont en train de mettre en place la méthode Agile et plus spécifiquement le cadre Scrum. J'avoue être assez ignorant sur le sujet, j'en ai beaucoup entendu parlé, je commence à me documenter mais est-ce que certains chouals ont déjà eu à travailler dans ce type d'organisation, quelles sont les choses que vous avez aimés et pas aimés ? Et est-ce que vous me conseillez des lectures ou des trucs particuliers ?
On fait ça dans notre boite de manière "light". Et c'est plutôt pas mal. Pour le context on est : 1 chef technique, 2 dev (dont moi), 1 testeur
On fonctionne en "sprint", période de 3-4 semaines.
Avant que le sprint ne commence, on chiffre le temps qu'on estime nécessaire à la réalisation d'une tache spécifique (parmi une liste de tache qu'on pourrait développer dans notre service car nous ne développons pas pour un client mais pour nous même).
Pour ça on utilise un planning poker (simplifié) https://fr.wikipedia.org/wiki/Planning_poker
On chiffre en jour-homme.
Une fois qu'on a chiffré les taches, notre chef nous prépare un sprint, il sélectionne le nombre taches nécessaire (et prioritaire) pour couvrir la période du sprint.
Puis le sprint démarre, on commence à développer chaque tache une par une.
Pour avoir un suivis, tous les matins on fait un scrum meeting. On se retrouve devant le "kanban" (j'y viens après) et chacun notre tour on doit dire :
- Ce qu'on a fait la veille
- Si on bloque, si on a des questions, si on a des remarques, etc
- Ce qu'on va faire aujourd'hui
Avant je me mettais la pression car si j'étais en retard sur ma tache, j'avais l'impression d'être le mauvais élève au tableau, alors que c'est le moment où tu peux demander de l'aide, expliquer pourquoi tu galère, etc
Pendant le scrm meeting, on remplis aussi un kanban. (J'ai mis une photo en bas)
Le kanban est un tableau composé de 4 colonnes : Todo, In progress, Validation et Done. Au début du sprint, on créer un post-it par tache qu'on mets dans la colonne todo.
Quand je choisis une tache à faire, je prends le post-it correspondant et le met dans la colonne in progress. Le post-it possède 3 cases : Le temps qu'on a chiffré avant le sprint, le temps passé dessus et le temps qui reste à faire.
Quand pendant le scrum meeting, je dis ce que j'ai fais la veille, en réalité je place 1 jour-homme dans une case "temps passé dessus", ensuite j'estime à la volé le temps qui me reste à passé sur ma tache.
ex:
| temps estimé | temps passé | temps restant |
| 2.25 | 2 | 0.5 |
Là, on est à la bourre
Quand on cumule toute les "restes à faire", ça nous permet d'estimer si on est en avance ou à la bourre par rapport au sprint en général (C'est la courbe que tu vois sur la photo)
Être à la bourre, c'est pas forcément la grosse panique. Et notre chef nous mets pas la pression pour absolument tenir les délais.
Des fois on repousse la fin du sprint, des fois on annule des taches qu'on a pas commencé et qui ne sont pas très importantes, etc
A la fin du sprint, on met sur le serveur live tous les changements qu'on à fait (après les avoir testé en serveur de test) et le sprint est terminé.
Après le sprint, on se laisse 1 à 2 semaines de répits, pour surveiller si il n'y a pas de bug, en corriger, faire les trucs qu'on à pas trop le temps de faire en sprint.
Mais aussi préparer le suivant et donc refaire un chiffrage. Bien sur chaque sprint passé sert de leçon pour les suivants.
Notre kanban en fin de sprint : https://i.imgur.com/ugiLlGG.jpg
On voit la courbe en rouge qui représente le "reste à faire", elle est plutôt droite , ça veut dire qu'on à ni pris trop de retard, ni trop d'avance.
Y'a des post-it rose en haut, qui sont les budget-temps pour les anomalies, les requetes que nous demande le marketing à l'arrache, la relecture de code.
Et tu peux voir qu'on a commencé une tache et qu'on l'a abandonné en cours de route.
(Par rapport à la photo, s'il y a des post-it rose et jaune. C'est que 1 rose = 1 tache et que chaque tache est découpé en 2-5 post-it jaune)
@Pigcell: Merci beaucoup de ce retour et du temps que tu as passé à expliquer. Par contre, visiblement c'est de la compétence et du sens humain de ton responsable technique que cela dépend. S'il est bon et suit la méthode sans jugement c'est plutôt positif. Mais si c'était juste une machine à faire pisser du code aux autres, ça serait une source de pression supplémentaire. est-ce que mon interprétation est correcte ?
@TontonEd: C'est sur qu'avoir un "point contrôle" tous les matins, ça te laisse pas beaucoup de possibilité pour glander (bon j'y arrive quand même)
Après je pense que même sans cette méthodologie, si le chef est con, il arrivera à mettre du stress et de la pression. Peu importe le cadre de travail.
Donc "source de pression", oui. "supplémentaire", non.
Pour gagner un peu délais, ça se joue pendant le planning poker, c'est le moment où il faut sortir les arguments et essayer de caresser le chef dans le sens du poil :
"Oui mais faut faire plein tests", "il faut que le marketing fasse un retour, donc ça prends AU MOINS 0.5 de plus", "c'est une techno qu'on maîtrise pas", "Après c'est pour toi hein, si tu veux qu'on soit à la bourre", "on mesure pas les effets de bords", "Le dernier sprint on a carrément sous-chiffré !", etc
@Pigcell: pour un project manager, sous estimer le délai d'un projet n'est jamais à son avantage.
Les stand up meeting de 15 minutes qui durent 1h c'est la loose.
Si t'as moyen de mettre ton grain de sel, essai de vraiment (vraiment) forcer le trait pour que ces réunions restent courtes.
Elles sont utiles, mais seulement si elles ne débordent pas. Sinon ça fait perdre du temps à tout le monde.
@Azertsix: j'approuve. On a mis en place un système chez nous. Quand un parle trop longtemps ou de truc inutile,on lève un main. À deux mains levées, il doit s'arrêter.
@Azertsix: Et c'est direct, on lui coupe la parole pour la donner à l'autre. A force, on finit par réfléchir à avoir quelque de concis et utile.
Slt, si tu es développeur. Ca va pas changer beaucoup ta vie.
Tu auras une liste de tâches à faire sur 2,3 ou 4 semaines suivant la longueur d'un sprint.
Le truc chiant c'est les standup meeting qui t'oblige a être là le matin et si le scrum master (moi je l'appelle le scrutum master) est un con, il va fixer ça à 9H00 pour que tout le monde soit bien devant son poste au matin.
En plus c'est d'un chiant...qu'est ce que tu en a foutre de ce que font les autres :)...et plus y'a de monde plus c'est long, plus tu perds ton temps...
Point d'entrée à lire : https://blog.trello.com/fr/methode-agile-scrum-gestion-projet
@athanar: Je ne fais plus beaucoup de dev, mais sachant que je suis généralement celui qui allume les lumières en arrivant le matin, 9h ça ne me pose pas de problème. En tout cas merci pour la lecture.
@TontonEd: Ah ben si tu gère le projet, ca va bien t'aider a avoir une vision constante sur ton projet, ce qui est en train d'être fait, sur ce qui reste à faire, et gérer les demandes du client qui ne sont pas prévues.
Le truc c'est que j'ai jamais vu un projet géré en Agile à 100%...On prend des petits bouts de la méthode, mais jamais tout.
Il faut aussi que le Product Owner joue le jeu et ça c'est plus compliqué.
@athanar: si tu trouves que le stand up ne sert à rien, c'est que tu n'as pas compris l'intérêt...
@Geraven: ça sert juste à contrôler les devs..si ils avancent ou pas, à leur mettre la pression...moi quand j'arrive pas à faire un truc je vais voir un autre dev pour conseil, pas la peine d attendre le lendemain.
@athanar: Tu n'as donc pas compris l'intérêt.
Je suppose que pour toi, le pair programming doit être une méthode pleines d'inconvénients et inutile...
D'ailleurs, si vous parlez de vos problèmes dans un but d'avoir de l'aide dans le stand up, c'est que vous n'avez vraiment pas compris le but du stand up...
C'est sensé être un partage de l'agenda, un partage rapide du travail effectué, et une projection rapide du travail à faire de la journée. Quand on développe à plusieurs, c'est hyper important de savoir ce que font les autres.
Franchement, pour travailler en Scrum depuis 6-7 ans, et de manière générale, en agile depuis une dizaine d'année, je constate que celui qui vous a apporté la méthode ne savait pas du tout ce que c'était... Ni vous apportez l'intérêt de cette méthode.
Et j'ajoute, cela doit se limiter à moins d'une minute par personne. Et encore, en 30 sec, une personne doit avoir faire le tour...
Cela dit, vu que tu t'en fous de savoir ce que font les autres, j'en déduis que tu dois pas taffer sur des trucs avec des implications énormes avec le reste de ton équipe... Ou alors, bon, hein...
@Geraven: ah non le pair programming je trouve ça cool...tu progresses, apprend, réfléchit autrement. Sur tout mes projets j'ai du bosser à 80% en équipe, on ne m'a jamais reproché de pbs de communication ou autre, je voie pas ce qui te permet de dire cela :). J'ai jamais dit que j'utilisais le stand-up pour avoir de l'aide non plus. Pour le stand-up, d'après ce que tu dis le seul intérêt est de savoir ce que font les autres? Je t'écoute.
@athanar: Le principe du stand up, c'est d'énoncer le travail de la veille, et le travail à faire today. En résumé de 30 sec max. Cela permet de savoir où en sont les autres, de savoir comment évolue le planning. Bref, en sprint, cela permet de faire un résumé du board. Cela permet de gagner du temps sur l'organisation.
@Geraven: 30s?j ai jamais vu ça... C était plutôt 2mn min et encore quand la chef de projet dérive pas sur des sujets dont tout le monde se fout et qu ils devraient en parler entre eux...ou en sont les autres? Sérieux à part si un gars travaille sur une fonctionnalité commune qui pourrait me bloquer et dans ce cas je vais le voir pour savoir où il en est où dans une pose café, le reste ben je verrais à la fin du sprint ce qui est fait ou pas...pour moi c est de la poudre de perlimpinpin qui permet de contrôler ce que font les devs et les obliger à venir le matin ( je parle du stand UP pas de tout hein) mais si ça marche pour toi tant mieux .
@athanar: Je pointe, donc bon, venir le matin, c'est inévitable pour moi.
D'ailleurs, je vois pas ce qui est gênant de venir le matin :/
Sinon, c'est bien ce que je pensais, ton scrum master est un âne. Il ne sait pas ce que c'est, ou fait à sa sauce, ce qui est idiot.
Si je comprend bien, tu ne prends pas part aux analyses?
Je sais pas, c'est la première fois que j'entends une telle réflexion. On contrôlerai si on demandait un détail de ce qui est fait, mais c'est pas le but du stand up. C'est sensé être trop bref que pour avoir une réelle idée du temps de travail ou de la qualité, ou quoique ce soit. C'est juste une synchro d'agenda.
@CaptainWaffle: c'est surtout qu'ils adorent utiliser un vocabulaire complexe, même pour des choses simples.
@TontonEd: du coup, tu sais ce que c'est un cadre de travail holistique itératif ?
@CaptainWaffle: itératif oui, mais holistique, tu penses qu'il y a un rapport avec les glory hole et qu'il va falloir que je suce des bites (j'avais pas prévu ça moi) ?
@TontonEd: j'imagine que c'est l'étape au dessus du léchage de cul, je te souhaite bien du plaisir !
Tu vas faire une correction qui va te prendre 5 minutes, elle sera mise en prod que 4 semaines plus tard.
Bon courage
@Offerzo: 4 semaines ? genre la durée de la release ? parce que j'avais compris qu'on devait faire au fur et à mesure du sprint et balancer directe...
@Offerzo: Ah bon ? La méthode Agile c'est plutôt l'inverse sur le principe. Des déploiements continus, plus d'agilité sur les projets, les livraisons, etc
@Offerzo: mise en prod 4 semaine après le développement c'est très rapide.
Et la méthode agile ne demande pas de mise en prod à la fin de chaque sprint mais une release fonctionnelle.
https://m.youtube.com/watch?v=VWhLcgo9z74
Pour dégrossi et partir sur des bases saine.
J'ai fait de l'Agile depuis 2 ans environ, des sprint de 3 semaines. C'est assez original en soi, un peu déconcertant au début, mais ça passe.
Pour moi les points négatifs c'est que la visibilité sur les prochains mois n'est pas toujours nette, et si t'as rien glandé la veille t'es baisé en daily meeting le matin.
En point positif, c'est que tu traites les fonctionnalités par petits bouts, quand ça va te prendre plus d'une semaine c'est qu'il faut bien réfléchir à est-ce que la fonctionnalité est bien pensée.
Notre système c'est :
Première semaine
Lundi :
- matin : chiffrage des choses à faire
- après-midi : suite chiffrage, et début du travail
Mardi : début officiel du sprint
--> chaque matin on se met en rond autour du tableau d'avancement, et on dit rapidement comment ça avance. Pas plus d'une minute par personne, on traite surtout les difficultés rencontrées. En cas de besoin de discussion technique, ça sera après, en privé. En théorie, ça doit pas dépasser 5 minutes au total, puisque l'agile est conçu pour les petites équipes. J'ai déjà testé en équipe de 20, c'est stupide et insupportable.
...
Vendredi matin : Check avec les chefs, voir si tout avance bien, si on a pas de souci, y en a pour 25 minutes (j'en sors là tiens)
Deuxième semaine
...
Vendredi matin : Check avec les chefs, voir si tout avance bien
Troisième semaine
...
Jeudi : on prépare la démo des nouvelles fonctionnalités (ça peut être démo live de l'IHM, ou les nouvelles commandes CLI, ou un ppt même)
Vendredi :
- matin : démo des nouvelles fonctionnalités devant l'équipe, les chefs, et même l'équipe voisine
- après-midi : le chef présente les nouvelles fonctionnalités à faire au prochain sprint, on en discute, et on commence gentiment à chiffrer les plus bizarres pour en re-parler avec le chef.
Résultat, honnêtement, le lundi de début de sprint et le vendredi de fin de sprint, c'est pépère comme journées. On commence un peu avant 10h, on finit vers 17h30, et c'est des réunions pas vraiment chiantes.
Tu ne dois accéder à ce site que si tu as au moins 18 ans ou si tu as l'âge légal pour visionner ce type de matériel dans ta juridiction locale, l’âge le plus élevé étant retenu. En outre, tu déclares et garantis que tu ne permettras aucun mineur à d'accéder à ce site ou à ces services.
En accédant à ce site, tu acceptes nos conditions d'utilisation.