¿Cuáles son exactamente los requisitos y tareas en Scrum?

Question

Estoy usando Scrum con un equipo pequeño por primera vez y he pasado por muchas presentaciones y documentos que explican este método ágil, pero todavía no sé exactamente qué requisito debe ser y qué tarea debería ser.

decir que quiero desarrollar una aplicación móvil que rastrea mis movimientos en tiempo real, lo primero que pensé estaba organizando mis requisitos y tareas como esta:

Requisito 1: Como usuario puedo ver mi posición en tiempo real en un mapa.

tareas que pertenecen al requisito 1:

• Código de la clase que crea un mapa con la API de Google Map.
• Codifique la clase de geolocalización.
• Dibuje un conjunto de iconos para representar al usuario .
• Escriba las pruebas unitarias.
• etc.

O, ¿hay que organizar las tareas de esta manera:

• escribir las pruebas unitarias.
• Codifique la lógica empresarial.
• Codifique la IU.

Ahora para los requisitos deberían tenemos:

• Como usuario puedo administrar mi cuenta.

O:

• Como usuario pueda iniciar sesión.
• Como usuario, puedo cerrar la sesión.
• Como usuario, puedo restablecer mi contraseña.
• etc.

Por último hay un nivel por encima de los requisitos en Scrum? He visto que algunas personas separan las cuotas y los requisitos, pero no puedo ver el beneficio. Si existen características en Scrum, ¿qué representan exactamente?

Gracias!

Answer 1

Todavía no sé exactamente qué requisito debe ser y qué tarea debería ser.

Ten cuidado.

En caso de duda, vuelva a leer el Manifiesto Ágil. http://agilemanifesto.org/

El punto no es que Scrum tenga una definición de requisito o tarea formal, oficial, válida para todos los tiempos.

Scrum le proporciona una forma de estructurar su trabajo. El punto es definir un entregable que usted (y su equipo) pueden crear en un tiempo razonable. Un equipo más grande y con más experiencia puede tener requisitos bastante "groseros".

Un equipo más pequeño y menos experimentado puede necesitar requisitos bastante "buenos".

Las tareas son las cosas que necesita hacer. El orden de las tareas no es parte de Scrum. Es parte de cómo usted y su equipo eligen trabajar.

Aquí está la parte compleja de Scrum (y Agile): está facultado para hacer lo que debe hacerse para crear software de alta calidad en el horario que usted haya definido.

Tiene que realmente pensar acerca de lo que se comprometerá y cómo desea llegar allí.

O, ¿hay que organizar las tareas de esta manera:

Esto es algo que debe decidir con su equipo. Debe construir software de alta calidad en un marco de tiempo predecible. Puede realizar las tareas aleatorias que desee de forma consistente con la entrega del software a tiempo. La gente debe saber que el caso de prueba primero (a/k/a TDD) realmente ayuda.

Ahora para los requisitos deberíamos tener:

Esto es algo que debe decidir con su equipo, el dueño del producto (y tal vez) a los usuarios. Debe comprometerse con la entrega a tiempo. Si entiende el dominio del problema, puede escribir historias de alto nivel y hacer sus compromisos. Si hay dudas, incertidumbre o duda, puede escribir historias de usuarios de nivel inferior para asegurarse de cumplir sus compromisos.

¿Hay un nivel superior a los requisitos en Scrum?

Si les ayuda, sí, puede ser.

He visto que algunas personas separan las tarifas y los requisitos, pero no veo el beneficio?

Entonces no te preocupes por eso. Vuelve a leer el Manifiesto Ágil. Si las características lo ayudan a usted, a su equipo y al propietario de su producto, deberá definirlos con mayor claridad. Si no ayudan a la conversación, entonces puedes ignorarlos.

Si existen funciones en Scrum, ¿qué representan exactamente?

Las características son parte de una historia. Son elementos específicos de GUI o pasos de procesamiento que ayudan al actor a superar la historia.

Answer 2

Los requisitos son desde la perspectiva del cliente de lo que esperan de la aplicación - en su mayoría sin jerga tecnología

Requisitos se descomponen en las historias de usuario (tareas - puede ser técnico).

Por ejemplo,

Como usuario puedo ver mi posición en en tiempo real en un mapa

Esto se puede llamar una historia de usuario, pero puede ser un poco alto nivel desde aún puede dividirse en historias de usuarios más pequeños. Como,

• Como una aplicación, tengo Google Map API integrada.
• Como una aplicación, que tienen la funcionalidad para configurar iconos para representar usuario

etc.

Editar:

Sin embargo, su hasta usted, historias de usuario pueden tener sub tareas también, por lo que puede tener su requisito original como una historia de usuario y puede agregar las cosas que mencioné como tareas secundarias a la misma. En general, ayuda a que las historias de los usuarios sean lo más pequeñas posible para obtener mejores estimaciones de tiempo y recursos.

Answer 3

Si existen características en Scrum, ¿qué representan exactamente?

La respuesta depende de dónde haya aprendido el scrum. Veo una función como una historia de usuario épica . Es un objetivo que desea alcanzar, pero es una gran parte del trabajo. Puede dividir historias de usuario épicas como cortar un pastel en [más pequeñas] historias de usuarios.

Usted puede leer acerca de esta práctica en Historias usuario Mike Cohn 's Aplicada: Para desarrollo de software ágil libro. Si acabas de empezar a utilizar Scrum, este libro realmente te ayudará.

Algo sin relación. Noté que tienes tareas separadas para las pruebas unitarias. No recomiendo hacer eso, porque esta tarea generalmente será lo último que el equipo implementará, y encontrarán errores demasiado tarde. Las últimas tareas generalmente se implementan bastante cerca de la demostración, y no tendrá tiempo para corregir esos errores.

Considere tareas como historias de usuario muy pequeñas, que no tienen valor para el cliente por separado, pero en conjunto, que valoran mucho, exactamente tanto como su historia de usuario, en realidad. Tener una definición del acuerdo realizado para las tareas, que contiene las pruebas unitarias como parte de los criterios de finalización.

O puede usar el TDD de XP.

HTH,

Zsolt