¿Puede Scrum usar especificaciones técnicas en la Lista de Producto en lugar de historias de usuarios?

En la compañía en la que estoy trabajando, 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. Entonces, (la mayoría) de las funciones es conocida y la mayoría de las mejoras son bastante técnicas.

En esto podría estar justificado tener tareas técnicas en lugar de historias de usuarios. Nuestra cartera de pedidos tiene todo tipo de tareas técnicas como:

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

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

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

TL; DR

Scrum no exige el uso de historias de usuarios; son simplemente una práctica ágil útil. Si bien el propietario del producto ciertamente podría usar especificaciones técnicas en lugar de historias de usuarios para crear la cartera de pedidos del producto, la mayoría de sus otros problemas de proceso se derivan de una falla en adoptar Scrum y prácticas ágiles efectivas.

Varios problemas con su proceso

Su Scrum parece estar roto en una amplia variedad de formas, que incluyen:

1. Sus especificaciones carecen de un punto de vista explícito o propuesta de valor.
2. Sus elementos pendientes no están vinculados a los objetivos de Sprint.
3. Su proceso de preparación del Backlog falta por completo o no puede crear picos de historia para el Backlog del producto.
4. Su proceso de Planificación de Sprint no está descomponiendo adecuadamente los elementos de la Pila del Producto en los elementos de la Pila del Sprint.
5. Su equipo no incluye adecuadamente la incertidumbre sobre los elementos de la cartera de pedidos en sus estimaciones de Sprint Planning.
6. Su equipo no respeta los fundamentos del time-boxing o la integridad del Sprint.

Si bien Scrum no siempre es el 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 historias de usuarios es solo una pequeña parte de los problemas de proceso más grandes que enfrenta su equipo.

Por qué los programadores ágiles adoptan historias de usuarios

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

• Reescribe el caché de objetos. ¿Por qué? Cual 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, ¿qué objetivo del proyecto aborda este?
• Implementar el registro del sistema. ¿Por qué? ¿Quién va a leer los registros? ¿Qué información necesitan contener los registros? ¿Cómo sabrá si el formato de registro o los datos de registro son útiles?

Desde la perspectiva del desarrollador, no poder responder a este tipo de preguntas conduce exactamente al tipo de problemas de proceso que usted 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 debe usar historias de usuario porque cree que es un requisito de marco o porque es una práctica ágil ampliamente aceptada. En cambio, debe trabajar en crearlos y usarlos de manera efectiva porque facilita las tareas de programación y hace que la profesión de programación sea más divertida. Su kilometraje puede variar, por supuesto.

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

Creo que sus tareas técnicas están bien, posiblemente en el lado grande, pero mensurables y definibles, así que absolutamente bien para una historia.

Las tareas de investigación son una gran señal de alerta para mí en Scrum porque proporcionan pocos beneficios visibles y pueden crear un enorme aumento de alcance. Abogo por limitar estos por adelantado en un sprint, no deberían agregarse y ciertamente no deberían agregarse a expensas de objetivos comprometidos. Si se necesitan 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 tapadera para los desarrolladores que en realidad no están haciendo un gran negocio y que desean pasar tiempo descubriendo 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 seguirán haciéndolo, siempre que lo permitan.

Scrum dice que será mejor que tengas un producto entregable para tu 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% de sentido para mí. Creas una cartera de pedidos que cuenta las historias del usuario de tus productos y quién es el usuario. Gerente técnico. Así elementos como:

1. Como gerente técnico, quiero que mi base de datos cambie de MySQL a X, de modo 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 entrega a su cliente (gerente 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 los picos en Scrum. Básicamente, son minitareas en cajas de tiempo que lo ayudan a determinar el tiempo requerido para realizar tareas más grandes y desconocidas.

Como Scrum Master, es posible que desee considerar carreras más largas debido a la naturaleza del trabajo. Esto le dará un poco más de amortiguación 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 código. ¿Qué esperas que haga un programador? Pídales que hagan algo para que funcionen y usen esta información para determinar si A: hace lo que queremos B: funciona mejor C: ¿Cuánto tiempo tomará ponerse más al día y comenzar a tener alguna idea de cuánto tiempo durará? aprovechar para hacer algo.

Si descubres que no sabes tanto como pensabas sobre la reescritura actual, puedes ir a ciclos de sprint más cortos. No tenga miedo de ajustarlos a medida que avanza; Esto es lo que significa ser ágil. Después de su investigación, también puede optar por la nueva tecnología. Esta podría ser otra razón para acortar los sprints antes de descontrolarse demasiado. Puede descubrir en medio de un sprint que las cosas nuevas no van a funcionar. Detenga el sprint y ajústelo 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ás haciendo malabarismos con las necesidades de tus desarrolladores y, en este caso, reescribiendo la aplicación. Supongo que hay propietarios de productos que desean que este proyecto se complete más temprano que tarde y no aceptarán la necesidad de "investigación" como una excusa a largo plazo.

Algunas de las siguientes estrategias pueden ayudar,

1. Sí, puede tener una cartera de pedidos con historias técnicas .

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

2. Para tareas de investigación (investigación), utilice 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 tener una caja de tiempo. Esto define el tiempo máximo que pasará aprendiendo y fija la estimación para el pico.