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

14

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

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

Por supuesto, una historia de usuario no es técnicamente un documento de requisitos. Es un grupo de trabajo manejable que se asigna a lo que a menudo se denomina una Vertical Slice de funcionalidad. Y el alcance de estas historias se puede definir sin ambigüedades a través del uso de los Criterios de Aceptación (AC).

Por lo tanto, aunque las Historias de usuario no son requisitos formales, su búsqueda 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 la cantidad 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 las Historias de usuario que amplían, sustituyen o incluso niegan las 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 ha ido y también lo es todo su conocimiento.

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, la acumulación de datos proporcionará cierta información, pero es difícil de encontrar.

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

En mi experiencia, las siguientes cosas no funcionan:

  • Preparación del trabajo atrasado para eliminar o actualizar las Historias de usuario anteriores para que el Registro se pueda leer 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 cerca de trabajar. Desafortunadamente, las pruebas de comportamiento codificado son víctimas del problema de nombres. Aunque las pruebas pueden documentar correctamente el sistema, conseguir que un equipo fluctuante de desarrolladores escriba sus pruebas siguiendo la misma terminología, redacción y estilo del dominio es casi imposible.

Por lo tanto, para reiterar:

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

    
pregunta MetaFight 04.08.2014 - 13:57

4 respuestas

10

Me parece que este es el elefante no hablado en la sala con proyectos ágiles: ¿cómo evitar 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 alrededor de individuos motivados, brindándoles el entorno y el apoyo que necesitan, y confiando en ellos para hacer el trabajo
  6. Conversación cara a cara como modo principal de comunicación
  7. El software de trabajo como la medida principal del progreso
  8. Desarrollo sostenible
  9. Atención continua a la excelencia técnica y al buen diseño
  10. Simplicidad: maximiza el trabajo que no tienes que hacer
  11. A intervalos regulares, el equipo reflexiona sobre cómo Para ser más efectivo, entonces afina y ajusta su comportamiento en consecuencia

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

El desarrollo sostenible significa que (con suerte) usted tiene a alguien que supervisa el proceso de desarrollo general, alguien que puede dirigir la nave más allá del crecimiento del software poco a poco, alguien que tiene una visión general de todo el proyecto, alguien con un gran conocimiento de la arquitectura de software, el diseño de sistemas, los principios de lógica de negocios y la 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 enfocarnos en el requisito central". Él es el que le da tiempo al equipo para reducir la deuda técnica. Él es el que aporta una estructura y organización global al proyecto. Él es el que llama a las reuniones donde el equipo se reúne y pregunta "¿Cómo podemos mejorar las cosas?"

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

En el libro Dominando 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 los pequeños proyectos de software que solo necesitan requisitos informales; trabaja 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 una gran cantidad de planificación inicial, una gran cantidad de documentación y un horizonte de tiempo largo. Podría decirse que no son ágiles, aunque se pueden dividir en proyectos más pequeños que se pueden construir utilizando ágil.

Los proyectos de Horse son algo confusos desde una perspectiva ágil. Todavía se pueden construir de forma iterativa, aún se pueden usar carreras cortas, pero sin una cierta disciplina en los procesos de recopilación y planificación de requisitos, se pueden ejecutar fácilmente. 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 para todo el proyecto.

Desde una perspectiva personal, trabajo con un pequeño equipo de una docena de desarrolladores. En un momento dado, 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 es un conejo, pero en realidad es un caballo. El cliente está comprometido, pero no a diario.

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

    
respondido por el Robert Harvey 04.08.2014 - 16:07
3

La pregunta no está del todo clara, pero parece que le preocupa la rastreabilidad de los requisitos . Una idea que tiende a perderse en Agile en mi experiencia es que requisitos comerciales es lo que el cliente desea que el sistema haga, mientras que historias de usuario son realmente requisitos funcionales que indica cómo funciona el sistema. "Como usuario, quiero poder 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 usuario en ambas direcciones. BR # 1 puede darse cuenta mediante las historias A y B. La historia C puede cubrir BRs # 2 y # 3. Ponga esto en su rastreador de proyecto, hoja de cálculo, lo 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. Esta debe ser una documentación bastante mínima que no sea onerosa de mantener, manteniendo la mentalidad ágil de no producir documentación que nadie necesita y es una tarea mantenerla actualizada.

También proporciona una manera para que los nuevos miembros del proyecto puedan llegar a la velocidad, ya que tienen algo que revisar para obtener el historial detrás de por qué el software hace lo que hace.

    
respondido por el user22815 04.08.2014 - 20:02
2

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

cada usuario / requisito / corrección de errores tiene un número de ticket y cada cambio de código de fuente está vinculado a un número de ticket en el campo sourcecontrol-comment.

sourcecontrol-checkin-s (svn) actualiza automáticamente el ticket correspondiente para que en el ticket tenga un enlace a todos los conjuntos de cambios sourceconrtol.

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

En el sistema de tickets (redmine), los tickets están enlazados entre sí ya que (es duplicado, es error, es refinamiento de, ...)

para que pueda seguir los tickets y ver los cambios de requisitos a lo largo del tiempo.

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

    
respondido por el k3b 05.08.2014 - 14:59
1

Personalmente, descarto las historias de usuario como una fuente de documentación sobre lo que puede hacer el sistema. 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 aplicaciones 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 trabajos pendientes que no son el trabajo pendiente de la implementación. Básicamente se ve así:

  1. Cartera de cartera (planificación estratégica de epopeyas y presupuestos)
  2. Programa / Release Backlog (Features and Epics)
  3. Trabajo pendiente del proyecto / equipo (Historias, picos, errores)

No recomendaría documentar en el nivel de Backlog del equipo. Es demasiado granular y rara vez alguien quiere ir a ese nivel de detalle. Sin mencionar que puede haber historias dentro de un lanzamiento que contradigan las historias anteriores en la acumulación del equipo.

En su lugar, recomendaría trabajar en su nivel de Registro 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 en qué se está trabajando dentro de un lanzamiento determinado.

    
respondido por el Jay S 05.08.2014 - 15:05

Lea otras preguntas en las etiquetas