¿Por qué los horarios de software son tan difíciles de definir?

Parece que, en mi experiencia, hacer que los ingenieros estimen y determinen con precisión las tareas a realizar es como tirar de los dientes. En lugar de dar una estimación de botín de 2-3 semanas o 3-6 meses ... ¿cuál es la forma más sencilla de definir programas de software para que no sean tan dolorosos de definir? Por ejemplo, el cliente A quiere una función antes del 01/02/2011. ¿Cómo se programa el tiempo para implementar esta función sabiendo que se pueden necesitar otras correcciones de errores en el camino y tomar tiempo de ingeniería adicional?

Si está elaborando un proyecto casi idéntico a otros proyectos que ha realizado, utilizando herramientas conocidas y un equipo familiar, y se le dan 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) de los proyectos de software.

A menudo se nos pide que calculemos 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. Por lo tanto, es natural que la estimación sea más difícil.

Según mi experiencia personal, es exactamente lo contrario de lo que dijo Pemdas : con la práctica, he entendido 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 intentaba 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 al cliente 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 a medida que otras personas trabajan, 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 que, después de días de trabajo, entendí que mi primer enfoque era incorrecto y que hay una manera mejor e inteligente de hacer las cosas.

2. Algunos problemas pueden surgir . Por ejemplo, si, para comenzar su trabajo, debe instalar en su máquina un servidor SQL sofisticado 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, cree que lo son. 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 acabas de terminar la parte en cuestión , y realmente no entienden por qué estás solicitando dos semanas más y $ 2000 para hacer un pequeño cambio, porque no ven que este pequeño cambio requiere cambiar otras cosas, que requieren cambiar otras, etc.

5. No puedes estimar tu motivación . Hay días en que puedes trabajar durante horas y tener éxito. Hay semanas en las 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 vuelven realmente malas cuando su 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 llegó tarde.

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

¿Qué puedes hacer?

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

2. Se claro . Si confía en un diseñador, otro desarrollador, etc., dígalo. En lugar de decir "entregaré el producto en tres meses", diga "entregaré 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 difícilmente se entregará a tiempo.

4. Corta tu horario . Entregar partes de un gran proyecto a tiempo es más fácil.

5. Nunca dé una estimación cuando use un producto que no conoce bien o, especialmente, cuando trabajará en el código fuente de otra persona: nunca podrá predecir qué tan malo puede ser el código fuente y cuánto tiempo pasará entendiéndolo y pegándolo en The Daily WTF.

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

No puede responder eso hasta que lo haya visto para ver numerosas cosas como:

• ¿Está en un idioma 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)
• ¿Alguna de las pistas requiere conocimiento adicional antes de que podamos entenderlo?
• ¿Hay algún lugar en el rompecabezas que, según tu conocimiento, requiera trabajo adicional?

Como generalmente hay varias cosas nuevas en un proyecto (de lo contrario, no sería un proyecto), no puede saber cuánto tiempo tomarán resolver hasta que las haya analizado con mucho cuidado. Tal vez incluso resuelva más o menos o ellos, y entonces todavía no está seguro de que no haya una sorpresa o dos en los que no haya pensado en ellos.

También existe una fuerte presión para hacerlo de la manera más económica posible, por lo tanto, lo más rápido posible y la culpa de una estimación demasiado baja no recae en la presión del gerente del proyecto, sino en el desarrollador que da la estimación. El desarrollador no necesita muchas iteraciones para comprender esto, y aprender a estar MUY cansado de dar números absolutos.

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

Por supuesto, puede estimar cuánto tiempo + -2 minutos le tomará desde su hogar al trabajo. Usted sabe cómo conducir un automóvil, puede evaluar el tráfico y algunos otros factores externos.

Dime cuánto tiempo te llevará conducir de Londres a Barcelona. Sin herramientas avanzadas de planificación GPS, por supuesto. Usando el método antiguo como lo hacemos en la estimación de software. Estimación empírica y predicciones .

En software, es peor:

1. Las estimaciones a menudo se convierten en un compromiso , por lo que nuestro juicio se modifica.
2. Puede haber grandes diferencias entre la estimación de Bob y Karl para la misma tarea.
3. Las incertidumbres son muy comunes: cuánto de nosotros quedamos atrapados en un error estúpido o un bloqueo del disco duro destruyendo cualquier estimación buena aparente.
4. Por lo general, nos olvidamos de todas las otras tareas que no sean la programación, incluidas reuniones, llamadas telefónicas, ayudar a nuestro colega, etc.
5. El cerebro humano es limitado . No ha sido 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, le recomiendo técnicas de estimación avanzadas como Planning Poker (descargo de responsabilidad: este es uno de mi sitio web) y el Desarrollo iterativo con cálculo de velocidad .

• Los dos primeros problemas se abordan con Planning Poker. Las estimaciones son colectivas y el equipo las posee en lugar de los individuos.
• El último tercio se aborda con Velocity y Iterative Development. Al conocer su velocidad (el factor que se aplicará a sus estimaciones basadas en el historial), puede planificar emisiones con más confianza. El desarrollo iterativo, cuando está bien hecho, trae las características más importantes a la cima y lo ayuda a entregar valor a sus usuarios temprano.

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

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

El único momento en que no hay una tecnología desconocida o una característica comercial 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 o nueva tecnología o ambas. Nuevo significa nuevo - desconocido - impredecible.

Debido a que el desarrollo de software debe involucrar novedad, el esfuerzo de desarrollo no puede predecirse.

Honestamente, creo que solo se necesita práctica. Si finalmente escribe suficiente código, debería ser "bastante" preciso. Mi primer jefe creía que esta habilidad era lo suficientemente importante como para que me pidiera que practicara informalmente esto en cada característica / proyecto que implementé. Después de cada proyecto revisamos las estimaciones e intentamos averiguar dónde me equivoqué. Finalmente, te acostumbras.

Nunca es fácil Solo trata de mejorar en eso.

Una ventaja de dividir su código entregable en partes más pequeñas es que los clientes entiendan qué esperar y cuándo esperarlo. Ahora tiene algún tipo de línea de base para que puedan 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. Corren un riesgo en la gravedad de los errores que ocurren y cuánto tiempo pueden pasar sin que se solucionen. Cuando surge algo importante, vuelve al cliente y lo obliga a tomar una decisión. ¿Arreglo el error o hago la fecha límite para la nueva función? Dales suficiente información para tomar una decisión informada.

Esperemos que tenga suficiente historial de trabajo conjunto y que se haya 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 aprovecha su falta de conocimiento.

Porque hacemos el horario demasiado temprano. Vea el artículo de Construx sobre cómo hacer un borrador preliminar, luego mejor uno más adelante. 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, menos las triviales, son estimadas por más de una persona (dos en nuestro caso)
2. Dividimos la tarea en una tarea más pequeña. Cuantas más tareas tenga, más probabilidades tendrá de que su estimación sea buena: ley de grandes números si no recuerdo mal del boo
3. estimamos el peor, el mejor y el más probable escenario. A veces, cada uno de nosotros estima esos escenarios de árbol de manera totalmente diferente. Eso significa que tenemos que hablar y generalmente resulta que uno de nosotros no entendió la tarea. Si esa persona estimara la tarea sola, se consideraría incorrecta.
4. Ponemos 3 números del punto anterior en la ecuación y recibimos la estimación (excell) k

Una vez finalizada la tarea de trabajo y nuestra estimación era incorrecta, intentamos encontrar los motivos. E incorporamos este conocimiento en el próximo proceso de estimación. Hasta ahora, este es el mejor proceso que he utilizado 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 proyectos en los que factura por hora en comparación con una tarifa fija / fija.

Por lo general, trato de planificar mi horario para que consista esencialmente en un montón de Sprints SCRUM (ya sea que use SCRUM o no). Desde el principio, cuando hago el cronograma, determino cuál será la duración de cada sprint y cuáles serán las características del proyecto. Por lo general, hay algunas características que deben hacerse primero, así que trato de dar una mejor estimación (que no debe confundirse 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 al 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 para esto es que hago todo esto transparente para el cliente por adelantado para 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 algo de amortiguación en el cronograma / finanzas, ya que la mayoría de ellos saben que las estimaciones de SW tienden a ser menos concretas. También son conscientes de que si no necesitamos el último sprint más o menos, 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 durante la ejecución del proyecto, cada cliente con el que he hecho esto ha quedado extremadamente satisfecho.

Además de todas las cosas nombradas, veo estas dos cosas como algunos de los mayores problemas. Primero, estima la fecha final en función de que cada devloper esté disponible durante las 8 horas diarias 5 días a la semana. Esto es incorrecto y prácticamente garantizará al 100% que se pierda la fecha de finalización en cualquier proyecto que no sea trivial. Las personas se toman un tiempo libre, asisten a reuniones de la compañía (o no basadas en proyectos), pelean con RR.

Los siguientes desarrolladores se olvidan notablemente de estimar todas las tareas que no son de desarrollo, como reuniones y correos electrónicos relacionados con el proyecto, implementación, soporte de control de calidad, soporte de UAT, pruebas de unidades de escritura, investigación, documentación, etc. Una vez que agregamos este tipo de tarea a nuestra hoja de cálculo de estimación, nuestro Las estimaciones mejoraron mucho.

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

1. No siempre tratar de predecir cuando otras personas terminarán su trabajo si quieres pasar a depender de ello. Habla solo por ti mismo.
2. Primero analice la tarea, luego estime. Al analizar me refiero al menos a escribir (¡y no tratar de mantener todo en tu cabeza!) Una lista de subtareas con una estimación para cada una de ellas.
3. Si una tarea es lo suficientemente compleja, calcule el tiempo para dicho análisis en sí. Deje 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 lleva tiempo hacer una estimación razonable y solo dígales algo como "Voy a nombrar una fecha mañana a las 11:00 cuando termine de analizar la tarea". Sé que algunos clientes / gerentes pueden presionar mucho, pero no pasarán. ¡Pon tu cara ocupada y reclama tu tiempo!
5. Pida un poco más de tiempo del que cree que necesitará porque probablemente olvidó agregar un tiempo de pausa para el café (y otras distribuciones) 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 realmente 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 pared. Acabo de formularlos ahora, pero provienen de mi experiencia (por lo que puede no funcionar para usted).

La única forma confiable de programar el desarrollo de software que se me ocurre (pero en realidad no lo he probado) es la programación basada en evidencia, que es básicamente el método de Monte Carlo utilizado para contar la probabilidad de una fecha de envío basada en registros históricos sobre tareas que usted ' He logrado antes. Se siente bien porque no intenta usar ninguna métrica que no sea el tiempo estimado y el tiempo real. Sin embargo, se requiere mucha experiencia para dividir las tareas grandes en otras más pequeñas de antemano y debe tener un gran conjunto de datos históricos para que funcione con la suficiente precisión.

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

1. Las estimaciones a menudo se convierten en plazos.

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

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

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

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