Roles

Equipo QA – El recurso oculto

Posted on 4 marzo 2009. Filed under: Calidad del Software, Ingeniería del Software, Metodologías de Desarrollo, Opinión, Procesos Ágile, Recursos Humanos, Roles, Trabajo en Equipo, Waterfall |

¿Que es lo primero que viene a mente cuando mencionamos Ingeniero QA o Tester?

Hay quienes piensan y asumen que las actividades típicas del Tester, las puede llevar a cabo cualquiera, ya sea utilizando procesos de desarrollos tradicionales o Agiles.

La razón puede estar fundada en el concepto erróneo de que cualquier persona puede determinar si una aplicación funciona o no. Sin embargo con este pensamiento se deja de lado la naturaleza destructiva de las actividades de Testing y el no centrarse en el funcionamiento correcto, sino en los aspectos fallidos del software.

También se está asumiendo que el aseguramiento de calidad es solo cumplir con actividades de Testing. Nada más lejos de la realidad.

En las metodologías tradicionales de desarrollo de software, se tiene especial cuidado con la planificación de las pruebas, de modo tal que esta sea acorde a la definición temprana de los requerimientos (obviando las verificaciones y validaciones QA) y en base a un aprendizaje oportuno de como debería funcionar el sistema, de modo tal que según lo planificado, en ciclos de pruebas de sistemas se valide la completitud y correctitud del sistema en base a tales requisitos.

Como contrapartida, se supone un Plan de Pruebas rígido, con muy baja adaptabilidad al cambios de requerimientos y a aparición de nuevos requisitos.

En la vereda del frente estarían las metodologías Agiles, donde la planificación del Testing debe ser adaptativa, acorde a la velocidad de cambios en los requerimientos del sistema, lo cual puede presumir una mayor participación de los miembros QA en etapas tempranas del proceso de desarrollo, inclusive en la misma formación de los requisitos, su analisis y estimaciones, lo cual comprensiblemente podría ser deseable.

Esto es en resumen como se comporta el Testing en metodologías no Agiles.

De este modo, conceptualmente la participación del QA cambia de un rol de “full-control” a “full-partner” del resto de los miembros del equipo.

Esta concepción permite revalorizar los roles QA debido al uso petenciado de los mismos, aportando un valor más estratégico para las necesidades de los negocios que atienden los sistemas que se construyen.

Los Testers, podrían ser utilizados a su máxima potencia, con actividades operativas que ayudan a los desarrolladores a promover la generación de soluciones más eficientes y en instancias tempranas.

A su vez los miembros del equipo QA podrían ser fuentes de información constante referido al comportamiento del sistema en construcción, permitiendo adelantarnos a cambios en los requerimientos, requerimientos mal concebidos o desarrollados en modo no deseado, promover mejoras y una lista larga de etcs. que en definitiva orientan a traves de todo el ciclo de vida del proyecto.

Pero no confundamos esta revalorización del personal QA tratando de abarrotarla detrás de las metodologías Agiles, ya que el concepto puede ser aplicado a cualquier proceso de desarrollo. De hecho, las metodologías Agiles no han planteado este paradigma ni es algo que les pertenece, aún cuando se utilice la terminología “Testing Agile”. Inclusive muchos “pseudoagilístas” consideran a un Tester como a cualquier otro recurso QA, un recurso de menos rango y hasta despreciable para la organización.

QA se da cuenta de la evolución por la misma adaptación que debió sufrir acorde a la velocidad de respuesta que requieren los procesos de desarrollos actuales.

Asumamos que un cambio de paradigma QA es posible aún dentro de procesos tradicionales. Aún así, el cambio no puede gestarse por si solo, debe surgir de un cambio en el paradígma organizacional.

Fuentes de inspiración:
Testers: The hidden resource

Leer entrada completa | Make a Comment ( Comentarios desactivados )

Palabras importantes o como crear confianza hacia el líder

Posted on 2 enero 2009. Filed under: Actitudes, Habilidades Personales, Liderazgo, PNL y Coaching, Roles, Trabajo en Equipo |

Reconocer los errores propios

Reconocer que uno no sabe de todo, que no es infalible, que no siempre lleva la razón, que necesita a los otros, es una magnífica oportunidad de acercarse a los suyos.

Felicitar en público aquellas cosas que se han hecho bien

Dejar los reproches para el ámbito privado, reconocer la valía de las personas y pedir opinión ayuda a resolver muchos sencillos problemas cada día.

Pida opinión y habrá ganado a un fiel colaborador
La persona que trabaja en algo generalmente es la más cualificada para solucionar un problema en su ámbito.

No tema parecer desinformado o sin conocimientos

No debe conocer ni dominar todos los ámbitos.  Consulte, muestre que necesita información y busca conocimientos. Si lo hace reforzará su imagen de ser falible, y dará su minuto de gloria a una persona de la organización. Si además, una vez tomada la decisión, le pide su opinión sincera y luego le da las gracias, el resultado será formidable. Ellos a su vez lo harán con las personas que tengan a su cargo, por lo que de su ejemplo, habrá obtenido una reacción en cadena que muy probablemente llegue hasta el último escalón de su organización.
Eso va creando cultura y confianza en la empresa y en su líder.

Use siempre estas “palabras importantes”

La seis palabras más importantes: Reconozco que he cometido un error.
Las cinco palabras más importantes: Estoy muy orgulloso de ti.
Las cuatro palabras más importantes: ¿Cuál es tu opinión?
Las tres palabras más importantes: Si te parece.
Las dos palabras más importantes: Muchas gracias.
La palabra más importante: Nosotros.
La última palabra y la menos importante: Yo.

Extraído del Newsletter del Grupo Newsletter del Grupo Argentina País Emergente. Tiempo para Decidir. 9º entrega “Liderar con el ejemplo”

Feliz año, feliz vida!

Leer entrada completa | Make a Comment ( Comentarios desactivados )

Quien es quien – II

Posted on 23 diciembre 2008. Filed under: Actitudes, Aptitudes, Artículos sueltos, Recursos Humanos, Roles, Trabajo en Equipo |

Que opinan de esto?

Es algo que encontré WEBEANDO y me pareció muy gráfico.

Algo que nunca aprendo es que debo guardar las URL de referencia. Lo siento pero esta vez no lo hice y google no me ayudó mucho tampoco y solo puedo dirigirlos a un buén grupo de discución donde mostré este mismo “artículo suelto”

1. Gestor de proyectos es aquel que piensa que nueve mujeres pueden traer un bebé al mundo en un mes.

2. Desarrollador es aquel que piensa que toma 18 meses traer un bebé al mundo.

3. El empresario es aquel que pretende que una sola mujer puede traer nueve bebés al mundo en un mes.

4. Cliente es aquel que no sabe por qué quiere traer un bebé al mundo.

5. Manager de marketing es aquel que piensa que puede traer un bebé al mundo incluso si no hay hombres ni mujeres disponibles.

6. El equipo de optimización de recursos piensan que no necesitan un hombre ni una mujer, ellos traerán un bebé al mundo con cero recursos.

7. El equipo de documentación piensa que a ellos no les importa si se trae un bebé al mundo, ellos sólo documentarán nueve meses.

8. El encargado de SQA es aquel que nunca está contento con el proceso de traer un bebé al mundo.

9. El tester es aquel que siempre le dice a su mujer que ese no es el niño definitivo.

Leer entrada completa | Make a Comment ( Comentarios desactivados )

Quien es quien – I

Posted on 22 diciembre 2008. Filed under: Actitudes, Aptitudes, Habilidades Personales, Metodologías de Desarrollo, Opinión, Recursos Humanos, Roles | Etiquetas: , , , , , |

Pensando los Roles y Competencias para definir nuestro proceso de trabajo

Las metodologías de desarrollo de software suelen establecer roles y delimitar sus competencias,  remarcar sus responsabilidad, indicar interdependencias, definir elementos de entrada-salida y proponer la repetición constante de estos ítems, con variantes que le dan alguna particularidad a los distintos procesos.

El objetivo es inicialmente presentarse de manera clara al publico usuario, como un mecanismo  estable, controlable, medible y repetible, que garantice en mayor o menor medida, el éxito de los proyectos permitiéndole llegar a su fin, con el uso de la secuencialidad propuesta.

Suele suceder que los modelos parecieran no tener en cuenta al área QA y Testing como un área independiente dentro los proyectos de productos/servicios, que genera su propio proyecto donde conviven productos/servicios que dan soporte al proyecto matríz.

Tal es así que las competencias QA y Testing no son tan bien definidas  y explicadas como las compentecias de otros roles, en la mayoría de los procesos. Y aunque algunos presentan detalles excesivos, quizás no encuadran correctamente a los roles QA.

Independientemente del proceso que se intente aplicar y su definición de roles y competencias, sugiero que las organizaciones consideren la aplicación de roles, pero justificado principalmente por el enfoque y especialización que exista o se desee.

Por ejemplo, la existencia de Líderes de Proyectos que a su vez sean verdaderos especialístas en los negocios que generan los productos que lideran.

Los Arquitectos de Sistema los mejores diseñadores y programadores, sobre todo líder especialista en “los aspectos íntimos de los sistemas”.

El Líder QA de perfil analítico transversal y el principal
“entrenado” en el uso de los productos en prácticamente todos los
niveles de los sistemas. También uno de los probadores más
importantes de la organización, guía de pruebas en todas las fases de revisión.

El equipo de testing  con competencias técnicas variadas y acabadas, conocedores de técnicas y métodos de pruebas, pero con grandes atributos actitudinales.

Las principales potencias de un equipo QA bien conformado quizás son:
capacidad analítica en el sentido transversal a lo que se supone como
la mejora solución técnica, la obsesión por demostrar que el sistema
tiene defectos, orientación bien marcada a las pruebas exploratorias,
proactividad y comunicación eficiente, entrenamiento anticipado en el
uso del sistema, énfasis en detectar debilidades en los requerimientos, énfasis en reconocer y entender por que y para que existe cada requerimiento, capacidad de proponer nuevas alternativas de uso, control del tiempo y el sentido de fin de fases.

Creo que habilidades de esta naturaleza no solo en los roles QA, sino en otros que reciben productos de fases anteriores y las destilan a fases posteriores en los procesos de desarrollo, ayudan a definir un proceso bien limpio y delimitado para elaborar, planificar, seguir y finalizar los proyectos.

Leer entrada completa | Make a Comment ( Comentarios desactivados )

Quien es quien – III

Posted on 5 diciembre 2008. Filed under: Comunicación, Habilidades Personales, Opinión, Recursos Humanos, Roles, Trabajo en Equipo |

Aunque causan gracia, es cierto que un mismo equipo de proyecto se puede ver con claridad a personajes que cumplen a rajatablas con procesos, etapas y pseudo etapas. Otros no tanto y algunos ni…

A modo de ejemplo y para reírme de mi equipo les cuento:

Líder de Proyecto

Más bien parece un Gerente de QA imponiendo a latigazos de lengua y soberbia, el rigor del proceso. Obviamente con efectos contrarios. Bien prendida a una montaña de templates, checklist y cuadernos de anotación más las herramientas informáticas de gestión de las que ya dispone.
Castiga y no premia, negocia su futuro con 14 horas en la oficina y 4 horas más de trabajo en su departamento.
Se enteró ayer que tiene un hijo de 2 años y un marido, cuando al llegar ambos reían y jugaban con la empleada doméstica.

Arquitecto de Sistema

La mayor parte de los días es Peter Pan negándose rotundamente a cargar sus avances de actividades, demorando eternidades aquellas actividades asignadas con apenas horas de duración estimada, renegando permanentemente de la matriz de rastreabilidad, proponiendo cada media hora la eliminación de algún documento formal, y peleando con el área de QA como si de un deporte se tratara.
Para el colmo delega tareas de revisión por pares dando instrucciones precisas de como debe ser el resultado de su revisión (llevada a cabo por otro) y por supuesto Testing no existe, salvo el unitario. Se conoce todos los procedimientos y procesos existentes, opina siempre en sentido contrario aunque la otra persona haya dicho lo mismo con otros términos.
Los workshop de 30 minutos con el duran 1.30 horas, solo está de acuerdo con lo que tiene que ver con sus criterios de medición y por lo general solo se refiere al código que el generó o del que se hizo cargo. El resto es mala palabra o esta mal, o el que lo hizo “es un muerto“. El resto del tiempo es chating.

Desarrollador Líder – Desarrollador Estrella

Me resulta definir su estado, pues el muchacho esta siempre bien dispuesto, revisa con exagerada motivación cada uno de los componentes de su actividad y de las que le fue delegada por su Arquitecto de Software, critica en forma constructiva el código que genera, el código que modifica, la arquitectura del sistema y de hecho tiene un umbral de conocimientos muy alto que cuesta definir que cosa no sabe.
Sin embargo no esta conforme con lo que hace, quiere cambiar a otra empresa y ya van cinco en dos años, no le apetece la cultura actual y creo que sueña con ser la estrella de una empresa estrella. Debe de tener aires de superioridad, pero es buen compañero y conversador aunque siempre que se comenta algo, ya le pasó lo mismo a él, a un intimo amigo, a la madre o padre, íntimo amigo de madre o padre o con más ocurrencia a su hermano mayor.

Analista de Pruebas

Naturalmente, por definición de proceso CMMI-5, debería pertenecer al departamento de QA, es decir, ser externo al equipo de proyecto. No debe verse influenciado por el Líder de Testing, ni por el Arquitecto del Sistema, ni por el Sponsor, ni por los Desarrolladores. Debe ser una suerte de verdugo del sistema, aunque el mayor colaborador.
Pero la suerte de esta persona es diferente al imponerse una política organizacional en la cual la empresa exige contar con su propio equipo de Testing. Entonces es influenciado por la Líder de Proyectos a realizar la carga de avances mentirosas, de actividades mal planificadas con estimaciones lastimosas por que no tuvo en cuenta las horas de I+D,  las de generación de los ambientes de prueba y juegos de datos, o por que no estimó que la tecnología a aplicarse es nueva y solo conocida por el área de desarrollo.
Si desvía los tiempos, seguramente quedará sin trabajo.
El arquitecto odia a los testers, no hay para que decir más.
Los desarrolladores odian a los testers.
El área de QA es de otra empresa. El Analista de pruebas (tester) no es de QA :(

Necesariamente para sobrevivir en un entorno así, hay que tener una gran adaptación según la situación lo requiera, pero particularmente yo, vivo rezando a Dios.

Saludos, Javo.

Leer entrada completa | Make a Comment ( Comentarios desactivados )

Como lidiar con un usuario que quiere liderar el proyecto?

Posted on 4 diciembre 2008. Filed under: Comunicación, Habilidades Personales, Liderazgo, PNL y Coaching, Project Management, Recursos Humanos, Roles, Trabajo en Equipo |

Creo que la pregunta está planteada en un contexto demasiado amplio y por lo menos surgen algunas preguntas:

¿Es posible liderar si no eres miembro del equipo del proyecto?
Los Stakeholder son todos los que sufren o gozan los resultados o productos del proyecto, pero solo algunos Stakeholder son miembros del equipo del proyecto.

¿Estará realmente interesado en liderar un equipo que no conoce?
Liderar no se consigue con solo presentarse y decir “hola soy el cliente y tengo una titulación en liderazgo, ahora están bajo mi tutela”. Liderar involucra roce con tu equipo y conocimiento de sus verdaderas fortalezas y debilidades, creo que de allí surge la capacidad de compromiso.

¿Querrá estar informado al detalle?
Eso es posible y hoy en día los clientes están mucho más involucrados con los proyectos que generan.

¿Quizas quiera determinar que se hará, como se hará, cuando se hará, introducir cambios?
Bueno, eso depende de las características del proyecto y de la flexibilidad del mismo para adoptar cambios, pero los controles pueden y deben ser planteados como hitos del proyecto y ese nivel de detalle es necesario que nuestro cliente involucrado tome decisiones y nos haga pedidos concretos.

En conclusión, podemos hacer que nuestro cliente sea un verdadero lider de nuestro proyecto, creando un canal de comunicación multinivel donde pueda no solo conversar con el LP del proyecto, sino con otros invlucrados y miembros del equipo del proyecto, por ejemplo con el Líder de Calidad para definir los esperables de calidad, conocer las estratégias de pruebas y métodos que se usaran para asegurar calidad. También se puede requerir su participación en algunas reuniones en las que su participación sería clave, siempre cuidando que su acceso no sea “irruptivo” y cuidando los alcances.

Creo que nuestro cliente es nuestro mejor líder si lo sabemos escuchar, guiar y enseñarle a cumplir su rol tan importante.

Saludos, Javier.-

Leer entrada completa | Make a Comment ( 2 so far )

Liked it here?
Why not try sites on the blogroll...

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.