Mon équipe se familiarise avec Scrum, mais la plupart d'entre nous connaissent mieux les méthodologies non agiles ou "pseudo-" agiles. La partie qui est le plus gros obstacle pour nous est l'organisation d'une réunion de planification de sprint efficace où nous divisons nos éléments de carnet de commandes en tâches et estimons les heures. (J'utilise la terminologie du modèle Scrum VS2010; excuses si j'utilise le mauvais mot quelque part.)
Lorsque nous essayons de comprendre combien de temps une tâche va prendre, nous tombons souvent dans le piège de la conception de la fonctionnalité au niveau du code - disposition des tables, interfaces, etc. - afin de comprendre combien de temps cela va prendre .
Je suis sûr que ce n'est pas l'endroit approprié pour faire ce genre de conception. Nous devrions planifier des tâches pour ces réunions de conception pendant le sprint. Cependant, nous avons du mal à trouver comment proposer des estimations significatives pour les tâches.
Existe-t-il des habitudes / techniques / etc. pour avoir rendu un jugement sur la durée d'une fonctionnalité, sans savoir comment vous prévoyez de la mettre en œuvre? Si nos estimations de temps vont changer de manière significative une fois la conception terminée, comment pouvons-nous correctement budgétiser notre backlog Sprint à l'avance?
ÉDITER:
Juste pour clarifier, car certains des commentaires / réponses sont très valables mais je pense que répondre à la mauvaise question.
Nous savons que ce que nous faisons n'est pas juste et que nous devrions consacrer du temps au sprint pour cette conception. Conceptuellement, tous les développeurs le comprennent. Nous avons également amené un membre de l'équipe avec une expérience Scrum pour nous garder sur la bonne voie si nous commençons à nous lancer dans les mauvaises herbes.
Le problème est que, sans passer par ce processus de conception, nous avons du mal à fournir des estimations de temps concrètes pour quoi que ce soit. Nous disons constamment des choses comme «eh bien, si nous le concevons de cette façon, cela pourrait prendre 8 heures, mais si nous finissons par devoir le faire autrement, cela prendra environ 32 heures, mais ce ne sera peut-être pas aussi mauvais une fois que nous commencerons à l'écrire. ... ".
Je suppose également que ce processus s'améliorera une fois que nous aurons une certaine vitesse historique à partir de laquelle travailler, mais bon nombre des technologies et des modèles architecturaux que nous utilisons sont nouveaux pour nous. Mais si les estimations potentiellement faussement erronées ne sont qu'une partie naturelle de l'adaptation de ce processus, nous aurons juste besoin de nous reconditionner pour l'accepter :)
Réponses:
Planifiez une réunion de "toilettage" récurrente où vous aurez ces discussions sur la conception. L'équipe dans laquelle je fais partie les a une fois par sprint, la veille de la planification. Le but ici est d'avoir le design suffisamment cloué pour que l'équipe puisse se mettre d'accord sur les estimations de temps pour l'histoire globale. Vous pourriez envisager de répartir les tâches au cours de cette réunion, de sorte que la planification devienne purement un exercice pour décider de la quantité à ramasser. En d'autres termes, vous devriez faire la conception dans les sprints AVANT de commencer à faire le travail réel.
Envisagez d'utiliser la planification du poker , c'est-à-dire des points / unités d'effort plutôt que des jours-hommes pour estimer les tâches. Essayez également de décomposer les histoires autant que possible. Plus une histoire est longue / complexe, moins il est probable que votre estimation sera exacte.
Lors de la planification, le Scrum Master doit maintenir la planification sur la bonne voie en mettant un terme à toutes les discussions qui vont trop loin dans la «résolution». À ce stade, les membres de l'équipe doivent rapidement parvenir à un accord sur l'estimation, en donnant généralement un nombre maximum / pire cas. Il est beaucoup plus facile de prendre plus de travail si les tâches finissent par être plus faciles que vous ne le prévoyez, plutôt que de faire face à des retards dans les plannings car les tâches prennent plus de temps que prévu et les histoires se déroulent en plusieurs sprints.
Parlez de la façon dont les estimations se sont déroulées dans la rétrospective à la fin du sprint. Surtout s'il y en avait qui étaient remarquablement éloignés. L'équipe a-t-elle appris quoi que ce soit de l'histoire par rapport à la façon dont ils s'attendaient à ce qu'elle se déroule? Le Scrum Master doit rester concentré sur les changements réalisables qui peuvent être apportés à votre processus de conception / estimation.
la source
Je pense que le problème est que vous essayez d'estimer le temps. Non.
Estimer la complexité. Examinez une exigence (espérons-le, une user story) et évaluez la complexité que l'équipe pense qu'il sera difficile de comprendre comment la construire et la tester, par rapport à la complexité des autres exigences ou user stories. Parfois, vous vous trompez, mais souvent vous aurez une bonne idée de la difficulté de quelque chose. Vous constaterez également que les éléments qui sont à peu près de la même complexité ont tendance à prendre le même effort à terminer.
Ainsi, les classements de complexité deviennent les «points d'histoire» associés aux histoires d'utilisateurs dans votre backlog de produit. Après avoir parcouru quelques sprints, vous aurez une idée du nombre de points d'histoire que vous pouvez franchir dans un sprint, et c'est votre vitesse. À ce stade, vous aurez une bien meilleure idée de la durée de chaque élément.
Je recommande fortement les User Stories Applied de Mike Cohn .
la source
Je sais que votre question concerne spécifiquement d'éviter la conception dans la planification. Mais c'est en quelque sorte un problème XY .
J'ai été là où tu es. Plutôt que de vous donner quelque chose qui pourrait apporter une amélioration progressive, j'aimerais vous aider à sauter certains de ces états intermédiaires.
Voici trois choses que notre équipe fait spécifiquement pour planifier et exécuter le travail. Ceux-ci nous ont aidés à éviter le détournement de conception et à échapper à des estimations de temps inexactes.
Critères d'acceptation automatisables
Nos histoires sont pointées par leur nombre de critères d'acceptation automatique . Cela signifie que si nous devions écrire des tests automatisés pour confirmer que l'histoire est terminée, quels seraient-ils?
Par exemple, "Lorsque l'utilisateur clique sur" jouer "sur un iPad exécutant iOS 6+, la vidéo commence à jouer." Il peut être difficile d'automatiser réellement ce test, mais c'est un critère d'acceptation (AC) de l'histoire et contribue à un point.
Nous utilisons l'échelle de Fibonacci et nous arrondissons toujours. Donc, si une histoire a quatre critères d'acceptation automatisables, c'est une histoire en cinq points.
Notre taille maximale de point d'histoire est de huit points, mais nous en avons rarement. Si une histoire a plus de cinq critères d'acceptation automatisables, nous trouvons un moyen de les diviser.
Pré-toilettage
Nous avons une réunion de lancement lundi, mais c'est lors de nos réunions de préparation que la planification de l'équipe a lieu. Avant le toilettage, les membres de l'équipe pré-toiletteront une histoire en décrivant le résultat et en essayant les critères d'acceptation automatisables.
Le toilettage met l'expertise de l'équipe au service des histoires pré-soignées, décortiquant les exigences non spécifiées, divisant les histoires, etc.
Nous listons parfois des tâches en plus des critères d'acceptation, mais celles-ci ne sont pas estimées dans le temps. Nous n’estimons jamais le temps. Les tâches ne sont que des énoncés de travail qui doivent être effectués à l'appui des critères.
Limiter les travaux en cours
La mêlée traditionnelle tente de limiter le temps de travail à la durée du sprint. Nous avons constaté que cela nous avait obligés à nous précipiter pour respecter les délais de sprint, tuant nos week-ends parce que le sprint se terminait vendredi.
Une autre approche consiste à limiter à tout moment les travaux en cours . Nous avons migré vers ce dernier et avons été beaucoup plus heureux pour cela.
Une fois qu'une histoire passe de l'arriéré à un travail en cours, nous la caractérisons comme étant dans l'un des états suivants:
Nous utilisons ensuite le nombre d'histoires dans chaque état pour diriger l'attention de l'équipe. Par exemple, un développeur peut être disponible pour prendre en charge une nouvelle histoire, mais si nous avons beaucoup d'histoires en cours de test, il vaut mieux qu'il aide les histoires existantes.
la source
Tout d'abord, reconnaissez que des estimations précises sont impossibles dans ces circonstances. Ne vous inquiétez pas si vous vous trompez. Cependant, vous avez toujours besoin d'une idée approximative pour planifier, et la seule façon de tenir compte de l'incertitude totale est d'ajouter plus de points d'histoire à votre estimation. Si vous ne savez pas si c'est un 5 ou un 13, utilisez le 13.
Il est également utile de décomposer les histoires aussi petites que possible. Nous avons souvent une histoire de recherche / conception dans le seul but de faire suffisamment de travail pour avoir une meilleure idée de la façon de faire la fonctionnalité, puis l'histoire de la fonctionnalité elle-même va dans un sprint ultérieur. Pensez à pourquoi cela fonctionne. Même si vous ne savez pas à quel point quelque chose sera difficile, vous savez généralement de manière assez précise par expérience passée combien de temps il faudra pour le découvrir.
la source
Il y a deux choses que vous pouvez faire ici.
Ayez d'abord une sorte de Scrum Master qui a pour rôle de suivre la discussion et de dire "Hé, vous concevez à nouveau" quand vous l'êtes. C'est plus difficile qu'il n'y paraît, faites pivoter les gens jour après jour et tout le monde doit être le scrum master pour que tout le monde puisse jouer.
Deuxièmement, si vous concevez pendant la planification du sprint, vous devez être en mesure de faire la différence entre ne pas en savoir assez pour effectuer un appel sur la durée d'une tâche, ou si vous concevez simplement parce que c'est plus amusant.
Encore une fois, le Scrum Master devrait intervenir ici et vous dire de remettre l'élément en attente jusqu'à ce que vous en sachiez assez pour le planifier, ou vous faire arrêter de concevoir et répondre à la question d'origine (combien de temps cela prendra-t-il).
Donc, si vous faites de la planification de sprint, il est logique d'avoir un sponsor commercial là-bas pour passer en revue l'arriéré avec vous et prioriser les choses qu'ils veulent voir faites en premier. Si vous faites cela, vous constaterez qu'il est plus difficile de concevoir pendant la session, car ils deviendront agités et ne voudront plus venir.
la source
Nous avons fonctionné sur la base d'une estimation de l'histoire «froide» pendant la planification du sprint avec seulement quelques discussions limitées. Les estimations sont vraiment assez inexactes malgré la mise en place d'équipes avec un objectif raisonnablement étroit ... principalement en raison de l'existence de beaucoup de code hérité non documenté et non commenté sans aucune idée réelle de ce qui est réellement censé se produire et d'un personnel qui a largement changé depuis la rédaction de l'original.
Ce que nous essayons maintenant, c'est de passer du temps avant de planifier l'enquête sur chaque histoire - et ici, un seul développeur enquêtera sur une histoire ... Nous espérons que cela signifie que le développeur qui a enquêté sera en mesure de fournir des éclaircissements et aider l'estimation. Jusqu'à présent, cela a aidé dans les occasions où il a été essayé.
Je n'ai pas encore été convaincu que l'enquête supplémentaire rend vraiment les estimations suffisamment précises pour justifier le coût, mais nous allons l'essayer pour quelques sprints à voir.
la source