Puntos de historia ágiles frente a horas: cómo estimar mejor el desarrollo de software
Publicado: 2021-10-05Puede ser difícil concentrarse en los procesos de desarrollo de software. Cuando se le ocurre una idea y se acerca a los desarrolladores, las dos primeras cosas que pregunta son cuánto costará implementar y cuánto tiempo llevará construir . La estimación es uno de los primeros pasos en el desarrollo de aplicaciones.
En este artículo, comparamos los dos modelos de estimación más populares en el desarrollo de software moderno: Puntos de historia ágiles frente a horas .
Siga leyendo para aprender cómo estimar el tiempo en Agile, conocer la esencia de ambos modelos de estimación, comprender sus diferencias y ver por qué los desarrolladores pueden elegir uno sobre el otro.
Las horas son bastante fáciles de entender y han sido el modelo de estimación principal en el desarrollo de software durante mucho tiempo. Las horas, también conocidas como horas-hombre u horas-trabajador, son la cantidad de horas que un desarrollador dedica al proyecto.
Entonces, ¿qué son los puntos de la historia y por qué surgieron si ya tenemos un modelo de estimación simple y directo?
Contenido:
- ¿Qué son exactamente los puntos de la historia?
- Así es como se calculan los puntos de la historia en Agile
- Ventajas de estimar en puntos de historia
- Desventajas de estimar en puntos de historia
- Ventajas de estimar en horas
- Desventajas de estimar en horas
- ¿Puedes convertir los puntos de la historia en horas?
- Puntos de historia frente a horas: ¿Qué elegir para el desarrollo de software?
¿Qué son exactamente los puntos de la historia?
Los puntos de historia son un modelo de estimación relativo nativo de Agile y Scrum. Calculan el esfuerzo para construir un producto al abordar tres aspectos del desarrollo:
la cantidad de trabajo que requiere el producto
la complejidad de las características del producto
Riesgos e incertidumbres que pueden afectar el desarrollo.
Al comienzo de la evaluación del proyecto, los desarrolladores eligen la historia de usuario más pequeña y simple que tiene un producto (por ejemplo, una historia de usuario de registro) y la configuran como una historia de usuario de 1 punto. Esa es la historia base : una historia de usuario que se utilizará para comparaciones de complejidad. A todas las demás historias de usuarios se les asignará una serie de puntos de la historia en función de su complejidad de desarrollo en comparación con la historia base.
Parece bastante simple en la superficie, pero ¿quién decide el número de puntos de la historia en cada historia?
Así es como se calculan los puntos de la historia en Agile
Al igual que con las horas, las personas que trabajarán en el producto suelen estimar los puntos de la historia para el desarrollo. Sin embargo, el proceso de estimación es ligeramente diferente con los puntos de la historia.
Para asignar puntos de historia a una historia de usuario, participan varios desarrolladores . Debería haber al menos dos, pero la empresa puede pedir a todos sus desarrolladores que contribuyan jugando a lo que la industria llama Planning Poker . Aquí están las reglas del juego:
Cada desarrollador recibe un juego de cartas de Planning Poker.
Los desarrolladores eligen una historia de usuario y discuten su complejidad y el esfuerzo de desarrollo necesario.
Cada desarrollador presenta una tarjeta correspondiente a la cantidad de puntos que le asignarían a la historia.
Si las estimaciones de puntos de la historia son las mismas, el número estimado de puntos se asigna a la historia.
Si los puntos de la historia sugeridos difieren, los desarrolladores discuten la historia del usuario hasta que encuentren una serie de puntos aprobados por la mayoría.
Los desarrolladores eligen la siguiente historia de usuario.
Repita los pasos del 3 al 5.
Cuando nuestras actividades se volvieron remotas, este proceso se modificó. En lugar de tarjetas y reuniones, los puntos de la historia se deciden en discusiones en línea, durante reuniones de Zoom o en mensajeros.
Se parece a esto:
Esto no significa que todos los desarrolladores involucrados en la estimación de los puntos de la historia trabajarán en el proyecto, por supuesto. Pero una ventaja clave del sistema de puntos de historia es que crea un marco más o menos universal que se puede utilizar no solo en el proyecto en cuestión, sino también en proyectos futuros con características similares.
Hay dos opciones de uso frecuente para estimar los puntos de la historia. Puedes asignar puntos:
utilizando cualquier número entero (1, 2, 3 ... 13,14,15, etc.)
usando números en la secuencia de Fibonacci (1, 2, 3, 5, 8, 13… 55, 89, 144, etc.)
La secuencia de Fibonacci es una opción más conveniente para estimar el desarrollo ya que deja cierto margen para la aproximación. El modelo de orden numérico es demasiado preciso para realizar comparaciones convenientes.
Durante el desarrollo y entre proyectos, si la historia del usuario termina siendo más o menos compleja de lo que se estimó originalmente, los puntos asignados de la historia podrían cambiar.
Ventajas de estimar en puntos de historia
Si el proceso de asignación de puntos de la historia parece un poco complejo, no dejes que te desanime. Hay ventajas en la planificación de la capacidad con puntos de historia.
1. Los puntos de la historia son independientes del desarrollador
Los puntos de la historia para cada historia son asignados por varios desarrolladores en la negociación , y el motivo es que el número se asigna no solo para un producto en particular y un desarrollador en particular, sino "en promedio". ¿Por qué es esto algo bueno?
Las cosas pasan. A veces, el desarrollador de su proyecto puede dejar su proyecto y ser reemplazado. Tal vez se enfermen, decidan tomarse un permiso parental o un año sabático, o simplemente dejar la empresa. Tal vez resulten estar subcalificados o sobrecalificados para el proyecto.
Cuando se reemplazan, un nuevo desarrollador puede tener una velocidad de trabajo diferente , lo que conducirá a volver a estimar las horas de trabajo necesarias para crear el producto.
Los puntos de la historia minimizan este problema . Asignados por varios desarrolladores diferentes, brindan una visión general de cuán compleja es una historia de usuario en particular. Los puntos de historia funcionan para todos y cada uno de los desarrolladores de una empresa en particular. (Aunque tenga en cuenta que las estimaciones de los puntos de la historia no serán correctas para diferentes empresas).
2. Los puntos de la historia facilitan volver a calcular el tiempo de desarrollo.
En la estimación de tiempo ágil con puntos de historia, los equipos usan el término velocidad para referirse a la cantidad de puntos de historia lanzados en un solo sprint.
Los equipos monitorean constantemente su velocidad y es bastante variable al principio. Un equipo puede lanzar características que valgan cinco puntos de historia una semana y veinte puntos de historia la siguiente. Pero eso es solo al principio. A medida que avanza el proyecto, el gráfico de velocidad se nivelará .
Con las horas, si un miembro del equipo cambia, cada tarea en la que está involucrado deberá volver a estimarse para ajustar los plazos. Con los puntos de la historia, esto es innecesario: el equipo puede ajustar la fecha límite del proyecto después del siguiente sprint conociendo el cambio en la velocidad general.
Los puntos de la historia evalúan el desempeño del equipo en su conjunto , eliminando la necesidad de una nueva estimación por tarea.
3. Los puntos de la historia son buenos para monitorear el desempeño del equipo
Cuando tiene equipos que trabajan en proyectos y / o tareas similares en diferentes momentos, la velocidad puede mostrarle fácilmente el progreso que ha logrado cada equipo. ¿Han mejorado y cuánto? ¿Qué equipo o desarrollador tiene dificultades y podría necesitar capacitación adicional? ¿Cuál es la curva de aprendizaje? ¿Quizás un equipo diferente se desempeña mejor?
Velocity es una gran herramienta para evaluar el desempeño de sus equipos no solo en el lugar sino de manera continua.
4. La estimación del tiempo de lanzamiento con los puntos de la historia es más precisa
Al rastrear la velocidad, el equipo sabe con alta precisión cuántos puntos de la historia pueden liberar en un sprint. Si bien el equipo de desarrollo de la aplicación tarda algún tiempo en calcular su velocidad, una vez que se ha calculado, la fecha de lanzamiento estimada es fácil de predecir .
Además, los cambios en los miembros del equipo, los requisitos o la cantidad / complejidad de las características no causan muchos problemas con la reestimación.
5. Puede reutilizar los puntos de la historia para proyectos futuros a fin de acelerar la estimación.
No es raro que una empresa esté bien versada en un nicho específico (o varios) y construya más de un producto con un conjunto similar de características. Después de completar incluso un proyecto estimado en puntos de historia, los desarrolladores pueden consultar esta estimación para nuevos proyectos . Esto acortará el tiempo de estimación.
Sin embargo, es importante seguir rastreando la velocidad de cada proyecto, ya que las circunstancias pueden cambiar.
6. Los puntos de la historia mejoran el trabajo en equipo
Tradicionalmente, las empresas de desarrollo tienen varios equipos de desarrolladores, cada uno trabajando en proyectos separados. Al estimar en horas, es el desarrollador que trabaja en el proyecto quien hace una estimación. Esto es algo bueno, en general, ya que quién sabe mejor cuánto tiempo tomará algo que la persona que lo hace.
Sin embargo, estimar la complejidad en los puntos de la historia ofrece una oportunidad para que los desarrolladores en el mismo campo cooperen , algo que rara vez ocurre de otra manera. Este tipo de trabajo en equipo brinda una gran oportunidad para compartir experiencias y motivarse mutuamente.
Desventajas de estimar en puntos de historia
Siempre existe el otro lado del argumento, que es cómo nacen los grandes sistemas. La estimación basada en la complejidad también tiene sus inconvenientes , y cada equipo tiene que decidir por sí mismo si sobrepasan las ventajas.
1. Los puntos de la historia deben ser asignados por más de un desarrollador.
El punto de venta del modelo de puntos de historia es su objetividad y valor para estimaciones futuras. Pero para que eso sea cierto, la estimación debe ser realizada por más de un desarrollador . Para empresas pequeñas con un solo equipo o empresas donde solo hay un especialista en un campo (es decir, solo un diseñador o desarrollador de iOS), los puntos de la historia no brindan tantas ventajas. Estas pequeñas empresas tradicionalmente eligen las horas de trabajo como modelo de estimación.
2. La estimación en los puntos de la historia requiere una acumulación considerable
Para aprovechar todo el potencial de los puntos de la historia, su equipo necesitará dedicar una cantidad considerable de tiempo . Si está trabajando en un proyecto con características en las que el equipo nunca ha trabajado anteriormente (o no ha trabajado a tiempo completo), los primeros dos o tres sprints serán difíciles de predecir en términos de rendimiento. Por supuesto, cuantos más elementos de la acumulación tengan sus equipos, más precisas pueden ser sus estimaciones debido a la abundancia de datos estadísticos. Pero Story Points no es un sistema que esté listo para funcionar de inmediato.
3. Los puntos de la historia son más complejos para la elaboración de presupuestos.
Los puntos de historia son excelentes para establecer plazos precisos y fechas de lanzamiento, lo que puede ser importante para los desarrolladores y para el marketing del cliente. Sin embargo, cuando se trata de estimar los costos de desarrollo de aplicaciones, son menos convenientes .
La cuestión es que los desarrolladores dedican tiempo a un proyecto no solo a escribir código (o hacer diseños o probar). Se dedica algo de tiempo a la investigación, la discusión, dentro del equipo y con el cliente, haciendo cambios, etc. El tiempo dedicado a estimar los puntos de la historia también es tiempo dedicado al proyecto, pero no se incluye en los puntos por historia.
Es posible presupuestar cuando se estima en puntos de la historia, pero generalmente es más rápido y más fácil equiparar el dinero al tiempo dedicado al proyecto.
4. La velocidad se calcula por equipo
Lo que esto significa es que si los equipos se mezclan entre proyectos, deberá calcular la velocidad para cada combinación de desarrolladores por separado. Por lo tanto, la estimación de un equipo no será necesariamente cierta para un equipo diferente, e incluso cambiar un solo miembro del equipo puede invalidar las estimaciones anteriores.
Por otro lado, puede utilizar la estimación de complejidad para encontrar las combinaciones de mejor rendimiento. Sin embargo, llevará tiempo.
Ventajas de estimar en horas
Si bien algunos equipos ágiles usan puntos de historia, muchos aún tienen que cambiar las horas de trabajo. Hay razones importantes para ello. Vamos a cubrirlos también.
1. Las horas son un modelo familiar
La innovación es genial, pero lleva tiempo. Tanto los desarrolladores como sus clientes conocen bien la estimación de horas de trabajo. Para muchos, la idea es "si no está roto, no lo arregles". Mientras el sistema ofrezca estimaciones viables, ¿por qué cambiar a otra cosa?
Es posible que la diferencia en la precisión de las estimaciones no sea lo suficientemente grande para que algunos desarrolladores cambien la forma en que hacen las cosas.
2. Los clientes suelen pagar por horas
Esto necesita poca elaboración. Para los clientes, la estimación basada en la complejidad puede resultar confusa . Además, si para el cliente el presupuesto es más importante que la fecha de lanzamiento (que suele serlo), los puntos de la historia no serán relevantes para él.
3. Un desarrollador puede realizar la estimación basada en horas
Para equipos pequeños o autónomos, los puntos de la historia son en gran parte inútiles, ya que requieren múltiples puntos de vista. Sin ninguna referencia, estimar en puntos de la historia es una molestia innecesaria.
Las horas, por otro lado, ofrecen al desarrollador que trabaja en el proyecto una forma de hacer estimaciones bastante precisas .
Lo mismo ocurre con la velocidad del equipo. Cuando los equipos cambian cada vez, como sucede con los autónomos o la subcontratación parcial, el seguimiento de la velocidad tiene muy poco sentido. La estimación basada en horas es la mejor opción aquí.
Desventajas de estimar en horas
Estas son las razones por las que los equipos podrían decidir dejar de usar las horas como modelo de estimación.
1. Ser el único responsable de la estimación supone mucha presión.
Por un lado, estimar sus propios requisitos de tiempo puede ser más fácil, ya que solo depende de usted mismo.
Por otro lado, si no cumple con sus estimaciones, es un gran golpe. Más aún si el equipo que está esperando para comenzar sus tareas depende de que usted complete las suyas.
Además, el estrés causado por la presión para cumplir lo que usted prometió puede interrumpir una tarea que, de otro modo, se desarrollaría correctamente.
2. La estimación de un desarrollador es siempre menos precisa que la de un equipo.
Las estimaciones individuales son subjetivas y están vinculadas a las circunstancias emocionales y psicológicas del estimador.
Algunos desarrolladores tienden a sobreestimarse a sí mismos y establecen marcos de tiempo que luego luchan por mantener. Esto no solo interrumpe el desarrollo (y genera costos adicionales en el equipo si hay multas), sino que también causa estrés y agotamiento en los desarrolladores .
Otros subestiman sus propias habilidades , lo que prolonga el desarrollo más de lo necesario objetivamente. La inseguridad y el hábito de pensar demasiado, verificar y volver a verificar el trabajo a menudo llevan a que las fechas límite de desarrollo se establezcan en fechas posteriores, y las tareas rara vez se completan antes de las fechas límite . La información del equipo permite una estimación que es más objetiva.
3. Cuanto mayor sea la tarea, más difícil será estimar en horas
Esto también se correlaciona con situaciones de no desarrollo. Es fácil decir cuánto tiempo tomará leer un folleto universitario de tres páginas, pero es más difícil estimar cuánto tiempo tomará terminar Guerra y paz .
Lo mismo ocurre con el desarrollo. Las tareas pequeñas son fáciles de estimar para desarrolladores con algo de experiencia. Sin embargo, cuanto más grande es la tarea, más cosas, que suceden tanto dentro como fuera del proyecto, pueden afectar el desarrollo. Las estimaciones basadas en horas no ofrecen los márgenes que tienen los puntos de historia, lo que hace que las estimaciones sean más aproximadas.
4. Poca flexibilidad
La estimación basada en horas se basa en el desarrollador. Si un miembro del equipo que trabaja en el producto cambia a mitad del proyecto, el equipo deberá volver a calcular cada historia de usuario afectada aún en desarrollo o programada para sprints futuros. Eso puede suponer mucho trabajo, dependiendo de la etapa en la que se encuentre el proyecto y la diferencia de habilidades entre el desarrollador original y el nuevo. La estimación del tiempo basada en horas es bastante rígida.
¿Puedes convertir los puntos de la historia en horas?
Los clientes pueden pedirle a un equipo que haga estimaciones en puntos de historia para convertir el mapeo de puntos de historia ágil en horas . La mayoría de las personas que no están familiarizadas con las últimas tendencias de desarrollo de software no sabrán qué hacer con los puntos de la historia.
Sin embargo, cuando un cliente pregunta a cuántas horas equivale un punto de la historia, es imposible responder definitivamente. Uno de los componentes clave de la estimación basada en la complejidad es el esfuerzo invertido para completar la historia. Pero el esfuerzo no se traduce directamente en tiempo invertido . Las horas abordan la incertidumbre de una manera más vaga que los puntos de la historia.
Cuanto más compleja es la tarea, más incertidumbre y riesgos existen. Convertir los puntos de la historia en horas de una manera sencilla y depender únicamente de la velocidad no tiene en cuenta muchos de esos riesgos, ya que la estimación basada en horas es más aproximada que los puntos de la historia cuando se trata de riesgos e incertidumbres.
Hasta cierto punto, el uso de la secuencia de Fibonacci al asignar puntos de historia explicará la incertidumbre en los tiempos de desarrollo, pero no permite exactamente una conversión directa.
He aquí un ejemplo.
Una historia de un punto de una historia (historia base) tarda, digamos, dos horas en completarse.
Una historia de 13 pisos puede llevar 26 horas en el mejor de los casos , si nada sale mal o se interpone en el camino. Por ejemplo, si la API utilizada se ajusta perfectamente, de un extremo a otro. Pero si no es así, la historia podría requerir entre, digamos, 30 y 50 horas, dependiendo de cuántos desajustes haya. Nadie puede decir de antemano cómo irá si el desarrollador aún no ha trabajado con la API en cuestión.
Entonces, al traducir los puntos de la historia a horas, debe haber un multiplicador de crecimiento exponencial para abordar la incertidumbre. Y ese multiplicador diferirá de un equipo a otro.
Puntos de historia frente a horas: ¿Qué elegir para el desarrollo de software?
Como puede ver, tanto los puntos de la historia como las horas son opciones válidas para que un desarrollador estime proyectos.
Con todo, diríamos que más empresas de productos eligen puntos de historia, mientras que los subcontratistas tienden a inclinarse por las horas.
Las empresas que trabajan con un modelo de precio fijo suelen optar por una estimación basada en horas. Los equipos que prefieren Scrum a menudo eligen puntos de historia, ya que literalmente nacieron de Scrum y son nativos de esta metodología.
En nuestros años de experiencia, hemos llegado a verlo de esta manera:
Si estimar con precisión la fecha de lanzamiento es más importante que ajustarse al presupuesto, busque puntos de historia.
Si el presupuesto es más importante que una fecha de lanzamiento precisa, considere las horas.
O, lo mejor de todo, combine los dos.
Los puntos de historia son muy convenientes para los equipos de desarrollo que trabajan en proyectos largos donde la velocidad de monitoreo marcará la diferencia.
Las horas son importantes para los clientes que se preocupan por ajustarse a su presupuesto. Además, las horas tienen más sentido para proyectos a corto plazo.
El sistema basado en la complejidad es todavía bastante joven, al igual que el propio Scrum, y aún se está desarrollando. La combinación de ambos modelos de estimación y la elaboración de un sistema para cambiar rápidamente cada punto de la historia a horas proporciona los beneficios de ambos modelos y minimiza los inconvenientes.