Cómo mantener la gestión fuera de nuestro proceso de desarrollo

Soy ingeniero de software en un equipo de desarrollo de software. Los últimos 3 años trabajamos para un cliente interno en un nuevo producto. Ahora que este producto está terminado, vamos a trabajar en nuevas características importantes para los productos existentes. Para una característica particular, la administración del producto ha adivinado que lleva 150 horas desarrollarla. Junto con nuestro gerente de proyecto, hemos creado un plan muy detallado y llegamos a un esfuerzo de 300 horas. Ayer discutimos esto y piensan que hemos sobreestimado las cosas.

En nuestra planificación estimamos las horas para escribir pruebas unitarias, su idea es volcarlas para ahorrar tiempo. La decisión aún no se ha tomado y defenderé esta planificación y las pruebas unitarias si es necesario. Pero lo que realmente no me gusta aquí es que la administración interfiere con nuestro proceso de desarrollo. ¿Cómo los mantengo fuera de nuestro proceso de desarrollo? ¿Y qué argumentos podría usar para mantener la unidad de prueba en su lugar (además de la calidad y el ahorro de tiempo a largo plazo)?

Como nota al margen, nuestra empresa tiene 3 equipos de ingeniería y el equipo en el que estoy entrega su software a tiempo (más o menos un 10% de margen). Mientras que los otros equipos siempre entregan tarde, principalmente debido a la subestimación en la planificación. Solo planean la codificación y no la gestión, las pruebas y el manejo a su alrededor.

Primero, déjame decirte que simpatizo completamente con tu posición. Puede ser frustrante cuando tiene una falta de comprensión o una falla de comunicación entre las diferentes partes del negocio. Dicho esto, no creo que debas tratar de mantenerlos fuera. En su lugar, debe mostrarles los números sobre por qué es una buena idea. ¿Qué hechos tiene que justifiquen las pruebas unitarias que valen la pena? Si no tiene ninguno, entonces debe comenzar a reunir esas cifras o mostrar algunas investigaciones para respaldar sus afirmaciones.

Yo mismo tuve que lidiar con escenarios similares y respondí esta pregunta sobre un tema similar . También escribí en un blog sobre cómo lo traté aquí:

http://practicalagility.com/show-them-the-numbers-its-results-that-matter/

En caso de que no tenga ganas de buscar enlaces, repetiré mi resumen de la pregunta relacionada:

Para resumir, comparé nuestras horas estimadas con las horas reales del proyecto y luego comparé nuestra tasa de defectos con la tasa de defectos de otros equipos. En nuestro caso, estos números se compararon favorablemente y no hubo más preocupaciones.

Mi conclusión basada en esta experiencia es:

... la mejor manera de convencer a cualquiera de que su enfoque para hacer algo es práctico y pragmático, es hacerlo y compararlo con otros enfoques. A la gente no le importa el dogma, o por qué crees que algo debería ser la mejor manera. Solo mostrando a las personas los números y midiendo la efectividad de su enfoque puede realmente demostrar que sus prácticas son efectivas.

Si su equipo de administración no acepta invertir lo que ven como 150 horas adicionales en pruebas unitarias, tal vez pueda convencerlos de que inviertan en un área pequeña del producto (o incluso acuerden aprovechar las horas para proporcionar algunos datos). ) Realice pruebas unitarias en esa área del producto y luego recopile datos sobre las tasas de defectos en esa área del producto y el costo para encontrar y corregir esos defectos en comparación con las tasas de defectos en otras áreas del producto. Con suerte, reunirá algunos datos para respaldar su caso y esto no será un problema para su próximo proyecto.

La regla número uno a seguir, independientemente del método que utilice, es que

1. Los desarrolladores deberían tener el derecho de estimar su propio trabajo.
2. Las partes interesadas deberían tener derecho a priorizar entre ese trabajo.

La estimación y la priorización son dos fuerzas que funcionan muy bien juntas una vez que ambas partes aceptan sus propias responsabilidades. Entonces, en lugar de perder el tiempo discutiendo, acuerde esto y respete que ambas partes harán su trabajo lo mejor que puedan.

Puede señalar que las pruebas unitarias ahorran tiempo, por lo que si las abandona, la estimación llega a 500 horas.

Infórmeles sobre la deuda técnica y el valor de las pruebas unitarias.

Mira esta publicación de algunas buenas ideas sobre deuda técnica. Siguiendo esa publicación, puede acceder al siguiente pdf

Me gusta esta publicación sobre el valor de las pruebas unitarias (probablemente hay más para encontrar)

La esperanza no es sacarlos de su proceso de desarrollo, sino involucrarlos y comprometerlos de la manera correcta.

En mi humilde opinión, debe escribir su planificación original, agregar los capítulos 1 y 2 (no en un apéndice) en los que explica la deuda técnica y el valor de las pruebas unitarias. Dales alternativas:

• menos horas (no las 150 completas, eso suena ridículo) donde cada cambio (durante la fase de desarrollo y durante el mantenimiento) tomará en promedio:
  • pequeño 4 horas
  • medio 16 horas
  • grandes 40 horas
• sus horas estimadas donde cada cambio (fase de desarrollo y durante el mantenimiento) en promedio tomará:
  • pequeño 2 horas
  • medio 8 horas
  • grandes 20 horas

(Las horas son solo indicativas. Estás mucho mejor equipado para dar estimaciones adecuadas).

No olvide incluir su historial de entregas a tiempo y dentro del presupuesto.

Escríbelo y discute esto con ellos. Es posible que tengan algunos puntos valiosos en características que realmente no necesitan en este momento o alguna deuda técnica que están dispuestos a asumir para entregar a tiempo. Solo asegúrate de que estas sean elecciones conscientes.

Espero que esto ayude y buena suerte.

En primer lugar, no divida las "pruebas unitarias de escritura" como una tarea separada para estimar, programar y potencialmente cortar. Sus estimaciones deben estar en el nivel de función "Implementar el XYZ - 18 horas". Esas 18 horas deben incluir lo que sea necesario en su proceso para que esa función se "HAGA", incluidas las "pruebas unitarias de escritura".

Esa es una buena manera de sacar el desarrollo no técnico "de su proceso de desarrollo". ¡No incluya su proceso de desarrollo en la lista de tareas o el cronograma del proyecto que les da!

En segundo lugar, parece que su equipo ya les está entregando buenos productos y a tiempo, pero que otros equipos no lo están. Tal vez este grupo de gestión esté acostumbrado a tener que administrar a esos equipos. Aproveche sus puntos fuertes: ofrézcales mostrarles actualizaciones semanales o quincenales con funciones de trabajo, y le quitarán la espalda sobre el "proceso de desarrollo".

Una vez estuve en una situación en la que estaba trabajando con una base de código en muy buen estado; se necesitaba una nueva función desafiante en un período de tiempo muy corto, y logré entregar la función en muy poco tiempo. En ese momento, la base del código estaba en un estado mucho peor. Así que la función se entregó, pero mi trabajo no se realizó: tuve que volver a poner todo en un estado igualmente bueno.

Le expliqué al gerente dos niveles más arriba así: es como hacer un trabajo de pintura en su hogar. Si todas las herramientas están allí donde pertenecen y en buen estado, todos los cepillos limpios, etc., puede hacer un trabajo de pintura muy rápidamente. Pero luego tiene que pasar el tiempo para volver a poner todas sus herramientas en orden. Si no lo hace, su próximo trabajo de pintura llevará mucho más tiempo. En realidad, no recordará dónde están sus herramientas, sus pinceles ya no se pueden recuperar y le cuesta mucho más tiempo y dinero extra como si hubiera realizado el trabajo de limpieza de inmediato.

Y lo mismo en mi trabajo de programación: al limpiar, obtengo la base de código en un estado en el que puedo entregar algo muy rápido nuevamente la próxima vez que sea necesario. Si no, la próxima vez tomará mucho más tiempo.

No puede mantenerlos fuera de su proceso por completo, después de todo, pagan su salario y utilizarán su producto (si no directamente, presumiblemente alguien de su empresa es el usuario final).

Los gerentes que acusan a los desarrolladores de sobreestimar el tiempo es un escenario muy común en mi experiencia, y si no se trata puede conducir a una carrera armamentista bastante tonta donde las próximas estimaciones se duplican porque saben que los jefes los reducirán a la mitad, lo saben. los cuadriculan, así que los cuadruplicas, etc., etc. Debes evitar este círculo vicioso si es posible.

Suponiendo que no hay una razón para la fecha límite, sugiero dos cosas.

1. Ofrezca un plan detallado de lo que cree que puede hacer en 150 horas, respetando su enfoque actual de trabajo de alta calidad. Enumere exactamente lo que se puede entregar en este período de tiempo. La respuesta de KeesDijk tiene algunos enlaces muy buenos sobre planificación en un nivel de grano fino.
2. Continúe con el mismo estilo de planificación detallada para cubrir todas las funciones y mostrar cómo tomará 300 horas (o lo que sea que salga a la luz).

Luego, trabaje e informe regularmente sobre el progreso y, si es posible, tenga algunos resultados a intervalos regulares. Esto debería dar confianza a la gerencia en sus habilidades de estimación y capacidad de entrega.

Pídales la base de sus estimaciones. Es justo discutir las discrepancias. Volcar las pruebas unitarias es una economía falsa, lo que no gasta escribiendo pruebas unitarias que gastará en un depurador más tarde (y más tiempo). Esencialmente, ha documentado el hecho de que planea probar el trabajo que completa. Te están diciendo que no pruebes en absoluto . Ya sea que realice pruebas utilizando pruebas unitarias o pruebas ad hoc mientras desarrolla el proyecto, aún debe tener en cuenta ese tiempo. Al eliminar el tiempo asignado para las pruebas unitarias, también se elimina el tiempo asignado para las pruebas ad hoc.

En pocas palabras: atenerse a sus armas con su estimación. Su historial muestra que sabe de lo que está hablando, y puede dar una respuesta razonable en cuanto a la base de su estimación (suposiciones, expectativas, rendimiento pasado, etc.). Parece que su alta gerencia no tiene la visibilidad que necesita para crear una estimación razonable. ¿Asumen días de 8 horas sin interrupciones para las reuniones? ¿Están presupuestando para la prueba del sistema en sus estimaciones? ¿Cómo se les ocurrió el número que es la mitad del tuyo, teniendo en cuenta tu historial?

Yo estimaría que tomará 300 horas y si presupuestan 150 les darán la opción, ya sea un trabajo urgente o tarde para ser entregados. Cuando el proyecto esté completo y sea como lo predice, puede decirles que es lo que solicitó.

¿Qué haría Wally?

Hay varias formas de interpretar lo que la gerencia le pide, una es que no quieren que entregue a tiempo.

Parece absurdo? Sí, pero ¿cómo pueden saber si no estás sobreestimando? No cumpla con sus plazos de entrega (si es necesario), si se resbala y entrega algo a tiempo accidentalmente, asegúrese de parecer realmente cansado para no dar la impresión de que fue un paseo por el parque.

Estás en apuros. Si te apegas a tus armas y quieres seguir con las pruebas unitarias, y quieres reclamar las 300 horas, harás enemigos.

Si reduce a 150 horas y realiza pruebas de unidad de mandril, puede entregar un producto con errores más rápido, pero causará dolor en el futuro, con un costo de mantenimiento más alto.

De cualquier manera, pierdes.

O eso parece.

Verás, no estás ejecutando un laboratorio de ciencias en una universidad. Usted está brindando un servicio comercial a una unidad comercial en una compañía que brinda servicios a clientes en un ecosistema de compañías. Es posible que su empresa necesite su producto para comenzar a ofrecer servicios más rápidos y mejores a sus clientes, y así aumentar los ingresos necesarios.

Verá, lo que necesita es un análisis de ROI, y no tiene todos los datos para hacer ese análisis. Solo tiene parte del costo (no conoce los números de nómina de todos) y ciertamente no tiene las partes de ingresos, especialmente no las proyecciones de ingresos.

Su gerencia, créalo o no, es experta en hacer las proyecciones de ROI (eso es lo que enseñan en la escuela de negocios) y puede haber ejecutado múltiples proyecciones de ROI y llegar a "si actuamos ahora, haremos mucho más dinero incluso con pagar el triple por el mantenimiento del software del que se quejan los bozos en TI ".

Por lo tanto, si desea ejecutar la articulación, comience su propia empresa. Verás, no es tan fácil.

En otras palabras: haz lo que te dicen. Si la gerencia sabe lo que está haciendo, saldrás adelante. Si no, estás sin trabajo, pruebas unitarias o no.

¿Qué ROI preguntas? Retorno de la inversión. Sin embargo, es un mal nombre. Debe ser el retorno de la inversión oportuna (ROTI), porque el tiempo lo es todo en la inversión.