Acabo de cumplir (¿es un buen término?) Dos historias de usuarios de un nuevo trabajo atrasado del proyecto que acabo de construir. Estos son el registro de usuario y el restablecimiento de contraseña, ambos requieren correo. Necesito implementar un componente de correo sustituto porque mi elección inicial, y normalmente confiable, no estaba funcionando. Como estaba enfocado en entregar las historias de los usuarios, no en depurar el componente de correo, lo cambié para entregar el código de trabajo al final del sprint. ¿Ahora registro un nuevo problema de soporte para el remitente o "vuelvo a insertar" estas historias en la cartera? Si hago esto último, ¿no estoy introduciendo demasiados detalles tecnológicos en las historias de los usuarios?
La deuda técnica es solo otra historia
Si se hace una historia, eso significa que ha pasado el control de calidad y ha sido aceptada por el propietario del producto.
Cualquier trabajo que deba hacerse para "limpiar" o "mejorar" la implementación se considera Deuda Técnica y simplemente debería ser una nueva Historia.
De esa manera, el Propietario del producto lo rastreará y priorizará como todo lo demás.
fuente
La cosa más simple que funcionará razonablemente
En un comentario relacionado , el OP dice:
Si ese es el caso, la pregunta original es discutible. El principio YAGNI requiere que una solución no sea diseñada en exceso en previsión de requisitos futuros.
Si una solución cumple con los objetivos actuales del sprint, funciona según lo diseñado y cumple con la "definición de hecho" del equipo, entonces está listo. No está a medio hacer, más o menos, o "hecho a la espera de una refactorización planificada".
Márquelo hecho y siga adelante.
Advertencia menor
Si realmente cree que hay otra historia allí, o algún tipo de deuda técnica que no impide que se haga la historia original, entonces debe plantear otra historia para la cartera de pedidos del producto .
Siempre se debe colocar un nuevo trabajo en el Backlog del Producto para aumentar la visibilidad , ¡nunca hay trabajo invisible! En última instancia, el trabajo del propietario del producto es decidir si la mejora propuesta se alinea con los objetivos del producto y priorizar su nueva historia de usuario dentro del Backlog del producto si decide agregar la historia.
fuente
De acuerdo con su pregunta y comentarios adicionales a la respuesta de @ Klee, creo que el problema es un poco diferente.
Has completado una historia. Debe significar que pasó todas las definiciones de hecho; de lo contrario, la historia del usuario no puede considerarse como completada. Pero si completó la historia y aprobó todas las definiciones de hecho, significa que su solución actual es satisfactoria. De lo contrario, el cliente / propietario del producto debe plantear la razón por la cual no es satisfactorio (no usted) y rechazar su finalización o definir otra historia de usuario que amplíe esta con una nueva definición de hecho que su solución actual no satisfaga.
La deuda técnica se genera solo cuando su solución actual no satisface algún requisito o restricción. ¿Hay alguna restricción que haya violado al usar una solución alternativa? En caso afirmativo, no debe marcar su historia de usuario como completada en primer lugar.
¿Hay alguna duplicación de código u otra mala práctica introducida por su solución? Luego ha creado una deuda técnica y debe resolverla lo antes posible. Puede ser justo con el propietario del producto y simplemente decirle que durante el próximo sprint debe dedicar el mismo tiempo a solucionar sus problemas técnicos, lo que dará como resultado historias de usuarios menos planificadas. O si su relación con el propietario del producto no es muy buena, simplemente planifique menos historias de usuarios debido a las complejidades "recientemente" descubiertas en cualquiera de ellos y arregle su deuda técnica.
Si no hay duplicación de código o alguna razón real por la cual su código debería mejorarse, simplemente no lo toque. Por la razón real me refiero a ninguna restricción definida por el cliente / propietario del producto (por ejemplo, la política de la empresa, el rendimiento, el tiempo predefinido para crear una nueva plantilla de correo electrónico que no se puede lograr con su solución actual, etc.). No hay deudas técnicas en su código. Lo que está tratando de hacer se llama chapado en oro: ofrecer características que no eran necesarias = malgastar los recursos de los clientes.
Si su solución no satisface ninguna historia de usuario futura, simplemente mueva su refactorización y código mejorando a esa historia de usuario. No tiene que resolverse ahora porque pasó la definición actual de hecho. Trate las mejoras cuando tengan que hacerse para pasar la definición de hecho para las historias recién implementadas y para evitar malas prácticas.
fuente