Comment structurez-vous un sprint de développement? [fermé]

Question

J'ai donc un arriéré de fonctionnalités et nous sommes sur le point de démarrer un projet de grande envergure. Je travaille sur la définition de la structure de nos sprints et je suis intéressé par les commentaires des communautés.

Ce que je pense, c'est:

• Planification d'un sprint d'une journée
  • Remplissez le carnet de commandes et déterminez le résultat de chaque sprint après ce sprint
• Trois semaines de développement
  • GO! ALLER! GO!
• réunion journalière
  • Vérifiez si quelqu'un a besoin d'aide ou ne se sent pas à l'aise
• Deux jours de bilan de sprint
  • les revues de code ont lieu ici, les présentations des parties prenantes
• Rétrospective d'un jour au sprint
  • qu'avons-nous fait lors du dernier sprint? comment pouvons-nous faire mieux la prochaine fois?

Les sprints doivent toujours se terminer un mardi (pour éviter un stress excessif le week-end).

Autre chose? Il y a évidemment plus d'agilité que cela. Je souhaite fournir à l'équipe un aperçu simple de la manière dont nous allons fonctionner lorsque ce projet sera lancé.

Answer 1

J'envisagerais d'expérimenter des sprints de moins d'un mois.

Personnellement, je trouve les itérations d’une semaine ou deux plus efficaces pour obtenir rapidement des commentaires efficaces. Cela évite également tout problème susceptible de causer des problèmes au niveau des itérations, voire des problèmes de gestion.

Même pour le sprint de 30 jours - deux jours semblent durer un jour trop longtemps pour la révision du sprint ... et un jour environ 0,5 jour de trop pour la rétrospective. J'ai constaté que si vous aviez besoin de beaucoup plus que cela, il y avait des problèmes de communication alors que les itérations se poursuivaient. Vous voudrez peut-être envisager de longs examens comme un drapeau rouge possible.

Bien sûr, c’est ce que je viens d’expérimenter: développer principalement des applications Web avec de petites équipes composées de 4 à 12 personnes. Votre expérience peut varier.

Cela dit - je tenterais certainement des sprints plus courts. Comme les versions d'intégration: beaucoup de choses deviennent plus faciles si vous les faites plus souvent.

Answer 2

Désactivez les applications de messagerie, de téléphone portable et de messagerie instantanée pendant la durée du code. 10h à 13h, 14h à 17h pourraient être de bons blocs pour cela.

Commandez de la nourriture et des boissons pour les membres de l’équipe lorsqu’ils se trouvent dans la "zone".

Annulez toutes les autres réunions pour les jours de, avant et après la session de planification et les jours de révision.

Answer 3

• Assurez-vous que le " stand-up " reste un stand-up. Il est très facile de glisser dans des réunions de plus en plus longues.
• Un jour de planification du sprint et trois jours à la fin peut être trop long. Planifiez uniquement le temps dont vous avez besoin.
• +1 à l'idée d'itérations plus courtes. Personnellement, quatre itérations d'une semaine dans un sprint ont bien fonctionné. Les gens sont doués pour estimer les tâches à court terme; passé que cela devienne de plus en plus de devinettes.

Answer 4

Cela semble être une bonne approche. Je partage ce que Adrianh et Jedidja ont dit à propos d’itérations peut-être plus courtes. J'aime 1 weekers moi-même. En plus d'une meilleure estimation, il conserve également l'idée de "logiciel de travail". sur un cycle beaucoup plus court.

Quelques questions:

Pourquoi les révisions de code sont-elles laissées jusqu'à la fin? Programmez en binôme ou faites vos critiques au fur et à mesure.

Est-ce que 3 semaines de développement signifient "dev, test, documentation, installateurs, etc." ? C'est à dire. tout ce dont vous avez besoin pour être vraiment fait?

Answer 5

Nous structurons nos sprints de manière très similaire à votre plan sauf que nos critiques de sprint sont le dernier jour du sprint et durent généralement environ une heure. La révision du sprint est le moment où vous exposez votre travail aux clients et à toute autre partie intéressée, pas le temps de réviser le code. Les révisions de code, si vous choisissez de les faire, doivent être effectuées périodiquement tout au long du sprint. Nous avions l'habitude d'avoir un bloc d'une heure chaque semaine où nous examinions le code proposé par les développeurs, ce qui signifiait que nous ne perdions pas de temps à revoir chaque lettre de crédit écrite.

Nous clôturons également nos sprints un mardi et commençons un jeudi, laissant mercredi à la table pour régler les points faibles et régler la dette technique créée lors du sprint.

Answer 6

Je ne recommande pas de reporter les révisions de code avant le sprint, elles devraient faire partie intégrante du processus de développement. En d’autres termes, une tâche n’est effectuée que si le code a été révisé (testé, documenté et ...).

Answer 7

Il est important de ne pas gérer pour gérer. SCRUM nécessite seulement 1 réunion par jour, et celle-ci est courte. De plus, lors de chaque sprint, les seules autres réunions sont la rétrospective Spring et la planification du sprint. Cela nous permet de mettre en œuvre ROWE ou un environnement de travail axé sur les résultats. Laissez vos développeurs décider comment, où et quand ils feront leur développement. Servez-vous de vos rencontres quotidiennes pour suivre le travail accompli. En dehors de cela, restez en retrait et laissez-vous étonner par leur productivité.

Des idées telles que "éteindre les téléphones portables, les applications de messagerie instantanée, etc. pendant le codage". sont toutes de mauvaises idées. Lorsque vous embauchez votre équipe, vous l'embauchez en sachant qu'elle saura bien faire son travail. Si vous les avez embauchés avec cette compréhension, pourquoi voudriez-vous limiter leur capacité à faire leur travail de la meilleure façon possible? Si vous utilisez SCRUM, chaque développeur aura choisi le travail qu’il pense pouvoir effectuer. Votre travail en tant que Scrum-Master consiste à supprimer les obstacles, pas à les créer.

Code Reviews: Absolument nécessaire. Les revues de code par les pairs sont un excellent outil pédagogique pour les développeurs débutants participant à des réunions et pour les personnes ayant révisé leur code.

Documents de conception: Personnellement, j’estime que les documents de conception détaillés décrivant ce que le développeur compte faire est très important, et j’estime également qu’ils jouent un rôle important dans le processus de développement. À présent, cela ne correspond pas spécifiquement au développement agile, mais je me réfère régulièrement à des documents de conception créés il y a des années pour voir ce que le développeur original pensait quand ils ont codé leurs modules.