No se puede simplemente tener historias de usuarios de alguna manera la funcionalidad del programa debe documentarse. ¿Terminas con un documento de especificaciones con scrum? Si lo haces, terminas asignando tiempo para hacer esto en la tarea?Scrum y requisitos
Un ejemplo sería un flujo de trabajo complejo.
Otro ejemplo sería un nuevo miembro que entra en el equipo.
Añadir "documentación" como una tarea en cada historia de usuario sin duda podría recorrer un largo camino hacia su objetivo.
Además de lo que dijo James Kolpack, el mapa de la historia del usuario debe continuar después de que el proyecto finalice, ya que también es una forma de documentación. Creo que planeamos cómo convertirlo en un documento que vive en nuestra Wiki cuando todo está dicho y hecho.
La idea es que este documento sea útil para las personas que necesitan mantener el sistema o agregar mejoras en el futuro porque comprenderán la perspectiva del usuario.
Se agregarán muchas buenas ideas a esta pregunta. Mi experiencia personal me ha enseñado que:
1 ~ El producto de trabajo es una forma de documentación en sí: suponiendo que el producto sea aceptado, entonces preguntar qué debe hacer bajo ciertas condiciones equivale a preguntar qué hace realmente bajo esas condiciones. condiciones: inicie sesión y pruébelo para obtener su respuesta.
2 ~ Las pruebas, ya sean manuales o automáticas (o una mezcla), son una forma de documentación. Ciertamente, las pruebas unitarias pueden estar muy lejos del idioma del dominio hablado por los miembros del equipo con menor inclinación técnica (por ejemplo, "expertos en negocios" o clientes). Las pruebas de aceptación pueden estar más cerca de un 'término medio' de tipo. Definitivamente, las pruebas de estilo BDD parecen tener la mejor oportunidad de construir un lenguaje ubicuo que todos puedan entender (consulte al respecto Gojko's Bridging the Communication Gap). No obstante, todas estas formas de pruebas son una forma de documentación que se puede usar para determinar qué debe hacer el producto.
3 ~ Dependiendo de dónde se encuentre su proyecto en el espectro, su documentación (y, en general, todos sus artefactos auxiliares) puede requerir un mayor o menor grado de ceremonia. Los productos más pequeños, los equipos más pequeños, donde el tiempo de comercialización es crítico, pueden encontrar que una documentación muy formal de los costos de los requisitos es demasiado alta en comparación con el valor que agrega. Los proyectos extremadamente grandes, que abarcan múltiples equipos y años de desarrollo, por otro lado, encontrarán que el ROI de la documentación formal es bastante diferente.
4 ~ En el mundo perfecto, probablemente no necesitará documentar requisitos distintos en forma de código de trabajo (que, en la torre de marfil sería también explica por sí mismo) y pruebas (sobre todo para las pruebas de regresión, y -en el margen- para impulsar el desarrollo de nuevas características). Por lo tanto, la cuestión de la documentación de requisitos es una pregunta sobre qué es diferente entre Perfect World/Ivory Tower y Real World/Trenches. La respuesta, por supuesto, es diferente caso por caso, según el proyecto y el equipo. Por ejemplo, podríamos decir "Todos los requisitos se guardarán en esta wiki, y se mantendrán con sumo cuidado, etc., etc.", pero si el equipo no está familiarizado y cómodo con los wikis, esto no funcionaría.
5 ~ Al final, las partes interesadas son las que debe preguntar. Ciertamente, el tema debe abordarse de manera colaborativa, ya que todos en el equipo tendrán que interactuar con los requisitos a lo largo del proyecto, pero debe encontrar una forma de documentación que satisfaga las necesidades de los interesados.
dicho todo esto, aquí hay algunos lugares que he visto requisitos documentados, mientras que la aplicación de Scrum (¿por qué siento que esta palabra siempre debe ser seguido por un asterisco?):
Y, para ser honesto, no puedo decir que cualquier sistema tiene una correlación consistentemente más alta con un proyecto exitoso que los demás. Supongo que, de hecho, no tenemos una bala de plata.
HTH, gracias por la pregunta a la reflexión!
Tal vez mi comprensión de la cuestión es totalmente erróneo, pero lo que entendí fue que el PO se sintió cómodo en el desajuste entre historias y necesidades de los usuarios. Con razón, diría.
En mi opinión, las historias de usuario cuentan cómo un trozo de funcionalidad se demostrará que el dueño del producto. El lenguaje de la historia puede ser algo que pueda ser entendido por el propietario del producto, pero principalmente por los desarrolladores. Es posible que tenga historias que describen cosas que ni siquiera son directamente requeridas por el propietario, sino que son desgloses de cosas que sí lo son.
requisitos en el otro lado son una especificación detallada en el idioma del usuario del dominio de lo que el sistema tiene que hacer con el fin de ser válido. En muchos casos, un documento de requisitos no es opcional (proyectos de precio fijo, por ejemplo).
Lo que hago es una mezcla de ambos. Tengo un documento de requisitos, y en la mayoría de mis historias de scrum, tengo algo en mis notas que vincula esa historia con uno o más elementos de los requisitos. Es tan simple como "Ver FR-042 y FR-45" (FR para requisito funcional, por ejemplo)
Scrum dice que se debe documentar lo que necesita, cuando lo necesite; no dice que no deberías tener documentos.
Entonces, si el producto final requiere un documento (por ejemplo, documentación de ayuda) o para producir el producto terminado (por ejemplo, documentación de requisitos), debe haber una tarea de documentación/historia de usuario en la acumulación de productos.
prioridad Luego se han colocado para esa tarea.
Para la documentación, el punto clave es; Sólo
No se puede tener historias de usuario de alguna manera la funcionalidad del programa tiene que ser documentado. ¿Tiene termina con un documento de especificaciones con scrum? Si lo haces, terminas asignando tiempo para hacer esto en la tarea ?
¿Por qué no puedes simplemente tener historias de usuarios? ¿Para qué sirven estos documentos de especificación? ¿Qué valor devuelve la inversión en la producción de estos documentos? ¿El beneficio pesa el costo? Si no es así, ¿no es el tiempo dedicado a crear y, lo que es más importante, mantener, el desperdicio de estos documentos?
Sé que estoy haciendo más preguntas que respondiendo, pero creo que parte de lo que Scrum y otros enfoques ágiles como Lean Do te obligan a volver a examinar tus prácticas actuales y ver si todavía tienen sentido.
En el caso de las especificaciones, ¿quién actualizará y mantendrá estos documentos una vez que la característica se haya lanzado? En la mayoría de las empresas en las que he estado, la documentación ha sido escasa, desactualizada o rara vez referenciada.
En su lugar, ¿por qué no utilizar pruebas ejecutables o BDD para que la documentación se vuelva parte del código y sea ejecutable? Por ejemplo, consulte Ben Mabey's talk on Cucumber
Si por algún motivo, se requiere un tipo de documento específico para cumplimiento legal, siempre puede agregarlo a la definición de "hecho" de los equipos, sin embargo, he encontrado en la mayoría de los casos , las historias y las pruebas son formas más que suficientes de documentación.
Principalmente estoy de acuerdo con Todd, pero hubo momentos en que parte de la tarea de mi equipo era producir documentación: La documentación era la historia del usuario en sí que nuestro pedido solicitó.
En estos casos se siguieron las siguientes directrices:
En mi experiencia que hace más fácil escribir documentos y permitir algún tipo de prueba (le preguntas a alguien, por lo general PO, para leer el documento y decir si está bien teniendo en cuenta el objetivo).
Usted escribe documentación para validar su sistema. Las historias de usuario tienen el mismo propósito si se escriben correctamente en un formato que refleja la interacción del usuario con el sistema. Recomendaré usar BDD y escribir historias usando la sintaxis de Gherkin. Eventualmente, sus escenarios se convierten en sus criterios de aceptación que ayudan a la validación de si el sistema está funcionando correctamente o no.
Tenemos un equipo de docs que produce el "manual de instrucciones" para nuestro producto. El manual está estructurado en torno a las características principales del producto y las tareas que el usuario puede realizar en esas características.
Cada sprint, los equipos Scrum trabajan en historias de usuarios que agregan funcionalidad a las características del producto.
Después de la planificación del sprint, el equipo de documentación se reúne con el equipo de Scrum y ver qué historias de usuarios se desarrollarán en este sprint. El equipo de docs luego comienza a mejorar el manual de instrucciones escribiendo los documentos iniciales. Durante el sprint, el equipo de documentación sigue el progreso de las historias de los usuarios y puede usar el producto a medida que se despliega en los entornos de prueba. Al final del sprint, el equipo de documentación finaliza el manual de instrucciones actualizado y agrega capturas de pantalla finales, etc. ...
El manual de instrucciones se envía como parte del lanzamiento de cada sprint.
Creo que estás pidiendo algunas cosas diferentes aquí. Si está agregando un nuevo miembro del equipo, entonces la documentación del sistema debe estar orientada a su rol en el equipo como parte del proceso de incorporación.
Si está hablando de documentar la funcionalidad del sistema; en nuestra organización, nuestros equipos de capacitación documentan la funcionalidad como parte del lanzamiento. Participan (como parte interesada) durante la Revisión de Sprint (demostración) y luego proporcionan un entorno de capacitación con la nueva funcionalidad para preparar los materiales de capacitación antes del lanzamiento.
Si está hablando sobre la provisión de documentación para la tractabilidad, su acumulación de datos puede servir como eso con los controles adecuados del proceso & agregados.
Cada uno de estos elementos diferentes requiere una planificación y un desarrollo deliberado del proceso para funcionar con eficacia y satisfacer las necesidades del equipo. Hemos incluido cada uno de estos elementos en nuestras retrospectivas cuando se identificó un problema y luego desarrollamos nuestros procesos a lo largo del tiempo.
Esta pregunta no está relacionada con el tema porque no está dentro del alcance de este sitio, como se define en [¿Qué temas puedo preguntar aquí?] (// stackoverflow.com/help/on -topic) También vea: [Qué tipos de preguntas que debo evitar preguntar?] (// stackoverflow.com/help/dont-ask) Puede solicitar en [otro sitio de Stack Exchange] (// stackexchange.com/sites#name), por ejemplo [ pm.se] o [softwareengineering.se]. Asegúrese de leer la página del tema en el centro de ayuda de cualquier sitio en el que desee publicar una pregunta. – Makyen