Planificación y Estimación Ágil

La planificación y la estimación son esenciales en los proyectos de software para lograr la previsibilidad, reducir los riesgos involucrados y establecer una expectativa básica para todas las partes interesadas. La planificación se centra mucho en la preparación y la previsión, mientras que la estimación es un proceso para pronosticar variables relacionadas con el proyecto, es decir, esfuerzo, alcance, cronograma, etc.  

Planificación: se requiere planificación independientemente de las metodologías de gestión de proyectos que siga el equipo, ya sea Waterfall o Agile. La planificación brinda al equipo del proyecto una perspectiva sobre cómo cumplir el objetivo de manera sistemática y ayuda a las partes interesadas del proyecto a controlar el progreso del proyecto y las inversiones realizadas.  

Como lo define Mike Cohn, “La planificación ágil equilibra el esfuerzo y la inversión en la planificación con el conocimiento de que revisaremos el plan a lo largo del proyecto. Un plan ágil es aquel que no solo estamos dispuestos sino ansiosos por cambiar”. Este concepto existe principalmente para evitar la debilidad de la planificación.  

Estas debilidades incluyen:  

• Centrarse en las actividades en lugar de las características entregadas
• Ignorando la priorización
• Ignorar la existencia de la incertidumbre
• Dar compromisos basados ​​en estimaciones

Tales debilidades en la planificación hacen que el equipo no pueda hacer frente a los entornos dinámicos del proyecto. Para resolver eso, la planificación debe avanzar para volverse ágil también.  

Estimación: el cronograma, el alcance, el costo y el esfuerzo son las cuatro variables principales que normalmente controlan los proyectos de software. Cualquier cambio en cualquiera de estas variables puede tener un efecto en un proyecto. La estimación es un proceso para pronosticar estas variables para desarrollar o mantener software basado en la información especificada por el cliente.  

Hay tres desafíos principales que se enfrentan durante la estimación, es decir, la incertidumbre, el autoconocimiento y la consistencia del método utilizado para la estimación. El uso de métodos de estimación estandarizados y científicos para estimar el tamaño, el esfuerzo y el cronograma ayuda a mantener una variación mínima entre las estimaciones planificadas y los valores reales, logrando así la máxima precisión de la estimación. Esto proporciona una mejor experiencia del cliente. Todas las necesidades de estimación de un proyecto no pueden determinarse mediante un único método. Es importante tener diferentes métodos de estimación para diferentes etapas.

La planificación y la estimación en proyectos ágiles se centran mucho en la preparación y la previsión. Ambas actividades se realizan teniendo en cuenta el contexto comercial y se compromete la entrega de valor medible al cliente. Por lo tanto, se recomienda contar con la planificación y estimación requerida en Agile desde el inicio del proyecto, para garantizar una mejor cobertura de riesgos y una mayor predictibilidad.  

La planificación y la estimación en los proyectos ágiles generalmente se realizan en tres etapas diferentes, que son:  

• Nivel de inicio del proyecto
• Nivel de lanzamiento
• Nivel de Sprint (es decir, una iteración dentro de cada Versión)

Comprendamos ahora cada etapa en detalle.

Nivel de proyecto:

Planificación: 

La planificación de actividades a nivel de Proyecto toma 360 grados de la vista del proyecto en términos de comprensión del panorama general, visión general, hoja de ruta, entrega de valor, planificación para una mejor cobertura de riesgos, creación de Product Backlog, definición de Releases, etc. Este es el nivel más alto. de planificación que se centra en las actividades inminentes del proyecto y su objetivo final. El Propietario del Producto (o Gerente de Cliente/Negocio) es la principal parte interesada involucrada en esta actividad.  

Durante esta etapa, el propietario del producto (PO) explica al equipo de proyecto/entrega las estrategias que deben seguir para entregar el producto potencialmente entregable a tiempo. El papel del equipo aquí sería comprender el plan estratégico con claridad y satisfacer al máximo las necesidades del propietario del producto.  

Una vez que se conoce el objetivo del proyecto, se requiere definir cómo lograr ese objetivo. Se trata de desglosar los requisitos en varios segmentos para que los entregables finales puedan construirse, validarse y publicarse. Esto ayuda a planificar y estimar varios lanzamientos según los requisitos de las funciones. En este punto, el rol del Product Owner se vuelve crucial. Esta planificación lleva a la generación de Product Backlog, que luego se utiliza en una planificación posterior, es decir, Planificación de lanzamiento. Ignorar la actividad de Planificación del proyecto llevaría a desarrollar un producto final que no es útil o no es el esperado por las partes interesadas.  

En la práctica, la planificación a nivel de Proyecto involucra una gran cantidad de componentes que brindan un control general para lograr la previsibilidad en cada entrega, mitigando los riesgos y estableciendo la expectativa básica con todos los interesados. Estos componentes están relacionados con la planificación de la infraestructura, la planificación de la gestión de la calidad, la planificación de la configuración del entorno, las herramientas y la planificación de la reutilización, la automatización de la construcción y la planificación de la integración continua, etc. Sin embargo, a un alto nivel, los aspectos importantes de la planificación incluyen la creación de una cartera de productos, teniendo Taller de Requerimientos, creación de un Plan de Release mediante la definición de los releases, y planificación de prácticas Ágiles a través de herramientas de Gestión del Ciclo de Vida de Aplicaciones, que necesitan ser adoptadas en el proyecto.  

• Product Backlog: Product Backlog es una lista priorizada de requisitos simplificados que es necesaria para lograr la entrega prevista del producto/función. Es un insumo clave para la planificación. Los propietarios de productos a menudo preparan la cartera de pedidos con la consulta de estrategas comerciales y usuarios finales. La priorización a menudo se basa en el valor comercial, la fecha de lanzamiento, la interdependencia y se mantiene en un lugar común, como un archivo MS Excel centralizado, herramientas ALM, etc.
• Talleres: El objetivo principal de realizar talleres es recopilar, comprender y priorizar requisitos, y definir un plan de alto nivel para los lanzamientos principalmente durante la fase de inicio del proyecto. Un taller es un evento en el que un grupo de personas colabora para presentar diversas ideas con el fin de lograr un objetivo definido con la ayuda de un facilitador imparcial. No es lo mismo que una lluvia de ideas. En un taller, debe haber una idea clara de lo que se requiere y cuál debe ser el resultado.
• Gestión del ciclo de vida de la aplicación: la gestión del ciclo de vida de la aplicación (ALM) ayuda a gestionar proyectos ágiles al proporcionar mecanismos para entregar software de manera más predecible e impulsar el valor empresarial. Las herramientas ágiles de ALM se utilizan para planificar y estimar historias de usuarios y compartirlas dentro del equipo. Se puede usar para crear un Product Backlog, Sprint Backlog, establecer el compromiso y la velocidad del equipo, visualizar la actividad del equipo y el progreso del proyecto a través de gráficos Burn Down e informar sobre el progreso del equipo. Con solo arrastrar las historias de los usuarios hacia arriba o hacia abajo en el backlog, el equipo puede priorizarlas en orden. Además, los equipos pueden capturar, autoasignar y administrar sus tareas de manera eficiente con una buena herramienta ALM.

Estimacion:

Durante la etapa de inicio del proyecto, los requisitos funcionales se encuentran en un nivel alto o los detalles de los requisitos no están bien formulados y documentados. En el Product Backlog, muchos requisitos aún se encuentran en el nivel Epic o Feature. En este punto, se requiere una estimación, ya que ayudará en la priorización y planificación de los lanzamientos. En esta etapa se pueden utilizar diferentes técnicas de estimación. Algunos de ellos son  

• QFPA (Análisis rápido de puntos de función)
• Puntos de caso de uso
• Estimación basada en la complejidad
• COCOMO (Modelo de Costo Constructivo)
• FP CÓSMICO

Durante la etapa de Inicio del Proyecto, la estimación debe realizarse como una actividad de grupo, donde se deben comparar los resultados y resolver los desacuerdos. Todos los supuestos y riesgos del proyecto deben resaltarse claramente. Por lo general, el equipo para realizar esta actividad incluirá:  

• Dueño del producto
• Clientes y partes interesadas comerciales
• Gerente de proyecto
• Desarrolladores y diseñadores
• Probadores

El enfoque general para la estimación a nivel de proyecto se ilustra en el siguiente diagrama:

La estimación del nivel del proyecto dará detalles sobre el  

• El número aproximado de Lanzamientos/Sprints que pueden ser necesarios antes de la implementación
• Fecha aproximada de finalización del proyecto.
• Plan de dotación de personal aproximado
• Plan de esfuerzo aproximado, etc.

Las estimaciones a nivel de proyecto se refinan regularmente en la fase de planificación de cada versión/sprint.

Nivel de lanzamiento:

Planificación:  

Sin un plan de lanzamiento, el equipo del proyecto estaría rebotando de un Sprint al siguiente, sin saber dónde detenerse (es decir, lógicamente). Un producto que se puede enviar se entrega y está listo para implementarse al final de cada versión. Como resultado, es fundamental que un equipo de proyecto comprenda y se adhiera al plan de lanzamiento.

La planificación de la versión tiene que ver con la planificación y programación de historias de usuario (es decir, requisitos funcionales/no funcionales) que el equipo convertirá en software funcional y entregará para esa versión. El equipo decide la cantidad de Sprints (duración de 1 a 4 semanas) para cada lanzamiento en un marco de tiempo en el que un conjunto de historias de usuarios se convierten en el software funcional mientras se lleva a cabo la planificación del lanzamiento.  

El plan de lanzamiento también puede mencionar algunos supuestos clave como la duración de un Sprint, el tamaño del equipo, quién trabajará en el equipo, el comienzo del primer Sprint, el final del último Sprint, etc. Los lanzamientos son Se recomienda que se planifique entre tres y seis meses según el contexto comercial para los proyectos de anualidad (larga duración, es decir, más de un año), y para los proyectos que no son de anualidad, de uno a tres meses.  

Es importante planificar las versiones, ya que brinda una imagen clara a todas las partes interesadas sobre lo que se espera que entre en producción, en el debido curso de la ejecución del proyecto. La planificación de la versión es un elemento importante, ya que se lleva a cabo antes del inicio de cada nueva versión. Esto ayuda al equipo a entregar el resultado esperado del proyecto de forma incremental al cliente, lo que les ayuda a obtener comentarios tempranos para que la planificación futura se alinee más con las necesidades del cliente. 

Todas las partes interesadas identifican y acuerdan la duración, el objetivo y el contenido de cada Sprint y Release. Sin embargo, debido a que los requisitos pueden agregarse o eliminarse a medida que avanza el proyecto, al comienzo de cada lanzamiento y sprint, se revisa la planificación del mismo y se revisa el alcance. El equipo del proyecto puede decidir tener Sprints o Lanzamientos adicionales durante el curso del proyecto dependiendo de la dinámica en ese momento.  

Las siguientes son varias actividades involucradas en la planificación de lanzamiento:

• Determinar el objetivo de la versión: el propietario del producto generalmente discutirá el objetivo deseado en la reunión de planificación de la versión. En su mayoría, el objetivo será una salida basada en la fecha o la hora o una salida basada en la funcionalidad. Cuando el objetivo es una salida basada en la hora/fecha, el propietario del producto esperará que el lanzamiento finalice en dicha fecha. Los propietarios de productos generalmente establecerán un objetivo para completar las funcionalidades ‘x’ al final del lanzamiento.
• Estimación de las historias de usuario (tamaño): los propietarios de productos siempre tendrán una lista de artículos deseados que les gustaría tener como objetivo durante cada próximo lanzamiento del proyecto. Es importante identificar y estimar el tamaño (complejidad) de las Historias de usuario en función del valor empresarial asociado a ellas. Estas estimaciones proporcionan entradas clave que deben tenerse en cuenta para la planificación de la versión para definir los plazos de la versión, así como la duración del Sprint.
• Priorización de historias de usuarios: los proyectos siempre enfrentan una situación en la que hay demasiado trabajo para entregar o muy poco tiempo para entregar. Por lo tanto, siempre es recomendable que el propietario del producto priorice las historias de usuario disponibles, para que el equipo pueda trabajar en consecuencia según la necesidad comercial.
• Seleccionar historias y definir la fecha de lanzamiento: en este paso, el equipo ágil tendría información sobre las estimaciones de las historias de usuario (en tamaño/complejidad), las historias de usuario priorizadas (según la necesidad comercial) y la duración requerida para cada Sprint. Estas entradas ayudarían en la planificación de la versión que cumple con el objetivo definido por el propietario del producto (o el cliente) para una versión. Todos los miembros del equipo del proyecto, junto con el propietario del producto y cualquier otra parte interesada (es decir, usuarios finales, etc.) están involucrados en esta actividad y la fecha de finalización del lanzamiento se define en colaboración con un consenso común.

Estimacion:

La estimación del nivel de lanzamiento se realiza en el momento de la planificación del lanzamiento. Los requisitos priorizados se toman del Product Backlog, que tiene la forma de User Stories. Las Historias de Usuario se estiman en términos de Puntos de Historia durante la planificación de la Versión, que se enfoca en estimar el tamaño del software que se entregará para esa Versión en particular. Los otros insumos considerados son el tamaño del proyecto, el esfuerzo, la duración del ciclo y las habilidades disponibles. Sobre la base de esta estimación, se planifican varios lanzamientos y un número total de puntos de la historia en cada lanzamiento para el proyecto general. 

La estimación durante la planificación del lanzamiento la realiza todo el equipo utilizando una de las siguientes técnicas:  

• Wideband Delphi (o enfoque de Consenso) sigue los pasos mientras realiza la estimación de los puntos de la historia del usuario utilizando el método Wideband Delphi:
  • El coordinador analiza las historias de usuario con el equipo y el propietario del producto.
  • Cada miembro del equipo estima la cantidad de días-persona necesarios para completar cada funcionalidad.
  • El coordinador compara y analiza las estimaciones individuales con el equipo.
  • El proceso se repite hasta que no haya diferencia significativa en la estimación por parte del grupo.
  • Este ejercicio generalmente se puede hacer en tres rondas.
• La estimación por analogía (o extrapolación) sigue los pasos mientras se realiza la estimación de los puntos de la historia del usuario utilizando el método de estimación por analogía:
  • La estimación de una historia de usuario se basa en su relación con una o más referencias.
  • Las historias de usuarios de tamaño similar se recopilan y estiman como un grupo.
  • Por ejemplo, se estima que una historia de usuario «Capacidad para agregar beneficiario» tarde 40 horas en completarse. Si la historia de usuario «Capacidad para editar beneficiario» es la mitad de complicada que «Agregar beneficiario», el esfuerzo requerido para esta historia será de 20 horas.
    A continuación se muestra otra representación de un ejemplo:

• La técnica de Planning Poker utiliza tarjetas de estimación, que se basan en la serie de Fibonacci, es decir, 0, 1, 2, 3, 5, 8, 13, 20, 40, 100 y ∞ al estimar los puntos de historia para las Historias de usuario. El póquer de planificación incluye a todos los miembros del equipo, es decir, desarrolladores, evaluadores, analistas, etc. Es una técnica de tamaño relativo basada en el consenso de todo el equipo. Los siguientes son los pasos seguidos al realizar la estimación utilizando este método:
  • Cada miembro/estimador tiene una baraja de cartas con una estimación legítima en cada carta.
  • El moderador (que no suele jugar) lee una historia, que luego se comenta brevemente.
  • Cualquier duda que surja es respondida por el Product Owner.
  • Cada estimador elige una tarjeta que representa su estimación y la coloca boca abajo (oculta).
  • Las cartas se dan vuelta todas al mismo tiempo para que todos puedan verlas.
  • Si las estimaciones difieren, se pueden utilizar los estimadores más alto y más bajo para justificar la diferencia.
  • Vuelva a estimar hasta que se acuerden los puntos de la historia.

Nivel de carrera:

Planificación:

El plan de lanzamiento proporciona una vista de alto nivel de lo que el equipo pretende construir y lo que el equipo pretende implementar al final del lanzamiento. No proporciona una vista detallada de cómo el equipo planearía impulsar el trabajo dentro de Sprints. Una vez que se conocen los lanzamientos y sus Sprints, el equipo comienza a planificar cada Sprint. Esto ocurre al comienzo de cada Sprint, es decir, el primer día del Sprint, y permite que el equipo sea más explícito sobre lo que entregará al final del Sprint. El equipo considera las sugerencias del Scrum Master, así como la lista de prioridades del propietario del producto. Luego, el equipo decide qué puede tomar del trabajo pendiente priorizado para este Sprint, luego desglosa las tareas para cada historia de usuario y se las asigna a sí mismo.

En la reunión de planificación de Sprint, el equipo se centrará más en lo que debe hacer para completar las historias de usuario seleccionadas para ese Sprint. A esta reunión asisten el propietario del producto, Scrum Master, todos los miembros del equipo, como analistas, programadores, evaluadores, ingenieros de bases de datos, diseñadores de interacción con el usuario, etc. El resultado de la planificación del Sprint se puede registrar en una hoja de cálculo simple o en una herramienta ALM (Administración del ciclo de vida de la aplicación), donde el equipo tendrá todas las historias de usuario de ese Sprint y sus tareas mencionadas secuencialmente (es decir, Sprint Backlog).

La planificación de la capacidad del equipo y el compromiso de la historia del usuario para un Sprint son siempre grandes desafíos para un equipo Scrum. Antes de comprometerse con un objetivo de Sprint, es importante conocer la capacidad actual del equipo. Con base en la Capacidad del equipo Scrum, el compromiso se realizaría para completar una cierta cantidad de historias de usuarios (o puntos de historias de usuarios) al final de ese Sprint. Según estas entradas y un acuerdo de consentimiento entre el propietario del producto, el equipo Scrum y el Scrum Master, las tareas se pueden estimar exactamente. De esta manera, la capacidad del equipo se puede utilizar para una planificación y estimación efectivas.

La planificación de Sprint se lleva a cabo al comienzo de cada Sprint. Esto ayuda al Equipo a enfocarse en la meta del Sprint. En Sprint Planning, el equipo decide qué construirá en el próximo Sprint y cómo lo construirá. El equipo se compromete con el objetivo de Sprint después de desglosar las historias de los usuarios en tareas y hacer una estimación a nivel de tareas. La planificación de Sprint la realizan el propietario del producto, el Scrum Master y el equipo. Durante esta reunión, la velocidad del equipo, las tendencias de velocidad anteriores (si están disponibles) y la capacidad disponible del equipo se considerarán para una planificación efectiva.  

La reunión de Planificación de Sprint se divide en dos segmentos, a cada uno de los cuales se le asigna la mitad del tiempo de la reunión de Planificación de Sprint.  

Parte 1: En la primera parte

• El equipo trabaja con el Product Owner para determinar qué se entregará como parte del Sprint.
• El propietario del producto explica las historias de usuario al equipo.
• Detalla la interacción
• Revisa la infraestructura y la interfaz
• Explica los criterios de aceptación.

Parte 2: En la segunda parte

• Los miembros del equipo deciden cómo van a construir esta funcionalidad en un incremento de producto durante el Sprint.
• El equipo selecciona la historia de usuario
• La historia de usuario se divide en tareas
• Cada una de las tareas se estima en horas
• El equipo acuerda las Historias de Usuario que se realizarán durante el Sprint.

El tiempo necesario para la reunión de Planificación del Sprint será en proporción similar en función de la duración del Sprint.  

Estimacion :

Durante la planificación de Sprint, las historias priorizadas de la cartera de productos se dividen en tareas que se pueden estimar. En Sprint Planning, se usa la estimación ascendente y las tareas se estiman en días/horas, lo que da como resultado el esfuerzo real para la historia de usuario.

Las tareas se pueden definir relacionadas con el diseño, la codificación, los escenarios de prueba, las pruebas unitarias, la ejecución de casos de prueba, etc. Según la «Definición de Hecho», la lista de tareas puede incluir Automatización, Pruebas de regresión, actualización de Guías de estilo, completar una revisión de código , etc. El equipo debe comprender que el éxito del Sprint significa que todos los parámetros se establecen como parte de la Definición de Terminado.  

En los proyectos Agile, la ‘Definición de Terminado’ determina las condiciones que se considerarán para una Historia de usuario, y sus tareas asociadas se completarán y estarán listas para la aceptación del usuario. La ‘Definición de Terminado’ proporciona un entendimiento compartido entre los miembros del equipo del proyecto junto con el Propietario del Producto. Cuando alguien en el equipo dice que una tarea ha terminado, todos en el equipo tienen un entendimiento común de lo que significa. A través de la ‘Definición de Listo’, el equipo se adhiere a los estándares de calidad.  

Cada miembro del equipo es responsable de sus propias tareas, que deben estimar por separado. Diariamente, el propietario de la tarea debe informar las horas restantes (pendientes) de la tarea, que se utiliza para dibujar el gráfico Burn-down.  

Muchas veces se pregunta si Tester también debe estimar el esfuerzo de desarrollo, y viceversa. Todas las actividades relacionadas con la historia del usuario deben estimarse juntas como un grupo. (es decir, probadores y desarrolladores). La estimación se realiza en función del tamaño relativo durante la planificación de la versión y se tiene en cuenta automáticamente. Cada trabajo debe ser estimado por su propietario durante la planificación del Sprint.

Como parte de la planificación del Sprint, Scrum Master, Product Owner y los miembros del equipo del proyecto comienzan con un Product Backlog priorizado para definir el alcance del Sprint y crear el Sprint Backlog. El Sprint Backlog consta de User Stories que se lograrían durante el Sprint actual. El equipo en conjunto toma las Historias de usuario del Sprint Backlog y las descompone en tareas individuales que podrían estimarse.  

Se estima el tiempo ideal para completar una tarea. La estimación del tiempo ideal traduce el tamaño (medido en puntos de la historia) de una tarea en una estimación completa del esfuerzo. Normalmente, este esfuerzo se mide en días u horas. La estimación de tareas está destinada al Sprint Backlog y solo está presente durante el Sprint.

Por ejemplo, mientras el equipo realiza la planificación de Sprint, elegirán una historia de usuario que puede tener un tamaño de 5 puntos de historia. Luego, esta historia de usuario se divide en diferentes tareas de trabajo, como diseño, detalle, implementación y prueba. El objetivo es averiguar con cuántas historias de usuario puede comprometerse el equipo de desarrollo durante un Sprint. El equipo de desarrollo debe sentirse cómodo con el compromiso y los Product Owners deben estar seguros de que el equipo cumplirá con ese compromiso.  

La estimación del tiempo ideal se basa en el enfoque ascendente en el que los miembros del equipo dividen los requisitos comerciales en actividades de bajo nivel y cada actividad se estima por separado. Se les pide a los miembros del equipo que se inscriban en las tareas y calculen cuánto tiempo les llevará completarlas en horas o días.

Cuando un equipo estima usando el tiempo ideal, se refiere al tiempo requerido para que un programador complete una función o tarea en comparación con otras funciones o tareas. El equipo se alinea para lograr la meta esperada al mostrar el esfuerzo restante en un lugar común (es decir, gráficos de trabajo pendiente).

Los miembros individuales del equipo seleccionan una actividad y envían estimaciones para la estimación de tiempo ideal de las tareas. Si hay un desacuerdo en estas estimaciones entre los miembros del equipo, lo discuten y llegan a un consenso.