Dans quelle mesure un sprint doit-il être détendu (ou non)?

Quelle devrait être l'attitude à l'égard de la réalisation d'histoires attribuées à un sprint? Évidemment, vous voulez donner la priorité à leur réalisation dans le sprint, mais pour moi, tout l'intérêt de l'agilité est d'être dynamique: vous ne voulez pas tergiverser délibérément ou faire en sorte que "ok" manque de terminer les user stories dans un sprint, mais à en même temps, lorsque des choses inattendues surviennent et que ces histoires ne sont pas terminées et sont poussées au sprint suivant, vous ne voulez pas avoir le sentiment d'avoir fait quelque chose de mal. Cela ne devrait pas être une expérience effrayante ou négative, n'est-ce pas?

Les expériences négatives / effrayantes sont-elles acceptables pour les engagements de sprint manqués? Les développeurs devraient-ils être tenus responsables des engagements de sprint manqués lorsque des tâches imprévues surviennent et doivent être traitées (par exemple, le soutien à la production)?

Vous devez absolument viser à obtenir des éléments dans un sprint.

L'un des principaux avantages de SCRUM est qu'il donne au projet un «rythme cardiaque».

Vous priorisez, choisissez des éléments dans une liste, vous les livrez, vous les faites une démonstration, vous reflétez comment ils se sont déroulés, puis vous le faites à nouveau dans des cycles prévisibles.

L'ensemble de la planification, des estimations et des priorités est basé sur ce concept. Que nous pouvons et que nous nous engageons à faire X points dans le sprint, et que, au fil du temps, nous puissions établir une vitesse à partir de laquelle nous pouvons utiliser pour une meilleure planification.

Si vous êtes trop décontracté sur le contenu et les engagements de vos sprints, SCRUM tombe en panne à mon avis et vous perdez beaucoup ses avantages.

Bien sûr, le monde réel aura parfois quelque chose à dire à ce sujet, mais cela devrait être l'exception plutôt que la règle ...

La clé est qu'il doit y avoir une responsabilisation pour ne pas terminer les histoires.

Cela signifie qu'il devrait y avoir une raison solide pour laquelle une histoire n'était pas complète, et que cette raison est prise en compte dans le plan de projet à l'avenir, de sorte qu'elle n'est pas répétée.

Cette raison doit être plus qu'un vague "truc est apparu".

Par exemple, si une histoire n'est pas terminée parce qu'un membre de l'équipe a dû travailler sur un problème de production, cette possibilité doit être envisagée dans les itérations futures - soit en prévoyant moins d'heures de la part de ce membre de l'équipe ou en organisant une autre couverture.

Si la raison aurait pu être évitée avec plus de diligence ou de travail acharné, alors, oui, cette responsabilité peut être un peu douloureuse. Avec un peu de chance, la douleur vient de la variété "C'est ce que nous devons faire mieux la prochaine fois" plutôt que de la variété "Vous ne faites pas votre travail".

Cela ne devrait pas être une expérience effrayante ou négative, n'est-ce pas?

Si cela se produit une ou deux fois, non, cela ne devrait pas être une expérience négative. Si cela se produit régulièrement, vous avez un problème. L'équipe est alors toujours surmultipliée. Améliorez votre estimation et réfléchissez bien à ce que vous vous engagez pour un sprint, mais ne vous inquiétez pas.

Des sprints détendus signifient que vous avez eu un sous-engagement.

Les sprints non détendus signifient que vous avez eu un engagement excessif.

Je livre juste ce que je m'engage et j'essaye de m'améliorer. Ce n'est que dans des circonstances spéciales que je déplacerais une histoire au prochain sprint. Je préfère avoir une légère pression tous les jours que d'avoir un enfer de pression peu avant certaines échéances.

Sur la base de mon expérience - Comme toute autre chose en agile, nous nous adaptons à un système de feedback continu incluant l'estimation.

Il est normal de manquer une date limite pour le premier sprint (début du projet) mais vous APPRENEZ de ce qui a mal tourné (sous-estimation, ne pas connaître les forces de l'équipe, etc.). Ensuite, vous prenez les commentaires et les alimentez au prochain sprint et vous obtenez une meilleure estimation.

D'après mon expérience, cela fait 11 mois sur mon nouveau projet agile que nous manquons rarement l'échéance maintenant, voire pas du tout. Mais nous avons manqué la date limite pour le premier sprint car nous ne connaissions pas le rythme et la force des membres de notre équipe.

Certaines personnes soutiennent que "allouer" plus de temps pour le premier sprint pour surmonter le premier problème de sprint.

Il est intéressant de voir les réponses / commentaires ici. Sur tous les projets (de type) agiles sur lesquels j'ai travaillé, le principal avantage était de répartir la pression des délais sur de nombreuses mini-échéances plutôt qu'une marche de la mort à la fin d'un projet. OMI, les sprints doivent être pris au sérieux. Tout retard dans la date limite ou la fonctionnalité livrée doit être considéré comme un problème potentiel de gestion ou de développement de projet.

Les processus agiles favorisent le développement durable. Les sponsors, développeurs et utilisateurs devraient pouvoir maintenir un rythme constant indéfiniment. - Principes derrière le Manifeste Agile

Si c'est une expérience effrayante ou négative, et cela arrive tout le temps, vous avez un problème. Le développement de logiciels devrait être amusant. Pas négatif ou effrayant.

Cependant, si l'équipe s'engage à terminer certaines histoires dans un sprint et à ne pas livrer en continu, vous avez également un problème. Ce problème ne sera certainement pas résolu en augmentant la pression sur l'équipe pour terminer les histoires. Si le problème est dû à des facteurs externes, ceux-ci doivent être gérés. Si l'équipe sur-engage, le ScrumMaster peut guider l'équipe vers l'engagement sur moins de points d'histoire. Il peut y avoir de nombreuses raisons et chacune doit être traitée différemment. Une équipe énergique et motivée devrait avoir beaucoup de motivation pour aller de l'avant.

Quel que soit le problème, idéalement, il est soulevé lors de la rétrospective et corrigé.

Cela ne devrait pas être si compliqué pour l'équipe de comprendre ce qu'elle peut accomplir pendant la période relativement courte du sprint, puis de l'accomplir (une histoire occasionnelle qui est poussée au sprint suivant est OK, la vitesse peut fluctuer, les choses changent, etc. .). Si vous ne pouvez pas le faire raisonnablement bien après quelques sprints, vous faites quelque chose de mal.

Cela dépend vraiment de votre chronologie.

Parfois, vous aurez BESOIN de terminer toutes les histoires, ou la plupart d'entre elles de toute façon. Bien qu'Agile offre une certaine flexibilité, vous devrez également réaliser le projet, éventuellement dans un délai serré. Ainsi, la plupart des histoires réalisées vous permettront de réaliser votre projet à temps.

Cela dit, cependant, des choses vont arriver qui vous empêcheront de terminer chaque histoire, chaque sprint.

Si le produit est sur une chronologie et que des histoires clés sont manquées, cela peut rendre le produit en retard. Le retard du produit dans certains cas peut nuire à la position concurrentielle d'une entreprise. Donc, dans ce cas, vous voudrez peut-être que ce soit une expérience négative d'avoir des histoires manquantes - cela pourrait vous faire tout faire la prochaine fois.

Lorsqu'il est correctement dosé, le stress est bon. Vous ne voulez pas supprimer tout le stress, vous voulez simplement le répartir plus uniformément dans le temps. Même lorsque vous jouez à votre jeu préféré, vous aurez une certaine quantité de stress et de sentiments négatifs. En fait, vous en tirez plus d'énergie.

Une équipe devrait vraiment se sentir mal à propos des histoires manquées. Cela leur donnera de l'énergie pour changer quelque chose la prochaine fois (travaillez différemment ou planifiez moins d'histoires, les deux sont bonnes). Ils devraient également se sentir fiers lorsqu'ils font leurs histoires, bien sûr.

Vous mentionnez également des tâches inattendues (assistance à la production). Cela soulève un drapeau rouge avec moi. Il aurait dû y avoir un calendrier convenu pour toutes les questions sans rapport avec les histoires. Sinon, le jeu n'est pas juste, l'équipe se sent impuissante et les sentiments négatifs ne sont pas utilisés pour s'améliorer.

Vous devez examiner les facteurs qui font échouer vos engagements et essayer de les corriger. De grandes quantités d'événements aléatoires continueront de perturber vos sprints, rendant votre vitesse imprévisible. Soit corrigez les causes de cela ou introduisez du mou dans vos sprints. Je préfère fixer.

Quoi qu'il en soit, l'équipe ne peut être tenue responsable si son travail est perturbé par des facteurs externes. Utilisez des rétrospectives pour examiner cela.