Realización de estimaciones precisas de proyectos de software

estimación de proyectos de software

Pixabay

Introducción

La estimación es simplemente difícil. Desafortunadamente, también es muy necesario. Las empresas utilizan estimaciones para proyectar los cronogramas de lanzamiento, hacer compromisos con sus clientes, decidir si vale la pena implementar una función propuesta, rastrear la velocidad de los equipos y priorizar el trabajo de manera efectiva. Los ejecutivos a menudo quieren saber cuándo una función o entrega estará lista para la producción. Después de todo, el desarrollo de software no es una inversión trivial. Sin estimaciones, ¿cómo haría una evaluación el director del proyecto? Si los humanos pudieran predecir el futuro con precisión, la gente no ganaría en las carreras de caballos el 2% de las veces. La estimación es el gran enigma. Es fundamental y necesario que las empresas pidan a su gente que haga lo imposible: predecir el futuro.

Primero, repasemos algunos métodos de estimación populares (en caso de que se haya perdido parte de la emoción). Entonces podemos ver lo que esto significa para nosotros y nuestros proyectos.

El modelo de adivino

Este modelo casi no requiere esfuerzo para producir una estimación. Los estimadores piensan un poco sobre lo que se debe hacer para implementar y probar una característica, luego arrojan un número. Suena mucho como "… (pausa larga)… Ummmmm… 6 semanas". Entonces todos asienten y seguimos adelante. Podrían pasar bastante tiempo hablando de lo que saben de los requisitos (que probablemente no sea la imagen completa). Este análisis cuidadoso hace que su estimación se sienta más confiable. Al final del proyecto, siempre hay una justificación aceptada de por qué la estimación estaba tan lejos de la realidad. Siempre hay circunstancias imprevistas que pueden servir como chivo expiatorio. A menudo, a nadie se le ocurre que el modelo tiene graves defectos.

Entonces, ¿cómo podemos mejorar este proceso? ¡Lo sé! Podemos utilizar la técnica de descomposición (es decir, dividir y conquistar). Este enfoque asume que conoce el alcance completo de la función o proyecto en la interfaz. Cada característica se divide en trozos pequeños. Cada parte se estima (estilo adivino), luego los sumamos para obtener una estimación general de la característica / proyecto. Este es ciertamente un enfoque más complicado, pero parece mejor por dos razones:

• Las partes más pequeñas de trabajo tienden a ser más fáciles de estimar de manera confiable.
• Si bien todavía existe la posibilidad de error (+/- alguna cantidad), se supone que los errores se cancelarán entre sí cuando lo sume todo y obtendrá una estimación general más confiable.

El defecto fundamental de este enfoque es que los contribuyentes individuales (las personas que realmente hacen el trabajo) subestiman universalmente. Todavía son significativamente mejores que los que están arriba y alrededor de ellos, pero eso no es un listón alto. Este no parece ser el caso porque todos hemos visto casos en los que los desarrolladores se sorprendieron al lograr algo antes de lo previsto. Pero este es un único dato, no una tendencia. De hecho, la gente gana ocasionalmente en el casino; gaste dinero en un casino todos los días durante un año y tendrá menos dinero del que tenía al principio. Si realiza un seguimiento de las estimaciones frente a los datos reales durante un año o dos, descubrirá que las estimaciones no se ajustan a la realidad. Si bien muchos empresarios están absolutamente seguros de que los desarrolladores están acomodando perezosamente sus estimaciones y empleando el tiempo extra para "chapa de oro" o comprobar sus existencias,los datos muestran lo contrario. La estrategia de "cancelación" no funciona.

¿Y ahora que? Abandonemos el modelo de adivino y cambiemos a un enfoque basado en el tamaño. Resulta que, si bien los humanos somos bastante malos para estimar el tiempo de finalización, en realidad somos bastante buenos para decir qué tan grande es algo. Somos especialmente buenos en el tamaño comparativo ("es más grande que eso, pero más pequeño que eso de allí"). Si pensamos en términos de tamaño o complejidad en lugar de tiempo, nuestro cerebro lo procesa de manera más confiable. Luego, podemos tomar los valores de tamaño y calcular la cantidad real de horas para el proyecto en función de una ingeniosa fórmula mágica. Y ahí es cuando el popular modelo de puntos de función entra en escena (escenario a la izquierda).

Análisis de puntos de función (FPA)

Para el análisis de puntos de función, necesitamos identificar cinco tipos de cosas en nuestra aplicación: entradas externas, salidas externas, consultas externas, archivos de interfaz externa y archivos lógicos internos (no se preocupe demasiado por las definiciones; puede investigarlas más adelante). Cada ejemplo de esos (una función) tiene una complejidad asociada (baja, media o alta). Usamos la siguiente tabla para calcular cuántos puntos se asignan a cada función.

Ahora, si sumamos los puntos de todas nuestras funciones, podríamos obtener un número como 457 puntos de función para nuestro proyecto. Entonces solo necesitamos una fórmula para calcular la cantidad de horas… Según nuestro último proyecto, nuestra "tasa de entrega" fue de 15 puntos funcionales por persona por mes. Eso es aproximadamente 30 meses-persona de trabajo, lo que debería tomar un poco más de dos meses y medio para mi equipo de 12. ¡Ta-da!

Esto ciertamente es más complejo que nuestro modelo anterior. De hecho, hay que reconocer cuatro áreas clave de complejidad.

1. Los cinco tipos de componentes no son necesariamente intuitivos y es fácil olvidarse de poner algo en la lista o asignarlo al depósito equivocado.
2. La tabla utilizada para generar realmente los puntos de función contiene números mágicos que requerirían mucho esfuerzo para validar. ¿Están estos números calibrados correctamente para generar estimaciones confiables para mis equipos?
3. La tasa de entrega (una pieza crítica del rompecabezas) se calcula en función de la productividad de su equipo. ¿Con qué frecuencia debemos calcular un nuevo número? En realidad, hay muy poca orientación sobre esto.
4. ¿Qué constituye una complejidad baja, media o alta? ¿Cómo lo definimos para que todos lo entiendan? ¿No es fundamental hacerlo bien para la precisión de nuestros cálculos?

Hay varias partes móviles en este ejemplo muy simple, y ni siquiera hemos discutido modelos de complejidad más complicados y los otros datos que pueden entrar en juego (por ejemplo, tasa de costo, tasa de soporte, densidad de defectos, etc.). Más partes móviles significan más oportunidades de que ocurran errores. ¿Estamos haciendo la estimación demasiado complicada ahora? No estamos pagando a los desarrolladores para que dediquen mucho tiempo a la estimación. No puedo vender un presupuesto a mis clientes. Necesito un software que funcione. ¿Hay algo más ahí fuera?

Ir ágil

Ahora veamos brevemente el scrum ágil (lo suficiente para hacer una comparación). Como se mencionó anteriormente, los humanos son terribles para estimar el tiempo y son bastante buenos en el tamaño comparativo. Aquí hay un par de términos para entender:

• Un sprint: un período de tiempo encuadrado (generalmente dos semanas).

• Historia de usuario: un trabajo discreto, preferiblemente lo suficientemente pequeño como para que lo haga una persona en un sprint. Esto es lo que estamos estimando.

La estrategia más popular es utilizar una secuencia de fibonacci (0, 1, 2, 3, 5, 8, 13) para las estimaciones. No es lineal: a medida que sube la escala, el tamaño de los espacios aumenta. La clave es que las brechas deben ser lo suficientemente amplias como para que no haya razón para discutir sobre diferencias insignificantes. Una vez que superas el 3, la diferencia entre 4 y 5 o 7 y 8 es tan insignificante que no tiene sentido perder tiempo averiguando cuál es. Una secuencia de base 2 también funcionaría (0, 1, 2, 4, 8, 16, etc.).

“Pero espera, esto es solo un número. Qué significa eso? ¿Cuántas horas es un punto? " Los puntos no están destinados a correlacionarse directamente con las horas, porque si lo hicieran, los equipos estarían tentados a volver a estimar en horas y luego convertir eso en puntos de alguna manera. Como se discutió anteriormente, la precisión de nuestras estimaciones proviene del tamaño comparativo y no de estimar la cantidad de horas que tomará algo. Si le da al equipo la capacidad de pensar en términos de horas, está comprometiendo su capacidad para estimar con precisión.

Digamos que comenzó con un ejercicio de calibración. Lleve a su equipo a una sala y guíelos a través de una lista de 10-12 historias de usuarios. Elija uno que sea pequeño pero no el más pequeño y hágalo primero. Revíselo y anuncie que esta historia es un "3". No estás preguntando. Lo estás diciendo. Luego pase a la siguiente historia. "Si ese fue un 3, ¿cuál es este?" Ahora el equipo está evaluando historias en relación con otras historias. Eventualmente, tendrán una idea bastante clara de lo que constituye un "1", un "2", etc. No están estimando. El tiempo no importa. Están dimensionando historias, en relación con otras historias que ya tienen un número. Luego, puede poner historias de ejemplo para cada número en la secuencia en un documento llamado regla. Pueden usar eso como referencia si no están seguros de qué es un “5”.

Ahora aquí está la clave. La salsa mágica que hace que esto funcione es la "velocidad" (la cantidad de puntos que un equipo puede completar en un sprint promediado en 3-4 sprints). Digamos que su sprint es de dos semanas y su equipo de 8 personas tiene una velocidad promedio de 35 puntos. Obtendrá 35 puntos en 640 horas de trabajo (8 x 80 horas). Si nos damos cuenta de que una función va a tomar alrededor de 100 puntos de trabajo de principio a fin, entonces sé que son aproximadamente 6 semanas de trabajo y ~ 1900 horas. El equipo se vuelve muy bueno para dimensionar historias de manera constante, y usted aprovecha eso para hacer la planificación de su proyecto. Este cálculo funciona porque la duración es constante de un sprint a otro.

Para hacer una planificación de alto nivel a largo plazo, puede pedirles a sus clientes potenciales que desglosen las características de alto nivel en historias provisionales de una sola línea y les asignen puntos. Se perderá cierto grado de precisión, pero está aprovechando el modelo que ya comprenden. Una ruta más precisa sería el tamaño relativo a nivel de función. "Esta función es más grande que la función de 40 puntos, más pequeña que la función de 120 puntos de allí y un poco más grande que la función de 65 puntos que acabamos de hacer". Las historias se agrupan en "épicas". Si cada función es épica, al final sabrá cuántos puntos se necesitaron para completar esa función. Mantenga un historial de eso y podrá usarlo para la planificación de su lanzamiento.

Conclusión

Actualmente se utilizan muchas metodologías. Cada uno tiene pros y contras. De alguna manera, necesitamos descubrir cómo maximizar la precisión de nuestras estimaciones para que podamos tomar buenas decisiones. Eso no significa que nuestras estimaciones tengan que ser precisas. Solo necesitan ser lo suficientemente precisos para que sean útiles. Si no comprende la estimación, puede asumir que las estimaciones no fueron precisas porque el equipo no hizo un buen trabajo. No estimaron correctamente o no ejecutaron correctamente el proyecto. Las palizas continuarán hasta que mejoren las estimaciones. Pero las estimaciones nunca deben utilizarse como compromiso. Es una mejor suposición basada en la información limitada que tenemos hoy. Cuando aparece nueva información, tenemos que permitir que se revisen las estimaciones. Cualquier otra cosa es esperar lo imposible, que es un problema de liderazgo (no del equipo).

El enfoque de Scrum es mucho más simple de lo que vemos en el análisis de puntos de función. Y diría que es mucho más confiable que las tablas mágicas con números mágicos. Obtiene el máximo rendimiento por el dinero (esfuerzo mínimo con un grado de precisión razonablemente alto). Desde la perspectiva del esfuerzo, no crea un proceso pesado para que los equipos lo comprendan y utilicen. La pieza de estimación ágil puede suceder muy rápidamente una vez que todos comprenden los detalles del trabajo que se está estimando. Ciertamente es mejor que sacar números de la nada. Aprovechar la velocidad hace algo muy importante: aporta datos históricos al cálculo. En cada sprint, recalcula su velocidad. Esto es fundamental, porque con el tiempo el rendimiento cambia. Los equipos que usan FPA pueden derivar su tasa de entrega de su proyecto anterior,que en algunos casos fue hace varios meses. Probablemente ha cambiado mucho desde entonces. Mi sugerencia es que explore Agile y realmente se esfuerce por comprender los puntos y la velocidad de la historia. No confíe en estimar en horas solo porque eso es lo que entiende. Creo que te lo agradecerás más tarde.

Encuesta rápida