Estimación ágil de funcionalidades

Idealmente, una función debería cumplir con los siguientes criterios.

1. debe proporcionar Valor de negocio.
2. Debería ser estimable – Debe tener la definición suficiente para que el equipo de desarrollo pueda proporcionar una estimación del trabajo que implica su implementación.
3. Debería ser suficientemente pequeño para que quepa dentro de una iteración; por lo tanto, si es demasiado grande, debería dividirse aún más.
4. Debería ser comprobable – Debes comprender qué prueba, automatizada o manual, debe superar una función para ser aceptable para el cliente.

Las distintas metodologías emplean terminología diferente para referirse a las funcionalidades. Es responsabilidad del equipo decidir qué metodología o terminología utilizar. La programación extrema (XP) utiliza los términos «historias de usuario» o «historias» para representar las funcionalidades; Scrum utiliza el «backlog del producto» para describir una lista de funcionalidades; el desarrollo guiado por funcionalidades utiliza el término «funcionalidad»; y DSDM utiliza el término «requisito». De forma similar, existen diversas versiones simplificadas del proceso unificado, o Agile UP, que utilizan «requisito» o «caso de uso» para definir la funcionalidad entregable de forma incremental. En definitiva, el objetivo es el mismo: entregar valor de negocio de forma regular en pequeños incrementos, y cuanto antes mejor.

diferencias metodológicas

Melé llama a una característica una elemento de la lista de pendientes, que tiende a ser más general y también puede incluir elementos que no son características, como “configurar el hardware de producción” o “investigar las opciones xyz”.

XP llama a una característica una historia, lo cual se presta a un enfoque particularmente útil para definir la funcionalidad.

DSDM llama a una característica una requisito, que también puede incluir más que solo características del sistema.

Agile UP Los profesionales utilizan requisitos  y  casos de uso para definir características.

Estructura de desglose de características (FBS)

Durante la planificación detallada, desarrollo ágil Prefiere un enfoque de estructura de desglose de funcionalidades (EDF) en lugar de la estructura de desglose del trabajo (EDT) utilizada en los enfoques de desarrollo en cascada. Las estructuras de desglose de funcionalidades presentan varias ventajas:

1. Permiten la comunicación entre el cliente y el equipo de desarrollo en términos que ambos puedan comprender.
2. Permiten al cliente priorizar el trabajo del equipo en función del valor para el negocio.
3. Permiten realizar un seguimiento del trabajo realizado en relación con el valor empresarial real producido.

Es aceptable comenzar con funcionalidades grandes e ir dividiéndolas en funcionalidades más pequeñas con el tiempo. Esto permite al cliente evitar profundizar en demasiados detalles hasta que estos sean necesarios para facilitar el diseño y la entrega.

Creación de una lista inicial de características

Antes de la planificación del lanzamiento y planificación de iteracionesEl equipo necesita elaborar rápidamente una lista con la mayor cantidad posible de funcionalidades potenciales para el sistema. Normalmente, una persona se encarga de recopilarlas (por ejemplo, un gerente de producto, un cliente, un gerente de programa, un analista de negocios o algún otro representante del cliente), pero las solicitudes de funcionalidades pueden provenir de diversas fuentes. Usuarios, clientes, ventas, marketing, solicitudes de propuestas (RFP), miembros del equipo de desarrollo, la gerencia, la competencia y las regulaciones gubernamentales pueden ser fuentes de funcionalidades. La lista central de funcionalidades del equipo debe contar con controles para evitar elementos duplicados, funcionalidades imposibles y solicitudes demasiado vagas. Sin embargo, se debe alentar al equipo a que ingrese nuevas funcionalidades a medida que las identifique, para que puedan incorporarse al proceso de priorización y planificación.

Una lista inicial de funcionalidades puede ser un esbozo preliminar, un conjunto general, que sirva como base para planificar el lanzamiento y la primera iteración. Representa el potencial actual del sistema, quizás a lo largo de varias versiones. No es necesario esperar a que todas las funcionalidades estén definidas para empezar. software de entregaY no es necesario que te aferres sin sentido a la lista original, las descripciones originales ni las prioridades originales. Uno de los puntos clave del desarrollo ágil es que esta lista (como todo lo demás) evoluciona, iteración tras iteración.

Imaginemos que se ha completado una lista preliminar de funcionalidades, se han elaborado un plan de lanzamiento y un plan de iteración, y se ha finalizado la primera iteración, antes de que se identifiquen un par de funcionalidades críticas. Estas funcionalidades simplemente se incorporan al plan de lanzamiento en desarrollo y a una iteración posterior, y se entregan lo antes posible. Mientras tanto, no se pierde tiempo. El equipo comienza a generar valor lo antes posible y crea la infraestructura que permite que el proyecto se adapte con el tiempo a nuevas prioridades, información y dinámicas del negocio.

Lista de características

Al elaborar una lista de funcionalidades, estas se describen inicialmente en un breve párrafo, generalmente de 2 a 4 oraciones. Esta descripción representa un resumen general de la funcionalidad, un punto de partida para una comprensión preliminar y una base para la comunicación futura. Es similar al titular de un artículo que se escribirá más adelante. El objetivo es dedicar el tiempo suficiente a describir la funcionalidad para comprender razonablemente su tamaño, complejidad y prioridad en comparación con las demás. Se irán conociendo más detalles durante el proceso. planificación de iteracionesPero la comprensión precisa y concreta de la característica puede surgir durante la iteración, a medida que los clientes y los desarrolladores la discuten lo suficiente como para implementarla o (en algunas metodologías) para crear pruebas de aceptación automatizadas que la especifiquen de forma determinista.

Referencias útiles

Historias de usuarios

Historias de usuarios aplicadas: para el desarrollo de software ágil Por Mike Cohn

Webinar

Cómo ejecutar la planificación de PI con Digital.ai Agility

Características de organización

Gestionar una lista extensa de funcionalidades puede ser complicado. Organizar las funcionalidades especificando categorías, agrupaciones funcionales de alto nivel, valor o prioridad para el negocio y riesgo resulta muy útil. Filtrar y ordenar por estos atributos permite dividir una lista muy larga en partes más manejables.

La lista completa de funcionalidades debe ordenarse en una secuencia continua para que el equipo del proyecto pueda identificar fácilmente las más valiosas. Si un proyecto comienza con 100 funcionalidades, es común que 50 de ellas tengan una prioridad alta. Esta clasificación secuencial ayuda a identificar las funcionalidades más importantes, que, por lo tanto, deben completarse primero para maximizar el valor entregado.

Contabilización del riesgo

Se puede prestar especial atención al riesgo asociado a ciertas funcionalidades. Algunas de ellas implican diseños, arquitecturas, marcos de trabajo o algoritmos novedosos para el equipo, o que presentan otros riesgos. Aunque estas funcionalidades no aporten el mayor valor comercial, suele ser conveniente priorizarlas lo suficiente como para abordarlas en las primeras iteraciones. Si una funcionalidad de alto riesgo se aborda al inicio del proyecto y, por algún motivo, resulta inviable, el equipo aún dispone de tiempo para reaccionar y encontrar una solución alternativa. Esto minimiza el riesgo general del proyecto. El equipo de desarrollo debe colaborar estrechamente con el cliente para identificar este tipo de problemas, riesgos y dependencias. En última instancia, la priorización de las funcionalidades recae en el cliente, pero este proceso crucial no debe llevarse a cabo de forma aislada. Los mejores equipos colaboran para aportar valor y reducir el riesgo a lo largo de todo el ciclo de vida del proyecto.

Características de estimación

Tras identificar las funcionalidades, el cliente suele colaborar con los principales responsables del desarrollo para definir las estimaciones de funcionalidades. Estas estimaciones son preliminares y de alto nivel, y sirven de guía para impulsar el desarrollo. planificación de lanzamiento y la planificación de iteraciones. Entre los participantes en la estimación se incluyen arquitectos, líderes técnicos, desarrolladores, testers, redactores y gerentes. Muchas organizaciones han establecido procesos donde los grupos colaboran para proporcionar rápidamente estimaciones iniciales. Este paso puede ser útil para determinar inicialmente si la funcionalidad debe desglosarse aún más.

Al estimar inicialmente las funcionalidades, el objetivo es llegar rápidamente a una estimación general razonable. En lugar de centrarse en si una funcionalidad requerirá exactamente 17.5 horas de idea (o Gomitas, Nueces o cualquier otra unidad que se utilice; véase más abajo), el objetivo es aproximarse lo máximo posible en mucho menos tiempo. Si se tarda dos minutos en acordar que la funcionalidad tardará entre dos y tres días ideales en implementarse, frente a 30 minutos para establecer una estimación precisa de 17.5 horas de idea, se prefiere el primer enfoque. Para establecer una única estimación cuando las opiniones en el grupo varían, los equipos pueden calcular una media, desarrollar una aproximación razonable, utilizar siempre el mejor escenario posible o, si se requiere mayor complejidad, utilizar un cálculo que incluya el mejor escenario, el peor escenario y la estimación esperada. En cualquier caso, los debates sobre las diferentes estimaciones suelen aportar información valiosa.

Este proceso de definición y estimación de funcionalidades puede parecer difícil al principio, y cuando los equipos lo implementan por primera vez, es posible que necesiten varias reuniones para familiarizarse con un proceso que les funcione bien. Con el tiempo, resulta más fácil dividir las funcionalidades en unidades de trabajo que se pueden entregar en una sola iteración. Los equipos se vuelven expertos en lo que practican, y el desarrollo ágil les permite practicar la estimación en cada lanzamiento e iteración.

Unidades de estimación

Las estimaciones, por su propia naturaleza, son imprecisas, y a los desarrolladores históricamente les ha resultado difícil generar estimaciones útiles del tiempo total necesario para completar una tarea de desarrollo. Las estimaciones del tiempo real de programación suelen ser inexactas (sobre todo si no se comparan rigurosamente con datos reales). Pero el tiempo dedicado a tareas ajenas a la programación es aún más difícil de precisar. ¿Qué respondes si alguien te pregunta cuánto se tarda en cruzar la ciudad en coche? Utilizas una medida relativa: «Una hora fuera de las horas punta, con buen tiempo y sin obras; si no, quizá dos horas», etc. Estos factores externos son imposibles de controlar y difíciles de predecir. Además de desarrollar código, los programadores dedican tiempo a realizar pruebas, redactar documentación, diseñar, participar en reuniones y revisiones, gestionar el correo electrónico, etc. En comparación con el trabajo de programación, el trabajo no relacionado con la programación es difícil de predecir o controlar. Puede variar según el sector, la organización, la época del año y cualquier tipo de presión externa que afecte a la organización.

Algunos equipos piden a los programadores que incluyan todas las actividades no relacionadas con la programación en sus estimaciones. Pero, como ya hemos dicho, esto no es fácil. En un proyecto ágil, mucho antes de que el equipo tenga una medición precisa del tiempo dedicado a tareas no relacionadas con la programación, puede conocer el trabajo relativo necesario para completar las diferentes funcionalidades y planificar en consecuencia. Por eso, lo más habitual es que los equipos ágiles centren sus estimaciones en lo que se puede estimar y medir con mayor facilidad: la programación propiamente dicha. Se centran en cuánto trabajo requerirá cada funcionalidad y cada tarea técnica, en comparación con otras funcionalidades y tareas técnicas. Permiten que el tiempo consumido por esas actividades no relacionadas con la programación se haga evidente a medida que la velocidad real emerge tras algunas iteraciones. Existen dos unidades de estimación principales que los equipos ágiles utilizan para centrar la atención en la programación de esta manera:

• unidades de trabajo
• tiempo ideal

unidades de trabajo

Una unidad de trabajo es una medida relativa que esperamos no pueda confundirse con el tiempo real. Algunos ejemplos de estas unidades son:

• Puntos
• ositos de goma
• Lb-pie
• NUTs (Unidades Nebulosas de Tiempo)

Estas métricas representan la cantidad relativa de trabajo necesaria para implementar una función (o tarea), en comparación con otras funciones (o tareas). Solo cuando el equipo alcanza una velocidad constante, generalmente tras varias iteraciones, puede empezar a relacionar estas unidades de trabajo con unidades de tiempo real. Ese es precisamente el objetivo de la velocidad: describir cuánto trabajo puede realizar el equipo por unidad de tiempo real.

Una vez que el equipo o la organización haya acordado una unidad de medida, deberían comprometerse a implementarla de forma consistente y a respetar su definición original. Sobre todo en las primeras fases del proyecto, es importante evitar la tentación de intentar relacionar estas unidades con unidades de tiempo con una precisión excesiva.

tiempo ideal

Al igual que las unidades de trabajo, el tiempo ideal excluye el tiempo no dedicado a la programación. Cuando un equipo utiliza el tiempo ideal para realizar estimaciones, se refiere explícitamente solo al tiempo de programación necesario para completar una funcionalidad o tarea, en comparación con otras funcionalidades o tareas. De nuevo, durante las primeras iteraciones, se acumula el historial de estimaciones, emerge una velocidad real y el tiempo ideal puede relacionarse con el tiempo real transcurrido.

Muchos equipos que utilizan el tiempo ideal han descubierto que su esfuerzo final supera las estimaciones iniciales de los programadores entre 1 y 2 veces, y que esto se estabiliza, dentro de un rango aceptable, tras algunas iteraciones. La proporción varía según la tarea, pero a lo largo de una iteración completa, las proporciones que desarrollan los equipos han demostrado ser bastante consistentes. Para un equipo determinado, una proporción histórica conocida entre el tiempo ideal y el tiempo real puede ser especialmente valiosa para la planificación de lanzamientos. Un equipo puede analizar rápidamente la funcionalidad requerida y proporcionar una estimación general de 200 días ideales. Si la proporción histórica del equipo entre el tiempo ideal y el real es de aproximadamente 2.5, el equipo puede sentirse bastante seguro al presentar una estimación de 500 días de proyecto. En escenarios de precio fijo, este tipo de estimación puede ser fiable.

Estimación relativa

Muchos equipos ágiles utilizan la práctica de la estimación relativa para las funcionalidades. En lugar de estimar las funcionalidades en un espectro de longitudes unitarias, seleccionan unas pocas categorías o grupos de estimación relativa (de tres a cinco) y estiman todas las funcionalidades en función de estas categorías.

Planificación de características frente a planificación de tareas

Si bien en esta etapa inicial de la planificación el énfasis se centra en la velocidad y en el trabajo relativo por funcionalidad, en algún momento las funcionalidades deben desglosarse en sus respectivas tareas y estimarse con mayor precisión. Esto ocurre durante la planificación de lanzamientos y la planificación de iteraciones. En general, las estimaciones de funcionalidades y las estimaciones de tareas tienen propósitos diferentes:

• Las estimaciones de funcionalidades ayudan a planificar las distintas versiones e iteraciones.
• Las estimaciones de tareas ayudan a determinar la asignación de recursos dentro de una iteración.

Dado que cumplen funciones distintas, la estimación de una característica no tiene por qué coincidir exactamente con la suma de las estimaciones de sus tareas. Sin embargo, para un conjunto de características, debería existir al menos una correlación aproximada entre las estimaciones de las características y la suma de las estimaciones de las tareas para dichas características.

Preguntas Frecuentes

¿Qué tamaño tiene una característica?

Esto puede variar considerablemente según el trabajo de desarrollo que realice tu equipo. Como regla general, una funcionalidad debe ser lo suficientemente pequeña como para completarse dentro de una iteración y lo suficientemente grande como para justificar su planificación. Por ejemplo, no sería conveniente planificar únicamente funcionalidades de una hora para un equipo de diez personas que trabaja en un sprint de un mes. Eso implicaría demasiadas tareas para planificar y gestionar. Si existen cambios específicos en las funcionalidades que son tan pequeños, suele ser mejor agruparlos en una tarea más grande para facilitar la planificación. Asigna una tarea a cada hora de trabajo dentro de esa funcionalidad.

¿Las correcciones de errores son características?

Sí, es posible. Scrum, por ejemplo, enseña que todo el trabajo que el equipo necesita realizar debe estar en la lista de tareas pendientes. Algunos métodos comunes para gestionar errores incluyen: 1) crear una funcionalidad para cada error, 2) crear una funcionalidad llamada «Corregir errores» en cada iteración y detallar la lista o los tipos de errores que se deben corregir, o 3) gestionar los errores por separado sin contabilizar el tiempo dedicado a ellos. La cantidad y el tamaño de los errores que el equipo prevé encontrar deben ser un factor determinante para elegir el método adecuado.

¿Por qué estimar las características?

Las estimaciones de funcionalidades ayudan a determinar la priorización y la programación en la planificación de lanzamientos e iteraciones. Para saber cuánto trabajo programar en un período determinado, es necesario estimar el tamaño de cada tarea. Véase también velocidad ágilSi dos funcionalidades tienen el mismo valor comercial, pero una tiene la mitad del tamaño de la otra, el equipo será más eficiente si trabaja en la primera funcionalidad, por lo que debería tener una prioridad mayor que la segunda.

¿Deberíamos actualizar las estimaciones de funcionalidades si las estimaciones de tareas no coinciden?

No, las estimaciones de funcionalidades determinan la planificación. Las estimaciones de tareas determinan la asignación de recursos. Si bien debe existir una correlación entre los valores, no es necesario que coincidan exactamente.