Las historias ágiles y tareas [cerrada]

Question

Al diseñar un sistema de back-end, lo granularidad es lo que normalmente da a sus historias y tareas?

La mayoría de los ejemplos de la creación de historias y tareas por lo general se centran alrededor de una aplicación GUI con la historia de ser algo que el usuario puede hacer (por ejemplo, buscar un libro por el ISBN) y cada tarea se centraron en cómo activar esta función interfaz gráfica de usuario.

Al diseñar un sistema de back-end, es decir, uno que no tiene una interfaz de usuario, pero es sólo un montón de servicios que hablan a bases de datos, middleware, etc., ¿cómo subir con las tareas y las historias?

Answer 1

Básicamente, trato de mantener el tamaño de mis historias de los usuarios en el área de 1 a 10 días-hombre para completar. Que me impide pasar lo que Mike Cohn llama "epopeyas" o "Temas" como historias de usuario a los desarrolladores, y por el otro tamaño detener mis usuarios-historias que ser tan específico como para dar a entender la solución (que debe describir el problema, no la forma en que debe ser resuelto).

En cuanto al contenido va, me aseguro de que mis historias contienen sólo el valor del negocio - que nunca describe ¿Cómo I (debería) satisfacer la demanda, ni se "requiere" no usuario de dominio conocimiento para comprender.

Buen ejemplo:. Como un gestor de contenidos, quiero que todos los usuarios tengan que entrar antes de escribir un talk-back, con el fin de negarles la capacidad de correo no deseado

Mal ejemplo:. Añadir código de imagen de la página web

Tareas, por el contrario, son pasos hacia la solución de la solución - que describen los componentes y funcionalidad que necesitan ser añadido / modificado. Aquí es donde una solución "Añadir Captcha" entra en juego. En lo que a tamaño se va, trato de tener cada tarea Tamaño 's estar entre medio día y 2-3 días de trabajo.

Las tareas también incluyen un conjunto de tareas estándares que se aplican a todos y cada función / requisito / problema / error, como por ejemplo:

• Documento
• Casos de prueba de escritura
• Prueba manual
• escribir pruebas funcionales automatizadas etc.

Espero que esta ayuda, Assaf.

Answer 2

Como siempre y cuando tenga los usuarios, historias de usuario pueden estar alrededor de cosas que los usuarios pueden hacer. Si proporciona una API para los desarrolladores de otros, entonces son sus usuarios. Las cosas se pondrán más técnico en ese momento (es decir, el usuario puede actualizar los registros de los empleados)

Answer 3

Me base las historias en la interfaz pública de las clases. Para granularidad tarea Disparo de esfuerzo de trabajo de medio día a dos días.

Answer 4

Un usuario / actor puede ser un sistema, no necesariamente una persona. Sus servicios tendrán una API, de entrada y los resultados esperados y servicio de los acuerdos de nivel (requisitos no funcionales). Todos los que se puede especificar en la tarjeta de historia.

Lo más importante, su tarjeta de historia debe especificar los criterios de aceptación. Accpetance criterios ayudarán a impulsar los desarrolladores de pruebas de unidad de prueba Desarrollo Deiven, las pruebas funcionales automatizadas y las pruebas de rendimiento automatizados. Si los criterios de aceptación es digno, la tarjeta es aceptada y aprobada por el dueño del producto.