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

12

Soy un 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 las nuevas características principales para los productos existentes. Para una característica particular, la gestión de productos ha adivinado que se demora 150 horas en desarrollarse. 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 deshacerse de ellas para ahorrar tiempo. La decisión aún no se ha tomado y defenderé esta planificación y las pruebas de la unidad si es necesario. Pero lo que realmente no me gusta aquí es que la administración está interfiriendo con nuestro proceso de desarrollo. ¿Cómo los mantengo fuera de nuestro proceso de desarrollo? ¿Y qué argumentos podría usar para mantener la prueba de la unidad en su lugar (además de la calidad y el ahorro de tiempo a largo plazo)?

Como nota al margen, nuestra empresa cuenta con 3 equipos de ingeniería y el equipo en el que estoy entrega su software a tiempo (con un margen de 10%). Mientras que los otros equipos siempre entregan tarde, principalmente debido a una subestimación en la planificación. Solo planifican la codificación y no la administración, las pruebas y el manejo a su alrededor.

    
pregunta refro 12.04.2011 - 08:14

10 respuestas

3

Primero, permítame decir que simpatizo completamente con su posición. Puede ser frustrante cuando tiene una falta de comprensión o un desglose de comunicación entre diferentes partes del negocio. Habiendo dicho eso, no creo que debas intentar mantenerlos fuera. En su lugar, debe mostrarles los números sobre por qué es una buena idea. ¿Qué datos tienes que justifiquen el esfuerzo de la prueba de unidad por el esfuerzo que pones en ello? Si no tiene ninguno, debe comenzar a reunir esas cifras, o mostrar algunas investigaciones para respaldar sus reclamaciones.

Yo mismo he tenido que lidiar con escenarios similares y yo respondió esta pregunta sobre un tema similar . También hice un blog sobre cómo lo traté aquí:

enlace

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

  

Para resumir, comparé nuestro estimado   horas contra horas reales para el   Proyecto y luego comparamos nuestro defecto   tasa contra la tasa de defectos de otros equipos.   En nuestro caso estos números se comparan.   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 hacer.   y medirlo contra otro   enfoques. A la gente no le importa   dogma, o porque piensas algo   debería ser la mejor manera Solo por   mostrando a la gente los números y   midiendo la efectividad de tu   enfoque puede realmente demostrar que su   Las prácticas son efectivas.

Si su equipo de administración no está de acuerdo en invertir lo que ven como 150 horas adicionales en la prueba unitaria, tal vez pueda convencerlos de que inviertan en una pequeña área del producto (o incluso acuerden chuparse las horas para hacerlo). 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. Esperamos que recopile algunos datos para respaldar su caso y esto no será un problema para su próximo proyecto.

    
respondido por el Paddyslacker 12.04.2011 - 18:48
18

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

  1. Los desarrolladores deben tener el derecho de estimar su propio trabajo.
  2. Las partes interesadas deben tener el derecho de establecer prioridades 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, ponte de acuerdo y respeta que ambas partes harán su trabajo lo mejor que puedan.

    
respondido por el Martin Wickman 12.04.2011 - 09:28
8

Puede indicar que las pruebas de unidad ahorran tiempo, por lo que si las abandona, la estimación es de 500 horas.

    
respondido por el HLGEM 12.04.2011 - 17:23
5

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

Mire esta publicación de alguna buena idea En deuda técnica. Después de esa publicación, puede acceder a la siguiente pdf

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

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

En mi humilde opinión, debe anotar 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 la totalidad de las 150, eso suena ridículo) donde cada cambio (durante la fase de desarrollo y durante el mantenimiento) tomará en promedio:
    • 4 horas pequeñas
    • medio 16 horas
    • 40 horas grandes
  • sus horas estimadas donde cada cambio (fase de desarrollo y durante el mantenimiento) en promedio tomará:
    • 2 horas pequeñas
    • medio 8 horas
    • 20 horas grandes

(Las horas son solo indicativas. Usted está mejor preparado para dar estimaciones adecuadas).

No olvide incluir su historial para entregas puntuales dentro del presupuesto.

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

Espero que esto ayude y buena suerte.

    
respondido por el KeesDijk 12.04.2011 - 10:05
1

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

En mi experiencia, los gerentes que acusan a los desarrolladores de tiempo de sobreestimación es un escenario muy común, y si no lo soluciono, puede conducir a una carrera de armas bastante tonta en la que se duplicarán sus próximas estimaciones porque sabe que los jefes los reducirán a la mitad, Sepa esto para que los dividan, así que los cuadruplica, etc. Debe evitar este círculo vicioso si es posible.

Suponiendo que no hay una razón de "vencimiento" para la fecha límite, sugeriría 2 cosas.

  1. Entregue un plan detallado de lo que cree que puede hacer en 150 horas, manteniendo su enfoque actual de trabajo de alta calidad. Enumere exactamente lo que se puede entregar en este marco de tiempo. La respuesta de KeesDijk tiene algunos enlaces muy buenos sobre la planificación a 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 aparezca en la figura).

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

    
respondido por el Steve Haigh 12.04.2011 - 11:08
1

Pídales la base de sus estimaciones. Es justo discutir las discrepancias. Dumping pruebas de unidad es una economía falsa, lo que no se gasta en escribir pruebas de unidad se gastará en un depurador más tarde (y más). Esencialmente, usted ha documentado el hecho de que planea probar el trabajo que realiza. Te están diciendo que no pruebes en absoluto . Ya sea que realice pruebas utilizando pruebas unitarias o pruebas ad hoc a medida que desarrolle 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.

Línea inferior: apégate a tus armas con tu estimación. Su historial muestra que sabe de lo que está hablando y puede dar una respuesta razonable sobre la base de su estimación (suposiciones, expectativas, desempeño pasado, etc.). Parece que su alta gerencia no tiene la visibilidad que necesitan para crear una estimación razonable. ¿Están asumiendo 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, considerando tu historial?

    
respondido por el Berin Loritsch 12.04.2011 - 17:47
1

En primer lugar, no divida las "pruebas de unidad de escritura" como una tarea separada que se debe estimar, programar y, posiblemente, recortar. 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 obtener el desarrollo no técnico "de su proceso de desarrollo". ¡No incluya su proceso de desarrollo en la lista de tareas o en el cronograma del proyecto que les da!

En segundo lugar, parece que su equipo ya les está entregando buenos productos a tiempo, pero que otros equipos no lo hacen. Quizás este grupo de administración esté acostumbrado a tener que microgestionar a esos equipos. Juegue a sus fortalezas: ofrezca mostrarles actualizaciones semanales o quincenales con funciones funcionales, y le contarán el "proceso de desarrollo".

    
respondido por el Marcie 12.04.2011 - 21:13
0

Estimo que tomará 300 horas y si el presupuesto de 150 les da la opción, será un trabajo urgente de buggy o un retraso en la entrega. Cuando el proyecto esté completo y sea como usted predice, simplemente puede decirles que eso es lo que pidió.

    
respondido por el Craig 12.04.2011 - 08:20
0

¿Qué haría Wally?

Hay varias formas de interpretar lo que la administración te pide, una es que no quieren que lo entregues a tiempo.

Parece absurdo? Sí, pero ¿de qué otra forma pueden saber que no estás sobreestimando? No cumpla con sus plazos (en caso de ser necesario), si se resbala y entrega algo a tiempo, asegúrese de verse realmente cansado para no dar la impresión de que fue un paseo por el parque.

    
respondido por el aaaaaaaaaaaa 12.04.2011 - 17:07
-1

Estás en un pepinillo. Si te pegas a tus armas y quieres quedarte con pruebas de unidad 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á una gran aflicción en el futuro, con un mayor costo de mantenimiento.

De cualquier manera, pierdes.

O eso parece.

Verás, no estás dirigiendo un laboratorio de ciencias en una universidad. Usted está proporcionando un servicio de negocios a una unidad de negocios en una compañía que brinda servicios a clientes en un ecosistema de compañías. Es posible que su empresa necesite que su producto comience a ofrecer servicios mejores y más rápidos a sus clientes y, por lo tanto, aumente los ingresos necesarios.

Usted ve, lo que necesita es un análisis de retorno de la inversión, y no tiene todos los datos para hacer ese análisis. Solo tiene una 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 administración, créalo o no, es un experto en hacer 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 la "si actuamos ahora haremos tanto "Más dinero incluso pagando el triple por el mantenimiento del software del que se quejan los informáticos".

Por lo tanto, si desea ejecutar la empresa conjunta, comience su propia empresa. Ya lo verás, no es tan fácil.

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

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

    
respondido por el Christopher Mahan 12.04.2011 - 18:02

Lea otras preguntas en las etiquetas