En Scrum, ¿debería dividir el trabajo acumulado en un trabajo funcional y un trabajo técnico o no?

12

En nuestros equipos de Scrum, utilizamos un backlog, que en su mayoría contiene temas funcionales, pero a veces también contiene temas técnicos. La ventaja de tener 1 backlog es que es fácil elegir los temas para el próximo sprint, pero tengo algunas preguntas:

  • Primero, para mí, parece más lógico tener un registro técnico separado, donde los propios desarrolladores pueden agregar elementos técnicos puros, como: podríamos mejorar el rendimiento en este método, esta clase carece de documentación técnica, ... Al tener uno backlog, todos los desarrolladores siempre tienen que pasar a través del propietario del producto para que sus temas se agreguen al backlog, lo que parece un trabajo adicional e innecesario para el propietario del producto.
  • Segundo, si tiene un propietario de producto que solo se enfoca en los elementos puramente funcionales, los elementos puramente técnicos (como la documentación técnica faltante, el código que erosiona y debe ser refactorizado), las clases que siempre dan problemas durante la depuración porque no No tenga una base estable y debe ser refaccionado, ...) siempre termina al final de la lista porque "no sirven directamente al cliente". Al tener un atraso técnico separado y un tiempo reservado en cada carrera para estos elementos puramente técnicos, podemos mejorar las aplicaciones funcionalmente, pero también mantenerlas saludables dentro.

¿Cuál es el mejor enfoque? ¿Un retraso o dos?

    
pregunta Patrick 25.09.2012 - 14:51

6 respuestas

15

No soy un experto, pero diría que solo puedes tener un backlog por equipo. El equipo debe decidir qué asuntos son urgentes y cuáles pueden posponerse. Si separa los problemas en tipos separados de pilas, se opone a la idea central que está en el corazón de scrum, que es que hay un conjunto de problemas y cada sprint en el que el equipo trabaja en el más urgente. Si usted (sub) divide los equipos, podría dividir los tipos de tareas que son relevantes para ellos, pero básicamente estaría configurando equipos que trabajan en paralelo. La urgencia / necesidad es la decisión número uno a la hora de planificar el próximo sprint. Puede clasificar las tareas, pero esto no debería interferir con su proceso de decisión.

    
respondido por el Onno 25.09.2012 - 15:10
9

Me gustaría agregar mi voz a aquellos que recomiendan un retraso por producto. Crear otro trabajo atrasado es una respuesta racional, pero en realidad solo se trata de evitar el problema central: ¿por qué el propietario del producto no prioriza los elementos técnicos sobre los elementos principales? Debes enfocarte en resolver esto en lugar de trabajar alrededor de esto. Puede utilizar la técnica 5 por qué , por ejemplo, para intentar llegar al fondo de las cosas.

Puede haber muchas razones por las cuales la OP no prioriza los problemas técnicos. Por ejemplo, tal vez el equipo técnico no esté explicando el costo a largo plazo (en $$$) de no abordar la deuda técnica. Tal vez sea algo completamente distinto. Es muy probable que se trate de un problema de comunicación, y la solución a largo plazo es trabajar en ello y resolverlo: eliminar el impedimento.

Además, tengo otra pregunta para que piense: ¿Por qué surgió la deuda técnica en primer lugar? Idealmente, el trabajo como la refactorización, etc., debería ocurrir dentro de las historias funcionales y completarse dentro del sprint. No deberían ser historias adicionales por derecho propio, de lo contrario, no tiene un código que se pueda enviar.

    
respondido por el MelR 25.09.2012 - 16:08
6

A lo que te refieres se le llama comúnmente 'deuda técnica'. A veces puede ser difícil ver cómo el trabajo técnico de la deuda encaja en el proceso de scrum, de la misma manera que los defectos pueden.

Lo que está proponiendo es similar a sugerir que también hay un 'atraso defectuoso' separado, dividiendo el atraso en 3.

Personalmente, no abogaría por la división de la cartera de productos en absoluto. La idea de la acumulación de productos es representar elementos de trabajo . Desde esa perspectiva, la única diferencia entre una característica y una deuda técnica es que el requisito provino del equipo de desarrollo, no del cliente. Sigue siendo un elemento de trabajo y aún debe gestionarse, incluida la priorización frente a otros elementos de trabajo. Esto es especialmente cierto si el elemento técnico de la deuda requiere pruebas, en cuyo caso debe pasar exactamente por el mismo proceso de control de calidad que una función regular.

    
respondido por el MattDavey 25.09.2012 - 15:42
4

Estoy de acuerdo con Onno en que solo debe haber un solo backlog por proyecto. De lo contrario, el equipo básicamente está tomando en sus propias manos algunas decisiones que pertenecen legítimamente al propietario del producto.

Incluso los elementos "puramente técnicos" deben tener algún valor práctico para los usuarios (y, por lo tanto, para el propietario del producto) para ser elegibles para la acumulación de sprint. Es su tarea explicar el beneficio de estos al propietario del producto y convencerlo del valor agregado que justifica el costo. Y este proceso lo obliga a pensar en estos problemas y seleccionar los cambios técnicos que aporten el mayor valor al proyecto con el menor esfuerzo.

    
respondido por el Péter Török 25.09.2012 - 15:43
2

Estoy de acuerdo con todas las respuestas anteriores. En el calor de la realidad comercial, la OP seguirá priorizando las historias funcionales sobre las técnicas. A menudo para la frustración del equipo. El equipo debe abstenerse de las historias técnicas sin ningún valor para el usuario (¿a quién le importa una optimización, si la velocidad no es un problema?) Y aprender a ver otras tareas técnicas según lo implican las historias funcionales. La "definición de hecho" también juega un papel importante. Las historias funcionales restantes se quedan en el backlog para que el PO las priorice.

Por ejemplo, Documentación técnica: la disponibilidad de documentación técnica (cuando corresponda) es un elemento típico que pertenece a la D.O.D. Y, por lo tanto, la actualización está IMPLÍCITA con cada historia funcional.

Por ejemplo, Código de refactorización: debe hacerse cuando beneficie el desarrollo del producto. No antes (el equipo no debe asumir en qué dirección evolucionará el producto) y no más tarde cuando ya se haya convertido en deuda técnica. Tener el diseño revisado también podría ser parte del DoD.

    
respondido por el Kris Van Bael 25.09.2012 - 19:25
0

Estoy de acuerdo con MelR. Si hay algo que sea 'técnico', debemos ver por qué lo estamos haciendo, o incluso a corto y largo plazo cause and effect (para el usuario)?

He visto muchos atrasos en los que las llamadas "tareas técnicas" se pueden escribir fácilmente en una forma de valor comercial.

Las tareas técnicas también suelen ser el resultado de grandes historias desglosadas, ya que puede ser la forma más fácil de descomponer las cosas. Pero esto puede causar iteraciones más lentas del verdadero valor agregado (u oportunidades de retroalimentación) o aún peor la falla de los sprints.

En lo que respecta al "código que se erosiona y debe ser refactorizado" como lo menciona Patrick, creo que debemos preguntarnos: ¿en qué área de la funcionalidad del sistema está afectando ese código? y ¿cuál es el efecto a largo plazo en el usuario si no lo refactorizamos ahora?

Luego está el tema de "dejar las cosas un poco mejor que cómo lo encontramos" para reducir la deuda técnica a largo plazo y, de este modo, se puede hacer esto como parte de las pequeñas historias de cada sprint sin demasiado impacto en el proyecto más amplio. ?

En última instancia, no veo la necesidad de dos atrasos, esto abre una oportunidad para frenar las necesidades priorizadas adecuadamente, pero existe la necesidad de que el propietario de un producto esté informado sobre las preocupaciones de los impactos técnicos y tenga una gran capacidad para identificar verdadero valor para desglosar las historias verticalmente - Adobe ofrece una buena explicación en corte vertical .

    
respondido por el James 23.02.2017 - 09:53

Lea otras preguntas en las etiquetas