Tarea: Valorar y defender la calidad
Esta tarea se centra en dar soporte al esfuerzo global de identificar las disparidades de calidad, evaluar su impacto y riesgos, y encontrar soluciones eficaces.
Disciplinas: Prueba
Objetivo

El objetivo de esta tarea es:

  • Identificar y fomentar la resolución de los defectos que tengan un impacto negativo grave en la calidad del software
  • Supervisar el progreso y dar soporte a la realización de los cambios pertinentes que mejoren la calidad del software al nivel deseado
  • Fomentar la resolución a tiempo de los defectos que impidan o desvirtúen el esfuerzo de prueba
Relaciones
Pasos
Examinar los resúmenes de evaluación de prueba más recientes
Objetivo:  Entender la valoración de resumen actual de los problemas de calidad del producto que ha identificado el equipo de prueba. 

Empiece examinando los resúmenes de evaluación de prueba que ha preparado el equipo. Compare la información de la evaluación con el plan de prueba de la iteración para entender el resumen en el contexto del trabajo planificado. Plantee las ambigüedades y los problemas con los miembros del equipo de prueba que han preparado el resumen y resuélvalos.

Para este paso y los siguientes que tratan sobre la recopilación de información y la valoración de la calidad del software, intente obtener una vista equilibrada que incorpore medidas objetivas y subjetivas. Recuerde que los números objetivos sólo proporcionan una imagen parcial, y que necesitan el soporte y la explicación del "clima" actual del proyecto. Por el contrario, no se base sólo en rumores y en la especulación subjetiva sobre la calidad del software: busque evidencias objetivas de soporte. Se recomienda complementar los datos objetivos mediante el debate con líderes del equipo o miembros individuales del equipo, siempre que sea posible, para recopilar valoraciones subjetivas y determinar cuánta confianza puede depositar en los datos objetivos.

Examinar el contexto adicional en resultados de búsqueda seleccionados
Objetivo:  Profundizar en los resultados de búsqueda que dan soporte a la valoración de resumen actual de la calidad del producto. 

A partir de los resúmenes de evaluación de prueba, examine el contexto adicional en resultados de búsqueda seleccionados. Profundice en los resultados hasta que esté seguro de entender los problemas más importantes que se han identificado en los resúmenes de evaluación de prueba.

Asimismo, revise los datos y busque tendencias relevantes en los datos de los resultados de la prueba que se hayan podido pasar por alto. En general, es más importante identificar qué indican las tendencias relativas en los datos que buscar números absolutos. Busque indicaciones como, por ejemplo, anomalías en unas áreas que se relacionen con anomalías en otras.

Examinar las solicitudes de cambio clave
Objetivo:  Obtener información de fondo que permita debatir de forma eficaz los problemas pendientes más importantes y las soluciones posibles. 

Se recomienda limitar este ejercicio a los problemas más apremiantes y las solicitudes de cambio asociadas. Podrá dedicar más energía a un número menor de problemas, que a menudo tienen una mayor probabilidad de afectar a la calidad del producto. Si tiene una gran lista de problemas clave, se recomienda dedicarles un esfuerzo proporcional a su prioridad relativa: no malgaste recursos defendiendo el problema más insignificante. No obstante, tenga en cuenta que un número elevado de solicitudes de cambio pendientes de baja prioridad puede permitir una sentencia sobre la calidad de los productos tan significativa como unos pocos cambios de alta prioridad. Intente agrupar las solicitudes de cambio de baja prioridad en aspectos lógicos de calidad basándose en el riesgo de calidad que representan. Esto permite articular y defender más claramente su efecto combinado en la calidad.

Identifique las tendencias relevantes que sean evidentes en los datos generales de las solicitudes de cambio. En general, es más importante identificar qué indican las tendencias relativas en los datos que buscar números absolutos. Busque señales positivas como, por ejemplo, un índice constante de resolución de defectos, o un aumento gradual y una posterior disminución en el índice de resolución con el tiempo. Esté atento a los picos altos y bajos en el índice de resolución que indiquen que el equipo de desarrollo haya encontrado problemas de proceso, entorno, políticos o de otro tipo, que reduzcan la productividad.

Nota: también puede aprovechar la oportunidad de aumentar la claridad de las solicitudes de cambio asociadas, eliminando la ambigüedad, así como el lenguaje y el razonamiento emotivos. Si realiza estos cambios, analice las mejoras con las personas que hayan creado originalmente estos productos de trabajo para que entiendan por qué son importantes las mejoras.

Identificar las disparidades de calidad, y valorar el impacto y el riesgo asociados
Objetivo:  Formular su percepción de los problemas clave en términos del riesgo que representan para la calidad del producto y el riesgo asociado que suponen para el éxito del proyecto de desarrollo de software. 

Identifique cada disparidad de calidad, y valore el impacto y el riesgo asociados de cada problema que crea la disparidad. Considere estrategias de mitigación y contingencia, formule sus ideas iniciales al respecto y debátalas con otros miembros del equipo.

Tenga en cuenta que el concepto de calidad "perfecta" es probablemente un mito. Utilice siempre un "listón de calidad" alcanzable y realista cuando valore la calidad e identifique las disparidades de calidad. Consulte el apartado Técnica: Calidad del producto

Identificar las acciones fundamentales para solucionar las disparidades de calidad
Objetivo:  Producir una lista mínima realista de acciones necesarias para negociar una resolución satisfactoria de los problemas clave. 

Para cada disparidad clave en la calidad, considere estrategias de mitigación y contingencia. Formule sus ideas iniciales al respecto y debátalas informalmente con otros miembros del equipo para obtener una percepción más clara y validar sus teorías. En el caso de las soluciones, se recomienda tener varias opciones: permiten sopesar las ventajas e inconvenientes, y elegir la mejor solución para un contexto dado.

Trabaje en busca de un conjunto de posibles soluciones y sugerencias útiles que permitan al equipo del proyecto solucionar adecuadamente cada disparidad de calidad. Es importante hacerlo de forma que se reconozca la contribución útil del esfuerzo de prueba en la resolución del problema, que no sea un simple informe de los problemas. Este es un aspecto importante para fomentar el trabajo del equipo de prueba, y ganar el respeto y la colaboración de los miembros de otros equipos.

Identificar y comprometerse con los defensores de los principales problemas
Objetivo:  Recopilar soporte de manera informal para resolver los problemas clave y entender qué propuestas tienen más probabilidad de ser aceptadas. 

Apoyar una causa perdida no es gratificante. Normalmente, el enfoque más eficaz es identificar soluciones a los problemas que tengan más probabilidad de conseguir el respaldo, la aceptación y el compromiso de finalización de los equipos del proyecto. Mantenga una relación estrecha con los encargados de tomar las decisiones, y empiece por exponer estos problemas clave de manera informal en conversaciones entre dos personas. A menudo, esta es una forma excelente de ganar soporte y encontrar soluciones alcanzables.

A veces, no tiene otra opción que apoyar una solución que no es popular entre el equipo de desarrollo. Cuando este sea el caso, es todavía más importante saber de quién puede esperar soporte y buscar formas de vender la solución que presenten sus ventajas lo más claramente posible, o explicar claramente la peor situación que puede ocurrir si no se resuelve el problema.

Negociar la prioridad del trabajo
Objetivo:  Fomentar la aplicación de una solución adecuada en un intervalo de tiempo aceptable que no afecte negativamente a la calidad necesaria. 

Este es el quid de la defensa de la calidad: poder negociar una solución adecuada que satisfaga al equipo de desarrollo y que no reduzca significativamente la calidad del producto. Recuerde que, en la mayoría de los casos, el equipo de prueba es principalmente un asesor sobre la calidad, por lo que debe tener cuidado de no exigir la aplicación de una determinada resolución.

No obstante, es importante que el equipo de prueba haga un buen trabajo como defensor de la calidad, y esto a veces significa ser portador de noticias que el equipo del proyecto preferiría no escuchar. Aquí es donde un buen equipo de prueba proporciona al esfuerzo de desarrollo todas las perspectivas del problema, las soluciones posibles y toda la información que permiten las ventajas e inconvenientes de cada opción. Debe actuar hasta cierto punto como agente para los clientes finales del producto y ayudar en la negociación de las soluciones que se adapten a sus intereses.

Supervisar el progreso del trabajo
Objetivo:  Proporcionar soporte, implicarse y estar atento al progreso de la resolución del problema. 

A veces, los defectos y otras solicitudes de cambio se pierden entre tanto desarrollo del producto básico y expansión de características. Esto se debe en parte a que es más atractivo para los desarrolladores trabajar en "nuevos temas" que solucionar un código antiguo y con errores, y en parte a que supone una ventaja empresarial más obvia añadir un nuevo objeto que solucionar un objeto dañado. Como defensores de la calidad, el equipo de prueba debe ayudar al proyecto a ver arreglos de defectos importantes hasta el final.

Los equipos de software competentes encuentran un buen equilibrio entre la mejora de la calidad mediante la resolución de defectos y la expansión cada vez mayor de las características. El equipo de prueba puede ayudar al equipo del proyecto a buscar nuevas formas de animar y dar soporte a la mejora de la calidad, en lugar de asumir un rol de "policía de la calidad" menos colaborador y más antagonista.

Confirmar la resolución adecuada de problemas clave
Objetivo:  Confirmar que las resoluciones de problemas clave realmente resuelven el problema sin importantes efectos secundarios negativos. 

Sea cual sea la solución que decida el equipo de desarrollo para resolver un problema de calidad, la resolución debe aumentar en última instancia la calidad. Asegúrese de dedicar tiempo a la valoración de la mejora de calidad que aporta una determinada resolución, y que ésta solucione el problema original y no tenga un impacto negativo en la calidad por otro lado.

Para aquellas soluciones que implican un determinado nivel de riesgo, se recomienda realizar pruebas en un release anterior, antes de dedicar mucho tiempo y esfuerzo en ejecutar al completo la resolución.

Evaluar y verificar los resultados
Objetivo:  Verificar que la tarea se ha realizado correctamente y que los productos de trabajo resultantes son aceptables. 

Ahora que ha terminado el trabajo, se recomienda verificar que el trabajo tenía el valor suficiente y que no sólo ha gastado una gran cantidad de papel. Debe evaluar si el trabajo tiene la calidad correcta y si es lo suficientemente completo para que resulte útil a aquellos miembros del equipo que vayan a utilizarlo posteriormente como entrada de su trabajo. Siempre que sea posible, utilice las listas de comprobación proporcionadas en RUP para verificar que la calidad y la completitud son lo "suficientemente buenas".

Fomente la participación en la revisión del trabajo interno de las personas que realizan tareas basadas en los resultados de su trabajo. Hágalo mientras todavía tenga tiempo para realizar acciones para solucionar sus problemas. También debe evaluar su trabajo en los productos de trabajo de entrada clave para asegurarse de que los ha representado de forma precisa y suficiente. Para ello, es muy útil hacer que el autor del producto de trabajo de entrada revise su trabajo.

Recuerde que RUP es un proceso de entrega iterativo y que en muchos casos los productos de trabajo evolucionan con el tiempo. Como tal, no siempre es necesario (y a veces es contraproducente) formar completamente un producto de trabajo que sólo se utilizará de forma parcial o que no se utilizará en absoluto en un trabajo inmediatamente posterior. Esto se debe a que existe una alta probabilidad de que la situación alrededor del producto de trabajo cambie (y que las suposiciones realizadas cuando se creó el producto de trabajo se demuestre que son incorrectas) antes de que se utilice el producto, lo que da como resultado un esfuerzo inútil y una revisión costosa. Asimismo, evite la trampa de invertir demasiados ciclos en la presentación en detrimento del valor del contenido. En entornos de proyecto en los que la presentación tenga importancia y un gran valor económico como entregable del proyecto, puede utilizar un recurso administrativo para ejecutar tareas de presentación.



Más información