¿Cuál es el mejor proceso para estimar el presupuesto de un proyecto de desarrollo de software de tamaño fijo de manera efectiva (rápida y precisa)?

Gran pregunta, incierta, pero dilema tradicional. Existen varios modelos y técnicas para estimar un proyecto de software. Algunos se basan en el historial de proyectos pasados, algunos en puntos de función, pantallas, complejidad de la base de datos y otros parámetros que impulsan el esfuerzo de desarrollo de software. NO DESEA hacer esto RÁPIDO, pero entiendo la necesidad de responder a su cliente (potencial).

Busque SLIM, PRECIO, @Risk, CASA y / o WIKI o las herramientas de estimación de software de Google “. PERO … Observo que usted dice” tamaño fijo “. Ahí es donde generalmente comienzan todos los problemas, y una gran razón por la cual los contratistas tienden a sobreestimar un esfuerzo propuesto: el cliente cambiará sus requisitos en algún lugar durante el compromiso, sin importar cuánto prometan ahora. Su negocio u otros aspectos de su universo cambiarán, por lo que deberán cambiar. Si su estimación es también PRECIO FIJO, deberá averiguar cómo controlar los cambios de requisitos que el cliente intentará realizar. Comparto historias sobre este tema en mi blog en Federal Technology Systems and Challenges

Si el proyecto es grande, desde mi punto de vista, ninguna estimación realmente se ajustará a la verdad. El problema es que los viejos conceptos (por ejemplo, el modelo en cascada) esperan que los proyectos tomen un intervalo de tiempo predefinido, pero estos intervalos de tiempo son casi imposibles de predecir. Como programador, tendría que planificar toda la aplicación y todas y cada una de las clases / métodos necesarios. pero como cada parte del código se está desarrollando y reemplazando por el tiempo (refactorizado), es difícil estimar cuándo algo está listo.

Sin embargo, me gustó el concepto scrum. aquí se mide la “velocidad” de los equipos (algún tipo de velocidad de desarrollo). La idea es que el desarrollador divida partes del desarrollo en un conjunto de tareas y cada tarea obtenga puntos dados por el equipo de programación. dentro de un período de tiempo específico (llamado sprint), usted mide cuántos puntos alcanza el equipo. y al evaluar el proyecto del hoyo, puede estimar la duración total. pero como se mencionó, en realidad no tiene sentido estimar un proyecto de pozo, ya que siempre habrá tareas que se agregarán, ya que algo cambió o no se predijo. Es mejor decirle a un cliente que el proyecto es un proceso en desarrollo. es mejor crear un “producto mínimo viable” y extenderlo. entonces el cliente tiene algo con lo que puede trabajar y obtiene mejoras con el tiempo

¡Bienvenidos!

El mejor proceso para hacer la estimación es una metodología ágil, cuando el primer paso es una definición de características y todas estas características deben ser conceptos de alto nivel, pero desde cada concepto puede comenzar a dividirlo en un paso más pequeño. Es una muy buena pregunta, y nosotros con mi equipo lo discutimos hace unos días, así que me animé a escribir un artículo para mi blog. Y aquí está. Que tengas una buena lectura!

Escríbeme tu comentario 🙂