¿Cómo administro las especificaciones en Scrum?

Question

En cuanto a this buddy question, quiero saber cómo se pueden administrar las especificaciones en el proceso de Scrum? Me enfrento a este problema al asignar tareas a mi equipo para el sprint. No hace falta decir que soy nuevo en Agile/Scrum.

Actualmente, estamos utilizando nuestra propia hoja de especificaciones para asignar StoryId a SpecId y viceversa. Me da la sensación de que Scrum se trata más de gestión de proyectos [hacer las cosas a tiempo] y necesita un proceso independiente para administrar las especificaciones y los requisitos.

¿Cómo gestionamos las especificaciones en un proceso de Scrum?

Answer 1

La respuesta corta es que no.

La pregunta importante que debe hacerse al escribir estas especificaciones es ¿por qué las hacemos? ¿Cuál es el valor en la especificación?

El valor en la especificación generalmente viene al comunicar las ideas del negocio con el equipo de desarrollo. Scrum está diseñado para llevar el negocio (en forma del propietario del producto) al equipo de desarrollo. Al interactuar con el equipo con frecuencia (recuerde, individuos e interacciones sobre procesos y herramientas) y al ver el software que funciona con frecuencia, la empresa puede trabajar codo a codo con los desarrolladores para producir software que resuelva mejor los problemas empresariales que tratando de especificar el conjunto cosa antes de que puedas probarlo.

Así es como los proyectos ágiles hacen un mejor trabajo entregando el producto que la empresa quiere en lugar del producto que solicitaron.

Dicho esto, hay ciertos criterios básicos que deben cumplirse. Podemos probar esto, y como con cualquier buena prueba, podemos automatizarlo.

Eche un vistazo a BDD y Cucumber. Además de su User Story, es bueno tener un conjunto básico de condiciones de satisfacción, preferiblemente en el formato "Give/When/Then". Estas condiciones son el mínimo conjunto de criterios para que la historia se acepte como completa.

Por ejemplo, "Dado que estoy conectado, cuando cierro la sesión, me vuelven a llevar a la página de inicio".

Si va a tener criterios de aceptación, querrá automatizarlo. La peor parte de la mayoría de las especificaciones es que a menudo terminan desactualizadas y acumulando polvo cuando el proyecto está completo.

Además, no debería asignar tareas al equipo. Los equipos de Scrum se organizan a sí mismos y cualquiera debe poder tomar cualquier tarea en la que sientan que pueden trabajar, respetando la prioridad de las historias. Swarming es una gran parte de los beneficios de rendimiento de Scrum.

Es posible que desee considerar traer a un entrenador externo para ayudar con su transición.

Answer 2

Según entiendo SCRUM, no se ocupa de la gestión de las especificaciones. Tienes que romper/asignar tus especificaciones o cambios de especificaciones a historias y tareas por separado. Pero puedes tener una tarea para esto :).

Answer 3

Creo que la manera más fácil es hacer que las especificaciones formen parte de las historias de los usuarios dentro de las tareas. Indique claramente los criterios de aceptación en cada uno (o si su software de seguimiento de problemas lo permite, créelos como tipos de elementos de trabajo de primera clase). Deje que el problema en lo que use para el seguimiento de elementos de trabajo se convierta en el documento vivo.

Existen inconvenientes, como encontrar problemas relacionados a medida que las especificaciones cambian con el tiempo, pero esto generalmente se puede gestionar en las herramientas de seguimiento de elementos de trabajo, suponiendo que puede relacionar problemas entre sí.

La forma en que lo hacemos es que nosotros (en realidad un BA, no los desarrolladores) creamos un mazo de aprobación para que el propietario del producto lo revise y colaboramos en la creación de tareas a partir de eso. Si no podemos crear una tarea, o si hay preguntas abiertas, volveremos al propietario del producto con las preguntas y actualizando la plataforma. Todos nuestros mazos están organizados (en SharePoint) para que podamos encontrarlos fácilmente en el futuro.

Answer 4

Existe una tensión real entre Scrum y otras metodologías ágiles de desarrollo y escritura de especificaciones. Creo que hay dos grandes puntos de tensión:

1. Debido ágil dice todo debe estar en una tarjeta, eso significa que tiene que tener cosas planeado suficiente para ajuste en una tarjeta. (Por ejemplo, usted tiene que saber cómo es todo ir a trabajar.)

2. Hay cosas que no tienen sentido en aislamiento (¿cuál es el uso de una página de archivo carga sin una página gestionar archivos cargados, por instancia.)

usted no tiene que diseñar toda la aplicación de una sola vez, pero hay que tener una visión de conjunto de la aplicación. Entonces, especialmente si tienes una separación de diseñadores y programadores, haces diseño funcional para un trozo del tamaño de un sprint a la vez. Esos diseños tienen que dividirse en trozos del tamaño de una historia.

Este es un diseño funcional frontal, y creo que se pasa por alto en muchas de las charlas sobre metodologías ágiles. Quizás algunas tiendas tienen los desarrolladores hacen más del diseño. Además, creo que es mucho más fácil usar scrum/agile para realizar cambios o corregir errores en las aplicaciones existentes en lugar de crear nuevas.

Lo que he encontrado más útil es luchar contra el tamaño de la historia. Muchas organizaciones se han vuelto locas, diciendo que las historias deben ser solo de unas pocas horas.El scrum original dice 16 horas, creo, que a menudo es lo suficientemente grande como para caber en una pantalla completa de una aplicación web. Entonces, "implementar administrar mi cuenta" podría ser una historia (en oposición al enfoque de cientos de historias pequeñas de "implementar nombre de usuario", "implementar contraseña", etc.) Luego, consulte el documento de diseño para "Administrar mi cuenta" y haga asegúrese de tener capturas de pantalla/prototipo/maqueta perfectos para que el desarrollador pueda verlos y copiar/pegar el texto directamente en el código que está escribiendo, y ellos saben con certeza qué campos deben estar allí (o qué enlaces, o cuales fotos, o lo que sea).

Answer 5

Para mí, las especificaciones se encuentran en las historias de los usuarios. Definimos las especificaciones y las tareas duing out scrum meeting junto con el propietario del producto. Las especificaciones y tareas son solo para el tiempo de vida de la iteración scrum, ya que todo podría cambiar en la próxima iteración (en el peor de los casos, pero definitivamente habrá cambios).

Por lo general, hacemos un seguimiento de las especificaciones y la tarea en una hoja de cálculo solo para que todos sepan en qué están trabajando. También he probado algunos programas para hacer esto y uno de los más interesantes que he encontrado es de [VersionOne] [1] y también de [Rally] [2].

Pero todavía encuentro que usar una simple hoja de cálculo es la solución más rápida y simple.