Comment pouvons-nous réduire les temps d'arrêt à la fin d'une itération?

Là où je travaille, nous pratiquons l’agilité basée sur la mêlée avec des itérations de 3 semaines. Oui, ce serait bien si les itérations étaient plus courtes, mais changer cela n’est pas une option pour le moment.

À la fin de l'itération, je trouve généralement que le dernier jour se passe très lentement. Le travail actuel est déjà terminé et accepté. Il y a quelques réunions (la planification rétrospective et la prochaine itération), mais à part cela, il ne se passe pas grand chose.

Quelles techniques pouvons-nous utiliser en tant qu'équipe pour maintenir notre élan jusqu'au dernier jour? Faut-il traiter les défauts? Commencer tôt le travail de la prochaine itération de toute façon? Autre chose?

J'ai eu du mal avec la même question un peu ces derniers temps. Nous commençons à la prochaine itération, mais j'estime que cela supprime la satisfaction d'une itération bien faite.

Je pense à l'option de laisser le soin aux développeurs, avec l'avertissement "tant que l'intention est de profiter à la société".

Exemples:

• Passez la journée à apprendre quelque chose
• Dépensez-le sur un projet de temps d'innovation
• Passez du temps à ranger ce morceau de code ennuyant que vous ne parvenez jamais à refactoriser
• Parcourez l'application en vue de l'expérience utilisateur (ce que nous ne semblons jamais trouver le temps de faire autrement)

Quel que soit ce qui motive le programmeur, incitez-le à livrer la publication à temps.

Prenez le jour de congé. Vous avez fait le travail que vous étiez censé faire, alors pourquoi travaillez-vous toujours?

Si un changement de processus était possible, envisagez de supprimer les itérations, de publier régulièrement, et continuez simplement à éliminer les récits de l'arriéré. Mais ne méritez-vous pas un peu de temps mort?

J'ai remarqué le même problème (et nous utilisons parfois des sprints de 2 semaines, ce qui l'exacerbe encore plus). Ce que j’essaie de faire ces jours-là (jour de révision du sprint et jour de planification du sprint), c’est de sauvegarder un travail que je voudrai faire, mais qui ne nécessite pas beaucoup de planification ou de communication intrateam, comme les bugs de faible priorité, le polissage, etc. ou des améliorations d'outils. Parfois, cela devient réellement positif, car cela crée un bon moment pour faire un travail important mais non sexy pour lequel il serait difficile de prendre du temps.

Même si nos user stories sont presque toujours terminées à la fin d'une itération, nous avons toujours une longue liste de «gentils à avoir» à la fin, ainsi qu'une liste de bugs connus. Alors, quand les gens finissent leurs histoires, il y a toujours beaucoup à faire.

Je pense que faire des réunions rétrospectives est roi, même si ce sont principalement les mêmes problèmes que ceux qui sont soulevés, il est très important de passer un peu de temps à réfléchir à la manière dont s'est passée l'itération, comment allez-vous apprendre, si vous ne réalisez pas vos erreurs et les choses qui se sont bien passées.

Si tous les bugs sont résolus, une longue liste de choses à faire mieux a été faite, ainsi que des points d'action, je pense que c'est bien de réunir l'équipe devant un grand écran et d'essayer de jouer avec le logiciel qui a été construit, avec quelques bières. Ce n'est pas extrêmement productif, mais c'est bien de parler de ce qui a été mis en œuvre et de son fonctionnement.

Si vous avez des jours, j'essaierais de trouver quelque chose de nouveau à apprendre et d'essayer de jouer avec, peut-être que ce sera la prochaine grande chose. Mais encore une fois s'il y a des jours, il y a probablement une histoire d'utilisateur dans le carnet de commandes à faire

Nos itérations se terminent le jeudi afin de pouvoir résoudre tout problème de dernière minute le vendredi. Mais ces vendredis (un toutes les deux semaines) coïncident avec nos vendredis de la bière, nous essayons donc de le prendre très calmement. Corrigez quelques bugs mineurs, passez du temps à lire des choses (livres, StackExchange, blogs, etc.) et détendez-vous avec une bière à la fin de la journée. Sinon, vous ne ressentez pas l'achèvement ou la fermeture et vous avez plutôt l'impression d'être un hamster qui tourne sans arrêt dans une roue.

Je ne suis pas sûr que vous vouliez toujours terminer exactement à l'heure. Faire votre travail un peu tôt vous permet de penser à de futures histoires, capacités et fonctionnalités. Cela vous laisse un peu de pause après un travail bien fait, ce qui peut être plus gratifiant que de commencer tôt, de s’engager dans plus d’histoires et d’avoir toujours du travail reporté.

Ken Schwaber déclare dans son blog http://kenschwaber.wordpress.com/2010/06/10/waterfall-leankanban-and-scrum-2/

"Que Dieu nous aide. Les gens ont trouvé le moyen de se détendre dans la cascade, de se reposer et de faire preuve de créativité. Avec Lean et Kanban, ces cachettes sont supprimées. Nous avons maintenant une marche de la mort progressive sans pause."

Sur mes projets, lors de la planification des itérations, nous sélectionnons toujours des tâches supplémentaires et nous les étiquetons comme des "tâches supplémentaires" sur lesquelles travailler si toutes les tâches de l'itération sont terminées. De manière pragmatique, ces "tâches bonus" sont généralement ce sur quoi on travaillerait en premier lors de la prochaine itération de toute façon, mais les appeler chimiquement "tâches bonus" fonctionne beaucoup mieux alors simplement avoir toujours plus de travail planifié, puis être achevé.

Pour d’autres choses telles que le temps d’apprentissage ou d’innovation, nous permettons simplement à chaque développeur de consacrer jusqu’à une journée par semaine à ce genre de choses, comme il se doit normalement. Cela peut être n’importe quel jour de la semaine (c’est-à-dire que ce n’est pas nécessairement à la fin de chaque semaine).

Tous les développeurs de mon équipe utilisent le temps libre vers la fin d'un sprint (à condition que toutes les tâches de sprint soient terminées) en tant que "temps Google".

C'est là que chaque développeur travaille sur sa propre idée / projet tant que cela profite à l'entreprise. Je suggère fortement de mettre en place un système comme celui-ci, cela a vraiment augmenté les niveaux de satisfaction au travail au sein de notre équipe.

Si vous finissez constamment trois jours à l'avance, cela me donne à penser que vous ne prévoyez pas assez d'histoires pour le sprint.

L'un des objectifs de Scrum est d'augmenter la productivité - vous ne le ferez pas si vous tirez à chaque sprint.

Pour résoudre ce problème, planifiez plus d'histoires que vous ne l'avez été. Ne vous engagez que dans votre précédente vélocité, mais si vous avez terminé, commencez à travailler sur les histoires supplémentaires. Si vous terminez plus, augmentez votre vélocité pour le prochain sprint. Prévoyez toujours un peu plus que ce à quoi vous vous engagerez, ou du moins, mettez quelques histoires en perspective, au cas où.

C'est l'une des raisons pour lesquelles nous avons opté pour le Kanban. Tous les avantages de la mêlée sans avoir à continuer à rompre avec le projet.

J'aime la réponse de Todd de prendre le jour de congé, mais je dirais qu’essayer de faire la planification et la rétrospective du sprint le matin et de fixer un défi pour le faire à temps pour le déjeuner puis prendre un long déjeuner en équipe. Au déjeuner, encouragez la discussion sur le sprint afin d’obtenir une rétrospective informelle gratuitement.

Si vous ne pouvez pas abandonner l'après-midi (et je veux dire en rentrant chez vous en début d'après-midi et non en fonction de vos objectifs après-midi), abordez la dette technique, car c'est le seul élément qui déprime le développeur (source : à mon avis) avoir à travailler sur la dette technique quand ils savent exactement comment y remédier et leur faciliter la vie.

Personnellement, j’ai constaté que les rétrospectives ne valent pas vraiment la peine de perdre du temps; il existe généralement quelques thèmes récurrents (mauvaises histoires d’utilisateurs, mauvaise estimation, etc.) et vous ne les acceptez que comme des problèmes et vous passez à autre chose. Nous essayons également de traiter les problèmes au fur et à mesure qu'ils se présentent, plutôt que d'attendre la rétrospective (ce que nous avions tendance à faire dès les premières étapes de l'adoption de Scrum).

Désormais, au lieu d'avoir une rétrospective, chaque couple de développeurs sélectionne un élément en suspens dans l'arriéré rétrospectif existant et y travaille.

Nous conservons également un arriéré de dette technique en continu, qui constitue un bonus pour les sprints (si l'entreprise n'est pas prête à mettre en œuvre quelque chose de son arriéré à l'avance).

Cela s’est déjà avéré très positif, dans la mesure où tous les petits articles qui continuent de bouillonner sous la surface font l’objet d’une journée d’attention à chaque sprint.

Organisez une session de conception de tableaux blancs et partagez des idées de mise en œuvre pour des histoires intéressantes sur le sprint à venir. Faites cela après la séance de planification, où les histoires étaient encore peu éclairées et jugées selon leur taille ou leur taille estimée. Gardez la session informelle et encouragez la créativité.