Programmation de paires avec Scrum

Je fais partie d'une équipe qui utilise actuellement Scrum, et nous envisageons d'ajouter la programmation par paires pour aider à améliorer les compétences interfonctionnelles de l'équipe, ainsi que pour réduire les défauts avec une philosophie «deux têtes valent mieux qu'une».

Dans notre équipe, chaque membre de l'équipe s'inscrit généralement pour une charge de travail complète lors de la planification du sprint (avec "complet" étant un nombre inférieur à 40 heures par semaine, permettant des réunions, une collaboration, etc.), avec un seul propriétaire dédié pour chaque tâche. Je pense que c'est assez courant dans les équipes Scrum mais ce n'est pas forcément le cas.

En particulier, je cherche à éviter une situation où les membres de l'équipe hésitent à se jumeler parce qu'ils ont leurs propres tâches à travailler, ce qui, je le crains, est susceptible de se produire si l'équipe s'auto-organise sans temps réservé pour le jumelage .

Compte tenu de cela, quelle est la meilleure façon de tenir compte des efforts / heures / points d'histoire dans un scénario d'appariement, pour nous assurer que nous avons alloué le temps nécessaire pour l'appariement?

Certaines options envisagées sont:

1. Permettre à deux personnes de s'inscrire pour chaque tâche et (grossièrement) doubler le nombre d'heures estimées
2. Seul le membre de l'équipe «clavier pratique» s'inscrit pour chaque tâche, qui est estimée en fonction des heures estimées de cette personne. Tout membre de l'équipe qui soutiendra le jumelage s'inscrira à moins de tâches dans le sprint pour laisser le temps de soutenir le jumelage.

L'option la plus courante que j'ai vue lorsque la programmation par paires est utilisée dans Scrum est de doubler les estimations de développement.

Autrement dit, si la tâche est estimée à prendre 3 heures pour une personne, le temps alloué serait de 6 heures pour la paire.

Remplacez les heures par des points si cela vous fait vous sentir plus propre;)

Je pense que d'autres ont déjà fourni de bonnes réponses, mais j'ajouterai la mienne uniquement parce que je pense que votre équipe vient de passer à Scrum et maintenant vous êtes dans une position très similaire à celle que nous avions lorsque nous avons commencé.

Tout d'abord, notre introduction à Agile et plus précisément à Scrum n'a pas été très fluide. Fondamentalement, la direction est descendue et a dit qu'à partir de ce jour, vous feriez Scrum et c'est un processus que vous suivrez tous. Voilà pour People Over Process .

Le processus que nous avons suivi à l'origine (aveuglément, je pourrais ajouter) s'est révélé très similaire à la façon dont vous l'avez décrit. Les gens se voient assigner des tâches, tout le monde est réservé et nous retournons tous à nos bureaux et nous branchons. Ensuite, nous avons une réunion de stand-up ennuyeuse tous les jours.

La clé à réaliser est que Agile, et Scrum inclus, concerne en fait les gens. Lorsque l'équipe entame la planification des itérations, ne laissez pas votre Scrum master (qui est probablement votre manager) vous assigner des heures, des histoires et des tâches. C'est complètement À L'ÉQUIPE. Je pense que pour beaucoup de gens, c'est un concept très difficile à mettre en œuvre car pendant des années auparavant, ils venaient travailler et ils avaient un patron (manager, responsable technique ...) qui assignerait simplement du travail. Ils plongent dans Scrum mais tout le monde (y compris Scrum Master lui-même) continue de fonctionner dans le même mode.

Un jour, vous en aurez assez, alors vous commencerez à lire des livres, des blogs et continuerez à poser des questions comme celle-ci sur l'échange de pile. La prise de conscience que vous obtiendrez est que vous, en tant que développeur et vos coéquipiers, devriez être la force motrice derrière la validation des histoires et l'attribution des tâches. Si vous pensez que vous bénéficierez de la programmation en binôme, créez certainement 2 tâches pour chacun des ingénieurs et affectez-leur deux heures. La seule chose que Scrum Master devrait faire est de mesurer la vélocité par rapport aux histoires terminées que vous avez livrées EN ÉQUIPE lors de l'itération précédente.

Une autre chose qui me dérange est la façon dont les gens sont informés que leur capacité est TOUJOURS 75% du nombre total d'heures, c'est donc ce à quoi ils s'engagent, puis pendant toute la durée de l'itération, ils se plaignent qu'ils ne peuvent pas a) vous aider ou b) ils ne peuvent pas faire la bonne chose parce qu'on leur a assigné trop d'heures. Les gens ne devraient pas être informés du nombre d'heures à engager et ils devraient certainement reculer si le Scrum Master tente de tirer quelque chose comme ça! Tout le monde devrait s'engager exactement avec quoi il est à l'aise. Par exemple, je suis un chef d'équipe et je me retrouve souvent dans une discussion de conception aléatoire non planifiée, ou pour aider quelqu'un avec du code, ou pour résoudre des problèmes étranges, donc ma capacité n'est jamais supérieure à 50%.

Il a fallu à notre équipe 4 cycles de publication pour apprendre à ne pas faire les choses que je viens de mentionner et même si nous nous sommes définitivement améliorés, si vous demandez aux experts, nous ne sommes même pas à moitié agiles. Donc encore beaucoup d'apprentissage à faire.

Mise à jour 1: réponse au commentaire de Cliff Eh bien vous avez offert vos oreilles alors la voici ...

Vous avez raison, le changement culturel est essentiel, mais ce changement n'a pas besoin de se produire au niveau exécutif. Votre propre chef de groupe peut changer la culture au sein de votre équipe et vous isoler des BS d'entreprise avec lesquels il doit faire face. Ce que vous décrivez, c'était EXACTEMENT de nous de 2007 à 2010. Notre équipe (et d'autres équipes également) a floppé version après version. Dans l'une des versions utilisant le «processus pour être agile» de la direction, nous parvenons à ce que 9 personnes produisent le travail qui serait généralement effectué par une seule personne et cela nous a pris deux fois plus de temps. J'avais tellement de temps libre que j'ai même mis à jour mon CV.

Ensuite, j'ai eu une conversation avec mon patron et lui ai expliqué toutes ces choses à quel point les gens sont agiles et que si vous voulez que nous nous soucions du produit, laissez-nous prendre des décisions qui affectent la façon dont nous travaillons et livrons le produit. Je pense qu'il a décidé d'en faire une expérience, il a fait chaque changement que nous ... enfin, surtout moi-même, mais je parle beaucoup avec le reste de l'équipe, donc 50% de capacité :) ... proposé. Il est possible qu'il ait pensé que s'il faisait tous les changements que nous demandons et que nous échouions toujours, il reviendrait avec un "Je vous l'ai dit" victorieux.

Donc, au cours des 12 derniers mois, nous avons éliminé tellement de choses "stupides" que ce n'est même pas drôle. Nos réunions debout ont en fait un sens maintenant parce que nous travaillons ensemble, pas isolément. Nous détenons toujours (au moins pour l'instant) des parties spécifiques du produit, mais nous entrons également très fréquemment dans le code des autres. Nous effectuons constamment des révisions de code afin que non seulement les membres de l'équipe apprennent d'autres codes, mais qu'ils apprennent également de meilleures techniques de codage et de conception. Nous avons divisé une équipe monolithique et géante "agile" en 3 équipes différentes, la planification et les autres réunions sont donc beaucoup plus courtes et les gens se soucient vraiment d'eux parce qu'ils ne restent pas assis et écoutent des choses qui ne les intéressent pas. JE' J'ai vu des nuits où 4 sur 5 de nos gars (une des équipes) étaient en ligne à 23 heures du soir et personne ne nous a dit que nous devions travailler dur ou ne nous avait jamais forcés à travailler plus de 40 heures. Les gens qui s'en fichaient il y a six mois, sont soudainement engagés et enthousiasmés par le travail qu'ils font. Et tout ce qu'il a fallu à notre manager, c'était de dire: "vous décidez de ce qui est bien et faites ce que vous devez faire et je garderai le BS d'entreprise hors de l'équipe autant que possible."

Cela a commencé comme une expérience (mes soupçons, il ne me l'a jamais dit), mais maintenant notre groupe donne des coups de pied par rapport aux autres groupes de développement du département et nous avons même d'autres développeurs qui essaient maintenant de venir nous rejoindre.

Le plus grand obstacle pour nous depuis que ce changement s'est produit (et toujours un problème aujourd'hui) était le fait que les ingénieurs dans un environnement d'entreprise normal sont comme des souris expérimentales dans une cage. Même lorsque votre manager décide de devenir vraiment «agile» et supprime la cage, tout le monde est dans cette cage depuis si longtemps qu'il ne se rend même pas compte qu'il est libre. Donc, même avec toute la liberté, ils continuent d'agir comme s'ils étaient toujours contraints. Je pense que ce qui aiderait, c'est d'avoir au moins quelques personnes dans l'équipe (comme vous), qui sortent des limites du groupe et cherchent de meilleures façons de faire les choses. Revenez ensuite dans ce groupe et remuez-le un peu.

Dans votre cas, la programmation par paires n'est peut-être pas une solution si vous recherchez une autre force externe pour faire partie de l'équipe et lui dire comment travailler. Au lieu de cela, jetez les règles, asseyez-vous avec eux, sans direction, et demandez-leur ce qu'ils veulent faire? Qu'est-ce qui les rendra heureux? Productif? Identifiez les plus gros problèmes, puis demandez à l'ÉQUIPE quelle devrait être la solution.

Scrum n'impose pas que des tâches soient attribuées à des individus - loin de là. La responsabilité des tâches à accomplir incombe à l'équipe dans son ensemble. Si l'équipe veut faire de la programmation par paires, où chaque paire reprend une tâche, elle doit très certainement le faire.

Du guide Scrum :

L'équipe de développement commence généralement par concevoir le système et le travail nécessaire pour convertir le Product Backlog en incrément de produit fonctionnel. Le travail peut être de taille variable ou d'effort estimé. Cependant, suffisamment de travail est prévu lors de la réunion de planification du sprint pour l'équipe de développement afin de prévoir ce qu'elle pense pouvoir faire dans le prochain sprint. Le travail prévu pour les premiers jours du Sprint par l'équipe de développement est décomposé en unités d'une journée ou moins à la fin de cette réunion. L'équipe de développement s'auto-organise pour entreprendre le travail dans le Sprint Backlog , à la fois pendant la réunion de planification du Sprint et selon les besoins tout au long du Sprint.

Affecter des tâches à la planification de la réunion est exactement ce qui va à l'encontre des décisions en matière de temps et de responsabilisation de l'équipe. Cela va également à l'encontre de l'agilité du sprint car depuis le premier jour d'un sprint, chaque développeur a exactement aligné ce qu'il doit faire. Cela signifie également que chaque tâche doit être estimée très correctement, ce qui n'est presque jamais le cas.

Les tâches d'estimation à mon humble avis sont redondantes. Vous vous êtes engagé à définir des histoires et la planification de la réunion 2 est juste assez de temps pour diviser ces histoires en tâches et créer des cartes pour ces tâches (ou les remplir sur un système). Il n'y a pas assez de temps pour estimer chaque tâche et ces estimations ne devraient pas prendre de temps pour un développement réel.

Pourquoi? L'estimation est une poubelle. Comment ça peut être une poubelle? Parce que faire plus d'estimation n'apportera pas plus de valeur commerciale = ce sont des ordures et doivent être réduites au minimum nécessaire. Le minimum est d'estimer / dimensionner des histoires qui vous aident à vous engager. Une fois que vous avez pris un engagement, vous n'avez besoin d'aucune autre estimation. Vous savez simplement que vous avez fixé une date pour livrer quelque chose que vous avez commis. Vous pourrez ou non livrer des histoires engagées. L'estimation des tâches ne vous aidera pas dans cette livraison.

Ignorer l'estimation des tâches n'affectera en aucun cas la visibilité de la progression du sprint, car la seule véritable mesure de la progression est le nombre d'histoires terminées (points d'histoire) et qui peuvent toujours être affichées dans le graphique de gravure du sprint.

Juste pour clarifier. L'engagement signifie = nous le ferons . Non, nous n'essaierons pas de le faire ou autre chose. Oui, vous ne pouvez pas livrer ce que vous avez commis, mais votre engagement doit être basé sur votre conviction qu'avec vos connaissances actuelles, vous livrerez des histoires sélectionnées. Si vous avez cette conviction, vous n'avez pas besoin d'une autre estimation.

J'ai toujours utilisé Scrum dans la façon dont le développeur choisit une nouvelle tâche une fois qu'il a terminé sa dernière. Les développeurs disent généralement lequel ils vont choisir lors d'une réunion debout. En général, il n'y a pas de règles sur la tâche qu'il doit choisir. C'est à l'auto-organisation de l'équipe et à la discussion entre les membres de l'équipe (en dehors de la réunion debout). Cela repousse la décision au dernier point possible où vous pouvez réagir à certains changements et problèmes sans affecter votre plan imaginaire. La tâche elle-même peut même changer de propriétaire si quelqu'un a des problèmes pour la terminer - alternativement, cette tâche peut être développée en paire.

Comment la programmation par paires peut-elle être impliquée dans cela? Facilement. L'équipe s'engage et l'équipe doit faire en sorte de faire de la place pour toutes les techniques de développement nécessaires pour fournir l'incrément de travail du produit. Estimez-vous une tâche ou le développement de tâches et les tests de tâches? Cette dernière approche est complètement fausse. Les tests font partie du développement et, de la même manière, la révision ou l'appariement du code fait partie du développement si nécessaire.

Faire de la programmation en binôme devrait permettre d'accomplir la tâche plus rapidement avec moins de bogues et une meilleure qualité de code. Ce ne sera pas deux fois plus rapide, il y aura donc encore des frais généraux, mais l'impact réel sur l'engagement causé par un appariement occasionnel devrait être très faible. Ce n'est pas un cas de mentorat ou d'enseignement. Si vous avez un tel développeur qui doit être encadré ou enseigné, vous ne devez pas du tout planifier sa capacité pour les sprints où il apprend la base de code du produit ou une technologie.