¿Cómo puedo convencer a mi equipo de que una especificación de requisitos es innecesaria si adoptamos historias de usuarios?

9

Estamos planeando adoptar historias de usuarios para capturar la 'intención' de los interesados ​​de una manera ligera en lugar de un SRS pesado (especificaciones de requisitos de software). Sin embargo, parece que aunque entienden el valor de las historias, todavía existe el deseo de 'convertir' las historias en un lenguaje similar al SRS con todos los atributos, prioridades, entradas, salidas, fuente, destino, etc.

Las historias de usuario 'eliminan' la necesidad de un SRS formal como artefacto para comenzar, entonces, ¿cuál es el punto de tener un SRS? ¿Cómo debería convencer a mi equipo (que son personas CS muy calificadas por cierto, tanto por educación como por práctica) que el SRS sería 'eliminado' si adoptamos historias de usuarios para capturar los requisitos funcionales del sistema? (También se pueden capturar NFR, etc., pero esa no es la intención de la pregunta).

Así que aquí está mi argumento de 'flujo de trabajo': captura los requisitos iniciales como historias de usuarios y luego los elabora para casos de uso (que deben documentarse a un nivel bajo, es decir, que describen las interacciones con los prototipos / maquetas de UI y son una publicación entregable) despliegue). Pasando así de historias de usuarios a casos de uso en lugar de historias de usuarios a SRS a casos de uso.

¿Cómo están actualmente capturando historias de usuarios en su lugar de trabajo (si es que lo hacen) y cómo sugieren que 'defienda' la ausencia de SRS en presencia de historias de usuarios?

agile requirements user-story requirements-management Doctor
fuente
no sucederá en un día, tome un enfoque fácil
Yusubov
Si trabaja para un proveedor de servicios de software, es posible que el SRS no sea necesario para realizar la implementación, sino para hacer el "juego de la culpa" cuando el cliente quiere reducir el costo o los argumentos del proveedor de servicios de que se necesita más dinero o ambos van a los tribunales.
k3b

Respuestas:

14

Pequeños pasos. Continúe escribiendo el SRS por un tiempo. Luego convoque a una reunión y discuta si todavía tienen un propósito. ¿Alguien todavía los lee? ¿Está justificado el tiempo dedicado a ellos? ¿Hay otro paso intermedio que sería más ligero?

Nunca se sabe, puede descubrir que está equivocado. Recuerde el manifiesto ágil, encontramos más valor en "Software de trabajo sobre documentación completa", pero todavía hay valor en este último.

Sin embargo, supongo que descubrirá rápidamente que el deseo de continuar escribiendo documentos pesados ​​desaparece cuando ven cuán estrechamente se relacionan los casos de uso y las historias de usuarios.

pdr
fuente
2
@ PhD: Tienes razón. Es casi primitivo. Y es por eso que no ganarás esta batalla con ningún tipo de lógica, solo con evidencia. Pequeños pasos.
pdr
2
He trabajado para gerentes que confrontaron el cambio con pasos pequeños , era su palabra clave para "hacer solo lo suficiente para fallar, así que puedo decir que tenía razón", este no es un camino hacia el éxito porque muestra una falta fundamental de comprensión de la nueva metodología y una falta de aceptación total por parte de la administración, que es crucial para un cambio exitoso. Esto suena bien en teoría, pero en la práctica es una excusa para no cambiar y reclamar la victoria de que la nueva forma no funciona y la vieja forma sí. Por lo tanto, el SRS se reforzó y las historias se etiquetarán como trabajo adicional y volverá a donde estaba.
2
Mi experiencia no es singular, es más de mis más de 22 años en la industria, la mayoría de los cuales fue consultoría. Así que he trabajado con muchos más gerentes y tomadores de decisiones que la mayoría de las personas en la misma cantidad de tiempo. Mi punto es que este enfoque de pequeños pasos es un enfoque de fracaso, solo el compromiso de la alta dirección con el cambio y la filosofía detrás del cambio conducirán a una implementación exitosa. Si sus colegas no están convencidos, dejarlos continuar haciendo lo que quieren no los convencerá, solo alimenta que todavía necesitamos la forma antigua y la nueva forma es un argumento de pérdida de tiempo.
1
@JarrodRoberson Solo quiero agregar que mis experiencias reflejan más de cerca las suyas. Hay dos tipos de personas y, por lo tanto, dos tipos de gerentes, conservadores y tomadores de riesgos. Los conservadores son naturalmente reacios al cambio y al riesgo. Cuando encuentran un modelo que funciona, incluso mal, se quedan con él. Cuando el cambio es forzado o presionado sobre ellos, inconscientemente lo sabotean tratando de dar pequeños pasos . Es por eso que la única vez que he visto un verdadero trabajo de adopción ágil es cuando está siendo dirigido por personas que toman riesgos.
maple_shaft
2
@maple_shaft: el truco es seguir avanzando. Si un cambio incremental no funciona, no necesariamente retrocedas el mismo paso, considera por qué no funcionó ... como si tal vez estuvieras pasando demasiado tiempo escribiendo un documento ahora sin sentido. Ahora reconoceré que se necesita un buen gerente para pensar de esa manera, y que la mayoría volverá a su zona de confort. Pero, exactamente por la misma razón, eso no significa que la única otra opción sea un cambio drástico. Un mal gerente lo arruinará de cualquier manera.
pdr
6

Las epopeyas son marcadores de posición

En casi cualquier metodología ágil, el concepto de épicas sería todo lo que necesita para una Especificación de requisitos, los marcadores de posición es lo que necesita a ese nivel. Esas entradas se priorizarán constantemente, más detalles se desperdician si el requisito tiene baja prioridad durante mucho tiempo, o si nunca se implementa. Documentarlo y administrar la documentación a su alrededor sería una completa pérdida de tiempo. YAGNI se extiende a las actividades de requisitos, así como a las actividades de codificación.

Las herramientas son tu amigo!

Si utiliza una herramienta adecuada para recopilar y administrar las historias de los usuarios, puede generar la Especificación de requisitos a partir de ellas. Una especificación de requisitos es un documento de artefactos temporales de todos modos, no es un documento vivo, es una instantánea de los requisitos a tiempo. Y nunca está sincronizado con la realidad.

Generar artefactos automáticamente

Las historias de usuarios que se pueden exportar desde una herramienta adecuada son mucho más valiosas que cualquier documento de artefactos estático en cualquier momento. Personalmente, prefiero Pivotal Tracker para rastrear historias de usuarios, incluso escribí un conjunto de complementos de MoinMoin en Python para publicar todas las diferentes historias y sus estados en el Wiki (que contenía notas detalladas del desarrollador y similares sobre las historias), los datos en vivo siempre son mejor que los datos estáticos.

El Wiki se convirtió en un documento en vivo de todas las tiendas / requisitos y su estado de finalización y prioridad con detalles y comentarios y otros metadatos.

¡Mucho mejor que un gran documento de Word en Sharepoint que simplemente se envía por correo electrónico constantemente y nunca se actualiza, garantizando que todos tengan una versión diferente y que no estén sincronizados con los demás!

Las historias de usuarios son más ricas que los casos de uso

La historia de uso es mucho más valiosa que un caso de uso porque dicen POR QUÉ .

El formato de la historia del usuario: As a [ROLE] I [ACTIVITY] so that [WHY]es mucho más expresivo que los casos de uso similares The System [shall/shall not/may/must] perform [action](donde la acción es un diagrama de flujo).

Con una historia de usuario, usted tiene QUIEN quiere hacer algo, tiene QUÉ quiere hacer (que puede indicar un diagrama / documento más detallado para tareas complejas) y tiene la parte más importante POR QUÉ quieren hacer esta actividad.

Si tiene el primero, el segundo es completamente redundante, y solo ruido en el mejor de los casos. Una especificación de requisitos formales tradicionales de una metodología de cascada no tiene cabida en un entorno ágil.

En el final

Si su gerencia no está comprometida con el cambio, no tendrá éxito con una nueva metodología. He trabajado para una compañía de más de 100 mil millones de dólares al año, no tomaron pequeños pasos para mudarse a Agile / SCRUM, solo dijeron, toda la compañía se está mudando a esto, aquí está la nueva forma de hacer las cosas, aquí está cuando comenzará su entrenamiento en la nueva forma, aquí están las nuevas herramientas que vamos a usar, aquí está la fecha en que comenzamos a hacer las cosas de esta manera. Les funcionó en menos de un año. He trabajado en implementar esto en compañías más pequeñas con el mismo éxito.

Compromiso

Las implementaciones de pequeños pasos , independientemente de cuál sea el cambio, son una receta para el fracaso. Es una palabra clave para la administración que discretamente no están de acuerdo y lo están configurando pasivamente para que falle. Dicen que no creo en esto lo suficiente como para comprometerme con él, por lo que te dejaré hacer lo suficiente para fracasar / no tener éxito , de esa manera pueden decir que lo intentaron y que no funcionó y de la forma en que lo estaban manejando. todo bien todo el tiempo. El compromiso parcial en última instancia conduce al fracaso.

En su caso, probablemente no creen en silencio en las Historias de usuarios, y después de un tiempo de hacer ambas cosas, comenzarán a afirmar que son las Historias de usuarios las que son inútiles y no el SRS, y presionarán para que dejen de escribirlas. , que solo lo llevará hacia atrás y no hacia adelante.

kmote
fuente
se sorprenderá bastante, las historias de usuario SON gestionadas por una herramienta que puede (y lo hace) exportar como requisitos. Sin embargo, la preocupación parece ser 'traducir' las historias de los usuarios al lenguaje SRS de "el sistema ...", etc., y NO dejarlas como historias de usuarios.
Doctorado
1
Bueno, si el problema es la termanología "debe / debe / puede" probablemente esté escupiendo al viento con esas personas. Las Historias de usuarios dicen QUIÉN / QUÉ y lo más importante POR QUÉ hay que hacer algo, mucho más útil que esos casos de uso estático, que son más incorrectos que correctos en la mayoría de los casos.
2
-1: No estoy en desacuerdo con la mayoría de la respuesta, sin embargo, afirmando que SRS es "Una especificación de requisitos es un documento de artefactos temporales de todos modos, no es un documento vivo", es tan incorrecto que muestra una inquietante falta de comprensión de lo que un SRS es para, o cómo se usa cuando se hace correctamente, por lo general solo en las casas de software de modelos de cascada heredados hoy en día.
mattnz 01 de
55
Un SRS es un documento muerto en cuanto se publica. Los he escrito desde 1990. Son como un plan de guerra, nunca sobreviven al primer contacto. Y nunca se mantienen al día con la implementación real, a menos que tenga un equipo dedicado de escritores que editan constantemente la cosa e incluso entonces está mal debido a la desconexión del cambio constante y los desarrolladores que siempre están por delante del documento, y no siempre dígale al dueño del documento lo que está pasando. Las empresas pasan miles de horas escribiendo cosas así, y los documentos se guardan en un estante y se pudren mientras comienza el desarrollo.
3
@JarrodRoberson +1 para ti. De hecho, Mattnz también tiene razón en que el SRS se supone que es un documento vivo, pero luego toma un par de problemas de producción críticos que el cliente exige que se modifiquen, mientras trabaja en una o más versiones ramificadas de la base de código, malinterpretando los requisitos por los analistas de negocios, los desarrolladores y el control de calidad ... lo que le queda es un documento que no es un reflejo verdadero del sistema en este momento, pero tampoco un reflejo verdadero de las necesidades del usuario. Las historias de usuarios son realmente adoptadas por compañías que están más preocupadas por el cliente que por el sistema.
maple_shaft
0

Intentaría usar el humor.

Comience con el http://www.halfarsedagilemanifesto.org/

Hable sobre esto por un tiempo ( diversión )
y hable sobre lo que realmente significan los conflictos ( discusión abierta ),
luego , después de un tiempo, recurra a su organización ( pivote )
y examine el SRS y si tiene sentido con la nueva configuración del proyecto .

Luego concluiría (o tal vez en otra reunión) con una discusión sobre el cambio en el enfoque re: SRS y ver si tiene más consenso.

Al final del día, también está limitado por el presupuesto y el servicio a la gente de negocios, por lo que puede haber un punto en el que sea un poco más firme en lo que se usa, pero esto realmente depende de la industria, el tamaño de la empresa, los factores organizativos y muchos otros. Otros factores de este tipo.

Michael Durrant
fuente
55
Ten mucho cuidado. Solo funcionará si tus compañeros de trabajo son muy seguros y tienes una buena relación con ellos. Muchas personas se enojan si usas el humor para decirles que están equivocadas y ocultas.
MarkJ
-1

Convencer a mgmt de alejarse del SRS y comenzar a usar historias de usuarios es esencialmente lo mismo que convencer a mgmt de adoptar Agile. Existen estadísticas convincentes sobre los beneficios de productividad de Agile. Un ejemplo es la presentación que dio VersionOne en una conferencia de 2013. Muestre los datos de esta industria y si son del tipo de escucha, tiene una oportunidad.

Joe
fuente
1
Lo siento, esa no es una gran respuesta. Usted dice 'mostrar estadísticas' y ni siquiera proporciona enlaces.
Jan Doggen
y escribir palabras y oraciones completas ...
jwenting