Project Manager solicita 100% de confianza completa cada vez que se confirma el código

¿Cómo debo responder a su pregunta en este caso, sin parecer incompetente? Honestamente, nunca tengo una confianza del 100 % en todo el sitio, pero tengo confianza en mis métodos de prueba. Y, como desarrollador, también sé que no es raro que surjan errores inesperados después de estos cambios principales.

El gerente de proyecto no entiende lo suficientemente bien el software, y ciertamente no entiende lo suficientemente bien las pruebas. Tal vez necesita ser educado.

Si tuviera un Departamento de control de calidad profesional, le recomendaría que solicitara el apoyo del Gerente de control de calidad para explicarle a este Gerente de proyecto la naturaleza del software, la naturaleza de los errores y la naturaleza de las pruebas. Le pediría al Gerente de control de calidad que indique por qué simplemente no es posible probar todas las condiciones, y cómo la liberación/no liberación es una actividad comercial que se ayuda con los resultados de las pruebas, pero nunca con información perfecta.

Es posible que desee obtener una copia del excelente libro de Gerald Weinberg " Software perfecto y otras ilusiones sobre las pruebas ". En el capítulo 3 ("¿Por qué no simplemente probar todo?"), Weinberg tiene una sección llamada "Hay un número infinito de pruebas posibles".

Habla de una puerta trasera colocada en un programa de alta seguridad mediante el cual la protección de contraseña ordinaria podría pasarse por alto escribiendo W seguido de tres espacios, luego M seguido de tres espacios, luego J seguido de exactamente 168 pulsaciones de teclas más sin usar una vez la letra L.

Luego escribe: "¿Entiendes el punto ahora? Si no adivinaste que la cantidad de pruebas requeridas para probar el software de manera exhaustiva es infinita, o al menos "una cantidad mayor de la que podría ejecutar en mi vida", no lo hiciste. No entiendo el punto de este capítulo. Ahora lo entiendes.

Explíquele a su gerente de proyecto que cada día de pruebas adicionales mejorará un poco su confianza en su código, pero nunca puede llegar al 100%. Dígale que estaría feliz de continuar probando a expensas de su otro trabajo productivo. Luego pregúntele cuántos días más le gustaría que dedicara a las pruebas y cuál de sus otros trabajos debería aplazarse.

Si su gerente de proyecto aún no lo entiende y se siente un poco impertinente, pregúntele si está 100 % seguro de que todas las estimaciones que publica son exactamente correctas y que nunca se incumplirán los plazos. Pregúntele si está 100% seguro de que ningún correo electrónico que escriba desde ahora y para siempre tendrá un error tipográfico. Pregúntele si está 100% seguro de que nunca cometerá un error, ahora y en el futuro.

Jefe: ¿Está 100% seguro de que esta solución no interrumpirá ninguna función existente ni causará efectos adversos en la experiencia del usuario?

Yo: No. Dado que no tenemos un conjunto de pruebas de cobertura del 100 %, no hay manera de verificar que cualquier cambio de código evitará la rotura de la aplicación o efectos adversos. Sin embargo, realicé las siguientes acciones para asegurar que es poco probable que funcione de manera no deseada:

• He limitado el alcance del cambio solo al módulo al que afecta
• He leído y actualizado la documentación en consecuencia.
• He ejecutado las pruebas unitarias para este módulo y los módulos afectados.
• Creé pruebas unitarias para verificar la nueva funcionalidad agregada, y las pruebas obsoletas ya no son relevantes debido al cambio

Si bien no puedo brindarle exactamente el 100 % de seguridad, brindé tanta seguridad como pude dentro del plazo que considero razonable para la implementación de esta funcionalidad. De hecho ya llegué al punto de rendimientos decrecientes. Puedo pasar otras 5 horas para darle otro 0,1% de seguridad, pero ya es muy poco probable que tal esfuerzo no esté justificado. Sin embargo, usted está a cargo del proyecto y el marco de tiempo, así que hágame saber cuánto tiempo más debo dedicar a esta función.

Ahora la pelota está en su tejado. Si realmente quiere que cambie mi estimación personal de, digamos, 95 % seguro a 95,1 % seguro por unas pocas horas más de trabajo, entonces, oye, puedo hacerlo.

Si sigue siendo detestable al respecto, tendré una conversación por correo electrónico con él y el "propietario" del proyecto sobre este requisito "100% probado" y qué recursos creo que se requieren para cumplirlo.

Como desarrollador, usted está UNIDAD probando los cambios en su código. En mi opinión (como desarrollador), eso es verificar que no haya errores obvios, todo se compila, todos los errores quedan atrapados. No tiene forma de saber qué escenarios se encontrarán una vez que el código se active (datos incorrectos, entrada inesperada, cambio en el software del cliente, la lista es interminable)

Para tener el 100 % de confianza de que un cambio no afectará nada, necesitará un entorno de prueba que refleje EXACTAMENTE el entorno en vivo (datos, hardware, permisos, conectividad) y un conjunto de scripts de prueba que cubran cada escenario. Este, como es bien sabido, es un entorno virtualmente imposible de crear por varias razones.

Si espera un 100% de confianza, entonces necesita proporcionar el entorno y la mano de obra para respaldar sus expectativas.

¡Es un poco como cuando los gerentes de proyecto y los clientes piden que las cosas estén preparadas para el futuro!

Parece que ha caído en un mal hábito. Está haciendo una pregunta que sabe, hasta cierto punto, que es tonta. Pero hay un poco de un elemento compulsivo en ello. Mi conjetura es que está actuando sobre una ansiedad subyacente, y hacer una pregunta irrazonable lo hace sentir que tiene más control.

En este tipo de situaciones trato de difuminar la dinámica siendo confiado e inyectando un poco de humor. Si comprende que su pregunta no proviene del razonamiento, sino de la ansiedad, entonces puede abordarla mejor indirectamente que directamente.

En situaciones como esta, suelo disipar los temores de la gerencia presentando todas las medidas que he tomado para garantizar la calidad. Él es, después de todo, el cliente y necesita saber que sus prioridades están en línea con las suyas. Mira estas pruebas unitarias. Mira este seguimiento. Mire cómo está estructurado el código para mantener los cambios locales y modulares. etc. Si transmite una sensación de confianza y control, aliviará su ansiedad y probablemente podrá tener una conversación más racional.

Ahí es donde entra en juego el arte de este negocio. No solo "funciona", sino que el cliente se siente bien al respecto.

En última instancia, sin embargo, es una relación de negocios. Si el acuerdo de contratación es cómodo y rentable para usted, entonces vale la pena aguantar esta peculiaridad. No parece que sea tan serio al respecto, solo un poco persistente. Como digo, ha desarrollado un hábito molesto. Si comienza a reaccionar negativamente y el tono se vuelve más hostil, entonces el equilibrio del acuerdo comercial puede hacer que no valga la pena para usted. Pero a partir de su breve descripción, me parece que aún puede manejar la relación de manera efectiva.

Mucha gente ha descrito esto como un problema de educación, y no digo que estén equivocados.

También es posible que sea un problema político. Lo que la pregunta podría significar en realidad es que el gerente del proyecto quiere ser absuelto de responsabilidad por cualquier error. Obtiene una declaración jurada de usted en la que siente que puede confiar "razonablemente", por lo que si algo sale mal, dice que ha hecho todo lo posible para evitarlo, pero usted falló.

Esta no es una buena gestión y tampoco está 100% garantizado para dejarlo limpio si ocurren problemas.

Admito que esto es una especulación de mi parte, pero los ejercicios para cubrir el trasero no son nada raros en la vida profesional y tienes que lidiar con ellos. Entonces, si esto suena cierto, entonces lo que debe hacer para resolver el problema no es solo educar al gerente que el 100% de confianza es imposible. También debe convencerlo de que un error no es un desastre, ni para él personalmente ni para la empresa.

Esto podría significar, por ejemplo, proporcionar ejemplos de errores que se solucionan a un costo razonable y sin culpas. Podría significar mirar la cultura de su propia empresa, si hay alguien más en la empresa preparándose para culparlo injustamente si algo sale mal. También podría significar implementar procedimientos para tratar futuros errores de la manera más rápida y económica posible. Si la empresa realmente confiara al 100% en el código, tales procedimientos no tendrían sentido porque estaría dispuesta a apostar arbitrariamente grandes cantidades de dinero a que no habrá errores en el futuro.

Como última sanción, si él (el empleador) le está pidiendo a usted (el contratista) que le venda una garantía que usted no puede dar sobre su trabajo, y nada lo hará cambiar de opinión sobre este punto, entonces todo lo que puede hacer es dejarle claro que usted no puede proporcionar esa seguridad, y que él es bienvenido a contratar a otra persona si cree que hay alguien que puede hacerlo. Por supuesto que es un largo camino por recorrer, pero es mejor que conozca su BATNA antes de comenzar.

Estrictamente hablando, uno nunca puede estar 100% seguro de que una confirmación no rompa un programa.

Incluso con todo tipo de pruebas posibles (pruebas unitarias, integración, componente, sistema, manual, interfaz de usuario, fuzz, seguridad, penetración... lo que sea). Esto se debe a un problema de detención . Un extracto relevante de la Wikipedia sigue a continuación:

En la teoría de la computabilidad, el problema de detención se puede establecer de la siguiente manera: "Dada una descripción de un programa de computadora arbitrario, decida si el programa termina de ejecutarse o continúa ejecutándose para siempre". Esto es equivalente al problema de decidir, dado un programa y una entrada, si el programa finalmente se detendrá cuando se ejecute con esa entrada o se ejecutará para siempre.

Alan Turing demostró en 1936 que no puede existir un algoritmo general para resolver el problema de detención para todos los pares posibles de programa-entrada. Una parte clave de la prueba fue una definición matemática de una computadora y un programa, que se conoció como máquina de Turing; el problema de la detención es indecidible en las máquinas de Turing.

Si su PM se preocupa por el valor y la entrega estable y predecible, tal vez pueda convencerlo de que eche un vistazo al marco SCRUM .

Otros han dado muchos consejos interesantes sobre cómo interactuar con su PM. Personalmente, recomendaría programar una reunión con su PM y el equipo donde puedan discutir sus procesos. Estoy totalmente a favor de SCRUM, por lo que esto estaría relacionado en gran medida con SCRUM.

Intentaría explicar que una meta del 100% es difícil de alcanzar. No se puede alcanzar. Nunca. En todo el universo. La historia ha visto muchos ejemplos de este tipo, por ejemplo, la demostración del lanzamiento de Windows 95 . ¿Hace mucho tiempo? Bueno, vea cuántas compilaciones rojas en un servidor CI público para proyectos de código abierto; inicie sesión como invitado si no tiene una cuenta allí. Entonces, un resultado de esto: el software fallará.

En segundo lugar, recomendaría adoptar una práctica en la que pueda ofrecer valor , en lugar de la confianza de un compromiso. Algo que a los clientes les importe. De forma iterativa, repetida y fiable. Ahora, puede cambiar la perspectiva de su PM de la seguridad del 100% a algo que realmente importa. Es decir: el software está en uso, su producto está mejorando y el equipo entrega valor al cliente.

En tercer lugar, debería ser una definición de hecho. Algo que se le ocurra a un equipo de desarrollo. Esto puede incluir: documentación, implementación, pruebas, controles de calidad, etc. Esto es muy importante, ya que ahora puede cambiar la subjetividad (es decir, "¿está 100 % seguro?") a la objetividad (esos son todos los puntos de la definición de hecho se han completado).

Hay otros pasos muy importantes que promueve SCRUM. Pero todos ellos permitirían a los desarrolladores mitigar tal frustración y permitirles entregar un resultado objetivamente cuantificable, en comparación con la garantía subjetiva.

La respuesta habitual para este tipo de objetivo es la revisión por pares y las pruebas de regresión.

1) No comprometa nada con el flujo de código de producción hasta que no solo el autor, sino uno o más programadores, lo hayan verificado para asegurarse de que cambia solo lo que es necesario, que cumple con todos los criterios acordados para buena práctica práctica de codificación, que viene con una prueba que le brinda probabilidades decentes de detectar si un cambio posterior rompe la lógica nuevamente, y así sucesivamente.

2) No comprometa nada con el flujo de código de producción hasta que TODAS las pruebas de regresión se hayan vuelto a ejecutar y se haya demostrado que no se rompe nada de lo que se probó en la prueba. Si ocurre alguna falla durante esa prueba, el cambio debe revertirse hasta que se pueda establecer claramente que no fue la causa del problema.

3) Realización de pruebas alfa y beta desde el principio y, a menudo, con escenarios de clientes del mundo real. Los clientes harán cosas con su código que nunca esperó.

Ninguno de ellos es 100%, ni su combinación. Pero te acercan considerablemente. Requieren una inversión no trivial de recursos adicionales. Retrasan el desarrollo en comparación con la práctica de codificación de skunkworks "simplemente hágalo y lo arreglaremos cuando se rompa". Pero si realmente desea un código libre de errores, reconocer que los humanos son falibles y poner en práctica prácticas para ayudar a detectar fallas antes de que lleguen a los clientes puede valer más que la pena esos costos.

Me dijeron que nunca hubo un error informado en el código que IBM escribió para la NASA, porque fue revisado por pares y probado durante el diseño, durante el desarrollo y antes de ser lanzado.

Si está haciendo algo crítico para la vida, obviamente vale la pena esa inversión. Si está haciendo algo que es infraestructura para grandes empresas, vale la pena esa inversión; usted no quiere ser aquel cuyo error desbarate los procesos de negocio de una empresa de miles de millones de dólares.

Sí, vuelve locos a los buenos codificadores. Hasta la primera vez que salva sus traseros.

La verdad es que es un ensayo pobre. La realidad es que una empresa que no esté dispuesta a invertir en un equipo de control de calidad tendrá pruebas deficientes. Una buena prueba es costosa y toma tiempo. La empresa ha aceptado el riesgo al no autorizar el tiempo y el dinero.

Incluso un equipo de control de calidad no puede garantizar que se prueben todas las posibilidades porque las rutas posibles a través de un programa complejo son básicamente infinitas. Sin embargo, lo acercarán mucho más de lo que está ahora. Una de las razones es que es imposible que un desarrollador pruebe adecuadamente su propio código. Saben lo que hace, por lo que tienden a diseñar pruebas en torno a lo que creen que se supone que debe hacer. Se pierden casos extremos, se pierden cosas estúpidas que hacen los usuarios que un desarrollador nunca haría porque saben cómo funciona, a veces interpretan el requisito incorrectamente, pero todas sus pruebas reflejarán su interpretación incorrecta original. A menudo pasan por alto los errores en el requisito y hacen lo que se les pide que hagan, no lo que deberían haber hecho (esta es la causa de una gran cantidad de errores que se encuentran solo después de que los usuarios reales [a quienes con demasiada frecuencia no se les consulta para definir el requisito] intente utilizar el software). Pierden efectos en partes de la aplicación en las que nunca han tenido motivos para trabajar, especialmente en partes realizadas por especialistas (como un cambio de tabla que tiene sentido para la aplicación pero interrumpe un proceso de importación automatizado o un informe).

Si quiere una mayor calidad, tendrá que pagarla tanto en tiempo como en dinero. Incluso con un control de calidad completo, no puede llegar al 100%, aunque ciertamente la NASA y sus contratistas se acercan. También gastan mucho más dinero del que está gastando su empresa. Incluso entonces, se las arreglaron para perder completamente MARTE una vez.

Si lo que quiere es asegurarse de que cualquier problema no le causará daño con los clientes, entonces hable sobre su proceso de prueba (muéstrele la lista de pruebas que ejecutó), lo que cree que se vería afectado y cómo lo verificó. , su proceso para revertir un mal impulso y su proceso para registrar errores para que los vea antes de que la mayoría de los clientes los noten. Dale la confianza de que incluso si hay un problema, se puede solucionar. Hable sobre el valor de obtener el código (nueva función o corrección) rápidamente frente al tiempo adicional que llevaría probarlo más a fondo. Hable sobre los riesgos de no sacarlo rápidamente.

También puede pedirle que proporcione la prueba de regresión completa del sistema cada vez que realice un cambio porque no es posible que un desarrollador pruebe completamente su propio trabajo (ya sabe cuáles eran sus suposiciones, si no son correctas, lo haría). nunca pruebe eso.) Asegúrese de que sepa que tendrá que probar cada página de la aplicación y cada cosa que se pueda hacer en una página en cada orden posible. Ah, sí, prueba cualquier importación/exportación, informes, trabajos automatizados también. Y cualquier aplicación relacionada que pueda verse afectada. Una vez que haya intentado ejercitar a fondo el sistema una vez, se dará cuenta de por qué no puede garantizarlo.

Otra cosa que puede intentar es decirle por adelantado que no, no puede hacer esa garantía, pero si él autoriza X horas de prueba, puede estar más cerca de hacer esa garantía. Déle una lista detallada de las pruebas adicionales y las horas que tomaría diseñar y ejecutar cada una. Dile qué porcentaje de confianza tendrías después de ejecutar todas esas pruebas y qué porcentaje de confianza tienes ahora mismo.

De hecho, dígale cuánto tiempo le llevaría ejecutar todas las pruebas unitarias actuales que tiene, independientemente de si están relacionadas con este problema o no. Entonces, si actualmente tiene 1000 pruebas unitarias y cada una tarda cinco minutos en configurarse, ejecutarse y evaluar los resultados, serían 83 horas. Pídale la autorización para seguir adelante y gastar ese tiempo.

El producto tiene muchas partes entremezcladas (no solo páginas independientes), unas 40 000 líneas de código escritas durante 4 años y, a veces, suceden cosas inesperadas de las que ni siquiera nos damos cuenta. Siento que él ve esto como una mala prueba.

Este es tu problema, pero hasta ahora no es tu culpa. Si no lo arreglas, tendrás que asumir la responsabilidad en algún momento. Hable con su jefe de que hasta que esto se arregle, nunca estará al 100%. Sugerir refactorización. Además, no es lo mismo estar al 100% en la mente de los no técnicos que en la de un programador. Tal vez debería indicar que está "100% seguro de que el cliente probablemente no lo notará".

No hay equipo de control de calidad Este es un lujo que su empresa no puede permitirse, así que usted lo es. Imagine que hubiera un equipo de control de calidad (usted) y determine cuánto tiempo tardarían en probar su código, luego póngalo en su estimación. No hay forma de que pueda codificar y controlar la calidad simultáneamente, por lo que no puede hacerlo en paralelo.

Deje de estar tan ansioso por verificar el código y cumplir con lo que parecen ser demandas irrazonables. Dales lo que quieren. Una vez que descubren el costo (tiempo de codificación excesivo), puede cambiar de opinión.

Si, de hecho, lo está controlando a detalle y está mirando por encima de su hombro a lo largo del proceso de construcción del proyecto, hay una manera fácil de asegurarse de que puede 'garantizar' un 100 % de confianza sin que él se lo explique más tarde.

Haz que lo apruebe él mismo

Para ser claros, no debe hacer esto como una demanda, sino más bien como una sugerencia, de que si él realmente quiere un código 100% perfecto, entonces debería mirar lo que está haciendo él mismo y aprobar cada cambio que está haciendo en el camino. Esto no quiere decir que literalmente deba leer el código, sino verlo en acción y confirmar 'sí, así es como debería actuar'.

Si usted es el único probador de su propio código, esto no es irrazonable: ya está completamente concentrado en el proyecto, y si él quiere la perfección, debe asumir la responsabilidad de garantizar esa perfección él mismo.

Además, tome notas de todo lo que aprueba, para que luego, cuando inevitablemente se rompa, pueda señalar su documentación que demuestre que lo aprobó.

Si, por alguna razón, cree que esto no funcionaría bien (por ejemplo, si pedirle que haga más trabajo es algo que ya sabe que sería desastroso), todo lo que puede hacer es realizar tantas pruebas de error como pueda. puede, escriba en sus informes todo lo que sepa que funciona correctamente y déle un 100 % de seguridad de que, "dentro de los límites de mis pruebas, confío al 100 % en estos cambios".

Desafortunadamente, puede estar en la posición de tener un 'jefe' cuya comprensión de su trabajo es limitada, lo que siempre es un dolor cuando se trata de explicar cómo la corrección de errores es imposible de mantener con un 100% de confianza. Entonces, para resumir, su mejor apuesta podría ser hacer lo mejor que pueda, registrar todo y hacer que se entienda que está haciendo lo que puede dentro de sus propios límites.

Algunas buenas respuestas aquí, el PM definitivamente necesita ser educado y aprender un poco sobre lo que significa escribir software.

No quiero repetir nada de eso, pero agrego otra idea bastante inusual. Este método es bastante arriesgado y depende mucho de qué tan alta sea su reputación, qué tan buenas sean sus habilidades (o más bien, cómo se perciban), y tanto su personalidad como la de su PM. Supongo que no lo entendiste mal, y él realmente quiere decir 100% (a menudo veo personas que dicen 100%, pero en realidad quieren decir "haz lo mejor que puedas").

Funcionó para mí una vez, y esa es la única razón por la que lo menciono aquí. Usted ha sido advertido. Esta es principalmente una forma posible de educar a un PM si todos los demás medios fallan.

A veces, un PM (o cualquier otro gerente) simplemente no quiere escuchar, por lo que debe hacer que él (o el equipo) golpee una pared en algún lugar para detenerse por un momento y pensar. En este escenario significa: Trabaje lo mejor que pueda, trate de probar lo mejor que pueda. Da lo mejor de ti y luego di "Sí, estoy 100% seguro de que funcionará".

Si tiene mucha suerte, nunca ocurrirá ningún error y todos estarán felices; pero en realidad lo que sucederá es: hay un error. ¿Qué harás ahora? Admites que cometiste un error. Haz una conexión con los errores y el error de estar 100% seguro. Los humanos son imperfectos y pueden crear errores en el software. Los humanos son imperfectos y crean errores en las pruebas. En consecuencia, los humanos son imperfectos y pueden "crear errores" en su percepción de estar 100% seguros de que no hay ningún error.

Presenta este bien, y 100% estanco (jaja, j/k, el 100% otra vez). Asegúrese de que después de todo esto, el mensaje que pasó sea "No puedo estar 100% seguro en mis pruebas". Si el PM no puede dar el paso lógico de "Esto será lo mismo para todos los desarrolladores", entonces probablemente se haya perdido toda esperanza...

Pero por favor, ¡prueba otras cosas primero!

El indicador clave es que se trata de un cambio reciente. Algo (o alguien) probablemente le haya dado una mala experiencia a tu PM, y ahora está nervioso cada vez que algo cambia. O tal vez leyó algo en un libro o una revista.

Si puede lograr que el PM le cuente su historia (quizás con su bebida preferida), entonces puede simpatizar y él puede volverse receptivo a la "innovación", también conocida como práctica sólida de ingeniería de software.

Esta es su oportunidad de hablar sobre el error humano y las formas que esta industria ha encontrado para aumentar los niveles de confianza en nuestros diseños y código. Para hablar sobre las ventajas y desventajas de la confianza, la calidad, los recursos y el cronograma que surgen de los diferentes enfoques de las pruebas, la revisión del código por pares, los métodos formales (también conocido como corrección por construcción).

Habla su idioma: usa metáforas para ilustrar el tamaño del problema. ¿Son 40.000 líneas de código? Dile que es como un misterio de asesinato de 600 páginas en un idioma extranjero. Si quieres cambiar algo en medio del capítulo 12, ¿cómo te aseguras de que no cause una interrupción en la continuidad con el resto de la historia?

Busque la aceptación de formas de aumentar la confianza hacia un objetivo aceptable dentro de límites económicos razonables. No podrá implementar el modelo de madurez de capacidad SEI nivel 5 de la noche a la mañana. Pero es posible que pueda pasar de la pregunta actual a "¿pasa el conjunto de pruebas de regresión automatizada?" y "¿cómo expresamos este nuevo requisito en el sistema de prueba de regresión?"

Yo lo contestaría de la forma más matemática, considerando que está pidiendo una probabilidad con un 100% de confianza, e ignorando por completo el efecto que tendrían las distribuciones estadísticas sobre dicho número: Deberías darle 2 o 3 números, con confianza asociada : 1 semana al 90%, 2 semanas al 95%, 6 meses al 100%. El último número fue una exageración, pero estoy seguro de que entendiste el punto.

Consulte el artículo de Wikipedia sobre intervalos de confianza para obtener más información.