¿Cómo funciona la gestión de requisitos a largo plazo con los proyectos ágiles?

La gestión de requisitos a corto plazo para proyectos ágiles me parece un problema resuelto.

Desde el ángulo de Scrum, los nuevos requisitos o cambios en los requisitos existentes se entregan a través de User Stories. Y las historias de usuario agrupadas bajo una épica o característica facilitan la entrega de requisitos más grandes y complejos.

Por supuesto, una historia de usuario no es técnicamente un documento de requisitos. Es una agrupación de trabajo manejable que se asigna a lo que a menudo se llama una rebanada vertical de funcionalidad. Y el alcance de estas historias se puede definir inequívocamente mediante el uso de los Criterios de aceptación (AC).

Entonces, aunque las Historias de usuarios no son requisitos formales, navegar a través de ellas puede darle una idea bastante clara de sus requisitos subyacentes. A corto plazo.

Digo a corto plazo porque, a medida que avanza un proyecto, aumenta el número de Historias de usuarios. Por lo tanto, navegar a través de una lista cada vez mayor de Historias para encontrar un Requisito se vuelve cada vez menos eficiente con el tiempo.

Este problema se agrava cuando considera Historias de usuarios que se expanden, reemplazan o incluso niegan Historias anteriores.

Ahora, imagine una brecha de 2 años entre las iteraciones de desarrollo en un proyecto (estable en producción). El equipo original se fue y también todos sus conocimientos.

Si el equipo original sabía que esto iba a suceder (por ejemplo, es la naturaleza del negocio), ¿qué medidas podrían tomar para ayudar a los equipos posteriores?

Claro, el trabajo atrasado proporcionará cierta información, pero difícilmente se puede navegar fácilmente.

Entonces, ¿qué se puede hacer para ayudar a los equipos posteriores a comprender el estado del proyecto, incluido por qué y cómo llegó allí?

En mi experiencia, las siguientes cosas no funcionan:

• Acumulación de trabajos pendientes para eliminar o actualizar Historias de usuarios anteriores para que el Trabajo pendiente pueda leerse como un documento de requisitos.
• Sprints de documentación donde los miembros del equipo tienen la tarea de documentar el estado actual del sistema.
• Documentación a través de pruebas de comportamiento . Este enfoque es el único que he visto acercarse a trabajar. Desafortunadamente, las pruebas de comportamiento codificadas son víctimas del problema de nomenclatura. Aunque las pruebas pueden documentar correctamente el sistema, es casi imposible lograr que un equipo fluctuante de desarrolladores escriba sus pruebas siguiendo la misma terminología, redacción y estilo del dominio.

Entonces, para reiterar:

¿Cómo se gestionan los requisitos del proyecto ágil a largo plazo?

Esto me parece ser el elefante tácito en la sala con proyectos ágiles: ¿cómo evitas que evolucionen hacia el caos?

Veamos el Manifiesto Ágil por un momento. Deseos ágiles:

1. Entrega temprana y continua
2. Abrazando los requisitos cambiantes
3. Entrega de software de trabajo con frecuencia
4. Desarrolladores y partes interesadas de negocios que trabajan juntos todos los días.
5. Desarrollar proyectos en torno a individuos motivados, brindarles el entorno y el apoyo que necesitan, y confiar en ellos para hacer el trabajo
6. La conversación cara a cara como el principal modo de comunicación.
7. El software de trabajo como medida principal de progreso
8. Desarrollo sostenible
9. Atención continua a la excelencia técnica y buen diseño.
10. Simplicidad: maximizar el trabajo que no tiene que hacer
11. A intervalos regulares, el equipo reflexiona sobre cómo ser más efectivo, luego ajusta y ajusta su comportamiento en consecuencia

He destacado los últimos cuatro. ¿Por qué? Porque son los que evitarán que el proyecto se derrumbe bajo su propio peso.

El desarrollo sostenible significa que usted (con suerte) tiene a alguien que supervisa el proceso de desarrollo general, alguien que puede dirigir el barco más allá del crecimiento del software un poco a la vez, alguien que tiene una visión global de todo el proyecto, alguien con un gran conocimiento de arquitectura de software, diseño de sistemas, principios de lógica de negocios y ergonomía de la interfaz de usuario. Un arquitecto, en otras palabras.

El arquitecto es el que dice "Sé que pediste esto, pero si construimos esta otra cosa, podemos evitar estas otras tres características que son confusas y centrarnos en el requisito central". Él es quien le da tiempo al equipo para reducir la deuda técnica. Él es el que aporta una estructura y organización general al proyecto. Él es el que convoca reuniones donde el equipo se reúne y pregunta "¿Cómo podemos hacer las cosas mejor?"

Y él es el que mantiene el documento maestro de requisitos.

En el libro Dominar el proceso de requisitos , los autores sostienen que hay tres tipos de clientes, tres tipos de proyectos de software: conejos, caballos y elefantes.Los conejos son pequeños proyectos de software que solo necesitan requisitos informales; trabajas directamente con el cliente en pequeños sprints, el alcance del proyecto está razonablemente limitado y el software se realiza en un período de tiempo relativamente corto. Los elefantes son esos proyectos gigantescos que requieren mucha planificación inicial, una gran cantidad de documentación y un horizonte de tiempo largo. Podría decirse que no son ágiles, aunque puede dividirlos en proyectos más pequeños que se pueden construir usando ágil.

Son los proyectos Horse los que son algo confusos desde una perspectiva ágil. Todavía se pueden construir de forma iterativa, aún puede usar sprints cortos, pero sin cierta disciplina en los procesos de recopilación y planificación de requisitos, pueden salirse fácilmente de los rieles. Estos son los proyectos que pueden beneficiarse de un proceso disciplinado de recopilación de requisitos, y luego una cuidadosa adaptación y modificación de esos requisitos a medida que el proyecto crece, mientras se mantiene una visión general de todo el proyecto.

Desde una perspectiva personal, trabajo con un pequeño equipo de aproximadamente una docena de desarrolladores. En cualquier momento, podríamos estar trabajando en tres proyectos de software al mismo tiempo, desde unos pocos miles de líneas de código hasta más de 100,000. Nuestro cliente piensa que son un conejo, pero realmente son un caballo. El cliente está comprometido, pero no a diario.

Con mucho, nuestra área más débil es reunir requisitos específicos, comprobables y medibles y gestionar las expectativas del cliente en relación con el alcance del proyecto. Pero estamos trabajando en eso.

La pregunta no está completamente clara, pero parece que le preocupa la trazabilidad de los requisitos . En mi experiencia, una idea que tiende a perderse en Agile es que los requisitos comerciales son lo que el cliente quiere que haga el sistema, mientras que las historias de usuarios son requisitos realmente funcionales que indican cómo funciona el sistema. "Como usuario, quiero poder hacer X". Pero eso se hace para satisfacer un requisito, que puede perderse en la historia del usuario.

Lo que funciona bien en mi experiencia es vincular los requisitos comerciales y las historias de usuarios en ambas direcciones. BR # 1 puede ser realizado por las historias A y B. La historia C podría cubrir las BR # 2 y # 3. Ponga esto en su rastreador de proyectos, hoja de cálculo, lo que sea que esté usando.

A largo plazo, esto ayuda a vincular lo que el cliente está pidiendo (BR) con lo que hace el sistema (historias) para lograr esos requisitos. Esto debería ser una documentación bastante mínima que no sea onerosa de mantener, teniendo en cuenta la mentalidad ágil de no producir documentación que nadie necesita y es una tarea difícil de mantener actualizada.

También proporciona una forma para que los nuevos miembros del proyecto se aceleren, ya que tienen algo que revisar para obtener el historial de por qué el software hace lo que hace.

De hecho, estoy trabajando en un proyecto de mantenimiento kanban de una gran tienda web donde los desarrolladores originales ya no están disponibles.

cada userstory / require / bugfix tiene un número de ticket y cada cambio de código fuente está vinculado a un número de ticket en el campo sourcecontrol-comment-field.

sourcecontrol-checkin-s (svn) actualiza atómicamente el ticket de coressponding para que en el ticket tenga un enlace a todos los conjuntos de cambios de sourceconrtol.

Si un módulo / función se implementa recientemente, también hay números de ticket en el código fuente.

En el sistema de tickets (redmine), los tickets están vinculados entre sí como (es duplicado, es un error, es un refinamiento de ...)

para que pueda seguir los tickets y ver los cambios de requisitos con el tiempo.

Ejemplo: tengo que cambiar algo en el "orderConfirmation-Web-page". En el código fuente de la página veo un comentario: 'creado para "# 4711"' para poder vincular mi nuevo ticket al antiguo ticket "4711" o uno de sus sucesores.

Personalmente, descarto las historias de los usuarios como fuente de documentación sobre lo que el sistema puede hacer. A menos que se hayan tomado medidas activas para crear documentación (lo que hemos hecho para algunos de nuestros clientes más tradicionales), la base de la aplicación es realmente la mejor documentación que existe.

Aunque eso no es nada nuevo.

Si está utilizando una versión más escalada de Agile (como SAFe ), tendrá otros retrasos que no son el retraso de la implementación. Básicamente se ve así:

1. Cartera acumulada (planificación estratégica de épicas y presupuestos)
2. Programa / Release Backlog (Características y epopeyas)
3. Proyecto / Equipo Backlog (Historias, Picos, Errores)

No recomendaría documentar en el nivel de Backlog del equipo. Es demasiado granular y rara vez alguien quiere llegar a ese nivel de detalle. Sin mencionar que puede haber historias dentro de una versión que contradicen las historias anteriores en el trabajo atrasado del equipo.

En cambio, recomendaría trabajar en su nivel de Backlog de lanzamiento para proporcionar documentación de nivel de lanzamiento. Estas historias rara vez explotan una vez asignadas a un lanzamiento en particular, y pueden ser una forma estable y rápida de revisar lo que se está trabajando dentro de un lanzamiento dado.