Estimar los costos de tiempo en el código base heredado

Lee "Clean Coder" de Bob Martin (y "Clean Code" mientras estás en ello). Lo siguiente es de la memoria pero fuertemente sugiero que compre su propia copia.

Lo que debe hacer es un promedio ponderado de tres puntos. Usted hace tres estimaciones para cada trabajo:

• el mejor escenario posible: suponiendo que todo salga bien (a)
• el peor de los casos: asumir que todo va mal (b)
• la suposición real: lo que crees que probablemente tomará (c)

Su estimación es entonces (a + b + 2c) / 4

• No, no será preciso. Hay mejores formas de estimar, pero este método es rápido, fácil de entender y mitiga el optimismo al hacer que consideres el peor de los casos.
• Sí, tendrá que explicarle a su gerente que no está familiarizado con el código y que es demasiado imprevisible para usted realizar estimaciones firmes y precisas sin tener que pasar mucho tiempo investigando el código cada vez para mejorar la estimación (oferta para haga esto pero diga que necesita n días solo para dar una estimación firme de cuántos días más tomará). Si usted es un "JuniorDev", esto debería ser aceptable para un gerente razonable.
• También debe explicarle a su gerente que sus estimaciones se promedian, en función del mejor de los casos, el peor de los casos y el caso probable, y proporcionarles sus cifras, que también les dan las barras de error.
• NO negocie con una estimación, si su gerente intenta usar el mejor de los casos para cada estimación (son un tonto, pero me he encontrado con algo así) y luego lo acosaré o lo motivaré para que intente cumplir con la fecha límite. Bueno, van a estar decepcionados a veces. Continúe explicando las razones detrás de las estimaciones (mejor caso, peor caso y caso probable) y continúe acercándose al promedio ponderado la mayoría de las veces y debería estar bien. Además, para sus propios fines, mantenga una hoja de cálculo de sus estimaciones y agregue sus datos reales cuando haya terminado. Eso debería darle una mejor idea de cómo ajustar sus estimaciones.

Editar:

Mis suposiciones cuando respondí esto:

1. El OP es un Desarrollador Junior (basado en el nombre de usuario elegido). Por lo tanto, cualquier consejo dado no es desde la perspectiva de un Gerente de Proyecto o Líder de Equipo, de quien se espera que pueda realizar estimaciones más sofisticadas dependiendo de la madurez del entorno de desarrollo.
2. El administrador del proyecto ha creado un plan de proyecto que consiste en un número bastante grande de tareas planificadas que demoran varios meses en entregarse.
3. Se le pide a la OP que proporcione una cantidad de estimaciones para las tareas a las que les asigna su Administrador de Proyectos que desea un número razonablemente exacto (no una curva de probabilidad :)) para incluirlo en el plan del proyecto y utilizarlo para hacer un seguimiento del progreso .
4. OP no tiene semanas para producir cada estimación y se ha quemado antes al dar estimaciones demasiado optimistas y desea un método más preciso que meter un dedo en el aire y decir "2 semanas, a menos que el código sea particularmente arcano en el que caso 2 meses o más ".

El promedio ponderado de tres puntos funciona bien en este caso. Es rápido, comprensible para lo que no es técnico y, según varias estimaciones, debería alcanzar una precisión aproximada. Especialmente si OP toma mi consejo acerca de mantener registros de estimaciones y datos reales. Cuando sepa qué aspecto tienen los "peores casos" y "los mejores casos" del mundo real, puede incluir los datos reales en sus estimaciones futuras e incluso ajustar las estimaciones para su gerente de proyectos si el caso más desfavorable es peor de lo que pensaba.

Hagamos un ejemplo trabajado:

  

• El mejor de los casos, desde la experiencia, lo más rápido que he hecho es realmente sencillo, fue una semana de principio a fin (5 días)
  
• En el peor de los casos, por experiencia, hubo un tiempo en el que hubo enlaces en todas partes y me tomó 6 semanas (30 días)
  
• Estimación real, probablemente me llevará 2 semanas (10 días)
  

5 + 30 + 2x10 = 55

     

55/4 = 13.75 que es lo que le dices a tu PM. Tal vez redondas hasta 14   dias. Con el tiempo, (por ejemplo, diez tareas), debería promediarse.

No tengas miedo de ajustar la fórmula. Tal vez la mitad de las tareas terminan en pesadillas y solo el diez por ciento son fáciles; así que haces la estimación a / 10 + b / 2 + 2c / 5. Aprende de tu experiencia.

Tenga en cuenta que no estoy haciendo ninguna suposición sobre la calidad del PM. Un mal primer ministro dará una breve estimación a la junta del proyecto para obtener la aprobación y luego acosará al equipo del proyecto para tratar de alcanzar el plazo poco realista que se han comprometido. La única defensa es mantener un registro para que te vean dando tus estimaciones y acercándote a ellas.

Este podría ser un buen momento para introducir un enfoque casi ágil. Si en lugar de estimar en términos de horas / días, asignó una escala de tipo fibonacci & asignó a cada tarea un valor en función de su tamaño:

• 0 - instantáneo
• 0.5 - victoria rápida
• 1 - cambio simple
• 2 - un par de cambios simples
• 3 - más desafiante
• 5 - requerirá un poco de reflexión sobre
• 8 - una cantidad significativa de trabajo
• 13: una gran parte del trabajo que probablemente deba descomponerse
• 20: una gran parte del trabajo que definitivamente necesita ser dividido

Luego, una vez que estimaste un montón de tareas como esta, trabajas en ellas. En un entorno ágil, desarrollas "velocidad", que es una medida de la cantidad de puntos que obtienes en, por ejemplo, una semana. Una vez que haya realizado algunas semanas de prueba y aprendizaje (puede vender esto a su gerente como parte del proceso: "Necesitaré algunas semanas de prueba y aprender a comprender el proceso de estimación"). tenga más confianza en la cantidad de puntos que puede obtener cada semana & por lo tanto, puede traducir su estimación de puntos más fácilmente en tiempo.

enlace

enlace

Esto no es realmente ágil, ya que no implicaría las ceremonias, pero el OP me da la idea de que él está solo. Esperemos que este enfoque pueda dar algunas estimaciones más confiables.

Lo primero que debe hacer es comenzar a recopilar datos sobre el tiempo que le lleva hacer todo esto en este momento. Cuantos más datos tengas sobre el rendimiento de tu equipo, mejor. Va a estar en todos los ámbitos, pero no te preocupes por eso ahora. Es la verdad y necesitas mostrarle a tu jefe la realidad.

Entonces vas a comprar unos cuantos libros.

1. Estimación del software: desmitificando el arte negro por Steve McConnell
2. Trabajando eficazmente con el código heredado por Michael Feathers

El libro de McConnell le dirá que comience a recopilar datos y luego explique cómo usarlos para obtener estimaciones más precisas. ¡Siempre da una estimación de 3 puntos! Siempre. Asegúrese de resaltar las partes del libro que hablan sobre cómo la mala calidad del código hará volar sus estimaciones. Muéstraselos a tu jefe.

Explique que si las estimaciones precisas son importantes para la empresa, deberá comenzar a aplicar las cosas que está aprendiendo del libro de Feather. Si desea ir de manera rápida, fluida y predecible, deberá comenzar a refactorizar el código y colocarlo en un arnés de prueba. He estado justo donde estás. El tiempo de desarrollo es completamente impredecible porque no tienes idea de lo que podrías romper, ¿verdad? ... Sí. Mételo en un arnés de prueba. Un servidor de CI para ejecutar esas pruebas tampoco podría hacer daño.

Por último, explícale a tu jefe que las cosas seguirán siendo un poco impredecibles por un tiempo. Probablemente algunos años, pero ese desarrollo se hará más fácil a diario y las estimaciones serán más precisas a medida que tenga más datos y el código mejore. Esta es una inversión a largo plazo para la empresa. Pasé por esto recientemente, tardé casi 2 años en ser predecible en su mayoría.

Sé que hablé más acerca de mejorar el código que estimar, pero la verdad es que sus estimaciones serán pésimas hasta que pueda domar la base del código heredado. Mientras tanto, use el rendimiento histórico para medir el tiempo que tomará. A medida que pase el tiempo, querrá tener en cuenta si ya incorporó o no el código a sus especificaciones.

  

Ahora, mi jefe me está preguntando correctamente cuánto tiempo tomaría escribir la función X en la nueva arquitectura. Pero estoy teniendo dificultades para llegar a una estimación realista; muchas veces subestimo la tarea debido a razones que mencioné anteriormente y me avergüenzo porque no puedo terminar a tiempo.

Tal vez esté pensando en el cuadro de enviar una estimación de una . Tengo que trabajar en código heredado, y cuando hago una estimación más formal, por lo general hago dos o tres :

1. Estimación primaria: asumiendo que tengo que dedicar algo de tiempo a cavar pero la arquitectura permite los cambios que queremos
2. Estimación angelical: asume que todo es transparente / fácil de encontrar y solo tengo que hacer cambios menores (este es el que a veces omito ... especialmente si sé que solo hay demonios en un código base en particular) )
3. Estimación abisal: supone que la estructura fundamental del código heredado es incompatible con la función solicitada y haré una refactorización importante para que las cosas funcionen

Las tres estimaciones tienen en cuenta lo difícil que es la característica en sí misma, cualquier experiencia que haya tenido con esa base de código general y mi intuición sobre el cambio (que he encontrado can ser bastante exacto)

Después de que se publiquen estas estimaciones, mantendré informado a mi gerente sobre cuál parece que estamos tratando. Si resulta que estamos viendo una característica abismal, entonces es posible que tengamos que sacrificarla, ha sucedido. Si su jefe no puede aceptar que hay características abismales para un trozo dado de código heredado, entonces les deseo buena suerte, ya que tendrán una vida muy difícil y frustrante.

Cuando me he enfrentado a este tipo de problema, me he basado en dar rangos a mis estimaciones. Me he salido con la suya al decirle a mis jefes "es difícil hacer buenas estimaciones sobre esta base de código. Si lo pides, será una estimación muy amplia". He dado "3 días a 3 años" como un estimado una vez. No hace falta decir que no fue una estimación popular, pero es lo que di.

La clave para esto es un acuerdo en el que actualizaré mis estimaciones a medida que avanza el trabajo. Entonces, si me dicen "Implementar XYZ, ¿cuánto tiempo tomará?" Mi respuesta podría ser "en algún lugar entre un día y 4 meses. Sin embargo, si me permite ver el código durante unas horas, puedo reducir la incertidumbre en esa ventana". Luego miro el código y vuelvo con "2 a 4 semanas". Todavía no es una ventana ideal, pero al menos es algo que se puede administrar.

Hay algunas claves para esto:

• Convenza al jefe de que estas estimaciones se tratan mejor como una conversación porque usted aprenderá más acerca de cómo se ve la tarea mientras la trabaja. Esta es una oportunidad para que su jefe tenga información que no tendrían si solo pidieran un presupuesto único.
• Ofrezca opciones sobre cómo avanzar en qué velocidad de desarrollo del código comercial en comparación con las estimaciones mejoradas. Dales un botón extra que puedan girar. A veces los jefes saben que una tarea solo necesita hacerse, y solo necesitan una estimación aproximada. Otras veces están ejecutando los pros y los contras de una tarea, y la capacidad de refinar las estimaciones es valiosa.
• Si es posible, también ofreceré bonos de sinergia. A menudo hay mejoras arquitectónicas que tendrían beneficios para muchas tareas. Si tengo 10 tareas, las cuales toman "1-2 meses ahora, pero me tomaría 2 semanas con la actualización X", es más fácil vender las 20 semanas que podría tomar la actualización X.

Si tengo un jefe que no se siente cómodo recibiendo un rango que se actualiza a medida que avanzo, les daré un número único y mi metodología. Mi metodología es una combinación de una regla de oro que me han contado como un desarrollador joven, y ley de Hofstader .

  

Estime cuánto tiempo cree que debería durar la tarea, luego cuadruplique ese número y délo como su estimación.

     

y

     

Ley de Hofstadter: "Siempre lleva más tiempo de lo esperado, incluso si se tiene en cuenta la Ley de Hofstadter".

  

La cosa sensata podría parecer realmente entrar en el código, tenga en cuenta cada   bifurcar y llamar a otras funciones y luego estimar el costo del tiempo.   Pero realmente hay una diferencia minúscula entre documentar lo viejo   código y en realidad escribir la nueva versión.

Esta es la solución a su problema. No puedes estimar si no tienes requisitos. Dígale a su jefe que tendrá que hacer esto antes de que pueda comenzar a codificar. Después de algunas funciones y módulos, puede descubrir que todos han sido codificados de forma consistente (en este caso, de manera deficiente), por lo que tiene una línea de base para determinar estimaciones futuras. Solo asegúrese de ajustar su estimación si descubre que la codificación empeora.

Me doy cuenta de que su jefe desea una estimación, pero sin saber cómo se utiliza esta información, no sabemos qué tan exactos deben ser sus estimaciones. Ten una conversación con él y descúbrelo. Si solo necesita un número para darle a su jefe, puede inflar las estimaciones ligeramente y proporcionar un número. Para los clientes que esperan pagar por su código hasta que se haga esto, asegúrese de averiguar si las fechas de vencimiento de la línea dura generarán ingresos significativos.

En una situación como esta, no creo que sea posible dar buenas estimaciones. El problema básico es que, a menudo, una gran parte de la tarea consiste en averiguar exactamente qué se necesita hacer.

Yo manejo casos como este dando una estimación basada en lo que parece implicar, pero con la sorpresa de que es probable que haya sorpresas. Si bien no he tenido que lidiar mucho con el código legado, he tenido algunas sorpresas muy desagradables con el aporte, he visto algunas horas convertirse en un par de semanas y una vez en esto es imposible (Después de Me di cuenta de que no tenía suficientes datos en un caso determinado, volviendo a la mesa de dibujo. Afortunadamente, mi jefe entiende cuando doy esas estimaciones.

Bueno, la estimación es una habilidad que algunas personas nunca aprenden bien. No te hace inútil como desarrollador, incluso si no puedes hacer buenas estimaciones. Tal vez los compañeros de equipo o la administración llenen los vacíos. Soy terrible en eso, todavía a la mayoría de los equipos les gustaba trabajar conmigo. Mantenga la calma, forme un equipo y continúe refactorizando.

La deuda técnica le brinda pequeños y agradables desafíos, pero recuerde que una empresa / equipo que terminó generando deuda continuará produciendo deuda a menos que haya cambios en el espíritu del equipo o en la administración. El código simplemente refleja los problemas sociales, así que concéntrese en los problemas reales.

Utilizamos una heurística para estimar características en un proyecto de zonas industriales abandonadas: estimamos cuánto tiempo habría sido implementar esa característica en un proyecto de zonas verdes sin nada ya implementado. Luego multiplicamos esa estimación por 2 para tratar de limpiar los residuos que ya existían.

Este factor depende de la cantidad de acoplamiento y el tamaño del código general, pero si realiza algunas funciones de esta manera, puede interpolar ese factor en función de la evidencia real.

Creo que deberías sentarte con tu jefe, mirarlo directamente a los ojos y decir:

  

'¡Escucha jefe! Solo estamos refactorizando aquí. No hay novedades   Funcionalidad para entregar, y no hay clientes esperando eso.   funcionalidad; por lo que no debería haber ningún plazo. Esto va a   tómese el tiempo que sea necesario, debe decidir si tenemos que hacerlo   o no. '

Use gesticulación asertiva firme como señalar y siéntese en su silla.

Alternativamente, podrías inventar algunos números para hacerlo feliz. Pero seamos realistas, hasta que haya terminado la mitad del trabajo, sus estimaciones serán bastante inexactas.