archivo

Archivos diarios: noviembre 21, 2012

Cuando se comienza a trabajar con prácticas basadas en Scrum, uno de los aspectos que más llama la atención a los desarrolladores es cómo se va a tener una pila de producto si todavía no se ha comenzado a analizar el mismo, es decir, si todavía no se sabe muy bien qué se va a hacer y el product owner no lo tiene muy claro, ¿cómo vamos a poder definir tareas?.

Esto hace que una de tus primeras impresiones sea que las prácticas de Scrum solo son válidas en contextos relacionados con el mantenimiento de sistemas de información o en procesos de desarrollo en los que ya se ha comenzado a trabajar con el producto.

Pues no, estas prácticas podrían ser válidas también para aplicaciones que se inician desde cero (otra cosa es que sea la mejor solución en todos los casos) pero requieren, como es lógico, una fase inicial de contextualización del sistema de información que permita a grandes rasgos obtener una primera visión de las expectativas del usuario, de lo que va a ser el producto y se defina la arquitectura y tecnología del sistema.

No se trata de una análisis en detalle y/o completo (ni se quiere, ni se pretende), sino de delimitar el sistema para determinar la mejor forma de abordar su desarrollo. Solo se entraría en más detalle en aquellas tareas que se consideren más prioritarias teniendo en cuenta la capacidad de trabajo (velocidad) absorbible en cada sprint, por lo que como mucho nos deberíamos centrar en lo que sería el primer sprint y tal vez el siguiente (abordar más de entrada significaría retrasar el inicio de las iteraciones corriendo el riesgo, además, de que se trabaje en balde porque puede haber aspectos que varíen una vez que el product owner empiece a analizar de manera tangible las ideas abstractas que tenía en la cabeza).

Anuncios