Estoy administrando el esfuerzo de prueba para una nueva aplicación de software como administrador de pruebas. En una reunión con el director del proyecto, recomiendo que se revisen los requisitos, los diseños y el código. El director del proyecto dice: “Eso parece mucho trabajo. ¿Cuál es el beneficio?"
¿Cuál cree que es una buena respuesta que responderá a la pregunta del director del proyecto?
Las pruebas modernas tienen que ver con cómo ayuda a "Acelerar el logro de la calidad de envío ".
¿Tus reseñas ayudan a acelerar? ¿Qué métricas usas para crear pruebas de eso? Las pruebas ayudan a reducir los riesgos, pero ¿a qué costo? ¿Cuál es el retorno de la inversión.
En general, creo que la pregunta de los gerentes de proyecto parece muy válida. Me pregunto si realmente hay un problema de calidad. Tenga cuidado al introducir cascada como compuerta en un proceso de trabajo actual.
En lugar de sugerir mejoras en los procesos que podrían haber funcionado para usted en el pasado, le facilitaría un análisis de riesgos y juntos mitigaría los riesgos si fuera necesario.
Lee:
¿Qué quiere decir con "críticas" en este contexto? Muchos equipos de desarrollo realizan revisiones por pares del código y el análisis porque descubren que las revisiones mejoran la productividad y la calidad. Muchos equipos también hacen que las reseñas de los usuarios finales formen parte de su Definición de Listo para el trabajo. Esto es algo sobre lo que todo el equipo debe tener una opinión, no es algo que deba discutir solo con el PM.
Las puertas de revisión , es decir, los miembros senior del equipo o las partes interesadas pueden aprobar todas las especificaciones antes de las pruebas, son algo muy diferente. En mi experiencia, las revisiones cerradas tienen un valor limitado porque la evidencia de las pruebas, la revisión por pares y la aceptación del usuario generalmente es mucho más valiosa que cualquier proceso formal de revisión inicial. Las puertas de revisión tienden a generar mucho trabajo y pueden volverse fácilmente contraproducentes porque pueden limitar el alcance de los cambios tardíos (la limitación de los cambios suele ser la razón que se da para introducir revisiones en primer lugar).
Es un principio de buena gestión del trabajo eliminar o reducir el número de pasos por los que debe pasar un solo elemento de trabajo. Si su equipo aún no tiene una forma establecida de trabajar, ¿por qué no probar diferentes enfoques y ver cómo funcionan en su entorno?
Creo que es una pregunta muy justa para que la haga el primer ministro. Evaluar el esfuerzo propuesto frente a sus beneficios, costos y riesgos es un liderazgo y una gestión adecuados. Si tiene una propuesta para probar, debe poder articular el valor. Si no puede, entonces ¿realmente entiende el trabajo?
La prueba es la mitigación de riesgos, y los PM tienen la responsabilidad de determinar el grado de mitigación de riesgos apropiado. ¿Cuánto dinero gastamos para mitigar un resultado probabilístico de diversos grados de impacto?
Con la calidad, puede gastar dinero y tiempo indefinidamente inspeccionando y reinspeccionando y moviendo la aguja de la calidad muy poco, si es que lo hace, persiguiendo una sensación de perfección que no podemos lograr razonablemente. Por lo tanto, hay que trazar una línea para mitigar el riesgo de calidad en la que ya es suficiente y el resto corre el riesgo.
No estoy seguro de que haya una buena respuesta a la pregunta del gerente. En algunos contextos, puede ser beneficioso contar con revisiones formales de entrada. Sin embargo, las revisiones tienden a ser inspecciones posteriores, que no son la mejor manera de incorporar calidad a un producto.
Recomiendo repensar lo que quieres decir con "revisión". Por ejemplo, los Tres Amigos pueden ayudarlo durante la ingeniería de requisitos y las actividades de planificación para asegurarse de que obtiene todas las perspectivas de un trabajo. En lugar de tener una revisión posterior a los hechos, todas las personas clave colaboran haciendo el trabajo juntos. De manera similar, el uso de programación en parejas o multitud para desarrollar el software puede reducir la necesidad de cualquier tipo de revisión formal del código.
Específicamente, como administrador de pruebas, no me gustaría imponer revisiones. En cambio, me gustaría que las personas que probarán el sistema se involucren, como colaboradores, desde el comienzo del esfuerzo hasta el final. También me gustaría que los otros miembros del equipo (desarrolladores, diseñadores, gerentes de proyecto, gerentes de producto, analistas comerciales, etc.) participen e inviertan desde el principio hasta el final del proceso de prueba para asegurarse de que los problemas que surjan en pruebas posteriores pueden clasificarse y resolverse de manera efectiva.
Posibles argumentos:
La mayor ventaja individual: ayuda a abordar la arrogancia de los desarrolladores que hacen suposiciones erróneas.
¿Por qué es difícil?
¿Por qué se cuestiona?
Tiene que ralentizar los procesos de trabajo con más revisiones, pruebas y debates... para acelerar o mantener la velocidad de entrega a lo largo del tiempo. Disminuir la velocidad hoy para acelerar mañana, la próxima semana y el próximo mes requiere madurez y visión.
Parece que el PM le está pidiendo un análisis de costo/beneficio. Las pruebas y revisiones ralentizan el proceso de producción de software (al menos a corto plazo), lo que significa que cuestan dinero. Si desea convencer al PM de que vale la pena implementarlos, debe demostrar que el valor esperado de hacerlo supera ese costo.
No necesita cifras exactas, pero sí deben ser lo suficientemente precisas para ser convincentes. Trate de obtener algunas estimaciones de cuánto tiempo y dinero se gasta actualmente en arreglar las cosas que están rotas en el código base, incluido el valor perdido que proviene de que los desarrolladores no pueden ofrecer nuevas funciones según lo programado. Si no tiene muchos de esos datos disponibles (por ejemplo, porque es un producto nuevo), intente encontrar algunas figuras públicas relevantes para su industria.
De improviso ... "lo más probable es que el primer ministro ya sepa la respuesta". Pero, él (s) sabe que sus sugerencias necesitan más desarrollo: (s) no podría aceptarlas antes que otras partes interesadas del negocio. Me parece bien.
Por ejemplo: "Recomiendo que se revisen los requisitos, los diseños y el código". en realidad es bastante genérico. Lo mismo podría decirse de "todos los proyectos de software en todas partes".
Hablando en serio, primero quizás debería invitar al PM a sugerir cómo su papel podría ser de mayor beneficio para él o ella. O bien, para sugerir cómo podría mejorarse su propuesta inicial (como él lo ve).
don branson
NoEseChico
MCW