¿Cómo se evita esperar a los requisitos cuando se usan métodos de desarrollo ágiles iterativos como SCRUM?

Question

Intentamos hacer un desarrollo ágil en mi trabajo actual y tenemos éxito en su mayor parte. El principal problema parece ser que los desarrolladores del proyecto siempre están esperando los requisitos al comienzo del sprint y apresurándose para obtener las cosas al final. Los analistas de negocios que están cumpliendo con los requisitos siempre están trabajando sin parar para cumplir con los requisitos.

EDITAR: Información adicional: Estamos personalizando una aplicación COTS para nuestro uso interno. Nuestras 'historias de usuario' solo consisten en qué parte de la aplicación vamos a personalizar en el sprint específico y también con qué sistemas vamos a integrar internamente. La integración con diferentes sistemas normalmente funciona bastante bien porque podemos comenzar a trabajar en eso de inmediato. La 'pantalla de personalizar x' son las principales áreas problemáticas porque los desarrolladores no pueden hacer nada al respecto. Tenemos que esperar hasta que obtengamos los requisitos de los BA antes de que podamos realmente hacer cualquier cosa.

EDIT: Una visión más clara/confusión quizá: me pregunto si parte del problema es que la pantalla que se está adaptando ya están allí, ya que es un producto COTS que está siendo fuertemente personalizada. La gente sugiere que las historias de los usuarios deben estar en la línea de 'crear una pantalla que haga X'. Eso ya está hecho. Tal vez no hay una buena manera de hacer historias de usuarios para estos requisitos ... tal vez esta sea una pregunta completamente nueva.

Answer 1

No espere. Cree un prototipo basado en los requisitos mínimos que tenga y obtenga retroalimentación lo antes posible del propietario del producto. En la mayoría de los casos, no saben lo que quieren de todos modos; si puede mostrarles algo tangible como punto de partida, es más probable que obtengan comentarios útiles. Además, una vez que tenga una mejor idea de los requisitos reales, es probable que ya haya obtenido una gran cantidad de información al desarrollar su prototipo.

Answer 2

En una posición anterior logramos esto solicitando a nuestros clientes comerciales una semana más o menos. Claro, esto se rompe de algunas de las interpretaciones estrictas de ágil, pero hizo las cosas mucho más fáciles. Tendríamos las pruebas y el negocio trabajando una semana o dos fuera del desarrollo, así que cuando los desarrolladores estaban trabajando en la iteración 2, las pruebas están trabajando en lo que salió de IT1 y el negocio está en IT3. Siempre se dio prioridad al desarrollo activo, por lo que algunas veces se rompió si una historia era particularmente flexible (es decir, el negocio tuvo que pasar mucho tiempo revisando las cosas a mitad de la iteración) pero, en general, funcionó bien.

actualización para responder a las questioneers Actualización de

Me parece los que en realidad no valerse por sí mismas como las historias a continuación, y tal vez el equipo de BA necesita volver a evaluar cómo se están escribiendo historias. Quiero decir que no puedes decir "contar una historia" con la pantalla X personalizada. En teoría, una historia debería ser algo así como: "Cuando el usuario vaya a la pantalla X, debería poder modificar (y guardar) el floozit"

Answer 3

Parece que los BA no le están entregando sus historias de usuario para el sprint en un manera oportuna.

Supongo que no hay sesiones de planificación de sprints a partir de lo que dices.

Dado que uno de los grandes principios de Scrum es que el equipo de desarrollo asume la responsabilidad de lo que trabajarán en cada sprint, parece que esto no es demasiado ágil para mí. (-:

Además de tener carreras cortas, eso es.

Answer 4

Si entiendo su situación correctamente, los BA se quedan atrás. Hay dos cosas que puedes probar.

1. Pruebe pequeños sprints o trozos de requisitos más pequeños. De cualquier manera, el trabajo para los BA debe ser más conciso y manejable.

2. Intente retrabajar o pelar calabazas. Eso debería dar a los BAs algún tiempo para adelantarse a la curva.

Si, sin embargo, el problema es que los BA tienen que ver con los requisitos anteriores en el "salvaje" antes de hacer más requisitos que tiene problemas mucho más grandes. :)

Answer 5

Bueno, un par de cosas pueden ayudar - En el proceso SCRUM, existe el concepto de propietario del producto que es una función de cerdo, esto representa al cliente. Entonces puede invitar al PLM o al contacto principal del cliente a la reunión de su SCRUM. Esto le dará a su cliente cierta aceptación en su proceso y hará que trabaje "con" usted en sus objetivos - Las versiones semanales para el cliente pueden ayudar. Entonces, la idea básica de las caídas semanales es mostrar al cliente "progreso". Entonces, si durante algunas semanas no hay progreso, esto debería plantear la pregunta "¿por qué?" y luego debería poder explicar que es por la falta de finalización de los requisitos.

Esperanza esto ayuda

Answer 6

la "historia de usuario" es un marcador de posición para un futuro conversación, por lo que se interponga en frente del cliente y preguntarles; si ese es el trabajo de BA, encienda un fuego ;-)

Answer 7

Sus historias de usuario están incompletas. 'Personalizar pantalla X' es una tarea, no describe ningún requisito o criterio de finalización. La historia del usuario debería ser algo como "Permitir que Nancy vea las órdenes de compra relacionadas para un artículo en el inventario". Luego divide eso en tareas durante tu carrera en la que puedas trabajar.

Una vez que los BA hayan desarrollado una historia de usuario viable , entonces agréguela a la cartera de pedidos de su producto, establezca prioridades y planifique sus sprints para los artículos pendientes más importantes. Los BAs deben desarrollar historias de usuarios y agregarlas a tu trabajo atrasado independientemente de tus sprints, y por lo tanto no te bloqueen. Durante un sprint, las tareas se completan y la historia del usuario no cambia. Después de liberar al cliente, proporciona comentarios que se incluyen en la cartera de pedidos del producto como más historias de usuarios.

Answer 8

veo algunas maneras de manejar esta situación:

Opción 1, bajo SCRUM, usted debe tener un propietario del producto que va a administrar su cartera de productos, que se supone que contienen las solicitudes de las características del software. Si la característica consiste en algo vago como 'Personalizar pantalla X' y decides agregar eso a tu sprint, entonces las tareas de sprint deben ser tareas concretas, descompuestas, y yo diría que una de esas tareas tiene que ser 'Definir requisitos para la pantalla X'.

Durante el SCRUM diario, cuando hace las tres preguntas a cada miembro del equipo, el desarrollador que tiene esa tarea de modificación de pantalla dirá "Estoy bloqueado esperando los requisitos del BA" y su scrum master hace lo que pueden para que eso avance.

opción 2, en mi opinión, es que los artículos no entran en la acumulación de productos hasta que se definen lo suficientemente bien como para hacer al menos un trabajo productivo. Todos sabemos que los requisitos cambian, pero el punto es que se supone que debes tener suficiente para empezar.

Answer 9

Fácil.

se permita pensar fuera de las estrictas reglas de Scrum, y volver a sus raíces magras: http://availagility.wordpress.com/2008/04/09/a-kanban-system-for-software-development/ http://leansoftwareengineering.com/2007/10/31/spreadsheet-example-for-a-small-kanban-team/ http://www.infoq.com/articles/hiranabe-lean-agile-kanban

Confía en mí, una vez que llegue ese flujo va, nunca mirar hacia atrás.

Answer 10

Como se dijo anteriormente, generalmente al comienzo de cada sprint debe priorizar la acumulación existente y elegir algunas historias para el sprint actual. Si no hay suficientes historias de usuarios para los desarrolladores, conviene trasladar a los desarrolladores a otro proyecto y dejar que el propietario del producto dedique algún tiempo a crear una acumulación decente (= lo suficientemente grande como para alimentar a algunos equipos) para el proyecto.