Manejo de trabajo "relacionado" dentro de un único elemento de trabajo ágil

Estoy en un equipo de proyecto de 4 desarrolladores, incluido yo mismo. Hemos tenido una larga discusión sobre cómo manejar el trabajo extra que surge en el curso de un solo elemento de trabajo.

Este trabajo adicional suele ser algo que está ligeramente relacionado con la tarea, pero no siempre es necesario para lograr el objetivo del elemento (puede ser una opinión). Los ejemplos incluyen, pero no se limitan a:

• refactorización del código modificado por el elemento de trabajo
• código de refactorización adyacente al código cambiado por el artículo
• rediseñando el área de código más grande alrededor del ticket. Por ejemplo, si un elemento hace que cambie una sola función, se da cuenta de que toda la clase ahora podría rehacerse para acomodar mejor este cambio.
• mejorar la interfaz de usuario en un formulario que acaba de modificar

Cuando este trabajo extra es pequeño, no nos importa. El problema es cuando este trabajo adicional causa una extensión sustancial del elemento más allá de la estimación original del punto característico. A veces, un elemento de 5 puntos llevará 13 puntos de tiempo. En un caso, teníamos un elemento de 13 puntos que, en retrospectiva, podría haber sido 80 puntos o más.

Hay dos opciones en nuestra discusión sobre cómo manejar esto.

1. Podemos aceptar el trabajo extra en el mismo elemento de trabajo y descartarlo como una estimación errónea. Los argumentos para esto han incluido:

   • Planeamos "rellenar" al final del sprint para dar cuenta de este tipo de cosas.
   • Siempre deje el código en mejor forma de lo que lo encontró. No verifique el trabajo a medias.
   • Si dejamos la refactorización para más adelante, es difícil programarla y es posible que nunca se realice.
   • Estás en el mejor "contexto" mental para manejar este trabajo ahora, ya que estás en la cintura en el código. Es mejor sacarlo del camino ahora y ser más eficiente que perder ese contexto cuando vuelvas más tarde.

2. Trazamos una línea para el elemento de trabajo actual y decimos que el trabajo adicional va a un ticket separado. Los argumentos incluyen:

   • Tener un boleto separado permite una nueva estimación, por lo que no nos estamos mintiendo sobre cuántos puntos son realmente las cosas, o tener que admitir que todas nuestras estimaciones son terribles.
   • El "relleno" del sprint está destinado a desafíos técnicos inesperados que son barreras directas para completar los requisitos del boleto. No está destinado a elementos secundarios que son simplemente "agradables".
   • Si desea programar la refactorización, simplemente colóquelo en la parte superior de la cartera de pedidos.
   • No hay forma de que podamos explicar adecuadamente estas cosas en una estimación, ya que parece algo arbitrario cuando surge. Un revisor de código podría decir "esos controles de la interfaz de usuario (que en realidad no modificó en este elemento de trabajo) son un poco confusos, ¿puede arreglar eso también?" que es como una hora, pero podrían decir "Bueno, si este control ahora hereda de la misma clase base que los otros, ¿por qué no mueve todo este código (cientos de líneas de) a la base y vuelve a conectar todo esto? , los cambios en cascada, etc.? " Y eso lleva una semana.
   • "Contamina la escena del crimen" al agregar trabajo no relacionado al boleto, lo que hace que nuestras estimaciones originales no tengan sentido.
   • En algunos casos, el trabajo adicional pospone un registro, lo que provoca el bloqueo entre los desarrolladores.

Algunos de nosotros ahora estamos diciendo que deberíamos decidir un corte, como si las cosas adicionales son menos de 2 FP, va en el mismo boleto, si es más, conviértalo en un boleto nuevo.

Dado que solo estamos unos meses en usar Agile, ¿cuál es la opinión de todos los veteranos Agile más experimentados sobre cómo manejar esto?

La planificación ágil y las historias de usuarios se centran en proporcionar valor y transparencia a las partes interesadas del proyecto y a los usuarios del software. Esto es algo bueno, pero no reemplaza, ni debe reemplazar, incluir o degradar la importancia de las buenas pautas arquitectónicas, la administración del diseño, las buenas prácticas de desarrollo y el mantenimiento de la deuda técnica.

Agile no hace bien esto último porque no fue pensado como una respuesta a estos problemas y problemas principalmente técnicos.

Sabiendo que estoy muy en desacuerdo con que las tareas de refactorización, el manejo técnico de deudas y el trabajo de diseño deberían explicar las historias de usuarios separadas en un sprint dado. Estas son simplemente tareas que un desarrollador podría emprender para ayudar a cumplir con la historia del usuario para ese sprint.

Recuerde que una Tarea es cualquier unidad de trabajo asignable que ayuda a mover una historia de usuario dada hasta su finalización dentro de las pautas arquitectónicas y mantener el buen diseño y las prácticas de desarrollo del software en su conjunto.

Esta es la razón por la cual la estimación de horas debe estar en tareas y no en historias de usuarios. Esta es también la razón por la cual algunas tareas son críticas para completar múltiples historias de usuarios.

Rojo, verde, refactor. Ese es el alcance de un solo elemento de trabajo. Escriba un conjunto de pruebas fallidas que cubra el alcance del cambio, codifique la cantidad mínima requerida para aprobar su prueba, luego refactorice para cumplir con los estándares de codificación mientras aún pasa las pruebas. Los tres pasos son obligatorios; no puede codificar la solución hasta que haya definido el problema, si refactoriza al escribir la línea de código invariablemente violará YAGNI, pero si no entra detrás de usted y refactoriza después de pasar las pruebas, por definición incurrirá en una deuda técnica que eventualmente tendrá que pagar.

Dada esta definición, y que se siguió, un puntero de 5 puntas que resultó ser un puntero de 13 fue una estimación errónea. Lo que consideraría refactorizar el trabajo fue probablemente más como una reestructuración; tenía que reorganizar un área bastante importante de la base de código para que la nueva funcionalidad se incluyera de una manera comprensible y fácil de mantener. Eso generalmente indica una falla del equipo para comprender el camino futuro general del desarrollo, lo que lleva a que algo se implemente de manera muy simple en una iteración anterior cuando eventualmente se requeriría que fuera muy SÓLIDO. Una mejor comunicación entre los BA y el PM, que saben qué hay más abajo en la cartera de pedidos, y el equipo de desarrollo que generalmente se enfoca en el sprint actual, puede mitigar esto. Alternativamente, esta historia expuso una gran cantidad de deuda técnica incurrida en desarrollos pasados, y simplemente alcanzó al equipo. Los mejores procesos de revisión de código, además de un mejor conocimiento conceptual de los patrones de diseño y de la ruta futura general del proyecto, pueden ayudar a reducir tales ocurrencias.

Una cosa a tener en cuenta es que la refactorización es un trabajo "no ideal". En Agile SCRUM, las tareas se estiman en "horas ideales"; es decir, la cantidad de horas dedicadas a escribir código nuevo que nunca existió y promueve la base de características del proyecto. Un día de desarrollador de 8 horas en realidad solo puede tener 5 horas ideales; a veces puedes contar con 6, especialmente en el "tramo" de un proyecto en el que el equipo realmente está tarareando. Refactorizar, o retroceder y realizar cambios que no afectan la funcionalidad del proyecto pero que mejoran la base de código de otras maneras, es un trabajo no ideal, como lo es la planificación, el diseño, la comunicación, la revisión, los descansos o el tiempo de inactividad técnico. Además del tiempo de inactividad técnico, el trabajo no ideal es importante, pero no progresa a los ojos del propietario del producto.

Por lo tanto, siempre que la refactorización no duplique las horas reales dedicadas, es de esperar una cierta cantidad de trabajo de refactorización cuando se estima en horas ideales. Digamos, porque no sé exactamente cómo está calibrada la escala de puntos de su equipo, que un puntero de 5 puntos es equivalente a una semana de desarrollador ideal, o alrededor de 25 horas ideales. Ese 5, que se convirtió en un 13 (más de dos semanas de desarrollador en la misma escala), es causa de cierta retrospección sobre lo que causó que la complejidad se disparara. Tal vez la base de código no necesitaba tanta refactorización como se hizo realmente, tal vez una gran cantidad de deuda técnica se había acumulado sin el conocimiento del equipo que tenía que resolverse para que las nuevas funciones funcionaran,

En un universo alternativo, imaginemos que un 5 como se estima en horas ideales se convirtió en un 7 (~ 35 horas) en función de las horas reales, porque necesitabas 10 horas de refactorización adicional para poner el nuevo código y algunos bits anteriores en un patrón correctamente arquitectura de diseño En ese caso, el extra está dentro de la "brecha" entre las horas ideales y totales durante el número de días de desarrollador que se suponía que debía llevar la historia. Entonces, como gerente de proyecto, llamaría a un 5 que se convirtió en un 7 una estimación razonable y seguiría adelante.

Los puntos de historia son una estimación de la complejidad relativa de una historia de usuario dada. Parece que estás usando puntos de historia para decir que esto tomará X hombre días / horas. En cambio, lucha por dos objetivos

1. Desglose las historias hasta que estén en un rango constante (3, 5 u 8 puntos)
2. Suponga que la historia incluye cualquier refactorización necesaria

Con el tiempo, esto le dará una línea de base para la velocidad. Cada historia de 5 puntos no tomará la misma cantidad de tiempo que las otras, pero la velocidad promedio por sprint (cuántos puntos de historia puede completar el equipo) será consistente.

Preocuparse por cuánto tiempo llevará una historia específica es contraproducente. Las estimaciones solo promedian el volumen de las historias de tamaño consistente (es decir, un puntero de 5 puede demorar un poco más debido a la refactorización, pero usted obtiene el beneficio de ese esfuerzo en uno relacionado).

Debe haber un límite relativo de cuánto hay dentro del elemento de trabajo original y cuánto es otra cosa. Las historias de usuarios son puntos de partida para las discusiones y, por lo tanto, puede haber todo tipo de elementos de alcance para concretar durante un sprint mientras se trabaja en una historia.

Puede haber ocasiones en las que, en una planificación de sprint, una historia puede agregar criterios adicionales en un esfuerzo por evitar el "arrastre de alcance" que puede suceder cuando un usuario desea un nuevo formulario y luego 101 cambios a ese formulario que no es realista para Hazlo en un sprint de 2 semanas a veces.

Una otra cara a tener en cuenta es cuánto valor se obtiene de este trabajo adicional. Puede haber toneladas de posibles refactorizaciones que podrían hacerse, pero ¿cuánto beneficio hay para alguien por todo ese trabajo? Aquí es donde debe haber algunas pautas para ayudar a que el equipo funcione bien pero no perderse al tratar de hacer que el código sea perfecto.