Estimación de costos de tiempo en código base heredado

Recientemente comencé a trabajar en un proyecto donde una aplicación monolítica muy antigua se está migrando a una arquitectura basada en microservicios.

La base de código heredada es muy desordenada ('código de espagueti') y, a menudo, una función aparentemente simple (p. Ej., Denominada "multiplyValueByTen") luego se revela como "miles de líneas de código de validación que involucran 10 tablas en 3 esquemas diferentes".

Ahora mi jefe (correctamente) me pide que calcule cuánto tiempo tomaría escribir la característica X en la nueva arquitectura. Pero tengo dificultades para llegar a una estimación realista; a menudo subestimo enormemente la tarea debido a las razones que he mencionado anteriormente y me avergüenzo porque no puedo terminar a tiempo.

Lo sensato puede parecer que realmente se mete en el código, anota cada rama y llamadas a otras funciones y luego estima el costo del tiempo. Pero realmente hay una diferencia minúscula entre documentar el código antiguo y escribir la nueva versión.

¿Cómo debería abordar un escenario como este?

Si bien entiendo perfectamente cómo funciona la refactorización de código heredado, mi pregunta no es sobre "¿cómo refactorizar / reescribir?" pero sobre dar una respuesta realista a "¿cuánto tiempo llevaría refactorizar / reescribir la parte X?"

Lea el "Codificador limpio" de Bob Martin (y el "Código limpio" mientras lo hace). El siguiente es de la memoria pero fuertemente sugieren comprar su propia copia.

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

• el mejor de los casos: suponiendo que todo salga bien (a)
• el peor de los casos, suponiendo que todo salga 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á exacto. Hay mejores formas de estimar, pero este método es rápido, fácil de entender y mitiga el optimismo al hacerle considerar el peor de los casos.
• Sí, tendrá que explicarle a su gerente que no está familiarizado con el código y que es demasiado impredecible que pueda hacer estimaciones firmes y precisas sin pasar mucho tiempo investigando el código cada vez para mejorar la estimación (ofrezca hacer esto, pero digamos que necesita n días solo para dar una estimación firme de cuántos días más tardará). 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, según el mejor de los casos, el peor de los casos y el caso probable, y proporcionarle sus cifras, lo que también les proporciona las barras de error.
• NO negocie una estimación: si su gerente intenta utilizar el mejor caso para cada estimación (son tontos, pero he conocido a algunos así) y luego lo intimidan / motivan para que intente cumplir con la fecha límite, bueno, ellos Te decepcionará a veces. Siga explicando la razón detrás de las estimaciones (el mejor caso, el peor caso y el caso probable) y siga 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 brindado no es desde la perspectiva de un Gerente de Proyecto o Líder de Equipo que se espera que pueda realizar estimaciones más sofisticadas dependiendo de la madurez del entorno de desarrollo.
2. El Gerente de Proyecto ha creado un plan de Proyecto que consiste en una cantidad bastante grande de tareas planeadas para demorar varios meses en completarse.
3. Se le pide al OP que proporcione una serie de estimaciones para las tareas que les asigna su Gerente de Proyecto, que desea un número razonablemente preciso (no una curva de probabilidad :)) para alimentar el plan del proyecto y usarlo para rastrear el progreso.
4. OP no tiene semanas para producir cada estimación y se ha quemado antes al dar estimaciones demasiado optimistas y quiere 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 cuyo caso 2 meses o más".

El promedio ponderado de tres puntos funciona bien en este caso. Es rápido, comprensible para los no técnicos y, en varias estimaciones, debería promediar a una precisión cercana. Especialmente si OP toma mi consejo sobre cómo mantener registros de estimaciones y datos reales. Cuando sepa cómo se ven el "peor caso" y el "mejor caso" del mundo real, puede alimentar los datos reales en sus estimaciones futuras e incluso ajustar las estimaciones para su gerente de proyecto si el peor de los casos es peor de lo que pensaba.

Hagamos un ejemplo trabajado:

• El mejor de los casos, según la experiencia, lo más rápido que he hecho fue una semana de principio a fin (5 días)
• En el peor de los casos, por experiencia, hubo un momento en que había enlaces en todas partes y me llevó 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 redondeas hasta 14 días. Con el tiempo (por ejemplo, diez tareas), debería promediar.

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; entonces haces el estmate a / 10 + b / 2 + 2c / 5. Aprende de tu experiencia.

Tenga en cuenta que no estoy haciendo ninguna suposición acerca de la calidad del PM. Un PM malo le dará una pequeña estimación a la junta del proyecto para obtener la aprobación y luego intimidará al equipo del proyecto para tratar de alcanzar el plazo irreal al que se han comprometido. La única defensa es mantener un registro para que pueda verse dando sus estimaciones y acercándose 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 de Fibonacci y le dio un valor a cada tarea 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 desglosarse
• 20 - una gran cantidad de trabajo que definitivamente debe desglosarse

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 cuántos puntos logras, por ejemplo, en una semana. Una vez que haya realizado algunas semanas de prueba y aprendizaje (puede vender esto a su gerente como parte del proceso: "Necesitaré unas semanas de prueba y aprender a comprender el proceso de estimación") estará tiene más confianza en cuántos puntos puede superar cada semana y, por lo tanto, puede traducir su estimación de puntos más fácilmente en el tiempo.

https://pm.stackexchange.com/questions/4251/why-would-teams-use-the-fibonacci-sequence-for-story-points

https://stackoverflow.com/questions/9362286/why-is-the-fibonacci-series-used-in-agile-planning-poker

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 cuánto tiempo le lleva hacer algo en este momento. Cuantos más datos tenga sobre el rendimiento de su equipo, mejor. Va a estar en todos lados, pero no te preocupes por eso ahora. Es la verdad y debes mostrarle a tu jefe la realidad.

Entonces vas a comprar algunos libros.

1. Estimación de software: desmitificando el arte negro por Steve McConnell
2. Trabajando efectivamente con Legacy Code por Michael Feathers

El libro de McConnell le dirá que comience a recopilar datos y luego le explicará cómo usarlo 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 afectará sus estimaciones. Muéstraselos a tu jefe.

Explique que si las estimaciones precisas son importantes para la empresa, deberá comenzar a aplicar lo que está aprendiendo del libro de Feather. Si desea ir de manera rápida, fluida y previsible, deberá comenzar a refactorizar el código y ponerlo 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 dañar.

Por último, explique a su jefe que las cosas seguirán siendo un poco impredecibles por un tiempo. Probablemente algunos años, pero ese desarrollo será 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 casi predecible.

Sé que hablé más sobre mejorar el código que sobre la estimación, pero la dura realidad es que sus estimaciones serán pésimas hasta que pueda domesticar la base de código heredada. Mientras tanto, use el rendimiento histórico para medir cuánto tiempo llevará. A medida que pase el tiempo, tendrá que tener en cuenta si ya ha obtenido el código según las especificaciones en sus estimaciones.

Ahora mi jefe me está pidiendo una estimación sobre cuánto tiempo tomaría escribir la característica X en la nueva arquitectura. Pero tengo dificultades para llegar a una estimación realista; muchas veces subestimo la tarea debido a las razones que he mencionado anteriormente y me avergüenzo porque no puedo terminar a tiempo.

Quizás esté pensando en el cuadro de presentar una estimación. Tengo que trabajar en código heredado, y cuando hago una estimación más formal, generalmente hago dos o tres :

1. Estimación primaria: suponiendo que tengo que pasar un tiempo cavando 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 omito a veces ... especialmente si sé que solo hay demonios en una base de código particular)
3. Estimación abisal: supone que la estructura fundamental del código heredado es incompatible con la función solicitada y tendré que realizar 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 puede ser bastante preciso)

Después de que se publiquen estas estimaciones, mantengo a mi gerente actualizado con el que parece que estamos tratando. Si resulta que estamos viendo una característica abisal, entonces tendremos que sacrificarla, ya sucedió. Si su jefe no puede aceptar que existan funciones abisales para un fragmento de código heredado, 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 en mis estimaciones. Me he librado de decirles a mis jefes que "es difícil hacer buenas estimaciones extravagantes en esta base de código. Si piden una, será una estimación muy amplia". Le di "3 días a 3 años" como estimación una vez. No hace falta decir que no era una estimación popular, pero es lo que di.

La clave de esto es un acuerdo de que actualizaré mis estimaciones a medida que avance el trabajo. Entonces, si me dicen "Implemente XYZ, ¿cuánto tiempo llevará?" mi respuesta podría ser "en algún lugar entre un día y 4 meses. Sin embargo, si me permite mirar 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:

• Convencer al jefe de que estas estimaciones están mejor tratados como una conversación porque usted va a aprender más acerca de lo que la tarea parece que mientras trabaja. Esta es una oportunidad para que su jefe tenga información que no tendrían si solo pidieran una sola estimación.
• Ofrezca opciones sobre cómo avanzar en la velocidad de desarrollo del código comercial frente a la mejora de las estimaciones. Dales una perilla extra que puedan girar. A veces, los jefes saben que una tarea solo debe 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, todas las cuales toman "1-2 meses ahora, pero tomarían 2 semanas con la actualización X", es más fácil vender las 20 semanas que podría tomar para la actualización X.

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

Estima cuánto tiempo crees que debería tomar la tarea, luego cuadruplica ese número y dalo como tu estimación.

y

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

Lo sensato puede parecer que realmente se mete en el código, anota cada rama y llamadas a otras funciones y luego estima el costo del tiempo. Pero realmente hay una diferencia minúscula entre documentar el código antiguo y escribir la nueva versión.

Esta es la solución a tu problema. No puede estimar si no tiene requisitos. Dígale a su jefe que tendrá que hacer esto antes de comenzar a codificar. Después de algunas funciones y módulos, puede descubrir que todos han sido codificados de manera consistente (en este caso mal), 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 quiere una estimación, pero sin saber cómo se utiliza esta información, no sabemos cuán exactas deben ser sus estimaciones. Conversa con él y descúbrelo. Si solo necesita un número para darle a su jefe, puede inflar ligeramente las estimaciones y proporcionar un número. Para los clientes que esperan pagar 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 hacerlo es descubrir exactamente lo que hay que hacer.

Manejo casos como este dando una estimación basada en lo que parece implicar, pero con el cavet que es probable que haya sorpresas. Si bien no he tenido que lidiar con mucho en el camino del código heredado, he tenido algunas sorpresas muy desagradables relacionadas con la entrada: he visto que algunas horas se convierten en un par de semanas y una vez en esto es imposible (después excavación considerable Me di cuenta de que no tenía suficientes datos en un caso determinado, de vuelta al tablero de dibujo.) Afortunadamente, mi jefe entiende cuando doy tales estimaciones.

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

La deuda técnica le ofrece pequeños desafíos, pero recuerde que una compañía / equipo que terminó produciendo deuda continuará produciendo deuda a menos que haya cambios en el espíritu de equipo o la administración. El código solo refleja los problemas sociales, así que concéntrate en los problemas reales.

Utilizamos una heurística para estimar características en un proyecto brownfield: estimamos cuánto tiempo habría sido implementar esa característica en un proyecto greenfield sin nada implementado. Luego multiplicamos esa estimación por 2 para lidiar con la limpieza de los desechos que ya existían.

Este factor depende de la cantidad de acoplamiento y del tamaño general del código, 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 decirle:

'¡Escucha jefe! Solo estamos refactorizando aquí. No hay una nueva funcionalidad para entregar, y no hay clientes esperando esa funcionalidad; así que no debería haber plazos. Esto va a tomar tanto tiempo como sea necesario, debes decidir si tenemos que hacerlo o no ”.

Use una gesticulación firme y firme como señalar y sentarse en su silla.

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