¿Por qué las programaciones de software son tan difíciles de definir?

Si está desarrollando un proyecto casi idéntico a otros proyectos que ha realizado, utilizando herramientas familiares y un equipo familiar, y se le otorgan requisitos firmes y escritos, entonces debería ser posible hacer una buena estimación.

Estas son las condiciones que los pintores, instaladores de alfombras, paisajistas, etc., experimentan regularmente. Pero no es una buena opción para muchos (o la mayoría) proyectos de software.

A menudo se nos pide que estimemos proyectos que usan nuevas herramientas, tecnologías, donde los requisitos están cambiando, etc. Esto es más extrapolación a lo desconocido que interpolación sobre nuestras experiencias pasadas. Entonces, es natural que la estimación sea más difícil.

Según mi experiencia personal, es exactamente lo contrario a lo que dijo Pemdas : con la práctica, acabo de entender que es totalmente imposible estimar cuánto tiempo requerirá una tarea. Al comienzo de mi carrera en el desarrollo de software, a menudo daba estimaciones como "45 días", "cinco semanas", etc., y luego me esforcé por terminar a tiempo. Unos años después, comencé a dar estimaciones menos precisas como "aproximadamente un mes", "cinco a siete semanas", etc. En realidad, trato de no dar ninguna estimación, o pedirle a la clienta que haga su propia estimación. o fecha límite o doy una estimación lo más aproximada posible.

¿Por qué es tan difícil tener una estimación? Porque es casi imposible saber cómo se escribirá todo el código fuente antes de escribirlo realmente, y porque su trabajo depende de cosas aleatorias como el trabajo de otras personas, su motivación, etc. Aquí hay una lista más detallada de las posibles razones:

1. No es fácil saber qué se requiere exactamente para hacer un producto, y especialmente cómo hacerlo . Muy a menudo, comencé algunas partes de una aplicación, después de días de trabajo, entendí que mi primer enfoque era incorrecto y que hay una forma mejor y más inteligente de hacer las cosas.

2. Pueden surgir algunos problemas . Por ejemplo, si, para comenzar su trabajo, debe instalar en su máquina un elegante servidor SQL y la instalación falla y el soporte es inexistente, puede pasar semanas resolviendo este problema.

3. Los requisitos a menudo no son lo suficientemente claros , pero después de leerlos al principio, crees que sí. A veces puedes entender que significa "A" y, después de comenzar a implementarlos, notarías que tal vez significan "B".

4. A los clientes les gusta cambiar sus requisitos exactamente cuando acaba de terminar la parte correspondiente , y realmente no entienden por qué solicita dos semanas más y $ 2000 para hacer una cambio pequeño , porque no ven que este cambio pequeño requiere cambiar otras cosas, lo que requiere cambiar otros, etc.

5. No puedes estimar tu motivación . Hay días en los que puedes trabajar por horas y tener éxito. Hay semanas en que, después de escribir diez líneas de código, cambia a Programmers StackExchange y pasa horas leyendo y respondiendo preguntas.

6. Las cosas se ponen realmente mal cuando tu estimación depende de otras personas . Por ejemplo, en un proyecto de 2 meses tuve que esperar a que un diseñador hiciera su trabajo para terminar el mío. Este diseñador tardó 3 meses antes de entregar un pedazo de basura inutilizable. Por supuesto, el proyecto se retrasó.

7. Su estimación también depende de su cliente . Tuve clientes que pasaron semanas antes de contestar su correo. Realmente puede afectar su programación cuando debe esperar su respuesta (por ejemplo, si les pide que precisen un requisito).

¿Qué puedes hacer?

1. Da un horario más amplio . Si cree que puede hacer el trabajo en dos semanas, diga que lo entregará en un mes.

2. Sea claro . Si confías en un diseñador, otro desarrollador, etc., dilo. En lugar de decir "Enviaré el producto en tres meses", diga "Enviaré el producto en dos meses después de que el diseñador me entregue los archivos PSD".

3. Explique que si los requisitos cambian todos los días, el proyecto apenas se entregará a tiempo.

4. Rebana tu horario . Es más fácil entregar partes de un proyecto grande a tiempo.

5. Nunca dé una estimación cuando use un producto que no conozca bien o, especialmente, cuando trabaje con un código fuente de otra persona: nunca puede predecir qué tan malo puede ser el código fuente y cómo pasará mucho tiempo entendiéndolo y copiándolo en The Daily WTF.

Una pregunta muy similar es "¿Cuánto tiempo llevará resolver este crucigrama?"

No puedes responder eso hasta que lo hayas visto para ver muchas cosas como:

• ¿Está en un lenguaje familiar? (Español versus Inglés versus Chino)
• ¿Es uno de los tipos que hemos resuelto antes? (Uno en una serie que se ejecuta en una revista, por ejemplo)
• ¿Alguno de los clientes potenciales requiere un conocimiento adicional antes de que podamos entenderlo?
• ¿Hay algún punto en el rompecabezas que, según tu conocimiento, requiera trabajo adicional?

Ya que generalmente hay varias cosas nuevas en un proyecto (de lo contrario no sería un proyecto), no se puede decir cuánto tiempo tomarán resolver hasta que hayas mirado con mucho cuidado. Tal vez incluso los resuelva más o menos, y entonces aún no está seguro de que no haya una o dos sorpresas en las que no haya pensado en ellas.

También existe una fuerte presión para hacerlo lo más barato posible, por lo tanto, lo más rápido posible y la culpa de una estimación demasiado baja no se debe a la presurización del gerente del proyecto, sino al desarrollador que da la estimación. El desarrollador no necesita muchas iteraciones para darse cuenta de esto, y aprender a estar MUY cansado de dar números absolutos.

  

La razón más obvia por la que sus ingenieros no pueden proporcionarle estimaciones precisas es que es imposible .

Por supuesto, puede estimar cuánto tiempo tardará en ir a trabajar desde su casa + -2 minutos. Sabe cómo conducir un automóvil, puede evaluar el tráfico y otros factores externos.

Dígame cuánto tiempo le tomará conducir de Londres a Barcelona. Sin ninguna herramienta avanzada de planificación de GPS, por supuesto. Utilizando el buen método antiguo como todavía lo hacemos en la estimación de software. Estimaciones y predicciones empíricas .

En software, es peor:

1. Las estimaciones a menudo se convierten en un compromiso , por lo que nuestro juicio se modifica.
2. Puede haber enormes diferencias entre la estimación de Bob y Karl para la misma tarea.
3. Las incertidumbres son muy comunes, ¿cuántos de nosotros nos quedamos atascados en un error estúpido o un fallo del disco duro que destruye cualquier buena estimación aparente?
4. Por lo general, nos olvidamos de todas las demás tareas que la programación, incluidas reuniones, llamadas telefónicas, ayuda a nuestros colegas, etc.
5. El cerebro humano es limitado . No se ha diseñado para estimar tareas de larga duración.

Es por eso que es imposible decirle a su cliente lo que podrá enviar para el 01/02/2011 con buena precisión, y olvidarse del 01/03/2011.

Para abordar todos esos problemas, te recomiendo técnicas avanzadas de estimación como Planning Poker (descargo de responsabilidad: este es uno de mi sitio web) y Desarrollo Iterativo con Velocity cálculo.

• Los dos primeros problemas se solucionan mediante Planning Poker. Las estimaciones son colectivas y el equipo las posee en lugar de las personas.
• Los últimos terceros problemas se solucionan utilizando Velocity y el desarrollo iterativo. Al conocer su velocidad (el factor a aplicar a sus estimaciones basadas en el historial), puede planificar lanzamientos con más confianza. El desarrollo iterativo, cuando está bien hecho, trae las funciones más importantes a la cima y lo ayuda a entregar valor a sus usuarios de manera temprana.

El desarrollo de software es, por definición, un acto de descubrimiento e invención. Siempre debe implicar algo desconocido.

La única vez que se conoce todo lo relacionado con el desarrollo de software es cuando el software está completo.

La única vez que no hay una tecnología o característica empresarial desconocida es cuando se trata de una solución completa y empaquetada lista para descargar.

La razón por la que escribimos un nuevo software es porque tenemos una nueva característica, una nueva tecnología o ambas. Nuevo significa nuevo, desconocido, impredecible.

Debido a que el desarrollo de software debe incluir la novedad, el esfuerzo de desarrollo no se puede predecir.

Honestamente, creo que solo se necesita práctica. Si escribes suficiente código, deberías ser "bastante" preciso. Mi primer jefe creía que esta habilidad era lo suficientemente importante, por lo que solicitó que practicara esto de manera informal en cada función / proyecto que implementé. Después de cada proyecto, revisamos las estimaciones e intentamos averiguar en qué me equivoqué. Con el tiempo, te entiendes.

Nunca es fácil. Solo intentas mejorar en ello.

Una ventaja de dividir su código de entrega en partes más pequeñas es que los clientes entienden qué esperar y cuándo esperar. Ahora tiene algún tipo de línea de base para usar como referencia.

Si tienen una definición estricta de una característica que necesitan en un momento definido, deben saber que se deben asignar recursos adicionales a esta solicitud. Se están arriesgando por la gravedad de los errores que ocurren y el tiempo que pueden pasar sin que se solucionen. Cuando surge algo importante, regresa al cliente y lo obliga a tomar una decisión. ¿Arreglo el error o hago la fecha límite en la nueva característica? Dales suficiente información para tomar una decisión informada.

Espero que tengas suficiente historial de trabajo en conjunto y te hayas establecido lo suficiente como para ser confiable. No puede esperar que comprendan completamente el proceso de desarrollo, pero puede hacerles sentir que está haciendo un esfuerzo honesto y no aprovechando su falta de conocimiento.

Porque hacemos el horario demasiado pronto. Consulte el artículo de Construx sobre cómo hacer una preliminar preliminar, luego una mejor. Además, si no realiza un seguimiento de cómo lo hizo en estimaciones anteriores, es difícil mejorar. FogBugz hace eso [un cliente de su libre, ningún otro conflicto de intereses].

He aprendido mucho de este libro:

Estimación de software: desmitificando el arte negro

En resumen, para obtener mejores resultados de estimación, hacemos esto:

1. todas las tareas, excepto las triviales, son estimadas por más de una persona (dos en nuestro caso)
2. dividimos tarea en tarea más pequeña. Cuantas más tareas tenga, más probable será que su estimación sea buena: ley de grandes números si recuerdo correctamente de la abucheos
3. estimamos el peor, el mejor y el más probable escenario. A veces, cada uno de nosotros estima esos escenarios de árboles de manera totalmente diferente. Eso significa que tenemos que hablar y generalmente resulta que uno de nosotros no entendió la tarea. Si esa persona hubiera estimado la tarea solo, se estimaría errónea.
4. ponemos 3 números del punto anterior en la ecuación y recibimos la estimación (sobresalir) k

Una vez finalizada la tarea de trabajo y nuestra estimación fue incorrecta, tratamos de encontrar razones por las que. E incorporamos este conocimiento en el próximo proceso de estimación. Hasta ahora, este es el mejor proceso que he usado para estimar tareas más grandes. Cuando digo tarea, me refiero a trabajos que duran entre 50 y 500 horas.

Nota: esto realmente solo se aplica a los proyectos en los que factura por hora en lugar de una tarifa fija / fija.

Por lo general, trato de planificar mi agenda de modo que consista esencialmente en un grupo de SCRUM Sprints (Ya sea utilizando SCRUM o no). Al momento de hacer el cronograma, determino cuál será la longitud de cada sprint y cuáles serán las características para el proyecto. Por lo general, hay algunas características que se deben hacer primero, así que trato de dar una mejor estimación (que no se confunda con optimista) para esas y cualquier característica que se encuentre hacia el final del proyecto tendrá estimaciones generalizadas. Después de asignar las características a los sprints, trato de agregar 1 a 2 sprints en el extremo final del proyecto para tener en cuenta las características que se deslizan hacia la derecha y las características que se pasaron por alto en la recopilación de requisitos original.

La clave de esto es que hago todo esto transparente para el cliente por adelantado, de modo que entiendan por qué los dos últimos sprints están vacíos o escasamente poblados. Al menos hasta este punto, a los clientes con los que he trabajado les ha gustado esto, ya que saben que hay un margen en el calendario / finanzas, ya que la mayoría de ellos saben que las estimaciones de SW tienden a ser menos que concretas. También son conscientes de que si no necesitamos el último sprint o más, entonces esas son horas que no facturamos. Con la transparencia en la forma en que se construye el cronograma y la retroalimentación regular sobre el progreso de la ejecución del proyecto, todos los clientes con los que he hecho esto han estado extremadamente satisfechos.

Además de todas las cosas nombradas, veo estas dos cosas como algunos de los mayores problemas. Primero, estimas la fecha final en base a cada devloper disponible para las 8 horas completas del día, 5 días a la semana. Esto es incorrecto y garantizará virtualmente el 100% que la fecha de finalización se pierde en cualquier proyecto que no sea trivial. Las personas se toman un descanso, asisten a reuniones de la compañía (o no basadas en proyectos), pelean con Recursos Humanos por reclamos de seguros de salud, toman descansos, etc. Nunca asuma más de 6 horas de disponibilidad por desarrollador por día.

A continuación, los devlopers notoriamente olvidan estimar todas las tareas de no desarrollo como reuniones y correos electrónicos relacionados con el proyecto, implementación, soporte de control de calidad, soporte UAT, pruebas de unidad de escritura, investigación, documentación, etc. Una vez que agregamos estos tipos de tareas a nuestra estimación hoja de cálculo, nuestras estimaciones han mejorado mucho.

Cuando se trata de la estimación de tiempo para tareas que pueden durar más de unas pocas horas, hago todo lo posible para usar estas reglas:

1. No alguna vez intente predecir cuándo otras personas terminarán su trabajo si usted depende de ello. Habla solo para ti.
2. Primero analice la tarea, luego estime. Al analizar me refiero al menos a anotar (¡y no tratar de mantener todo en tu cabeza!) Una lista de subtareas con estimación para cada una de ellas.
3. Si una tarea es lo suficientemente compleja, estime el tiempo para dicho análisis. Que la estimación sea un proceso separado. También puede asegurarse de que su jefe lo sepa.
4. No estimar bajo presión. Deje en claro que toma tiempo hacer una estimación razonable y solo dígales algo como "Mañana nombraré una fecha a las 11:00 cuando termine de analizar la tarea". Sé que algunos clientes / gerentes pueden presionar fuerte, pero no deben pasar. ¡Pon tu cara ocupada y reclama tu tiempo!
5. Pida un poco más de lo que piensa necesitará porque probablemente olvidó agregar un tiempo de descanso (y otras distracciones) en su estimación.
6. Para tareas grandes, pida aún más: probablemente habrá más de un descanso para tomar café.
7. Si realmente no puede estimar (la tarea es demasiado difícil / desconocida) o no está seguro, pídale ayuda a alguien capaz de realizar su análisis.

Probablemente haya más reglas que eso, pero en realidad no tengo un póster con estas reglas en mi muro. Los formulé ahora, pero provienen de mi experiencia (por lo que puede que no te funcione).

La única forma confiable de programar el desarrollo de software que se me ocurre (pero no lo he probado) es Programación basada en la evidencia , que es básicamente el método de Monte Carlo que se utiliza para contar la probabilidad de una fecha de envío en función de los registros históricos de las tareas que ha realizado anteriormente. Se siente bien porque no intenta usar ninguna métrica distinta del tiempo estimado y real. Sin embargo, se requiere mucha experiencia para dividir las tareas grandes en tareas más pequeñas de antemano y debe tener un gran conjunto de datos históricos para que funcione lo suficientemente preciso.

Hay "incógnitas conocidas" y "incógnitas desconocidas". :-)

1. Las estimaciones a menudo se convierten en fechas límite.

   • ¡Nadie quiere perderse una fecha límite y convertirse en titular!

2. Los requisitos cambian (a menudo de manera racional) y el programador no puede vetarlos.

3. El programador tiene / puede no tener control sobre factores como

   • Disponibilidad del código en el que depende.
   • Calidad del código del que depende
   • Arquitectura general y diseño del sistema
   • API para acceder a otras partes del sistema