Dans Scrum, comment gérer les conflits / la charge de travail à la fin du sprint

Mon équipe a commencé à utiliser Scrum il y a quelques sprints. Notre projet consiste à créer un logiciel d'interfaçage avec des appareils physiques (pensez aux robots et aux capteurs) et notre backlog produit typique représente généralement l'ajout d'un appareil de contrôle à l'ensemble du système.

Nous avons divisé la tâche près de l'exemple ici . Chaque fonctionnalité d'intégration de périphérique est divisée en code, tests, tests d'intégration, examen par les pairs, etc. De toute évidence, il existe une séquence inhérente à chaque élément de backlog de produit. En règle générale, nos sprints durent 2 semaines et l'équipe compte entre 4 et 6 membres.

Nous rencontrons 2 problèmes à la fin des sprints:

• Le premier est de garder tout le monde occupé à la fin du sprint.
• La seconde (liée) est la contention sur le système. On finit par s'intégrer au cours des derniers jours du sprint. Nous n'avons qu'un seul système d'intégration, donc les gens sont souvent empêchés de continuer à travailler sur leur tâche parce qu'ils ne peuvent pas accéder au système. Comme c'est la fin du sprint, il n'y a pas beaucoup de travail à faire dans le backlog du sprint. Sur quoi ces personnes devraient-elles travailler? Le retrait des articles en haut du carnet de produits n'est pas bien reçu du propriétaire du produit, car les articles actuels ne sont pas terminés. Travailler sur la dette technique aidera le projet dans son ensemble mais n'aidera pas à terminer le sprint.

Existe-t-il des meilleures pratiques pour structurer les sprints afin d'éviter ces problèmes? Des conseils pour négocier avec les propriétaires de produits?

à certains égards, il est bon que vous soyez lent à la fin d'un sprint, cela signifie que vous estimez bien et que vous ne vous engagez pas trop, en ce qui concerne l'occupation, sur les équipes de mêlée sur lesquelles j'ai travaillé, nous avons toujours ajouté des tâches de recherche pour ce qui s'en vient ensuite sprint.

Cela pourrait être une preuve de concepts pour les choses à venir, ou chercher où re-factoriser le code existant, travailler à obtenir une meilleure couverture de test sur votre code, etc.

Vous devez corriger votre système d'intégration afin que votre équipe puisse intégrer son travail dès que chaque tâche est terminée, plutôt que d'attendre un big bang à la fin du sprint.

Je recommande de travailler avec des user stories suffisamment courtes pour être terminées en quelques jours. Terminé ici signifie code complet, testé et intégré.

En se rappelant qu'il est de la responsabilité de toute l'équipe de livrer, et non des membres individuels en soi , il est possible que les quatre à six membres travaillent ensemble sur chaque tâche - pousser chacun à travers le processus et passer à la suivante. Cela peut sembler inefficace au début, mais si les goulots d'étranglement que vous voyez sont si mauvais, cela peut être une option valide.

En outre, vous voudrez peut-être examiner la théorie des contraintes ( Le but de Goldratt ) et voir comment vous pouvez mieux analyser pourquoi et où vous avez ces goulots d'étranglement d'intégration.

Nous avons résolu ce problème en adoptant l'approche Kanban.

Nous avons des files d'attente dans notre logiciel de suivi (Jira) avec un minimum et un maximum.

Nous toilettons «au besoin». Peut-être une fois par semaine, peut-être 3 fois, dépend des limites et du travail qui est fait.

Cela vous aidera à concentrer le propriétaire du produit sur la conservation de votre file d'attente et à réduire la micro-gestion des tickets individuels. N'oubliez pas que, comme toujours, le changement prendra du temps.

Nous avons toujours une démo toutes les deux semaines et nous sortons chaque semaine.

Wow, si vous n'avez pas dit de robots, je suppose que vous étiez dans mon équipe en ce moment. Nous avons exactementmême ensemble de problèmes. Ayant travaillé sur de nombreux projets agiles avec différents degrés de fidélité au manifeste et divers degrés de succès, mon analyse est que notre problème est que les sprints sont trop courts. Nous faisons des sprints de deux semaines, ce qui pose quelques problèmes. La première est que nous finissons par être trop prudents dans la planification et nous retrouvons souvent avec des jours morts à la fin. Deuxièmement, il y a l'énorme surprise de l'examen, de la rétrospective et de la planification qui prend 1-2 jours toutes les deux semaines. Un autre est, comme vous l'avez dit, de devoir s'intégrer à la dernière minute et échoue souvent avant l'examen. Mon premier projet agile et le plus réussi a eu des sprints de quatre semaines, ce qui, je suppose, est assez énorme par rapport aux normes de l'industrie, mais cela a très bien fonctionné pour nous.

EDIT: Je me suis souvenu d'une chose de plus de ce premier projet qui était une aubaine. Nous avons toujours eu un backlog de produits entièrement priorisé et avons donné aux développeurs la liberté d'en extraire des tâches si leurs tâches de sprint étaient terminées et qu'aucune autre tâche de sprint n'était disponible.

Le deuxième problème est probablement une conséquence de la tentative de résolution du non-problème n ° 1. Vous devriez amener des gens qui ne sont pas occupés à aider leurs pairs; au lieu de travailler sur des tâches non sprint, ce qui provoque des conflits sur l'intégration limitée.

De plus, vous ne devez pas vous intégrer à la fin du sprint, mais en continu.

Vous commencez tout juste. Donnez aux équipes une chance de s'attaquer elles-mêmes à ce problème par le biais de leur processus rétrospectif.

Deuxièmement, votre propriétaire de produit doit faire confiance à l'équipe pour savoir comment s'organiser et s'optimiser au mieux. En retour, l'équipe fait confiance au bon de commande pour connaître au mieux les besoins du client.

Ce sont des défis très courants avec de nouvelles équipes agiles. Super de voir quand une équipe commence à briser ses propres silos et à grandir.