El director del proyecto pide una confianza total del 100% cada vez que se compromete 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 sí tengo confianza en mis métodos de prueba. Y, como desarrollador, también sé que no es raro que surjan errores inesperados más tarde a partir de estos cambios fundamentales.

El director del proyecto no entiende el software lo suficientemente bien, y ciertamente no entiende las pruebas lo suficientemente bien. Quizás necesita ser educado.

Si tuvieras un departamento profesional de QA, te diría que consiguieras el apoyo del Director de QA para explicarle a este Director de Proyecto la naturaleza del software, la naturaleza de los bugs, y la naturaleza de las pruebas. Tendría al Gerente de QA indicando por qué simplemente no es posible probar cada condición, y cómo la liberación/no liberación es una actividad comercial ayudada por los hallazgos de las pruebas, pero nunca por la información perfecta.

Puede 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 probar todo?”), Weinberg tiene una sección llamada “Hay un número infinito de pruebas posibles”

Él habla de una puerta trasera colocada en un programa de alta seguridad por la cual la protección ordinaria de la contraseña podría ser evitada escribiendo W seguida de tres espacios, luego M seguida de tres espacios, luego J seguida de exactamente 168 pulsaciones más sin usar ni una sola vez la letra L.

Luego escribe: “¿Ya has entendido el punto? Si no adivinó que el número de pruebas necesarias para probar exhaustivamente el software es infinito, o al menos "un número mayor del que podría ejecutar en mi vida”, no entendió el punto de este capítulo. Ahora lo entiendes"

Explica a tu Director de Proyecto que cada día de pruebas adicionales mejorará tu confianza en tu código de alguna manera, pero nunca puede llegar al 100%. Dile que estarías feliz de continuar probando a expensas de tu otro trabajo productivo. Luego pregúntale cuántos días más le gustaría que pasaras en las pruebas y cuál de tus otros trabajos debería ser aplazado.

Si tu Director de Proyecto todavía no lo entiende, y te sientes un poco frívolo, pregúntale si está 100% seguro de que cada estimación que publique es exactamente correcta y que los plazos nunca se incumplirán. Pregúntale si está 100% seguro de que ningún email que escriba desde ahora hasta siempre tendrá un error de escritura. Pregúntele si está 100% seguro de que nunca cometerá un error, ahora y en el futuro.

Jefe: ¿Está seguro al 100% de que esta solución no romperá ninguna característica existente o causará ningún efecto adverso en la experiencia del usuario?

Me: No. Como no tenemos un paquete de pruebas de cobertura al 100% no hay forma de verificar que cualquier cambio de código evitará la rotura de la aplicación o efectos adversos. Sin embargo, he realizado las siguientes acciones para asegurarme de que es poco probable que se realice de forma no intencionada:

• He limitado el alcance del cambio sólo al módulo que afecta
• He leído y actualizado la documentación en consecuencia
• He realizado las pruebas unitarias para este módulo y los módulos afectados
• He creado pruebas unitarias para comprobar la nueva funcionalidad añadida, y las pruebas obsoletas que ya no son relevantes debido al cambio

Aunque no puedo ofrecerles exactamente una garantía del 100%, he proporcionado tanta garantía como he podido dentro del plazo que creo que es razonable para la implementación de esta funcionalidad. De hecho, ya he llegado al punto de disminuir los rendimientos. Puedo pasar otras 5 horas para darle otro 0,1% de seguridad, pero ya es tan poco probable que tal esfuerzo no esté justificado. Sin embargo, usted está a cargo del proyecto y del marco temporal, así que hágame saber cuánto tiempo más debo dedicar a esta función.

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

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

Como desarrollador, estás probando los cambios en tu código. En mi opinión (como desarrollador), es decir, para comprobar que no hay errores obvios, todo compila, todos los errores están atrapados. No tienes forma de saber qué escenarios se encontrarán una vez que el código se ponga en marcha (malos datos, entradas inesperadas, cambios en el software del cliente, la lista es interminable)

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

Si está esperando un 100% de confianza, entonces necesita proveer el ambiente 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 sean a prueba de futuro!

Parece que ha caído en un mal hábito. Está haciendo una pregunta que sabe que, a cierto nivel, es una tontería. Pero hay un poco de un elemento compulsivo en ella. Mi suposición es que está actuando sobre una ansiedad subyacente, y hacer una pregunta irrazonable le hace sentir más en control.

En este tipo de situaciones trato de difuminar la dinámica siendo confiado e inyectando un poco de humor. Si entiendes que su pregunta no viene del razonamiento, sino de la ansiedad, entonces puedes abordar eso mejor indirectamente que directamente.

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

Ahí es donde el arte de este negocio entra en juego. No sólo “funciona”, sino que el cliente se siente bien con ello.

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 soportar esta rareza. No suena como si fuera tan serio, sólo un poco persistente. Como digo, ha desarrollado un hábito molesto. Si comienza a reaccionar adversamente y el tono se vuelve más hostil, entonces el balance del acuerdo de negocios puede hacer que no valga la pena para usted. Pero por su corta 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 director del proyecto quiere ser absuelto de responsabilidad por cualquier error. Él recibe una declaración jurada de usted que siente que puede confiar “razonablemente” en ella, así que si algo sale mal, dice que ha hecho todo lo posible para evitarlo pero que usted ha fallado.

Esto no es una buena gestión y tampoco está garantizado al 100% para ponerlo al descubierto si se producen problemas.

Admito que esto es una especulación por mi parte, pero los ejercicios para cubrir el trasero no son nada raros en la vida profesional y tienes que lidiar con ellos. Así que si esto suena cierto, entonces lo que tienes que hacer para resolver el problema no es sólo educar al gerente de que el 100% de confianza es imposible. También tienes que convencerle de que un bicho no es un desastre… para él personalmente o para la empresa.

Esto podría significar, por ejemplo, proporcionar ejemplos de bichos que se tratan a un coste razonable y sin ninguna culpa volando por ahí. Podría significar mirar su propia cultura de empresa, si hay alguien más en la empresa preparándose para echarle la culpa injustamente si algo sale mal. También podría significar poner en marcha procedimientos para hacer frente a futuros bichos tan rápido y barato como sea posible. Si la empresa realmente tuviera una confianza del 100% en el código, estos procedimientos no tendrían sentido porque estaría dispuesta a apostar grandes cantidades de dinero de forma arbitraria a que no haya futuros fallos.

Como sanción final, si él (el empleador) le pide a usted (el contratista) que le venda una garantía que no puede dar sobre su trabajo, y nada le hará cambiar de opinión sobre este punto, entonces todo lo que puede hacer es establecer claramente que no es capaz de proporcionar esa garantía, y que es bienvenido a emplear a alguien más si cree que hay alguien que puede. Por supuesto que eso es un largo camino, pero es mejor que conozcas a tu BATNA antes de empezar.

Estrictamente hablando, uno nunca puede estar 100% seguro de que un compromiso no rompa un programa.

Incluso con todo tipo de pruebas posibles (pruebas de unidad, integración, componente, sistema, manual, UI, 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 computación, el problema de la detención puede ser expresado de la siguiente manera: “Dada una descripción de un programa de ordenador arbitrario, decidir si el programa termina de ejecutarse o continúa ejecutándose para siempre”. Esto equivale al problema de decidir, dado un programa y una entrada, si el programa se detendrá eventualmente cuando se ejecute con esa entrada, o si se ejecutará para siempre.

Alan Turing demostró en 1936 que no puede existir un algoritmo general para resolver el problema de la detención para todos los pares posibles de entrada de programas. Una parte clave de la prueba fue una definición matemática de un ordenador y un programa, que se conoció como una 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, quizás pueda convencerlo de que eche un vistazo a marco SCRUM .

Otros han dado muchos consejos interesantes sobre cómo interactuar con su PM. Personalmente, le aconsejaría que organizara una reunión con su PM y el equipo donde pueda discutir sus procesos. Estoy a favor de SCRUM, así que esto estaría relacionado en gran medida con el SCRUM.

Trataría de explicar, que un objetivo 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, demo del lanzamiento de Windows 95 por ejemplo. ¿Hace mucho tiempo? Bueno, mira cuántos edificios rojos en un servidor público de CI para proyectos de código abierto; entra como invitado si no tienes una cuenta allí. Así que un resultado de esto - el software fallará.

En segundo lugar, yo aconsejaría adoptar una práctica, donde se puede entregar valor, en lugar de la confianza de un compromiso. Algo, que los clientes se preocupen. Iterativamente, repetidamente y de manera confiable. Ahora, puedes cambiar la perspectiva de tu Primer Ministro del 100% de seguridad, a algo que realmente importe. Esto es: el software está en uso, tu producto está mejorando y el equipo está entregando valor al cliente.

Tercero, la 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, puertas de calidad, etc. Esto es muy importante, ya que ahora se puede cambiar la subjetividad (es decir, “¿estás 100% seguro?”) a la objetividad (es decir, todos los puntos de la definición de hecho se completan).

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

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

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

2) No comprometas nada en el flujo de código de producción hasta que TODAS las pruebas de regresión hayan sido ejecutadas de nuevo y se haya probado que no rompen nada de lo que la prueba para. Si ocurre algún fallo durante esa prueba, el cambio debe ser retrocedido hasta que se pueda establecer claramente que no ha causado el problema.

3) Prueba alfa y beta temprana y a menudo con escenarios de clientes del mundo real. Los clientes harán cosas con tu código que nunca esperabas.

Ninguna de ellas es al 100%, ni tampoco su combinación. Pero te acercan considerablemente más. Requieren una inversión no trivial de recursos adicionales. Ellos hacen que el desarrollo sea más lento comparado con la práctica de codificación de “sólo hazlo y lo arreglaremos cuando se rompa” de Skunkworks. Pero si realmente quieres un código libre de errores, reconocer que los humanos son falibles y poner en práctica prácticas que ayuden a detectar los fallos antes de que lleguen a los clientes puede valer más que esos costes.

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

Si estás haciendo algo crítico para la vida, obviamente vale la pena esa inversión. Si estás haciendo algo que es infraestructura para grandes empresas, vale la pena esa inversión; no quieres ser el único cuyo fallo derribe los procesos de negocio de una empresa de mil millones de dólares.

Sí, vuelve locos a los buenos codificadores. Hasta la primera vez que les salva el trasero.

La verdad es que es una prueba pobre. La realidad es que una empresa que no quiera invertir en un equipo de control de calidad va a tener una prueba pobre. Las buenas pruebas son caras y llevan tiempo. La compañía ha aceptado el riesgo al no autorizar el tiempo y el dinero.

Ni siquiera un equipo de QA puede garantizar que todas las posibilidades sean probadas porque los caminos posibles a través de un programa complejo son básicamente infinitos. Sin embargo, te llevarán mucho más cerca de lo que estás ahora mismo. Una razón es que es imposible para un desarrollador probar adecuadamente su propio código. Saben lo que hace, así que tienden a diseñar las pruebas en torno a lo que creen que debe hacer. Echan de menos los casos límite, echan de menos las cosas estúpidas que los usuarios hacen y que un dev nunca haría porque saben cómo funciona, a veces interpretan el requisito de forma incorrecta pero todas sus pruebas reflejarán su interpretación incorrecta original. A menudo pasan por alto 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 un gran número de errores que se encuentran sólo después de que los usuarios reales [a los que con demasiada frecuencia no se les consulta al definir el requisito] intentan utilizar el software). Echan de menos los efectos en las partes de la aplicación en las que nunca han tenido motivos para trabajar, especialmente en las partes que son realizadas por especialistas (como un cambio de tabla que tiene sentido para la aplicación pero que rompe un proceso de importación automatizado o un informe)

Si quiere una mayor calidad tendrá que pagar por ello 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. Ellos también gastan un gran trato más dinero del que su compañía está gastando. Incluso entonces, se las arreglaron para perder completamente a MARS una vez.

Si lo que él quiere es la seguridad de que ningún problema le causará daño con los clientes, entonces habla de tu proceso para las pruebas (Muéstrale la lista de pruebas que hiciste.), lo que piensas que se vería afectado y cómo lo comprobaste, tu proceso para cómo revertir un mal empujón y tu proceso para registrar los errores para que los veas antes de que la mayoría de los clientes los noten. Dale la confianza de que incluso si hay un problema, se puede arreglar. Hable sobre el valor de sacar el código (nueva característica o arreglo) rápidamente viceversa el tiempo adicional que tomaría hacer la prueba más a fondo. Hable de los riesgos de no sacarlo rápidamente.

También puede pedirle que proporcione la prueba de regresión completa del sistema cada vez que haga un cambio porque no es posible que un dev pruebe completamente su propio trabajo (usted sabe cuáles fueron sus suposiciones, si no son correctas, usted nunca probaría eso). Asegúrate de que sabe que tendrá que probar cada página de la aplicación y cada cosa que se podría hacer en una página en cada orden posible. Oh sí, pruebe cualquier importación/exportación, informes, trabajos automatizados también. Y cualquier aplicación relacionada que pueda ser afectada. Una vez que haya tratado de ejercitar el sistema a fondo una vez, se dará cuenta de por qué no puede hacer esa garantía.

Otra cosa que hay que intentar es decirle por adelantado que no puede hacer esa garantía, pero si autoriza X horas de prueba, puede acercarse a hacer esa garantía. Dale una lista detallada de las pruebas adicionales y las horas que se necesitarían para diseñar y ejecutar cada una de ellas. Dígale qué porcentaje de confianza tendría después de ejecutar todas esas pruebas y qué porcentaje de confianza tiene en este momento.

Para ello, dígale cuánto tiempo llevaría simplemente ejecutar todas las pruebas unitarias actuales que tiene, independientemente de si están relacionadas con este tema o no. Así que si actualmente tiene 1000 pruebas de unidad y cada una toma cinco minutos para configurar y ejecutar y evaluar los resultados, eso sería 83 horas. Pídele la autorización para seguir adelante y gastar ese tiempo.

Si él está de hecho micro-gestionando y mirando por encima del hombro durante todo el proceso de construcción del proyecto, hay una manera fácil de asegurarse de que usted puede “garantizar” el 100% de confianza sin tener que pregonarlo más tarde.

Conseguir que él mismo lo apruebe

Para ser claros, no debe hacer esto como una demanda, sino más bien una sugerencia, que si él realmente quiere un código 100% perfecto, entonces debe mirar lo que usted está haciendo por sí mismo y aprobar cada cambio que usted está haciendo a lo largo del camino. Esto no quiere decir que él debería literalmente leer el código, sino más bien 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 - usted ya está completamente enfocado en el proyecto, y si él quiere la perfección, debería tomar la responsabilidad de asegurar esa perfección por sí mismo.

También, tome notas de todo lo que él aprueba, para que más tarde cuando inevitablemente se rompa, pueda señalar su documentación mostrando que él lo aprobó.

Si, por alguna razón, no cree que esto vaya a salir 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 hacer tantas pruebas de error como pueda, escribir en sus informes todo lo que sabe que funciona correctamente, y darle el 100% de seguridad de que, “dentro de los límites de mis pruebas, tengo el 100% de confianza 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. Así que para resumir, su mejor apuesta podría ser hacer lo mejor que pueda, registrar todo, y hacer entender que está haciendo lo que puede dentro de sus propios límites.

Bastantes 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 cuán alta es tu reputación, cuán buenas son tus habilidades (o más bien cómo se perciben), y tanto tu personalidad como la de tu PM. Presumo que no lo malinterpretaste, y realmente quiere decir 100% (a menudo veo a la gente diciendo 100%, pero realmente quiere decir “haz lo mejor que puedas”)

Funcionó para mí una vez, y es la única razón por la que lo menciono aquí. Estáis advertidos. Esta es 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, así que debes en algún lugar hacer que él (o el equipo) se golpee contra una pared para detenerse un momento y pensar. En este escenario significa: Trabaja tan bien como puedas, intenta probar tan bien como puedas. Da lo mejor de ti, y luego di: “Sí, estoy 100% seguro de que esto funcionará”.

Si eres extremadamente afortunado, nunca se producirá un error y todo el mundo está feliz; pero en realidad lo que ocurrirá es: hay un error. ¿Qué harás ahora? Admite que cometió un error. Hacer una conexión con los bichos 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. Por consiguiente, los humanos son imperfectos y pueden “crear bugs” en su percepción de estar 100% seguros de que no hay ningún bug.

Presenta este pozo, y 100% estanco (jaja, j/k, el 100% otra vez). Asegúrense de que después de todo esto, el mensaje que se repita sea “No puedo estar 100% seguro de mis pruebas”. Si el PM no puede dar el paso lógico de “Esto será lo mismo para todos los desarrolladores” entonces probablemente se pierda 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 ha dado a su PM una mala experiencia, y ahora está al límite cada vez que algo cambia. O tal vez leyó algo en un libro o revista.

Si puedes hacer que el PM te cuente su historia (tal vez sobre su bebida preferida) entonces puedes simpatizar, y él puede volverse receptivo a la “innovación”, también conocida como una sólida práctica de ingeniería de software.

Esta es tu 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. Hablar de las compensaciones en confianza, calidad, recursos y programación que provienen de los diferentes enfoques de las pruebas, revisión del código por pares, métodos formales (también conocidos como corrección por construcción).

Hablar su lenguaje: Usar metáfora 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 quiere cambiar algo en la mitad del capítulo 12, ¿cómo se asegura de que no cause una ruptura en la continuidad con el resto de la historia?

Busque la manera de aumentar la confianza hacia un objetivo aceptable dentro de límites económicos razonables. No podrás implementar el Modelo de Madurez de Capacidades SEI nivel 5 de la noche a la mañana. Pero usted podría ser capaz de ir 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 pruebas de regresión?”

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

Ver el artículo de Wikipedia sobre Intervalos de Confianza para más lectura.