Índice del contenido
Selección de características (planificación de sprints: primera parte)
Muchos equipos establecen un objetivo general para la iteración para ayudar a guiar la selección de funciones. Al comienzo de la reunión, las características de mayor prioridad se seleccionan típicamente de la release plan. Si la iteración tiene un objetivo general, entonces se pueden seleccionar algunas características de menor prioridad si se alinean mejor con el objetivo. La velocidad previa es fundamental para permitir que el equipo programe una cantidad realista de trabajo.
Por ejemplo, si el equipo planeó previamente obtener 40 puntos de historia en características del producto, pero solo entregó con éxito 30 puntos de historia, entonces 30 puntos de historia deben considerarse la velocidad actual para la siguiente iteración. Las estimaciones de velocidad pasadas comparadas con los números reales son útiles a nivel de iteración, nivel de característica y nivel de tarea. Todo esto ayuda al equipo a determinar cuánto pueden inscribirse en la próxima iteración. Si la iteración tiene overbooking, entonces el cliente debe seleccionar qué funciones deben retrasarse para una iteración futura. Durante el planificación de iteraciones En la reunión, el cliente discutirá las características con el equipo e intentará responder cualquier pregunta que tenga el equipo.
Planificación de tareas (planificación de sprints – segunda parte)
El equipo dividirá las características en tareas. Luego, los desarrolladores se registran para las tareas y las estiman. Las tareas suelen variar en tamaño de cuatro horas a dos días, y la mayoría de las tareas se pueden entregar en un día. Las tareas de más de dos días generalmente deben dividirse en tareas más pequeñas. Ocasionalmente, durante la planificación de tareas, se determina que una característica se ha subestimado lamentablemente en el original release plan. En este caso, el equipo deberá trabajar con el cliente para proporcionar una estimación corregida y determinar qué función o funciones deben retrasarse como resultado.
Ajustes de iteración
Durante la iteración, si queda tiempo después de que se hayan entregado todas las características, el equipo puede solicitar que el cliente identifique características adicionales para agregar a la iteración. Si, por otro lado, es obvio que no se pueden entregar todas las funciones, entonces el equipo trabaja con el cliente para determinar qué funciones podrían retrasarse o tal vez dividirse para brindar el mayor valor antes de la fecha límite de la iteración.
Señales de advertencia
- Si a lo largo de una serie de iteraciones, el equipo continúa impulsando funciones hacia el futuro, es una señal de que el equipo debe prestar más atención a su velocidad anterior para minimizar la sobreventa continua y maximizar la precisión de la planificación.
- Si el equipo sigue impulsando las mismas funciones en cada iteración, puede ser una señal de que el equipo está evitando deliberadamente ciertas funciones y se deben explorar las causas principales.
- Si el equipo se sumerge en demasiados detalles y diseña cada característica en su totalidad, puede haber una oportunidad de enfocarse más en identificar el trabajo de tarea que es necesario.
Preguntas Frecuentes
¿Cómo manejamos las dependencias entre tareas?
Esta pregunta surge bastante. Como parte de la planificación de la iteración, el equipo debe esforzarse por minimizar las dependencias de tareas a medida que dividen las funciones. Técnicas específicas abundan en el excelente libro de Mike Cohn Historias de usuarios aplicadas. A continuación, el equipo debe esforzarse por colaborar para minimizar los efectos de las dependencias inevitables. Los equipos ágiles suelen adoptar diseños adaptables, simples y poco acoplados que minimizan las dependencias. Un excelente recurso para diseñar y refinar tales arquitecturas es el libro seminal de Bob Martin. Desarrollo de software ágil: principios, patrones y prácticas. Los equipos ágiles también usan técnicas, herramientas y prácticas que les permiten trabajar simultáneamente en subsistemas y módulos interdependientes. Desarrollo guiado por pruebas, arneses de prueba automatizados y objetos simulados ayudan a los equipos a minimizar y hacer frente a las interdependencias de tareas. La colaboración estrecha y continua puede ser clave aquí; A los equipos ubicados en el mismo lugar les resulta más fácil resolver juntos los desafíos de dependencia a lo largo de la iteración de manera justo a tiempo.
Las iteraciones son tan largas, lo que reduce el riesgo de que una sola dependencia al acecho mate el proyecto. Los diagramas PERT y CPM, si bien son potencialmente valiosos en términos de comprensión general del sistema, tienen una tendencia muy alta a desmoronarse bajo el estrés del desarrollo de software iterativo de alta velocidad. El tiempo y el esfuerzo adicionales que se dedican a crear un modelo de dependencia para una iteración de dos semanas rara vez valen la pena. Las pruebas y el código automatizados le brindarán comentarios más precisos y ejecutables al menos con la misma rapidez.
¿A cuánto debe inscribirse un miembro del equipo?
Un miembro del equipo rara vez debe inscribirse en más de la estimación total de las tareas que pudo completar en la iteración anterior. Si las tareas no se registran durante la planificación de la iteración, entonces se pone más énfasis en asegurarse de que el equipo no se registre para demasiado trabajo al comparar con la característica de la iteración anterior y la velocidad de la tarea.
¿Cómo planifica las iteraciones si el tamaño del equipo varía?
Sin la capacidad de confiar en el esfuerzo constante del equipo, ningún enfoque de proyecto, ágil o de otro tipo, proporciona mucha información. Sin embargo, con el desarrollo de software iterativo, al menos suele haber algo de historia que se acumula con el tiempo para usar como base para la planificación. Con el desarrollo iterativo, si entregó varias iteraciones con un equipo de diez con una velocidad promedio de 20 días ideales o 200 horas por iteración, y su equipo se reduce a la mitad, entonces un simple cálculo debería llevarlo a planificar no más de diez días ideales para la próxima iteración (al menos inicialmente). Si se ha eliminado personal clave, o si descubre que está equivocado, lo descubrirá en las próximas semanas y podrá ajustarse rápidamente para futuras iteraciones.
¿Cómo contabiliza los gastos generales (reuniones, correo electrónico, etc.)?
Por lo general, los equipos no dedican mucho tiempo al seguimiento de elementos generales menores. En el transcurso de algunas iteraciones, estas interrupciones se reflejan en datos reales de velocidad cada vez más consistentes (aunque inesperados). Algunos equipos incorporan interrupciones e interrupciones más grandes en sus planes de iteración explícitamente, 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?
Hay un par de formas en que los equipos se ocupan de la corrección de errores. Uno de los más simples es incluir errores como entrada explícita para la planificación de la iteración, priorizándolos y estimando las tareas involucradas. Los errores y las características son esencialmente unidades de trabajo equivalentes para fines de planificación. Algunos equipos eligen rastrear errores por separado fuera de su proceso de iteración. Esto es un poco más arriesgado: si el esfuerzo de corrección de errores varía entre las iteraciones, la velocidad del equipo variará en consecuencia, lo que descartará las estimaciones y los planes. Pero si el esfuerzo de corrección de errores se mantiene constante, entonces este método puede funcionar razonablemente bien.
¿Por qué las iteraciones siempre deben tener la misma longitud?
Las iteraciones con longitudes iguales o muy cercanas proporcionan un ritmo en el que los equipos confían para estimar y planificar. Sin iteraciones de longitud fija, puede ser difícil lograr y medir la velocidad constante. La disciplina de cortar la producción al final de una iteración enfoca las mentes de todos, aplicando presión para mantener los diseños simples y resistir el enchapado en oro o el avance del alcance. Toda la organización se acostumbra rápidamente a un zumbido constante de entrada, planificación, ejecución, salida y retrospección. Sin este ritmo, el equipo es menos eficiente. Ocasionalmente, habrá buenas razones para estirar o comprimir iteraciones específicas, para ajustarlas a plazos, interrupciones importantes o días festivos. Pero estos deberían ser la excepción, no la regla.
¿Cómo contabilizo el tiempo de pruebas y documentación?
Las actualizaciones de pruebas y 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 en funciones específicas, pero también se pueden agrupar como su propia función.
¿Deberían revisarse las estimaciones de características durante la planificación de la iteración?
Las estimaciones de características solo deben revisarse durante la planificación de la iteración si se descubre que la estimación original está muy por debajo de la base y el nuevo nivel de esfuerzo tendrá un impacto significativo en la capacidad del equipo para completar otro trabajo.
¿Deberían revisarse las estimaciones de tareas durante una iteración?
La estimación de la tarea original no debe revisarse una vez que se haya completado la planificación de la iteración. Por otro lado, las estimaciones para iteraciones futuras deben revisarse continuamente para reflejar una evaluación precisa del trabajo restante.
¿Todos los equipos deberían operar con el mismo programa de iteraciones?
Hay ventajas en tener todos los equipos trabajando en el mismo programa de iteraciones. La acumulación de estado de iteración entre equipos solo tiene sentido si los equipos tienen el mismo cronograma. No es útil acumular ningún estado numérico en un equipo que recién comienza su iteración junto con otro que está a punto de finalizar. La desventaja de tener todos los equipos en el mismo programa de iteraciones radica en iniciar y finalizar las iteraciones al mismo tiempo. Si los recursos comunes (por ejemplo, un cliente o la administración) se comparten entre proyectos, pueden apreciar un programa de iteración escalonado entre equipos.
