Si has seguido los primeros dos pasos en esta serie, deberías tener tu pila del producto en orden y haber estimado su tamaño usando puntos de Fibonacci.
El siguiente paso es planear tu Sprint.
Taller de planeación del Sprint
Organiza una Reunión de Planeación del Sprint. Asegurate que la reunión sea atendida por todo el equipo. Incluyendo todos los roles. Analistas del negocio si los tienes. Personal de prueba si los tienes. Todos los desarrolladores del equipo Scrum para el producto. Y muy importante el Propietario del Producto.
La primer cosa que debes hacer (en tu primera reunión de planificación del Sprint), es decidir la duración del Sprint. Esta duración debería ser tomada como un equipo.
Decidir la duración del Sprint
Esta es una decisión importante. Scrum sugiere 30 días. Puede que sea lo correcto. Pero este es un punto que parece ser ampliamente adaptado por equipos ágiles implementando Scrum.
La óptima duración del Sprint depende de muchos factores. Algo que leí recientemente sugiere que un "ciclo de vida" de un equipo de desarrollo es un reflejo directo de la madurez de sus procesos. Creo que estaría de acuerdo con esa sentencia.
Un equipo con procesos inmaduros encontrará la intensidad de Scrum y la carga de Planeación del Sprint, Pruebas, Despliegue y Revisión muy onerosa para un ciclo corto de Sprint. Mientras que para equipos con procesos muy maduros (por ejemplo pruebas automatizadas, despliegue automatizado y equipos que se han vuelto muy rápidos en la Planeación del Sprint), un ciclo corto puede ser muy confortable.
He sugerido que el rango este entre una semana y un mes. Una semana es probablemente el tiempo mas corto que puede ser práctico, aunque si realmente dominas las prácticas ágiles, ¿por que no entregar cada nueva característica cuando este lista? (si es que es apropiado para el producto). Un mes debería ser ciertamente lo mas largo.
Para productos o mercados de rápido movimiento, tales como productos basados en web - donde hay un despliegue central, sin lanzamientos ni entrenamiento de usuarios - un mes puede parecer una eternidad. Personalmente me gustan los Sprints de 2 semanas para productos de movimiento rápido.
Mike Cohn es uno de los exponentes claves del desarrollo ágil. Aquí está el artículo de Mike dando mas consejos sobre como seleccionar la duración de iteración óptima
Mantén la duración del Sprint, consistente
Cualquiera que sea la duración del Sprint que elijas, mi sugerencia es mantenerla consistente.
Esto, de hecho, es mas importante que la duración en sí misma. Por que es la consistencia la que permite tomar ritmo. Es la consistencia que hace al proceso muy repetible. Y por lo tanto te ayuda a tomar el paso como equipo. Y es la consistencia la que te permite empezar a entender cuantos puntos de la Pila del Producto puedes típicamente hacer en un Sprint.
Una vez que lo has decidido, puedes ahora armar un taller de planificación del Sprint como cita periódica antes de cada Sprint.
Selecciona la pila objetivo para el Sprint.
Ahora que has decidido la duración de tu Sprint. Lo siguiente es que debes decidir la meta para el Sprint.
Viendo en la sección alta de la Pila del Producto, ¿que parecería ser una meta razonable para el Sprint? ¿Puedes expresar un objetivo que englobe la meta para el siguiente Sprint, o puedes al menos tomar una sección de items/características desde el comienzo de la Pila del Producto que el equipo piense que puede ser lograda en la duración del Sprint?
Selecciona el objetivo del Sprint. Toma la decisión como equipo.
Incluye un poco mas de lo que pienses que puedes realizar. Es importante preparar mas items durante la planeación en caso de que el equipo termine pronto. Estos items pueden ser claramente identificados como tareas de extensión y el Propietario del Producto no debería esperar que sean completadas. Estás son las cosas que harás solamente si el Sprint va mejor de lo esperado.
En futuros Sprints, serás capaz de usar la velocidad previa del equipo Scrum para ayudarte con esta decisión. Velocidad es el número de puntos de la Pila del Producto entregados en un Sprint. Esto tiende a fluctuar ampliamente al inicio cuando adoptas Scrum. Pero se normalizará cuando el equipo entre en ritmo, y en el futuro te proveerá con una razonable base para escoger el objetivo.
Clarifica los requisitos del Sprint
Toma cada item en la Pila del Producto. Es importante pasar a través de ellos metódicamente, un item a la vez...
El Propietario del Producto presenta cada item y explica como el/ella lo ve trabajando desde una perspectiva funcional.
Los resultados de esta discusión deberían ser capturados en una pizarra o rotafolio, o alguien podría escribir notas en una portátil a la vez que la discusión progresa. Pizarras interactivas o imprimibles son ideales para este proceso.
Puedes usar cualquier forma que quieras para escribir los requisitos. Pero el principio importante de Scrum y de cualquier metodología ágil de desarrollo, es que escribas los requisitos característica por característica, antes que sean desarrolladas.
Escribe los requisitos de forma ligera y visual. Los requisitos ágiles deben ser apenas suficiente. El hecho de que las características serán desarrolladas y probadas en las siguientes semanas y por el equipo presente, hace esto posible.
Considera escribir "Historias de Usuario", un concepto de XP(Extreme Programming -Programación Extrema-). Está mas allá del alcance de este artículo explicar las historias de usuario en detalle. Pero el concepto básico es escribir las características usando esta construcción:
Como [tipo de usuario], quiero [hacer algo], así puedo [lograr que meta].
La historia puede ser respaldada por un esquema de la interfaz de usuario. Anota el esquema para describir la funcionalidad. Respaldalo con oraciones sobre como será confirmado (o probado). Esto ayudará a identificar escenarios por adelantado, antes que sea desarrollado.
Para mas información sobre historias de usuario, Mike Cohn ha escrito un libro, Historias de Usuario Aplicadas.
Siguiente...
Una vez que has clarificado los requisitos para todos los items de la Pila del Producto que son parte del objetivo del Sprint, el siguiente paso es: Planificación del Sprint / Estimar tareas.
Kelly
El siguiente paso es planear tu Sprint.
Taller de planeación del Sprint
Organiza una Reunión de Planeación del Sprint. Asegurate que la reunión sea atendida por todo el equipo. Incluyendo todos los roles. Analistas del negocio si los tienes. Personal de prueba si los tienes. Todos los desarrolladores del equipo Scrum para el producto. Y muy importante el Propietario del Producto.
La primer cosa que debes hacer (en tu primera reunión de planificación del Sprint), es decidir la duración del Sprint. Esta duración debería ser tomada como un equipo.
Decidir la duración del Sprint
Esta es una decisión importante. Scrum sugiere 30 días. Puede que sea lo correcto. Pero este es un punto que parece ser ampliamente adaptado por equipos ágiles implementando Scrum.
La óptima duración del Sprint depende de muchos factores. Algo que leí recientemente sugiere que un "ciclo de vida" de un equipo de desarrollo es un reflejo directo de la madurez de sus procesos. Creo que estaría de acuerdo con esa sentencia.
Un equipo con procesos inmaduros encontrará la intensidad de Scrum y la carga de Planeación del Sprint, Pruebas, Despliegue y Revisión muy onerosa para un ciclo corto de Sprint. Mientras que para equipos con procesos muy maduros (por ejemplo pruebas automatizadas, despliegue automatizado y equipos que se han vuelto muy rápidos en la Planeación del Sprint), un ciclo corto puede ser muy confortable.
He sugerido que el rango este entre una semana y un mes. Una semana es probablemente el tiempo mas corto que puede ser práctico, aunque si realmente dominas las prácticas ágiles, ¿por que no entregar cada nueva característica cuando este lista? (si es que es apropiado para el producto). Un mes debería ser ciertamente lo mas largo.
Para productos o mercados de rápido movimiento, tales como productos basados en web - donde hay un despliegue central, sin lanzamientos ni entrenamiento de usuarios - un mes puede parecer una eternidad. Personalmente me gustan los Sprints de 2 semanas para productos de movimiento rápido.
Mike Cohn es uno de los exponentes claves del desarrollo ágil. Aquí está el artículo de Mike dando mas consejos sobre como seleccionar la duración de iteración óptima
Mantén la duración del Sprint, consistente
Cualquiera que sea la duración del Sprint que elijas, mi sugerencia es mantenerla consistente.
Esto, de hecho, es mas importante que la duración en sí misma. Por que es la consistencia la que permite tomar ritmo. Es la consistencia que hace al proceso muy repetible. Y por lo tanto te ayuda a tomar el paso como equipo. Y es la consistencia la que te permite empezar a entender cuantos puntos de la Pila del Producto puedes típicamente hacer en un Sprint.
Una vez que lo has decidido, puedes ahora armar un taller de planificación del Sprint como cita periódica antes de cada Sprint.
Selecciona la pila objetivo para el Sprint.
Ahora que has decidido la duración de tu Sprint. Lo siguiente es que debes decidir la meta para el Sprint.
Viendo en la sección alta de la Pila del Producto, ¿que parecería ser una meta razonable para el Sprint? ¿Puedes expresar un objetivo que englobe la meta para el siguiente Sprint, o puedes al menos tomar una sección de items/características desde el comienzo de la Pila del Producto que el equipo piense que puede ser lograda en la duración del Sprint?
Selecciona el objetivo del Sprint. Toma la decisión como equipo.
Incluye un poco mas de lo que pienses que puedes realizar. Es importante preparar mas items durante la planeación en caso de que el equipo termine pronto. Estos items pueden ser claramente identificados como tareas de extensión y el Propietario del Producto no debería esperar que sean completadas. Estás son las cosas que harás solamente si el Sprint va mejor de lo esperado.
En futuros Sprints, serás capaz de usar la velocidad previa del equipo Scrum para ayudarte con esta decisión. Velocidad es el número de puntos de la Pila del Producto entregados en un Sprint. Esto tiende a fluctuar ampliamente al inicio cuando adoptas Scrum. Pero se normalizará cuando el equipo entre en ritmo, y en el futuro te proveerá con una razonable base para escoger el objetivo.
Clarifica los requisitos del Sprint
Toma cada item en la Pila del Producto. Es importante pasar a través de ellos metódicamente, un item a la vez...
El Propietario del Producto presenta cada item y explica como el/ella lo ve trabajando desde una perspectiva funcional.
Los resultados de esta discusión deberían ser capturados en una pizarra o rotafolio, o alguien podría escribir notas en una portátil a la vez que la discusión progresa. Pizarras interactivas o imprimibles son ideales para este proceso.
Puedes usar cualquier forma que quieras para escribir los requisitos. Pero el principio importante de Scrum y de cualquier metodología ágil de desarrollo, es que escribas los requisitos característica por característica, antes que sean desarrolladas.
Escribe los requisitos de forma ligera y visual. Los requisitos ágiles deben ser apenas suficiente. El hecho de que las características serán desarrolladas y probadas en las siguientes semanas y por el equipo presente, hace esto posible.
Considera escribir "Historias de Usuario", un concepto de XP(Extreme Programming -Programación Extrema-). Está mas allá del alcance de este artículo explicar las historias de usuario en detalle. Pero el concepto básico es escribir las características usando esta construcción:
Como [tipo de usuario], quiero [hacer algo], así puedo [lograr que meta].
La historia puede ser respaldada por un esquema de la interfaz de usuario. Anota el esquema para describir la funcionalidad. Respaldalo con oraciones sobre como será confirmado (o probado). Esto ayudará a identificar escenarios por adelantado, antes que sea desarrollado.
Para mas información sobre historias de usuario, Mike Cohn ha escrito un libro, Historias de Usuario Aplicadas.
Siguiente...
Una vez que has clarificado los requisitos para todos los items de la Pila del Producto que son parte del objetivo del Sprint, el siguiente paso es: Planificación del Sprint / Estimar tareas.
Kelly
Serie completa:
#3: Planeación del Sprint (Requisitos)
Comentarios
Publicar un comentario