Programación en pareja con Scrum

Estoy en un equipo que actualmente usa Scrum, y estamos considerando agregar programación de pares para ayudar a mejorar las habilidades multifuncionales del equipo, así como ayudar a reducir defectos con una filosofía de "dos cabezas son mejores que una".

En nuestro equipo, cada miembro del equipo generalmente se inscribe para una carga de trabajo completa durante la planificación del sprint (con "completo" es un número de menos de 40 horas a la semana, que permite reuniones, colaboración, etc.), con un único propietario dedicado para cada tarea. Creo que esto es bastante común en los equipos Scrum, pero puede que no sea necesariamente por el libro.

En particular, estoy buscando evitar una situación en la que los miembros del equipo duden en emparejarse porque tienen sus propias tareas en las que trabajar, lo que me temo que es probable que suceda si el equipo simplemente se autoorganiza sin tiempo reservado para el emparejamiento .

Dado esto, ¿cuál es la mejor manera de dar cuenta de los esfuerzos / horas / puntos de historia en un escenario de emparejamiento, para asegurarnos de que hayamos asignado el tiempo adecuado para el emparejamiento?

Algunas opciones consideradas son:

1. Permita que dos personas se registren para cada tarea y (aproximadamente) duplique el número de horas estimadas
2. Solo el miembro del equipo "manos en el teclado" se inscribe para cada tarea, que se estima en función de las horas estimadas de esa persona. Cualquier persona en el equipo que apoyará el emparejamiento se registrará para realizar menos tareas en el sprint para dar tiempo a apoyar el emparejamiento.

La opción más común que he visto cuando la programación de pares se emplea en scrum es duplicar las estimaciones de desarrollo.

Es decir, si se estima que la tarea dura 3 horas para una persona, el tiempo asignado sería de 6 horas para la pareja.

Sustituya los puntos por horas si eso lo hace sentir más limpio;)

Creo que otros ya proporcionaron buenas respuestas, pero agregaré las mías solo porque creo que su equipo acaba de hacer la transición a Scrum y ahora ustedes están en una posición muy similar a la que teníamos cuando comenzamos.

En primer lugar, nuestra introducción a Agile y más específicamente a Scrum no fue muy fluida. Básicamente, la gerencia bajó y dijo, a partir de este día harás Scrum y este es un proceso que todos seguirán. Demasiado para las personas sobre el proceso .

El proceso que seguimos originalmente (a ciegas, podría agregar) terminó muy similar a cómo lo describiste. A las personas se les asignan tareas, todos se reservan y todos volvemos a nuestros escritorios y nos desconectamos. Luego tenemos una aburrida reunión de pie todos los días.

La clave para darse cuenta es que Agile, y Scrum incluido, en realidad se trata de personas. Cuando el equipo entra en la planificación de iteración, no permita que su maestro Scrum (quien probablemente sea su gerente) le asigne horas, historias y tareas. Está completamente a la altura del equipo. Creo que para muchas personas es un concepto muy difícil de entender porque durante años antes habían venido a trabajar y tendrían un jefe (gerente, líder técnico ...) que simplemente asignaría trabajo. Se sumergen en Scrum, pero todos (incluido el mismo scrum master) continúan operando en el mismo modo.

Un día, te cansarás de esto, así que comenzarás a leer libros, blogs y seguirás haciendo preguntas como esta en el intercambio de fichas. La comprensión que obtendrá es que usted, como desarrollador y sus compañeros de equipo, deben ser la fuerza impulsora detrás de comprometerse con historias y asignar tareas. Si ustedes creen que se beneficiarán de la programación de pares, por supuesto, creen 2 tareas para cada uno de los ingenieros y asignen a ambos horas. Lo único que debería estar haciendo scrum master es medir la velocidad contra historias completadas que entregaste COMO UN EQUIPO en la iteración anterior.

También otra cosa que me molesta es cómo se les dice a las personas que su capacidad SIEMPRE ES el 75% del total de horas, por lo que es a lo que se comprometen y luego, durante toda la duración de la iteración, se quejan de que a) no pueden ayudarlo o b) no pueden hacer lo correcto porque les han asignado demasiadas horas. ¡A las personas no se les debe decir cuántas horas deben comprometerse y sin duda deberían retroceder si scrum master intenta hacer algo como esto! Todos deberían comprometerse a exactamente con qué se sienten cómodos. Por ejemplo, soy un líder de equipo y, con frecuencia, terminaba en una discusión de diseño no planificada al azar, o ayudaba a alguien con el código o solucionaba problemas con cosas extrañas, por lo que mi capacidad nunca supera el 50%.

Le tomó a nuestro equipo 4 ciclos de lanzamiento para aprender a no hacer las cosas que acabo de mencionar y, aunque definitivamente hemos mejorado, si le preguntas a los expertos, ni siquiera somos medio ágiles. Así que todavía hay mucho que aprender a hacer.

Actualización 1: Respuesta al comentario de Cliff Bueno, ofreció sus oídos, así que aquí está ...

Tiene razón, el cambio cultural es clave, pero este cambio no necesita suceder a nivel ejecutivo. Su propio gerente de grupo puede cambiar la cultura dentro de su equipo y aislarlos de las BS corporativas con las que tiene que lidiar. Lo que usted está describiendo fue EXACTAMENTE sobre nosotros de 2007 a 2010. Nuestro equipo (y otros equipos también) fracasaron lanzamiento tras lanzamiento. En uno de los lanzamientos que utilizan el "proceso para ser ágil" de la gerencia, logramos que 9 personas produzcan el trabajo que generalmente haría una sola persona y nos llevó el doble de tiempo. Tenía tanto tiempo libre que incluso actualicé mi currículum.

Luego, tuve una conversación con mi jefe y le expliqué todo lo ágil que es sobre las personas y que si quieres que nos preocupemos por el producto, déjanos tomar decisiones que afecten la forma en que trabajamos y entregamos el producto. Creo que decidió convertirlo en un experimento, hizo todos los cambios que ... bueno, sobre todo yo mismo, pero hablo mucho con el resto del equipo, de ahí el 50% de capacidad :) ... propuso. Es posible que se haya dado cuenta de que si hace todos los cambios que estamos pidiendo y aún fallamos, regresará con un victorioso "Te lo dije".

Entonces, en los últimos 12 meses, hemos eliminado tanto "estúpido" que ni siquiera es gracioso. Nuestras reuniones de pie realmente tienen sentido ahora porque trabajamos juntos, no de forma aislada. Todavía tenemos la propiedad (al menos por ahora) de partes específicas del producto, pero también nos cruzamos con mucha frecuencia en el código de los demás. Constantemente hacemos revisiones de código para que no solo los miembros del equipo aprendan otro código, sino que también aprendan mejores técnicas de codificación y diseño. Hemos dividido el equipo monolítico gigante "ágil" en 3 equipos diferentes, por lo que la planificación y otras reuniones son mucho más cortas y la gente realmente se preocupa por ellas porque no se sientan y escuchan cosas que no les importan. YO' Hemos visto noches en las que 4 de cada 5 de nuestros muchachos (uno de los equipos) estarían en línea a las 11 p.m. de la noche y en realidad nadie nos dijo que teníamos que trabajar duro ni nos presionaron para que trabajáramos más de 40 horas. Las personas a las que no les importaba menos hace medio año, de repente están comprometidas y entusiasmadas con el trabajo que están haciendo. Y todo lo que hizo falta para que nuestro gerente hiciera fue decir: "ustedes deciden qué es lo correcto y hacen lo que deben hacer, y mantendré a las BS corporativas fuera del equipo tanto como pueda".

Comenzó como un experimento (mi sospecha, él nunca me dijo eso), pero ahora nuestro grupo está pateando el trasero en comparación con otros grupos de desarrollo en el departamento e incluso tenemos otros desarrolladores que ahora están tratando de venir y unirse a nosotros.

El mayor obstáculo para nosotros desde que ocurrió este cambio (y sigue siendo un problema hoy) fue el hecho de que los ingenieros en un entorno corporativo normal son como ratones experimentales en una jaula. Incluso cuando su gerente decide ser realmente "ágil" y retira la jaula, todos han estado en esa jaula durante tanto tiempo que ni siquiera se dan cuenta de que son libres. Entonces, incluso con toda la libertad, continúan actuando como si todavía estuvieran limitados. Creo que lo que ayudaría es tener al menos pocas personas en el equipo (como usted), que salgan de los límites del grupo y busquen mejores formas de hacer las cosas. Luego regresa a ese grupo y revuelve un poco.

En su caso, tal vez la programación emparejada no sea una solución si está buscando otra fuerza externa que venga al equipo y les diga cómo trabajar. En cambio, descarte las reglas, siéntese con ellas, sin administración, y pregúnteles qué quieren hacer. ¿Qué los hará felices? ¿Productivo? Identifique los mayores problemas y luego pregunte a EL EQUIPO cuál creen que debería ser la solución.

Scrum no exige que las tareas se asignen a individuos, ni mucho menos. La responsabilidad de completar las tareas recae en el equipo en su conjunto. Si el equipo quiere hacer la programación de pares, donde cada par recoge una tarea, seguramente deberían hacerlo.

De la Guía Scrum :

El equipo de desarrollo generalmente comienza diseñando el sistema y el trabajo necesario para convertir la cartera de productos en un incremento de producto que funcione. El trabajo puede ser de diferente tamaño o esfuerzo estimado. Sin embargo, durante la reunión de Planificación de Sprint se planifica suficiente trabajo para que el Equipo de Desarrollo pronostique lo que cree que puede hacer en el próximo Sprint. El trabajo planeado para los primeros días del Sprint por el Equipo de Desarrollo se descompone en unidades de un día o menos al final de esta reunión. El Equipo de Desarrollo se autoorganiza para emprender el trabajo en el Backlog de Sprint , tanto durante la Reunión de Planificación de Sprint como cuando sea necesario durante todo el Sprint.

Asignar tareas en la reunión de planificación es exactamente lo que va en contra de las decisiones de tiempo y el empoderamiento del equipo. También va en contra de la agilidad del sprint porque desde el primer día en un sprint cada desarrollador ha alineado exactamente lo que debe hacer. También significa que cada tarea debe estimarse correctamente, lo que casi nunca es el caso.

Las tareas de estimación de Imho son redundantes. Se ha comprometido a establecer un conjunto de historias y planificar la reunión 2 es el tiempo suficiente para dividir esas historias en tareas y crear tarjetas para esas tareas (o llenarlas en algún sistema). No hay tiempo suficiente para estimar cada tarea y estas estimaciones no deberían consumir tiempo para un desarrollo real.

¿Por qué? La estimación es una basura. ¿Cómo puede ser una basura? Porque hacer más estimaciones no traerá más valor comercial = es basura y debería reducirse al mínimo necesario. El mínimo es estimar / dimensionar historias que lo ayudan a comprometerse. Una vez que hizo un compromiso, no necesita ninguna otra estimación. Solo sabe que tiene una fecha fija para entregar algo que ha comprometido. Podrás entregar historias comprometidas o no. Estimar tareas no lo ayudará en esa entrega.

Omitir la estimación de la tarea de ninguna manera afectará la visibilidad del progreso del sprint porque la única medida real del progreso es el número de historias completadas (puntos de la historia) y eso todavía se puede mostrar en la tabla de quemado de sprint.

Sólo para que quede claro. Compromiso significa = Lo haremos . No intentaremos hacerlo ni nada más. Sí, puede fallar en entregar lo que ha comprometido, pero su compromiso debe basarse en su creencia de que con su conocimiento actual entregará historias seleccionadas. Si tienes esta creencia, no necesitas otra estimación.

Siempre usé Scrum en la forma en que el desarrollador elige una nueva tarea una vez que completa la última. Los desarrolladores suelen decir cuál van a elegir en una reunión de pie. Generalmente no hay reglas sobre qué tarea debe elegir. Depende de la autoorganización del equipo y la discusión entre los miembros del equipo (fuera de la reunión de pie). Eso es posponer la decisión al último punto posible donde puede reaccionar ante algunos cambios y problemas sin afectar su plan imaginario. La tarea en sí misma puede incluso cambiar al propietario si alguien tiene algunos problemas para completarla; alternativamente, dicha tarea puede desarrollarse en pareja.

¿Cómo puede participar la programación de pares en esto? Fácilmente. El equipo se compromete y debe hacerlo en el camino para hacer espacio para todas las técnicas de desarrollo necesarias para entregar el incremento de trabajo del producto. ¿Estima una tarea o desarrollo de tareas y pruebas de tareas? El último enfoque es completamente incorrecto. La prueba es parte del desarrollo y, de la misma manera, la revisión o emparejamiento del código es parte del desarrollo si es necesario.

Hacer la programación de pares debería resultar en completar la tarea más rápido con una menor cantidad de errores y una mejor calidad de código. No será el doble de rápido, por lo que todavía habrá algo de sobrecarga, pero el impacto real en el compromiso causado por el emparejamiento ocasional debería ser muy pequeño. Este no es un caso de mentoría o enseñanza. Si tiene un desarrollador que necesita ser asesorado o enseñado, no debe planear su capacidad para sprints donde aprenda la base del código del producto o alguna tecnología.