¿Puede Scrum usar especificaciones técnicas en el Product Backlog en lugar de las historias de los usuarios?

14

En la empresa en la que trabajo actualmente, comenzamos a hacer proyectos Scrum. No fue tan difícil convencer a los gerentes de pasar de la cascada a Scrum. Estamos haciendo un proyecto donde reconstruimos nuestra plataforma desde cero. Así que (la mayoría) de la funcionalidad es conocida y la mayoría de las mejoras son más bien técnicas.

En esto podría justificarse tener tareas técnicas en lugar de historias de usuario. Nuestro backlog tiene todo tipo de tareas técnicas como:

  • Reescriba la clase DB desde MySQL a PostgreSQL.
  • Implementar el registro del sistema.
  • Reescribe el caché de objetos.

Las cosas que surgen durante los enfrentamientos incluyen que se desean largas "tareas de investigación", pero nunca se hacen. Además, los miembros del equipo afirman en medio de la carrera que se deben agregar tareas no planificadas.

¿Cómo debería un Scrum Master lidiar con esto? ¿Podría ser que para este tipo de proyecto, Scrum NO sea el camino a seguir?

    
pregunta sanders 02.09.2013 - 14:43

5 respuestas

10

TL; DR

Scrum no exige el uso de historias de usuario; Son simplemente una práctica ágil útil. Si bien el Propietario del producto podría usar especificaciones técnicas en lugar de historias de usuario para crear el Registro de productos, la mayoría de los otros problemas de procesos se derivan de una falla en adoptar prácticas eficaces y ágiles de Scrum.

Varios problemas con su proceso

Su Scrum parece estar roto en una gran variedad de formas, incluyendo:

  1. Sus especificaciones carecen de un punto de vista explícito o de una propuesta de valor.
  2. Sus elementos de la cartera de pedidos no están vinculados a los objetivos de Sprint.
  3. Falta el proceso de preparación de su Backlog o no se pueden crear picos de historia para el Product Backlog.
  4. Su proceso de planificación de Sprint no está descomponiendo adecuadamente los elementos de la cartera de productos en elementos de la cartera de sprint.
  5. Su equipo no está incluyendo correctamente la incertidumbre sobre los elementos de la cartera en sus estimaciones de Sprint Planning.
  6. Su equipo no está respetando los fundamentos del boxeo temporal o la integridad del Sprint.

Si bien Scrum no es siempre el ajuste adecuado para cada proyecto, en este caso sería más exacto decir que Scrum no está funcionando porque el equipo realmente no está haciendo Scrum. Su pregunta sobre las historias de los usuarios es solo una pequeña parte de los problemas de procesos más grandes que enfrenta su equipo.

Por qué los programadores ágiles adoptan las historias de usuario

Las especificaciones técnicas son una forma fundamentalmente rota de comunicar los requisitos. Los requisitos que no están guardados desde un punto de vista no proporcionan una guía útil para los desarrolladores. Usando los ejemplos publicados:

  • Reescriba la caché de objetos. ¿Por qué? ¿Cuál es el objetivo? ¿Quién recibe el beneficio? ¿Quién puede proporcionar aclaraciones sobre la tarea? Si esto está vinculado a un requisito no funcional, ¿a qué objetivo del proyecto se dirige?
  • Implementar el registro del sistema. ¿Por qué? ¿Quién va a leer los registros? ¿Qué información deben contener los registros? ¿Cómo sabrá si el formato de registro o los datos de registro son útiles?

Desde la perspectiva de un desarrollador, no poder responder a este tipo de preguntas conduce exactamente al tipo de problemas de proceso que describe. Eso es lo que hacen las historias de usuarios: proporcionan un contexto muy necesario y actúan como marcadores de posición para conversaciones adicionales con partes interesadas o usuarios finales sobre características específicas.

No debes usar historias de usuario porque crees que es un requisito del marco, o porque es una práctica ágil ampliamente aceptada. En su lugar, deberías trabajar para crearlos y usarlos de manera efectiva porque facilita las tareas de programación y la profesión de programación es más divertida. Su kilometraje puede variar, por supuesto.

    
respondido por el CodeGnome 02.09.2013 - 19:11
9

No creo que el problema aquí sea Scrum como tal, creo que el problema es que no existe un entregable del proyecto claramente definido y (lo he experimentado muchas veces) no hay una dirección clara.

Creo que tus tareas técnicas están bien, posiblemente en el lado grande pero mensurables y definibles, por lo que es absolutamente bueno para una historia.

Las tareas de investigación son una gran señal de advertencia para mí en Scrum porque ofrecen pocos beneficios visibles y pueden crear un enorme alcance. Yo abogo por limitar esto por adelantado en un sprint, no deben agregarse y ciertamente no deben agregarse a expensas de los objetivos comprometidos. Si son necesarios para completar una tarea de sprint acordada, entonces esa dependencia debería haber sido clara en la planificación (de lo contrario, ¿qué estaban estimando?).

En mi experiencia, los proyectos con muchos "picos de investigación" son una cubierta para los desarrolladores que, en realidad, no están haciendo un gran esfuerzo y quieren dedicar tiempo a descubrir lo nuevo y genial en lugar de crear valor comercial. No estoy sugiriendo que su equipo esté haciendo esto, pero un proyecto necesita objetivos claros y si los desarrolladores tienen libertad para "investigar", lo harán y lo seguirán haciendo, siempre que lo permita.

    
respondido por el Michael 02.09.2013 - 14:51
4

Scrum dice que es mejor tener un producto entregable a su cliente. Sin embargo, el punto aquí es que no especifica el producto entregable y el cliente .

En otras palabras, en su caso específico, puede definir su producto entregable como mejoras de código, cambios de plataforma, reescrituras y rediseños, etc., y considerar a su gerente técnico como su cliente.

Eso tiene 100% sentido para mí. Usted crea un atraso que cuenta las historias del usuario de sus productos y quién es el usuario. Gerente técnico. Así artículos como:

  1. Como gerente técnico, quiero que mi base de datos cambie de MySQL a X para que pueda aumentar la escalabilidad
  2. Como desarrollador, quiero un sistema de registro completo, para poder diagnosticar de manera más eficiente

Y lo que le entrega a su cliente (administrador técnico) es un sistema de registro.

Sin embargo, con respecto a las tareas de I + D de las que habló, le recomiendo que lea sobre picos en Scrum. Básicamente, son mini tareas que le ayudan a determinar el tiempo requerido para realizar tareas desconocidas.

    
respondido por el Saeed Neamati 02.09.2013 - 19:45
1

Como Scrum Master, es posible que desee considerar sprints más largos debido a la naturaleza del trabajo. Esto le dará un poco más de un búfer para las tareas de "investigación". Sin embargo, creo que debe asegurarse de que las tareas produzcan algún tipo de producto de trabajo / prueba de concepto en el código. ¿Qué más esperas que haga un programador? Pídales que trabajen en algo y utilicen esta información para determinar si A: hace lo que queremos B: funciona mejor C: cuánto tiempo tardará en ponerse al día y comenzar a tener idea de cuánto tiempo tomar para hacer algo.

Si descubre que no sabe todo lo que pensaba acerca de la reescritura actual, puede realizar ciclos de sprint más cortos. No tengas miedo de ajustarlos a medida que avanzas; esto es lo que significa ser ágil. Después de su investigación, también puede decidir ir con la nueva tecnología. Esta podría ser otra razón para acortar los sprints antes de salirse de control. Puedes descubrir en medio de un sprint que las cosas nuevas no van a funcionar. Detén el sprint y ajústalo con la vieja tecnología. Después de todo, sus desarrolladores deberían haber podido comparar y contrastar los métodos antiguos y nuevos.

Está haciendo malabares con las necesidades de sus desarrolladores y, en este caso, reescribiendo la aplicación. Supongo que hay propietarios de productos que quieren que este proyecto se complete más temprano que tarde y que no acepte la necesidad de "investigación" como excusa a largo plazo.

    
respondido por el JeffO 02.09.2013 - 17:31
1

Algunas de las siguientes estrategias pueden ayudar,

  1. Sí, puede tener un retraso con historias técnicas .

    Al igual que una historia de usuario, esto también debe ser Historias técnicas, centrándose en los beneficios que se brindarán al usuario final. Aquí hay algunos consejos para escribirlo. Estas son historias que aportarán un valor intrínseco al producto, como usted quiere moverse a un mejor back-end, etc.

  2. Para tareas de investigación (investigación) Use Spike

    Un pico es un experimento que permite a los desarrolladores aprender lo suficiente sobre algo desconocido en una historia de usuario, por ejemplo. Una nueva tecnología, para poder estimar esa historia de usuario. Una espiga debe estar en una caja de tiempo. Esto define el tiempo máximo que se dedicará a aprender y fija la estimación para el pico.

respondido por el ManuPK 04.09.2013 - 06:10

Lea otras preguntas en las etiquetas