Índice del Contenido
Selección de características (Planificación del sprint – primera parte)
Muchos equipos establecen un objetivo general para la iteración que les sirve de guía para seleccionar las funcionalidades. Al inicio de la reunión, se suelen seleccionar las funcionalidades de mayor prioridad del plan de lanzamiento. Si la iteración tiene un objetivo general, se pueden seleccionar algunas funcionalidades de menor prioridad si se alinean mejor con dicho objetivo. La velocidad previa es fundamental para que el equipo pueda planificar una cantidad de trabajo realista.
Por ejemplo, si el equipo planeó inicialmente desarrollar funcionalidades del producto por un valor de 40 puntos de historia, pero solo logró entregar 30, entonces 30 puntos de historia deberían considerarse la velocidad actual para la siguiente iteración. Comparar las estimaciones de velocidad anteriores con los valores reales es útil a nivel de iteración, de funcionalidad y de tarea. Todo esto ayuda al equipo a determinar cuánto puede abarcar en la siguiente iteración. Si la iteración está sobrecargada, el cliente debe seleccionar qué funcionalidades deben posponerse para una iteración futura. planificación de iteraciones En la reunión, el cliente discutirá las características con el equipo e intentará responder cualquier pregunta que el equipo tenga.
planificación de tareas (Planificación del sprint – segunda parte)
El equipo dividirá las funcionalidades en tareas. Los desarrolladores se asignarán a las tareas y las estimarán. La duración de las tareas suele oscilar entre cuatro horas y dos días, y la mayoría se pueden completar en un día. Las tareas que duren más de dos días generalmente se dividirán en tareas más pequeñas. En ocasiones, durante la planificación de tareas, se determina que una funcionalidad se había subestimado considerablemente en el presupuesto original. plan de lanzamientoEn este caso, el equipo deberá trabajar con el cliente para proporcionar un presupuesto corregido y determinar qué función o funciones podrían necesitar retrasarse como resultado.
ajustes de iteración
Durante la iteración, si queda tiempo tras la entrega de todas las funcionalidades, el equipo puede solicitar al cliente que identifique funcionalidades adicionales para incluir en la iteración. Si, por el contrario, resulta evidente que no se pueden entregar todas las funcionalidades, el equipo colaborará con el cliente para determinar cuáles podrían retrasarse o dividirse con el fin de maximizar el valor entregado antes de la fecha límite de la iteración.
Señales de advertencia
- Si a lo largo de varias iteraciones el equipo continúa posponiendo las funcionalidades, es una señal de que debería prestar más atención a su velocidad anterior para minimizar la sobrecarga continua y maximizar la precisión de la planificación.
- Si el equipo sigue impulsando las mismas características en cada iteración, puede ser una señal de que el equipo está evitando deliberadamente ciertas funcionalidades y se deben explorar las causas fundamentales.
- Si el equipo se adentra demasiado en los detalles y diseña cada función por completo, puede haber una oportunidad para centrarse más en identificar las tareas necesarias.
Preguntas Frecuentes
¿Cómo gestionamos las dependencias entre tareas?
Esta pregunta surge con bastante frecuencia. Como parte de la planificación de la iteración, el equipo debe esforzarse por minimizar las dependencias entre tareas al dividir las funcionalidades. En el excelente libro de Mike Cohn abundan las técnicas específicas. Historias de usuarios aplicadasA continuación, el equipo debe esforzarse por colaborar para minimizar los efectos de las dependencias inevitables. Los equipos ágiles suelen adoptar diseños sencillos, con bajo acoplamiento y adaptables que minimizan las dependencias. Un excelente recurso para diseñar y perfeccionar este tipo de arquitecturas es el libro fundamental de Bob Martin. Desarrollo de software ágil: principios, patrones y prácticasLos equipos ágiles también utilizan técnicas, herramientas y prácticas que les permiten trabajar simultáneamente en subsistemas y módulos interdependientes. Desarrollo guiado por pruebasLas plataformas de pruebas automatizadas y los objetos simulados ayudan a los equipos a minimizar y gestionar las interdependencias entre tareas. La colaboración continua y estrecha puede ser clave en este sentido; a los equipos que trabajan en el mismo lugar les resulta más fácil resolver juntos los problemas de dependencia a lo largo de la iteración, de forma oportuna.
Las iteraciones tienen una duración limitada, lo que reduce el riesgo de que una sola dependencia oculta acabe con el proyecto. Los diagramas PERT y el CPM, si bien pueden ser valiosos para comprender el sistema en general, tienden a fallar bajo la presión del desarrollo de software iterativo y de alta velocidad. El tiempo y esfuerzo adicionales que se invierten en crear un modelo de dependencias para una iteración de dos semanas rara vez compensan la inversión. Las pruebas y el código automatizados proporcionan información más precisa y ejecutable, al menos con la misma rapidez.
¿Cuánto debería pagar un miembro del equipo por su inscripción?
Un miembro del equipo rara vez debería asumir más tareas de las que pudo completar en la iteración anterior. Si no se asignan tareas durante la planificación de la iteración, se hace mayor hincapié en asegurar que el equipo no asuma demasiado trabajo, comparando la velocidad de desarrollo de funcionalidades y tareas con la de la iteración anterior.
¿Cómo se planifican las iteraciones si el tamaño del equipo varía?
Sin la posibilidad de contar con un esfuerzo de equipo constante, ningún enfoque de proyecto, ágil o de otro tipo, ofrece mucha información. Sin embargo, con el desarrollo de software iterativo, al menos suele existir un historial que se va acumulando con el tiempo y que sirve de base para la planificación. En el desarrollo iterativo, si se han entregado varias iteraciones con un equipo de diez personas a una velocidad promedio de 20 días ideales o 200 horas por iteración, y el equipo se reduce a la mitad, un cálculo sencillo debería permitir planificar no más de diez días ideales para la próxima iteración (al menos inicialmente). Si se ha prescindido de personal clave o si se descubre que el cálculo fue erróneo, se detectará en las próximas semanas y se podrá realizar ajustes rápidamente para las iteraciones futuras.
¿Cómo se contabilizan los gastos generales (reuniones, correo electrónico, etc.)?
Por lo general, los equipos no dedican mucho tiempo al seguimiento de pequeños gastos generales. A lo largo de varias iteraciones, estas interrupciones se reflejan en una velocidad real cada vez más consistente (aunque inesperada). Algunos equipos incorporan explícitamente interrupciones y perturbaciones mayores en sus planes de iteración para reducir el riesgo y aumentar la visibilidad.
¿Cómo se tiene en cuenta la corrección de errores durante la planificación de la iteración?
Existen varias maneras en que los equipos gestionan la corrección de errores. Una de las más sencillas consiste en incluir los errores como un elemento explícito en la planificación de la iteración, priorizándolos y estimando las tareas involucradas. A efectos de planificación, los errores y las funcionalidades se consideran unidades de trabajo equivalentes. Algunos equipos optan por realizar un seguimiento de los errores por separado, fuera del proceso de iteración. Esto conlleva cierto riesgo: si el esfuerzo dedicado a la corrección de errores varía entre iteraciones, la velocidad del equipo también variará, lo que afectará a las estimaciones y los planes. Sin embargo, si el esfuerzo de corrección de errores se mantiene constante, este método puede funcionar bastante bien.
¿Por qué las iteraciones siempre deben tener la misma longitud?
Las iteraciones de duración similar o casi idéntica proporcionan un ritmo que los equipos utilizan para estimar y planificar. Sin iteraciones de duración fija, resulta difícil alcanzar y medir una velocidad constante. La disciplina de detener la producción al finalizar una iteración centra la atención de todos, presionando para mantener los diseños simples y evitar la complejidad excesiva o la ampliación del alcance. Toda la organización se acostumbra rápidamente a un flujo constante de aportaciones, planificación, ejecución, entrega y análisis. Sin este ritmo, el equipo es menos eficiente. Ocasionalmente, habrá buenas razones para alargar o acortar iteraciones específicas, para ajustarlas a plazos de entrega, interrupciones importantes o días festivos. Pero estas situaciones deben ser la excepción, no la regla.
¿Cómo contabilizo el tiempo dedicado a las pruebas y la documentación?
Las pruebas y las actualizaciones de la documentación deben priorizarse, estimarse y planificarse como cualquier otra actividad importante que requiera el tiempo de un desarrollador. A menudo se crean como tareas dentro de funcionalidades específicas, pero también pueden agruparse como una funcionalidad independiente.
¿Deberían revisarse las estimaciones de funcionalidades durante la planificación de la iteración?
Las estimaciones de funcionalidades solo deben revisarse durante la planificación de la iteración si se descubre que la estimación original está muy lejos de la realidad y el nuevo nivel de esfuerzo tendrá un impacto significativo en la capacidad del equipo para completar otros trabajos.
¿Deberían revisarse las estimaciones de tareas durante una iteración?
La estimación inicial de la tarea no debe revisarse una vez finalizada la planificación de la iteración. En cambio, las estimaciones para iteraciones futuras deben revisarse continuamente para reflejar una evaluación precisa del trabajo restante.
¿Deberían todos los equipos operar con el mismo cronograma de iteraciones?
Existen ventajas al tener todos los equipos trabajando con el mismo cronograma de iteraciones. Consolidar el estado de las iteraciones entre equipos solo tiene sentido si estos comparten el mismo cronograma. No es útil consolidar el estado numérico de un equipo que apenas comienza su iteración junto con el de otro que está por finalizar. La desventaja de tener a todos los equipos con el mismo cronograma de iteraciones radica en que todas comienzan y terminan simultáneamente. Si se comparten recursos comunes (por ejemplo, un cliente o la gerencia) entre proyectos, estos podrían preferir un cronograma de iteraciones escalonado entre los equipos.
