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.
|
|