Scrum: ¿dónde haces todas las "otras" cosas?

Question

Con Scrum, está el principal de las historias de usuario y estas tareas de derivación, etc. pasando por un producto terminado, lo cual está bien.

Pero, digamos que tengo 100 características que deben implementarse, en el mundo real no puedo poner ningún desarrollador sobre estas hasta que se hayan hecho muchas cosas auxiliares normales, por ejemplo, hacer un diseño de IU (seguramente necesita tener una idea general de la funcionalidad para esto?), o construir las cosas subyacentes que no necesariamente se manifiestan como una característica.

Entonces, ¿dónde sucede esto?

Answer 1

Según tengo entendido, en scrum solo crea lo que se necesita para implementar cada historia de usuario. Por lo tanto, crea los elementos subyacentes que no son solo una función cuando se requiere implementar una característica para la historia del usuario en la que está trabajando.

Answer 2

En mi opinión, lo mejor es incluir como "Historia" la mayor cantidad de cosas posibles, para que todos tengan una buena visibilidad de a qué hora se aplica.

Sin embargo, siempre habrá tareas no planificadas que realizar (por ejemplo, reinstalar la máquina si está rota). Para esas tareas, una opción es dejar en cada iteración un porcentaje del tiempo libre, si tiene una velocidad de 300 puntos por iteración, por ejemplo, solo un total de 250 con historias al principio, para dejar el lugar a las cosas no planificadas. Entonces, en las siguientes iteraciones puede ajustar estos valores de acuerdo con su historial pasado.

Answer 3

Básicamente, ocurre dentro de cada característica, lo cual es más fácil decirlo que hacerlo, pero quizás sea el objetivo de un desarrollo incremental de software ágil.

Por ejemplo, en lugar de generar montones de "elementos subyacentes que no se manifiestan necesariamente como una característica", debe sospechar que no lo va a necesitar, y solo generar todo lo que necesite para la función en cuestión.

Answer 4

Las tareas no funcionales pueden seguir en la acumulación de productos, en mi opinión, cuando estaba usando Scrum, sin duda lo hice. Tuvimos que explicarle al propietario del producto por qué deberían considerarse importantes, de modo que pudiéramos tener el tiempo para hacerlo. Si el propietario del producto no cree que sea muy importante, no se hace, y el propietario tiene que vivir con los resultados. Después de haber sido mordido varias veces al rechazar sus solicitudes de cosas como la prueba de carga y luego caerse, es probable que vuelvan :)

Por otro lado, puede encontrar que hay algunos requisitos no funcionales que originalmente crees que son importantes, pero pueden languidecer sin impacto. A veces, sólo a veces, los instintos de los desarrolladores están equivocados :)

Para las tareas que son factores de compuerta genuinamente, creo que sólo hay que ser honesto con el dueño del producto y insiste que hay que hacerlas. Si no puede continuar con el propietario del producto en la medida requerida para continuar con el proyecto, existen problemas mayores que no obtener un diseño de interfaz de usuario :)

Answer 5

Construiría las tareas auxiliares en la primera función que lo requiera .

Es importante distinguir la diferencia entre la acumulación de pedidos del producto y la acumulación de sprints. La acumulación de productos contiene historias de usuarios que representan "qué/por qué", no "cómo". Cuando se selecciona una historia para un sprint, la historia se divide en las tareas necesarias para construirla. Por ejemplo: "UI Design" sería una tarea para la historia de "Seleccionar artículos para comprar".No hay daño en el nivel de planificación del sprint para que las tareas tengan dependencias tampoco; de hecho, la mayoría de las veces habrá tareas que harán la vida más fácil para otros artículos atrasados ​​del producto.

Espero que ayude!