Dominio IV: Planificación adaptativa.
Los proyectos ágiles generalmente tratan de reducir el trabajo que no agrega valor. La planificación de un proyecto no agrega valor directamente al negocio, por lo tanto, la etapa de planificación debe ser lo más eficiente posible. No es factible planificar los proyectos ágiles una sola vez, ya que son propensos a un alto índice de cambio.
La planificación en Agile es un esfuerzo continuo. Después de algunas demostraciones, los interesados pueden comunicar mejor los requisitos, lo que, a su vez, conduce a una nueva planificación según los nuevos requisitos. Otra característica de los proyectos ágiles, discutida anteriormente, es que pueden considerarse necesarios ajustes en cualquier etapa del proyecto.
Hay tres prácticas que acompañan este dominio, cada una con sus propias herramientas, técnicas, conocimiento y habilidades:
- Conceptos de planificación.
- Estimación.
- Planes ágiles.
Conceptos de planificación.
La Elaboración progresiva describe el aprendizaje como un proceso continuo a lo largo de un proyecto. A medida que un proyecto avanza, puede ser necesario modificarlo con nueva información. La nueva información se puede utilizar para refinar y aumentar la precisión de los planes, requisitos, estimaciones y otros aspectos del proyecto.
Time-boxing se refiere a fijar períodos cortos de tiempo durante los cuales se realiza el trabajo. Cuando el trabajo queda incompleto al final del Time-box, se mueve a otro. Algunos ejemplos de dónde se utilizan Time-boxes:
-
-
- Reuniones diarias de pie (generalmente de 15 minutos)
- Iteraciones de una a seis semanas
-
Los Time-boxes suelen proporcionar la estructura necesaria para los proyectos ágiles, que tienen un elemento de incertidumbre, son dinámicos por naturaleza y están sujetos a varios cambios durante su ciclo de vida. Ayudan a medir el progreso del proyecto y a modificar el enfoque cuando sea necesario.
Característica mínimamente comercializable (MMF) es un conjunto mínimo de funcionalidades completas que pueden ser lanzadas a los usuarios y utilizadas por ellos, pero estas funcionalidades no representan el proyecto completo. Este término puede aplicarse al desarrollo de software en el que los usuarios pueden beneficiarse del progreso incremental realizado en el proyecto. También puede ayudar al equipo a probar la funcionalidad en el campo y realizar cambios si es necesario.
Análisis basado en valor se puede utilizar para priorizar la lista de tareas pendientes (backlog) y trabajar en las tareas que tienen mayor valor comercial. El valor comercial de un elemento se calcula en función de la relación entre su costo de desarrollo y el beneficio para el negocio.
Descomposición y priorización basada en valor es el proceso mediante el cual se obtienen los requisitos de los interesados y luego se priorizan en un backlog.
Primero, se determinan la visión a gran escala, los objetivos y la misión del proyecto. Segundo, se realizan talleres para identificar posibles características del proyecto. Tercero, se seleccionan las características basándose en el valor comercial y los riesgos. Finalmente, la lista priorizada se utiliza para el ciclo de desarrollo.
Juegos ágiles (juegos colaborativos)
Los juegos colaborativos, también conocidos como juegos innovadores, son utilizados por los equipos y los interesados para identificar problemas y acordar soluciones.
Existen varios juegos colaborativos que los equipos ágiles pueden utilizar, entre los cuales se incluyen los siguientes:
-
-
- Recuerda el futuro: Este ejercicio ayuda a establecer una visión para el proyecto y a obtener los requisitos de los interesados.
- Poda el árbol de productos: Este ejercicio de lluvia de ideas se lleva a cabo para determinar las características y funcionalidades de un producto.
- Speedboat: Con este ejercicio, los equipos e interesados identifican los beneficios y amenazas del proyecto.
- Compra una característica: Este ejercicio se realiza para priorizar características una vez que están finalizadas.
- Valor por el costo: Este ejercicio evalúa el valor comercial en comparación con el costo.
-
Estimación
Estimar proyectos puede ser difícil debido a la novedad y complejidad de cada proyecto. Sin embargo, las estimaciones son importantes para determinar los costos, el ROI del proyecto y evaluar el cronograma para completarlo. Nuevas estimaciones deben hacerse continuamente a lo largo del proyecto a medida que se consideran los costos reales y surgen otros factores al comenzar la ejecución del proyecto.
-
-
- Wideband Delphi es una práctica de estimación grupal en la que los miembros de un equipo proporcionan estimaciones anónimas para diferentes características, y las estimaciones iniciales se grafican. Luego, el equipo discute los factores que influyeron en sus estimaciones actuales y procede a una segunda ronda de estimación. Este proceso se repite hasta que las estimaciones individuales se acercan entre sí y se alcanza un consenso.
- Planning Poker, también llamado Estimation Poker, es una derivación de Wideband Delphi. Es una técnica de estimación que utiliza el consenso para estimar el tamaño relativo de las User Stories o el esfuerzo necesario para crearlas.
- Tiempo ideal es otra forma de estimar, en la que se les pide a los equipos calcular el tiempo que les tomaría completar el proyecto asumiendo que dedican todo su tiempo de trabajo al proyecto y no a actividades no relacionadas. Aunque este proceso no produce una predicción realista del tiempo que tomará un proyecto, proporciona estimaciones sin todas las variables que pueden influir en el proyecto.
- Tamaño relativo/Puntos de historia. Las estimaciones de puntos de historia deben incluir tiempo para todas las actividades, incluidas las tareas no relacionadas con el proyecto. Es importante mantener el tamaño de los puntos de manera relativa. Por ejemplo, una característica con 2 puntos de historia debe requerir el doble de esfuerzo que una con 1 punto; una con 3 puntos debe requerir tres veces más esfuerzo que una con 1 punto.
-
Las características que ya se han completado pueden recibir puntos de historia. Con base en la complejidad de estas características anteriores, se pueden estimar los puntos de historia para las características restantes. Por ejemplo, si se asigna 1 punto de historia a una pantalla de entrada, entonces se puede calcular la complejidad de la tarea y el tiempo requerido, y extrapolar estos datos para estimar puntos de historia para otras características.
Los equipos deben ser cautelosos de inflar artificialmente los puntos de historia para dar una falsa sensación de progreso. Para mitigar este problema, los equipos pueden usar los puntos de historia previamente estimados de tareas de proyectos anteriores como referencia.
-
-
- Affinity Estimating se utiliza para estimar rápidamente un gran número de requisitos o User Stories. Con notas adhesivas o tarjetas e índices, el equipo coloca las User Stories en una superficie, ordenándolas de pequeñas a grandes. Cada miembro del equipo comienza con un subconjunto de User Stories del backlog de producto priorizado para colocar según su tamaño relativo. Esta colocación inicial se realiza en silencio. Luego, el equipo revisa todas las ubicaciones y puede mover las User Stories según sea apropiado. Finalmente, el Product Owner indicará algunas categorías de tamaño en la pared (pequeño, mediano, grande) o usará valores de puntos de historia para indicar el tamaño relativo.
-
Estimación de tiempo, presupuesto y costos
Estimar un proyecto involucra los siguientes pasos:
-
-
- Determinar el tamaño del proyecto usando uno o más de los métodos de estimación.
- Calcular el esfuerzo requerido en términos de horas, días, semanas y meses, según la capacidad y disponibilidad del equipo.
- Convertir el esfuerzo en un cronograma considerando dependencias y recursos necesarios.
- Calcular el costo del proyecto sumando los costos laborales y otros costos.
-
Principios contables de proyectos ágiles
Los costos laborales suelen constituir una gran parte de los gastos de un proyecto. Estos costos se pueden calcular dividiendo el salario anual del miembro del equipo por 52 semanas o considerando el costo total del empleado, que incluye salario, equipo, espacio de oficina y otros beneficios. También se debe tener en cuenta el tiempo dedicado al proyecto.
Rango de estimación
Las estimaciones en proyectos ágiles deben presentarse en rangos. Las cifras precisas pueden dar la impresión de ser altamente exactas, cuando en realidad podrían no serlo. Los rangos de estimación deben basarse en el nivel de confianza del equipo en cada estimación. El rango puede ser estrecho cuando el equipo está seguro y más amplio cuando no lo está. A medida que el proyecto avanza, las estimaciones pueden ser más precisas gracias a la retroalimentación de iteraciones completadas.
Planes ágiles.
Caso de negocio.
Un caso de negocio es un documento que describe por qué los patrocinadores del proyecto deberían emprenderlo. También proporciona una estimación del beneficio en términos monetarios. En caso de que el proyecto no tenga un valor monetario directo y sea un servicio que deba proporcionarse, un caso de negocio ilustra el riesgo que los patrocinadores pueden evitar si se implementa el proyecto.
Un caso de negocio generalmente incluye lo siguiente:
-
-
- Resumen del proyecto.
- Costos y beneficios esperados para los patrocinadores del proyecto.
- Evaluaciones del Retorno de la Inversión (ROI), Valor Presente Neto (VPN) y Tasa Interna de Retorno (TIR).
- Riesgos que se pueden evitar si se implementa el proyecto.
- Sugerencias de los interesados.
-
Planificación de iteraciones y lanzamientos.
La entrega de valor en un proyecto ágil suele dividirse en iteraciones y lanzamientos.
-
-
- La planificación de iteraciones se enfoca en la entrega de los elementos del backlog planificados para cada período de tiempo definido, o iteración. Durante esta planificación, se determina una lista de prioridades basada en cuánto trabajo se puede realizar y qué características se pueden lograr dentro de la duración de la iteración. Luego, el backlog se divide en partes individuales que se distribuyen entre los miembros del equipo según su capacidad. Al calcular la capacidad de los miembros del equipo, es importante tener en cuenta los límites de disponibilidad, como días libres planificados y no planificados.
- Planificación de lanzamientos. Un lanzamiento es un conjunto de funcionalidades utilizables que se desarrollan a lo largo de varias iteraciones y se entregan al cliente. La planificación de un lanzamiento puede estar impulsada por las funcionalidades si el objetivo es entregar una vez que se haya desarrollado un conjunto predeterminado de funcionalidades. También puede estar impulsada por una fecha si el lanzamiento debe entregarse en una fecha específica.
-
Al planificar lanzamientos, los equipos pueden utilizar tendencias de velocidad para predecir el tiempo que necesitarán para completar el desarrollo de un lanzamiento.