Idealmente, una característica debe cumplir con los siguientes criterios
- debe proporcionar Valor de negocio.
- Debería ser estimable – debe tener suficiente definición para que el equipo de desarrollo proporcione una estimación del trabajo involucrado en su implementación.
- Debería ser suficientemente pequeño para caber dentro de una iteración; por lo tanto, si es demasiado grande, debe desglosarse aún más.
- Debería ser comprobable – debe comprender qué prueba automática o manual debe pasar una característica para que sea aceptable para el cliente.
Las diferentes metodologías utilizan diferente terminología para referirse a las características. Depende 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 características; scrum usa "backlog del producto" para describir una lista de características; el desarrollo basado en características utiliza "característica"; y DSDM usa "requisito". De manera similar, existen varias versiones ligeras del proceso unificado, o Agile UP, que usan "requisito" y/o "caso de uso" para definir la funcionalidad de entrega incremental. En última instancia, el objetivo es el mismo: ofrecer valor empresarial de forma regular en pequeños incrementos, y más pronto que tarde.
Diferencias metodológicas
Melé llama a una función elemento pendiente, que tiende a tener un grano más grande y también puede incluir elementos que no son funciones, como "configurar hardware de producción" o "buscar opciones xyz".
XP llama a una función historia, que se presta a un enfoque particularmente útil para definir la funcionalidad.
DSDM llama a una función requisito, que también puede incluir más que solo características del sistema.
Ágil ARRIBA los practicantes usan requisitos y casos de uso para definir características.
Estructura de desglose de características (FBS)
Durante la planificación detallada, desarrollo ágil favorece un enfoque de estructura de desglose de características (FBS) en lugar de la estructura de desglose de trabajo (WBS) utilizada en los enfoques de desarrollo en cascada. Las estructuras de desglose de funciones son ventajosas por varias razones:
- Permiten la comunicación entre el cliente y el equipo de desarrollo en términos que ambos puedan entender.
- Permiten al cliente priorizar el trabajo del equipo en función del valor empresarial.
- Permiten el seguimiento del trabajo frente al valor comercial real producido.
Es aceptable comenzar con características que son grandes y luego dividirlas en características más pequeñas con el tiempo. Esto permite que el cliente evite sumergirse en demasiados detalles hasta que ese detalle sea necesario para ayudar a facilitar el diseño y la entrega reales.
Creación de una lista inicial de características
Antes release planificación y planificación de iteraciones, el equipo necesita elaborar rápidamente una lista de tantas funciones potenciales para el sistema como sea posible. Generalmente hay una sola persona responsable de recopilar funciones (por ejemplo, un gerente de producto, un cliente, un administrador de programas, un analista de negocios o algún otro representante del cliente), pero las solicitudes de funciones pueden provenir de muchas fuentes. Los usuarios, los clientes, las ventas, el marketing, las RFP, los miembros del equipo de desarrollo, la administración, los competidores y las regulaciones gubernamentales pueden ser fuentes de funciones. La lista de funciones centrales del equipo debe tener algunos controles para evitar elementos duplicados, funciones imposibles y solicitudes demasiado vagas. Sin embargo, se debe alentar al equipo a introducir nuevas funciones a medida que las identifiquen, de modo que puedan incorporarse al proceso de priorización y planificación.
Una lista inicial de características puede ser un bosquejo aproximado, un superconjunto, que se utilizará como entrada para planificar el release y primera iteración. Representa el potencial actual de lo que podría llegar a ser el sistema, quizás a lo largo de varios releases. No es necesario esperar hasta que todas las funciones estén definidas antes de comenzar. entrega de software. Y no es necesario que se adhiera sin sentido a la lista original, a las descripciones originales o a las prioridades originales. Uno de los puntos principales del desarrollo ágil es que esta lista (como todo lo demás) evoluciona, iteración tras iteración.
Supongamos que se completa una lista aproximada de características, una release Se elaboran el plan y el plan de iteración, y se completa la primera iteración, antes de que se identifiquen un par de características críticas. Estas características simplemente se integran en la evolución release plan y una iteración posterior, y se entregan lo antes posible. Pero mientras tanto, el tiempo no se pierde. El equipo comienza a generar valor lo antes posible y crea la infraestructura para permitir que el proyecto se adapte con el tiempo a nuevas prioridades, información y dinámica comercial.
Lista de características
Al elaborar una lista de características, las características se describen inicialmente en un párrafo breve, generalmente de 2 a 4 oraciones. Esta descripción representa un resumen de alto nivel de la función, un marcador de posición para la comprensión preliminar y una base para la comunicación futura. Es más bien como un titular para un artículo que se escribirá más adelante. El objetivo es dedicar suficiente tiempo a describir la característica para tener una comprensión razonable del tamaño relativo, la complejidad y la prioridad en comparación con todas las demás características. Algunos detalles más surgirán durante planificación de iteraciones. Pero se permite que la comprensión precisa y concreta de la función surja durante la iteración, ya 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 especifican de manera determinista.
Referencias útiles
Historias de usuarios
Historias de usuarios aplicadas: para el desarrollo de software ágil por Mike Cohn
Seminarios Web
Cómo ejecutar PI Planning con Digital.ai Agility
Funciones de organización
Administrar una sola lista larga de características puede ser difícil. Es muy útil organizar características especificando categorías, agrupaciones funcionales de nivel superior, valor comercial o prioridad y riesgo. Filtrar y clasificar por estos diversos atributos puede ayudar a desglosar una lista de características muy grande en partes manejables.
La lista completa de funciones debe clasificarse en una sola secuencia continua para que el equipo del proyecto pueda ver fácilmente qué funciones son las más valiosas. Si un proyecto comienza con 100 funciones en la lista, no es raro que 50 de esas funciones caigan en una categoría de prioridad "alta". Una sola clasificación secuencial de las funciones ayuda a identificar aquellas que son las "más altas de las más altas" y, por lo tanto, deben completarse primero para maximizar el valor entregado.
Contabilización del riesgo
Se pueden tomar consideraciones adicionales para el riesgo asociado con ciertas características. Algunas características involucrarán diseños, arquitecturas, marcos o algoritmos que son nuevos para el equipo o que son riesgosos. Incluso si tales características no ofrecen el valor comercial más alto, a menudo tiene sentido aumentar su prioridad lo suficiente como para abordarlas en las primeras iteraciones. Si una característica de alto riesgo se aborda al principio del proyecto y, por alguna razón, resulta inviable, el equipo aún tiene tiempo para reaccionar y solucionarlo. Esto minimiza el riesgo general para el proyecto. Depende del equipo de desarrollo trabajar en estrecha colaboración con el cliente para ayudar a identificar este tipo de problemas, riesgos y dependencias. En última instancia, depende del cliente priorizar las características, pero este proceso crítico no debe ocurrir en el vacío. Los mejores equipos trabajan juntos para ofrecer valor y reducir el riesgo a lo largo de la vida de un proyecto.
Características de estimación
Después de identificar las características, el cliente a menudo trabaja con las partes interesadas clave en el desarrollo para definir las estimaciones de características. Las estimaciones de características están destinadas a ser estimaciones preliminares de alto nivel que se utilizan para impulsar release planificar y planificación de iteraciones. Las partes interesadas involucradas en la estimación pueden incluir arquitectos, líderes tecnológicos, desarrolladores, evaluadores, escritores y gerentes. Muchas organizaciones han establecido procesos en los que los grupos trabajan juntos para proporcionar estimaciones iniciales rápidamente. Este paso puede resultar útil para determinar inicialmente si la función debe desglosarse más.
Al estimar inicialmente las características, el objetivo es converger rápidamente en una estimación razonable de alto nivel. En lugar de centrarse en si una característica requerirá exactamente 17.5 horas de idea (o Gummi Bears, o NUTs, o cualquier unidad que se esté utilizando; ver más abajo), el objetivo es acercarse razonablemente en una fracción del tiempo. Si se tarda dos minutos en aceptar que la característica tardará de dos a tres días ideales en implementarse frente a 30 minutos para establecer una estimación precisa de 17.5 horas idea, se prefiere el primer enfoque. Para establecer una estimación única cuando las opiniones en el grupo varían, los equipos pueden tomar un promedio, desarrollar una aproximación razonable, usar siempre el mejor de los casos o potencialmente usar un cálculo que involucre el mejor de los casos, el peor de los casos y la estimación esperada si es más complejo. adecuado. En cualquier caso, las discusiones sobre las diferentes estimaciones a menudo generarán conocimientos útiles.
Este proceso de definición y estimación de funciones puede parecer inicialmente difícil, y cuando los equipos lo implementan por primera vez, pueden requerir varias reuniones para sentirse cómodos con un proceso que funcione bien para ellos. Con el tiempo, se vuelve más fácil desglosar las funciones en unidades de trabajo que se pueden entregar en una sola iteración. Los equipos se vuelven muy buenos en lo que practican y el desarrollo ágil les permite practicar la estimación cada release e iteración.
Unidades de estimación
Las estimaciones, por su propia naturaleza, son inexactas y, históricamente, los desarrolladores han tenido dificultades para producir estimaciones útiles de todo el tiempo necesario para completar una tarea de desarrollo. Las estimaciones del tiempo de programación real a menudo son inexactas (especialmente si no se comparan rigurosamente con los números reales). Pero el tiempo de no programación es aún más difícil de precisar. ¿Qué respondes si alguien te pregunta cuánto tardas en cruzar la ciudad en coche? Usas una medida relativa. “Una hora fuera de las horas pico, con buen tiempo, si no hay obras, de lo contrario tal vez 2 horas”, etc. Estos factores externos son imposibles de controlar y difíciles de predecir. Además de desarrollar código, los programadores pasan tiempo probando, escribiendo documentación, diseñando, participando en reuniones y revisiones, enviando correos electrónicos, etc. En comparación con el trabajo de programación, el trabajo que no es de programación es difícil de predecir o controlar. Puede variar según su industria, su organización, la época del año y cualquier forma de cambiar las presiones externas sobre la organización.
Algunos equipos piden a los programadores que incluyan cada actividad no relacionada con la programación en sus estimaciones. Pero como hemos dicho, esto no es fácil de hacer. Para un proyecto ágil dado, mucho antes de que el equipo tenga una medición precisa del tiempo que dedican a cosas que no son de programación, pueden conocer el trabajo relativo requerido para realizar diferentes funciones y pueden planificar en consecuencia. Es por eso que es más común que los equipos ágiles centren sus estimaciones en lo que se puede estimar y medir de manera más sencilla: la programación real. Se centran en cuánto trabajo llevará cada función y cada tarea técnica, en comparación con otras funciones y tareas técnicas. Permiten que la cantidad de tiempo consumido por esas cosas que no son de programación se aclare a medida que surge la velocidad real después de algunas iteraciones. Hay dos unidades de estimación principales que los equipos ágiles utilizan para concentrar el enfoque 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 que no se pueda confundir con el tiempo real. Algunas de estas unidades:
- Puntos
- ositos de goma
- Lb-pie
- NUTs (Unidades Nebulosas de Tiempo)
Representan la cantidad relativa de trabajo necesaria para implementar una característica (o tarea), en comparación con otras características (o tareas). Solo una vez que el equipo se ha establecido en una velocidad constante, generalmente en unas pocas iteraciones, pueden comenzar a asignar estas unidades de trabajo a unidades de tiempo real. Ese es exactamente el punto de la velocidad: describir cuánto trabajo puede hacer el equipo por unidad de tiempo real.
Una vez que el equipo u organización haya acordado una unidad de estimación, debe acordar hacer un esfuerzo para implementarla de manera consistente y ceñirse a su definición original. Especialmente en las primeras iteraciones del proyecto, todos deben resistir la tentación de tratar de mapear estas unidades a unidades de tiempo con precisión exacta.
tiempo ideal
Al igual que las unidades de trabajo, el tiempo ideal excluye el tiempo de no programación. Cuando un equipo usa el tiempo ideal para estimar, se refiere explícitamente solo al tiempo del programador requerido para realizar una función o tarea, en comparación con otras funciones o tareas. Una vez más, durante las primeras iteraciones, se acumula el historial estimado, surge una velocidad real y el tiempo ideal se puede asignar al tiempo real transcurrido.
Muchos equipos que utilizan el tiempo ideal han descubierto que su esfuerzo final supera las estimaciones iniciales del programador en 1 o 2 veces, y que esto se estabiliza, dentro de un rango aceptable, en unas pocas iteraciones. Tarea por tarea, la proporción variará, pero durante una iteración completa, las proporciones que desarrollan los equipos han demostrado ser bastante consistentes. Para un equipo dado, una relación histórica conocida de tiempo ideal a tiempo real puede ser especialmente valiosa en la planificación. releases. Un equipo puede analizar rápidamente la funcionalidad requerida y proporcionar una estimación de alto nivel de 200 días ideales. Si la proporción histórica del equipo de ideal a 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 oferta fija, este tipo de estimación puede ser confiable.
Estimación relativa
Muchos equipos ágiles utilizan la práctica de la estimación relativa de características. En lugar de estimar características a través de un espectro de longitudes unitarias, seleccionan unas pocas (de tres a cinco) categorías de estimación relativas, o cubos, y estiman todas las características en términos de estas categorías.
Planificación de funciones frente a tareas
Si bien el énfasis en esta etapa inicial de planificación está en la velocidad y en el trabajo relativo por función, en algún momento las funciones deben desglosarse en sus respectivas tareas y estimarse con mayor precisión. Esto sucede durante release planificación y planificación de iteraciones. En general, las estimaciones de características y las estimaciones de tareas sirven para diferentes propósitos:
- Las estimaciones de características ayudan a impulsar la programación en releases e iteraciones.
- Las estimaciones de tareas ayudan a impulsar la carga de recursos dentro de una iteración.
Debido a que sirven para diferentes propósitos, la estimación de una característica no necesita alinearse con precisión con la suma de sus estimaciones de tareas. Sin embargo, en un rango de características, debe haber al menos una correlación aproximada entre las estimaciones de características y la suma de las estimaciones de tareas para las características.
Preguntas Frecuentes
¿Qué tan grande es una característica?
Esto puede variar en gran medida según el trabajo de desarrollo que esté realizando su equipo. Una regla general es que una característica debe ser lo suficientemente pequeña como para completarse en una iteración y lo suficientemente grande como para justificar la programación. Por ejemplo, no querría programar nada más que funciones de una hora para un equipo de diez personas que trabajan en un sprint de un mes. Son demasiados elementos para programar y rastrear. Si hay cambios de características específicas que son tan pequeños, a menudo es mejor agrupar esos cambios más pequeños en un elemento más grande para fines de programación. Haz que cada hora de esfuerzo sea una tarea bajo esa función.
¿Son funciones de corrección de errores?
Ellos pueden ser. Scrum, por ejemplo, enseña que todo el trabajo que el equipo debe realizar debe estar en la lista de tareas pendientes. Los métodos comunes para manejar errores incluyen 1) crear un elemento de función para cada error, 2) crear un elemento de función llamado 'corregir errores' dentro de cada iteración y detallar la lista o los tipos de errores que se corregirán, o 3) manejar errores por separado y no seguimiento del tiempo contra ellos. La cantidad y el tamaño de los errores que su equipo espera encontrar deben ser un factor importante para determinar qué método elegir.
¿Por qué estimar características?
Las estimaciones de funciones ayudan a impulsar la clasificación y la programación que se producen en release planificación y planificación de iteraciones. Para saber cuánto trabajo programar dentro de un período determinado, debe tener una estimación de qué tan grande es cada pieza de trabajo. Ver también velocidad ágil. Si dos funciones 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 función, por lo que debería clasificarse más alto que la segunda.
¿Deberíamos actualizar las estimaciones de características si las estimaciones de tareas no cuadran?
No, las estimaciones de características impulsan la programación. Las estimaciones de tareas impulsan las asignaciones de recursos. Si bien debe haber una correlación entre los valores, no es necesario que se alineen con precisión.
