Opinión

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

Anuncios
Leer entrada completa | Make a Comment ( Comentarios desactivados en Equipo QA – El recurso oculto )

Actitudes y Aptitudes – 2

Posted on 20 febrero 2009. Filed under: Actitudes, Aptitudes, Capacitación, Habilidades Personales, IT Management, Opinión, Pruebas de Campo, Recursos Humanos | Etiquetas: , , , , |

Agustín, ¿que esperabas obtener de las respuestas de los entrevistados?

sería importante que nos contaras eso para saber si no pecaste de lo que la mayoría de los entrevistadores pecan, que quieren innovar en las entrevistas siguiendo un proceso que en definitiva es clasisista. 

Es muy interesante ver cuando los entrevistadores hablan mal de los entrevistados adusiendo que no pueden resolver tal o cual “asunto simple” que uno mismo está acostumbrado a resolver a diario, o no responden de acuerdo a las espectativas.

Sin embargo, la mayoría de las veces no se explica el contexto de la entrevista, por ejemplo indicando que no se esperan respuestas tradicionales y que se busca que los interesados en el trabajo puedan responder innovativamente, hasta con un toque de “infantilismo” si se quiere aceptar el término.
Así mismo no se plantean las dinámicas que le permita al entrevistado adaptarse rápidamente al proceso de selección y logre participar de juegos, actividades de grupo y cosas por el estilo que ayuden al mismo entrevistador ir detectando líderes, planificadores, operarios, según la participación y su modo de resolver los aspectos de las dinámicas.

Luego hay que tener en cuenta que muchos recruiters intentan innovar en la forma de encontrar nueva gente, pero en cuanto ven un talento, inmediatamente le buscan el “pero”, y lo tildan de excéntrico o viciado, dado a que gente de esta naturaleza es un poco excentrica y hasta demasiado exigente. Allí mismo comienza el proceso de truncar el caracter innovador del prospecto.

También se debe tener autocrítica
Analizar si se está dispuesto a que la gente sea proactiva, auto resolutiva, extrovertida y motivada como motivadora, por que aunque son atributos deseables en las personas, son aplacables en la mayoría de los entornos de trabajo.

¿Se está dispuesto a detectar los talentos con potencial pero sin las habilidades técnicas maduras?
creo fuertemente que esta es la principal razón que evita que las personas talentozas estén ahora mismo trabajando y no pasa lo mismo con quienes mañana mismo puede iniciar una actividad técnica que aporte valor técnico y operativo inmediato, pero que a la larga su curva de aprendizaje en el resto de los ámbitos, es plana.

Buscar talentos es un proceso de maduración organizacional
fortalecido por un aprendizaje por parte de los RRHH, en estrategias, métodos y técnicas específicas y hasta comprendiendo aspectos psicológicos y neurofisiológicos de los que ni si quieran oyeron hablar y mucho menos entienden de buenas a primeras.
Lleva mucho tiempo comprender esto y mucho más aplicarlo y mucho más aún ver los resultados reales.

“Extreme Interviewing”
es un metodo reciente de entrevistas basadas en dinámicas de grupo y trabajo específicos que ayudan a detectar talentos, basados no netamente en habilidades técnicas, sino más bien en actitudes correctas que permitan la absorsión de nuevas habilidades según el curso de los negocios actuales.
Se pretende detectar a las personas que podrán sostener una curva de aprendizaje constante dentro de la organización.
Intenta validarse en contraposición con las “Entrevistas Tradicionales”, pero lo malo es que ya se le dió una orientación que la liga con las metodologías Ágile.

¿Malo por que?
Por que ya antes, con mucho sentido común, muchos se dieron cuenta que la búsqueda y reclutamiento tradicional de personal IT (o de cualquier otro tipo), son obsoletas o comenzaban a serlo y mientras estas buscaban “robots tecnificados”, las personas comenzaron a estar más lejos de estas habilidades requeridas, por la velocidad del cambio tecnológico, por los desmanes psicológicos que propinan seguir estos rítmos de aprendizaje contínuos, por la mala calidad de vida que genera en si mismo tratar de estar al corriente, sobre todo los que sientes estar siempre al borde del avismo para permanecer en sus puestos de trabajos o conseguir uno mejor.

En artículos de opinión personal, yo mismo ya había hablado de este tema y muchos foros había preguntado cual es la preferencia en una organización “¿un elevado perfil técnico o una mejor actitud?”. Un ejemplo puede leerse aqui: “Actitudes y Aptitudes – 1”

Sin embargo este tipo de “entrevistas extremas” tiene una connotación importante, pues todos los posibles candidatos son convocados a trabajar juntos en sesiones de trabajo por pares, donde se les asigna una tarea a realizar, con la premisa de resolver un problema, sin embargo, los recruiters no observan solo las capacidades de resolución, sino el desembolvimiento del prospecto como un ser humano que interactuará en una sociedad de trabajo colaborativo y con objetivos comunes, tal es así que la resolución del problema pasa a ser un elemento secundario y se valor mucho la capacidad de “hacer sentir bien a tu socio colaborador”.

La respuesta siempre apunta al equilibrio
pero los reclutadores parecen no entenderlo, ni las organizaciones cuando inician el proceso de búsqueda para cubrir vacantes. Es en ese punto cuando quieren al “genio de la bola de cristal”. Ah!!! también debe ser proactivo, autogestionado, colaborador y resolutivo con un alto sentido de la urgencia, con un caracter apacible pero fuertemente decidido, con amplia orientación al cliente y a los servicios.

Hacer sentir bien a tu socio colaborador
Lo que se debe intentar buscar, es evidencia de las personas con verdaderas capacidades de ayudar a sus pares, colaborar con ellos sin importar el inconveniente, ni las diferencias de habilidades técnicas. Quizás la idea es siempre “nivelar hacia arriba”.
Lo que se destaca, es que las personas que finalmente serán seleccionadas, en realidad comenzaron con su entrenamiento en el preciso momento en que iniciaron el proceso de evaluación y selección.

El diseño de un ambiente propicio para el aprendizaje
es el aspecto fundamental para este cambio de paradigma, ya que no es posible promover el reclutamiento de talentos sobre el reclutamiento de habilidades si organizacionalmente solo nos interezan los aspectos de resolución técnica inmediata y no contamos con la estructura de capacitación y transferencia de conocimientos técnicos.
Nuevamente la capacitación es un ítem de importancia, pero fijémonos que aquí no comentamos los mismos errores.

Leer entrada completa | Make a Comment ( Comentarios desactivados en Actitudes y Aptitudes – 2 )

Actitudes y Aptitudes – 1

Posted on 19 febrero 2009. Filed under: Actitudes, Aptitudes, Capacitación, Comunicación, Habilidades Personales, Liderazgo, PNL y Coaching, Opinión, Organización del Trabajo Personal, Recursos Humanos, Resolución de problemas, Trabajo en Equipo | Etiquetas: , , , |

El balance Actitud/Aptitud. Una respuesta desde Recursos Humanos

El trabajo de un individuo no solo puede evaluarse por sus resultados externos, sino también por el aprendizaje del sujeto en el proceso de trabajo

El proceso de aprendizaje podrías ser tal vez, el agente disparador de las actitudes y aptitudes que definen a un sujeto frente al trabajo y a las acciones que realice para ejecutarlo, de modo tal que tanto actitud como aptitud se encuentran fuertemente ligadas.

Aunque las aptitudes (relativo a los conocimientos agnósticos y técnicos) puedan ser mejores en algunos individuos, probablemente lo que mejor define a un trabajador es su actitud, ya que le favorece notablemente en su curva de aprendizaje continuo, en el enfrentamiento con nuevos desafíos, en la posibilidad de innovación, en la propuesta de cambios y mejoras,  en la colaboración y en la toma de decisiones, elementos necesarios en los paradigmas de los negocios actuales.

En respuesta a estos criterios, es que las organizaciones en sus áreas de Recursos Humanos, debe evaluar correctamente y con amplio criterio a las personas que pertenecerán a los equipos de calidad y testing, de modo tal que no sea excluyente el conocimiento técnico aplicado a una herramienta particular.

Recursos Humanos debe integrar sus conocimientos de selección de personal con los requisitos del área QA y Testing, de modo tal que su búsqueda no se encause en aspectos débiles, inclusive buscando fortalezas técnicas.

Me inclino ampliamente a la contratación de personal que tiene una elevada actitud positiva, proactiva, comunicativa y coloborativa, al menos para actividades de calidad, salvo que el requisito implique a personal con capacidades acabadas en el manejo de una o más herramientas operativas donde no existen posibilidades de una curva de aprendizaje por parte del prospecto.

Personas con grandes habilidades técnicas suelen llevar al fracaso proyectos por derruir la moral del equipo, desmotivándolo, volviéndolos contrarios y haciendo que los mismos se olviden aunque sea en forma temporal, de la misión de su participación en los proyectos.
En muchas ocasiones puede inclusive hasta perderse la confianza en su desempeño técnico, gracias a la observación de actitudes contrarias a las necesidades de los proyectos y de los equipos de trabajo.

Los líderes de equipos muchas veces no saben como lidiar con esta gente, pues los necesitan por su valor técnico y los desprecian por su actitud.
Esta dualidad no es buena y quizás eliminarla desde un principio, detectando cual es el balance Actitud/Aptitud, sea lo conveniente para asegurar éxito en los proyectos.

Es importante que Recursos Humanos evite  dejar toda la carga de control de la situación en manos de los líderes, que sin duda deberán restar esfuerzo y concentración a sus otras actividades para encausar su equipo de colaboradores.

Después de todo como en cualquier proceso, lo importante es no introducirse BUGS a uno mismo.

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

QA & Testing en SCRUM

Posted on 24 enero 2009. Filed under: Actitudes, Aptitudes, Calidad del Software, Comunicación, Entorno de Pruebas, Gestión de Equipos, Gestión de Proyectos de Software, Herramientas Colaborativas, Herramientas, Métodos y Procesos, Ingeniería del Software, Metodologías de Desarrollo, Opinión, Organización del Trabajo Personal, Procesos Ágile, Project Management, Soporte Colaborativo, Testing, Trabajo en Equipo | Etiquetas: , , , , , , |

Estimado tester del mundo,

Dando vueltas por “la red” veo repetidamente tus preguntas que reniegan de las metodologías Ágile, principalmente de  SCRUM:

“¿Cómo es posible que me digas que las iteraciones deben ser tan cortas? ¿si una iteración dura cuatro(4) semanas, tres (3) serán de desarrollo y una (1) de testing? ¿como se gestionan los defectos? ¿como es la comunicación en la gestión de defectos en proyectos Ágile? ¿si los desarrolladores deben continuan codificando los próximos incrementos, cuando corrigen los defectos? ¿cuando se los verifica?

NO ME QUEDAN CLARO LOS CICLOS!!!”

Como te habrás dado cuenta no obtuviste respuestas concretas ni en los mejores foros estos últimos dos años. Eso es así por que QA no tiene una definición concreta y formal en los entornos Ágile y me arriesgo a decirte que en SCRUM no está bien estipulado como es el proceso de testing y calidad.
Leí varios libro sobre agilísmo y en todos ellos dicen “la calidad no se negocia”, pero en ninguno de ellos explican como evitan la merma de calidad con iteraciones tan cortas, o dicho de otra manera, como la obtienen y garantizan.

Alguna respuesta lógica podría ser:

  1. la intervención temprana del equipo de testing en el ámbito del proyecto.
    Esto quiere decir que hay que apartarse de la idea de esperar a que los requisitos estén maduros para tomar el documento de requerimientos y realizar el diseño de casos de pruebas. En este tipo de metodologías, debemos tener en cuenta la mutación de requerimientos, como también la eliminación de algunos de ellos y la aparición de nuevos en tiempos muy cortos.
    Aquí debemos ingresar en el preciso momento en el que nace un requerimiento, es decir cuando el requerimiento es expuesto al equipo. Nuestra fase de análisis comienza al mismo tiempo que para el equipo de desarrollo.
    Prontamente estaremos en la fase de diseño de las pruebas, donde también es extremadamente dificultoso ser veloces y preciso con iteraciones tan cortas. Es debido a ello que verás muy pocas propuestas serias para trabajar, aunque hoy en día se están abriendo paso…
  2. …herramientas colaborativas donde los encargados de indicar criterios de calidad, criterios de aceptación, modos de fallos, modos de prueba y demás, son todos los miembros del equipo e interesados.
    Esto es así dado a que la industria se dió cuenta que las mejores pruebas las hacen nuestros clientes y en todo el ciclo de vida de un requisito, los distintos tipos de analistas (negocios, requerimientos, sistemas, soporte, pruebas) representan algún aspecto de los clientes, aunque no todos.
    Estas herramientas ayudan a…
  3. … automatizar el proceso de desarrollo, donde la generación del requisito es el inicio natural, pero está acompañada su evolución por aspectos de la gestión de proyectos, tales como criticidad y priorización, estimaciones, asignaciones, control de cambios, control de estados, gestión de recursos, desvíos, replanificación y métricas. Todos elementos para sostener un curso razonable de la calidad del proceso y del proyecto.

En relación a tus preguntas te diría que:

  • Tres semana de desarrollo y uno de testing es posible. Debes contar con los recursos necesarios y adecuados. El problema aquí nuevamente es la planificación del testing y la calidad.
    ¿tendrás tiempo de planificar algo que garantice cobertura sobre los requerimientos? dificilmente del modo tradicional.
  • Mientras se hace testing los desarrolladores codifican. Para eso están, salvo que también sean testers, ya que aunque está mal visto en los paradígmas tradicionales, puedo asegurar que visto con un pensamiento lateral es positivo, imprime rítmo, genera velocidad y ayuda al crecimiento técnico del equipo QA.
    También adoptan perspectivas diferentes que le ayudan en sus próximos enfoques para el desarrollo de las soluciones.
    Tiene sus aspectos negativos que se pueden ir puliendo. Por ejemplo un desarrollador que eventualmente pasa a testing, al detectar un defecto lo analizará desde el aspecto que más conoce. Querrá acceder a la base de datos y debaguear el código, y si fuera posible corregir y recompilar inmediatamente.
    Bueno, eso también lo hemos hecho, pero en otras situaciones, por ejemplo cuando se hace la verificación de las correcciones de defectos.
  • Particularmente yo me salto “el aparato comunicacional” y  digo al desarrollador: “master, tengo un defecto persistente. Que te parece mirarlo juntos y resolverlo de buenas a primera?”
    La herramienta de gestión de defectos es como cualquier otra o como una planilla Excel si lo quisieras llevar a extremos precarios (habrá quienes me discutan lo de precario por Excel) y en ocaciones suele ser una importante barrera comunicacional burocrática, puesto a que nuestros defectos deben “atravezar el espacio-tiempo” mientras esperan ser atendidos. Yo prefiero la interacción y la proactividad, inicialmente hablar con quien lidera el proyecto mostrando los defectos detectados, dándole información precisa y concisa, ayudándole a priorizar su resolución y a medir los impactos.
    También interactuo con los desarrolladores planteándoles un modo de uso, uno modo de fallo, un modo de prueba y ayudando a desarrollar una mejor solución.
  • Al respecto de cuando se solucionan los defectos, opino que no es buena cosa pasar a un próximo ciclo de desarrollo si no se cerró el anterior. De manera tal que decir que tenemos un incremento va ligado de la frase “está hecho!!!”.
    Sin embargo en la vida real, notarás que es común iniciar la próxima iteración antes de corregir todos los defectos. Esto será válido si el incremento desarrollado fue aceptado por el cliente (Product Owner) aún a sabiendas de los defectos de la entrega.

Como elemento QA debes ser lo suficientemente analítico para iniciar el ciclo de vida de los proyectos, estudiando los requerimientos, detectando sus falencias, investigando modos de pruebas y modos de fallos. Mientras tanto deberás ir generando los criterios de aceptación funcional, generando un modelo de pruebas y si tuvieras el tiempo, los casos de pruebas.

También será menester gestionar los ambientes de pruebas netamente funcionales, aislados de accesos a bases de datos e IDEs de desarrollo, ya que lo que se pretende al menos en las pruebas de funcionalidad, es utilizar el sistema como lo haría nuestro cliente final, pero con mucho más rigor.

Entonces, como verás hay muchísima tela para cortar al respecto. Solo hemos “tocado por encima” algunos aspectos QA & Testing. Imagina si tenemos que hablar de pruebas unitarias, de componentes, de integración, métodos y técnicas…. en fin.

Lo cierto es que SCRUM es solo una metodología de gestión de proyectos, bien sinérgica, orientada a equipos maduros, autogestionados, con altísimos conocimientos técnicos, con gran dominio del negocio que genera los requerimientos y no pretende indicar como se hará el arte de desarrollar, ni de probar, mucho menos se hará de conceptos para el mundo QA & Testing.

Saludos,
Javo.

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

Skills de un Consultor IT

Posted on 9 enero 2009. Filed under: Consultoría IT, IT, Opinión | Etiquetas: , , , |

Estas son algunas de las preguntas que rondan en los foros especializados en IT:

¿Qué perfil consideran que debe tener un Consultor?
¿Debe de existir una formación especial para Consultores o cualquiera puede serlo?
¿Qué problemáticas han experimentan los Consultores IT?
¿Qué experiencias positivas aportan los Consultores IT?

Tales cuestiones surgen quizás de la ampliación del espectro de soluciones que requieren nuestros clientes.
Actualmente quienes requieren productos/servicios IT, exigen mucho más que solo consejos sobre tecnologías convenientes, productos tangibles y servicios asociados. Ellos requieren que la consultoría IT interprete el negocio que prima y le provea soluciones estratégicas que acompañen el crecimiento del mismo, construyendo relaciones duraderas y evolutivas.

Bajo esta premisa, el consultor IT debe ser un hombre de negocios que aplica la tecnología como soporte principal de las unidades de negocios de la organización que requiere sus servicios.

A su vez el consultor IT debe poder presupuestar las soluciones, garantizando que los costos son satisfactorios y equilibrados con la unidad de negocios a la que ofrece una solución. De nada sirve tener una estructura de soluciones costosas, cuando los requerimientos de nuestros clientes son aplicables a unidades de negocio de baja o mediana prespuestación general.

Se debe tener conciencia de las alternativas de solución existentes en el mercado y lograr evaluar y asesorar convenientemente al cliente con el objeto de adaptar las soluciones a la estructura organizacional, con un bajo esfuerzo de parte de la misma.

Planificar efectivamente podría ser una de las habilidades requeridas a un consultor IT, de modo tal que el mismo debería poder diseñar la estratégia de implementación de las soluciones para el negocio, reconocer con exactitud los requerimientos explícitos y tácitos, exponer y administrar los riesgos identificados y los potenciales, gestionar los recursos de los que dispone y cuidar los tiempos.

El conocimiento del riesgo tecnológico, el conocimiento de alternativas de soluciones, la capacidad de planificar,la capacidad comunicacional, el grado de abstracción y análisis, el manejo de costos, el manejo de recursos humanos y aspectos de liderazgo, entre otros aspectos, son los que transforman a un consultor en líder técnico y aliado de la organización que lo contrata.

Alguien en la gran red dijo:
“Un consultor IT va más allá de brindarle consejos sobre tecnología, debe corresponder a los intereses de su negocio.”

En las organizaciones hay muchos colaboradores que facilitan el trabajo de consultoría y al menos para mi, la consultoría IT es algo que no se puede practicar unitariamente en solitario.

Leer entrada completa | Make a Comment ( Comentarios desactivados en Skills de un Consultor IT )

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 en Quien es quien – I )

CMMI/Agile. Un híbrido que se viene – II

Posted on 22 diciembre 2008. Filed under: CMMI, Gestión de Proyectos de Software, Herramientas, Métodos y Procesos, Ingeniería del Software, Metodologías de Desarrollo, Opinión, Procesos Ágile, Project Management | Etiquetas: , , , , |

Tratando de continuar con la saga CMMI/Ágile,  diré que creo que si tenemos en claro que CMMI es el modelo del proceso de desarrollo a seguir y Scrum es el modelo de gestión, entonces en teoría no habría discrepancias ni razones de frustración a la hora de intentar gestionar con Scrum mientras se siguen las prácticas sugeridas por CMMI.

Sin embargo Scrum se plantea con un conjunto de prácticas bien definidas, que bien podrían no ser compatibles con las prácticas CMMI, las cuales desde un principio parecieron ser mejor adaptadas a RUP y las “gestiones pesadas” con prácticas al estilo PMBOOK.

Habría que plantearse si eso de ligar a CMMI con RUP, PMI o procesos Waterfall, no es un fallo conceptual, puesto a que en realidad CMMI no plantea restricciones al respecto del modelo de gestión de los proyectos.

En cierto aspecto, lo interesante es tratar de respetar toda la metodología de gestión Scrum y sus roles, mientras se respetan las exigencias de los roles CMMI.
Creo que aquí es donde nos damos cuenta de la necesidad de nuevos significados para las cosas y reestructuración de los modelos, si es que los mismos debieran sostener su vigencia.

Por ejemplo yo partiría los roles en dos capas:

  • una capa de nivel “No Operativa” o administrativa donde por ejemplo, el Product Owner sería todo el Stakeholder de capa superior de los roles exigidos por CMMI (Gerencia, Gerencia Senior, Sponsor, Representante del Cliente, y Gerente QA)
  • una capa “Operativa” donde encontraríamos por ejemplo, al Team (Líder de Proyecto, Arquitecto de Sistemas, Líder de Testing, Testers, Desarrolladores) todos gestionados con Scrum, donde Scrum Master sería necesariamente el Líder de Proyectos.

Ahora bien, solo estamos hablando de gestionar roles, pero habría que profundizar en las similitudes y diferencias de las prácticas sugeridas o impuestas para cada rol y PA por cada modelo.

A mi entender por más que se gestione con Scrum, el proceso ya no sería puramente Ágile ni puramente RUP sino uno de los “hibridos que se vienen”.

Leer entrada completa | Make a Comment ( Comentarios desactivados en CMMI/Agile. Un híbrido que se viene – II )

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 en Quien es quien – III )

El impacto de las redes sociales en Argentina

Posted on 29 noviembre 2008. Filed under: Comunicación, Herramientas Colaborativas, Mercado Tecnológico, Opinión, Redes Sociales, Soporte Colaborativo, WEB 2.0 | Etiquetas: , , , , , |

Argentina se encuentra liderando el acceso y participación de las redes sociales, aún cuando España es el país que recientemente mas integrantes a sumado a este fenómeno Web 2.

image

El fenómeno de la creciente participación en las redes de enlace social, está relacionado principalmente por la necesidad de recupero de comunicación interpersonal, muy probablemente ligado a la gran dispersión de las personas al rededor de todo el mundo. Estos medios son la herramienta ideal para localizar y contactar a personas a las cuales se les ha perdido el rastro.

Otro motivo no menos poderoso para el uso de herramientas sociales, tiene que ver con búsqueda de trabajo y relación profesional o comercial, donde nuevas oportunidades se abren en dos frentes, tanto para quienes buscan un nuevo puesto de trabajo como para quienes buscan nuevos prospectos. Del mismo modo para quienes tienen relaciones de negocios en algún grado.

Es interesante notar que lo que aparentemente tiene un impacto de corto alcance, en realidad tiene un alcance inimaginable, tal es así que con solo tener unos cuantos contactos directos o de primer nivel, se genera una red de contactos que se disgrega por múltiples regiones del mundo, logrando así disponer de una red verdaderamente amplia, donde localizar a una persona, buscar trabajo, mano de obra califica o promocionar un producto, es mucho más simple y veloz, por no hablar de los costos que aún pagando, tienden a cero.

Aún no hemos visto más que los inicios de las redes de la Web 2 y los servicios comienzan a escalar para brindarnos capacidades multimedias, aplicaciones de planificación de proyectos globales, coordinación de equipos distribuidos, ambientes colaborativos, soporte de archivos, voice mail, chat y poderosos monitores de estadísticas que nos ayudan a tener mayor visibilidad y definición de los rumbos a tomar.

No me atrevo a especular sobre todo lo que aún nos deparan estos avances, pero sin duda estamos en un proceso de aprendizaje y adaptación, el cual cada vez es más rápido, tiene más adeptos y el feedback es instantáneo, hasta el punto tal que en cuestión de horas las aplicaciones OnLine perfeccionan sus funcionalidades y potencian sus servicios.

Leer entrada completa | Make a Comment ( Comentarios desactivados en El impacto de las redes sociales en Argentina )

…alguien usó "la solución de la galera"

Posted on 29 noviembre 2008. Filed under: Capacitación, Gestión de Proyectos de Software, Habilidades Personales, Herramientas Colaborativas, Liderazgo, PNL y Coaching, Opinión, Project Management, Recursos Humanos, Trabajo en Equipo |

¿Que evidencia hay de que los conocimientos que exiges hoy de un RRHH siempre fueron vitales y exigibles?

Como líder, ¿te has puesto a pensar en la presión obcecada que ejerces sobre tus colaboradores, muchas veces tratándolos de ineptos por no tener sus prácticas al día en relación a alguna herramienta o técnica en particular?

¿Te has puesto a pensar en lo injusto de pedir soluciones inmediatas cuando no capacitas a tu gente en el uso de esas herramientas? quizás nunca antes habías hecho un pedido que involucre conocimientos técnicos para llevar adelante operaciones que hoy te son útiles.

¿Pensaste que quizás tu falta de previsibilidad para los proyectos? ¿Que quizás no tienes en consideración sus riesgos?  ¿Nunca asumiste la culpa por que tu equipo de trabajo no está correctamente preparado para enfrentar los problemas?

Somos informáticos y nos dedicamos a muchas cosas distintas, pero no somos el “botón rojo que lanza el misil”.

Nuestro personal siempre debe estar capacitado con mucha anticipación para poder ser resolutivos en los proyectos venideros.

Ya sea que nuestro colaboradores obtuvieron la experiencia de otros proyectos o por que los capacitamos, los líderes nos hacemos cargo verdaderamente del éxito de los proyectos que guiamos. Si no es así, entonces nos arriesgamos a un fracaso rotundo o a un éxito poco meritorio, donde alguien usó “la solución de la galera”.-

Leer entrada completa | Make a Comment ( Comentarios desactivados en …alguien usó "la solución de la galera" )

Demanda laboral IT en Argentina – Acumulado Anual

Posted on 29 noviembre 2008. Filed under: Artículos sueltos, Calidad del Software, Gestión de Proyectos de Software, Opinión, Recursos Humanos |

Recientemente en el sitio Universo Bit se publicó la lista de demanda laboral IT, actualizada hasta el 22 del mes de noviembre del año 2008.

La imagen muestra cuales son las herramientas IT más requeridas en el mercado en todo el año y cuales son los perfiles de mayor demanda.

Demanda Laboral IT - Noviembre 08

Queda muy a las claras que la inversión en calidad aún no es demandante, o quienes cubren puestos QA tienen mayor estabilidad y perduran en sus posiciones, o un bajo porcentaje de profesionales involucrados en QA es suficiente para el control, seguimiento y aseguramiento de la calidad de todos los procesos, prácticas, productos, servicios y derivados de todas las áreas.

De cualquier manera algo no me huele bien respecto a la demanda de profesionales QA.-

Leer entrada completa | Make a Comment ( Comentarios desactivados en Demanda laboral IT en Argentina – Acumulado Anual )

Cloud Computing. Mucho más que un BUZZWORD!

Posted on 19 noviembre 2008. Filed under: Artículos sueltos, Cloud Computing, Herramientas Colaborativas, Mercado Tecnológico, Opinión, SaS, Soporte Colaborativo, Soporte de Aplicaciones, WEB 2.0 | Etiquetas: , , |

Virtualización fue una de las primeras palabras que se escucharon varios años atrás y cuando nadie lo entendía, creímos que era algo para las mega corporaciones, inaplicable para un usuario común y corriente o para pequeñas organizaciones y muchos se resistieron a la idea.
Hoy nadie se resiste, todos abogan por esa tecnología por que abarata terriblemente los costos y de la negación nadie se acuerda.
“Cloud Computing” es el buzzword del momento y algunos nos metimos a usarlo aún a costa de que nuestra información personal pudiera perderse o caer en manos irresponsables.
Particularmente yo necesité años atrás una solución para poder generar mis documentos y disponer de ellos en cualquier momento y lugar, así fue que me sumé a EYEOS como algo experimental. Hoy el sueño es más tangible o está  hecho realidad. Utilizo dos servicios alternativamente: google doc y Office Live Workspace, ambos con muy bueno resultados y criticables en ciertos aspectos.
Las acciones de hoy ya dejaron de ser meras iniciativas y son bien serias. No son simples prototipos por que el usuario ya dijo “SI”.
Aplaudo a las corporaciones por su competencia y garantizo que pequeñas organizaciones daremos soluciones alternativas basados en el mismo modelo.
Levanto mi copa por que pronto las grandes y pequeñas compañías puedan decir que utilizan los servios OnLine de “…..” sin discriminación.
Pagar? lógico y moderado.

Leer entrada completa | Make a Comment ( Comentarios desactivados en Cloud Computing. Mucho más que un BUZZWORD! )

4 Tips para mejorar la calidad del Testing

Posted on 18 noviembre 2008. Filed under: Calidad del Software, Opinión, Testing |

En Testing no todo es Casos de Pruebas y cobertura en base a los mismos. Existe un sin número de factores que alteran notablemente los resultados y la calidad de las pruebas.

Aquí me atrevo a idear 4 TIPS para tener en mente a la hora de hacer nuestro plan de calidad y Testing:

  1. Reutilización de todos sus datos existentes.
    Es lógico y necesario guardar los datos de prueba en un lugar seguro y a su vez accesible para que se pueden utilizar y re usar por todos los Testers.
    Esto permite ahorrar mucho tiempo y encontrar más errores.
  2. Dejar de hacer copias de la producción.
    Hay quienes dicen que más del 90% de los datos en producción son similares, por lo que trabajar únicamente con ellos creyendo que así tendremos mejor cobertura, es un engaño.
    Es mejor utilizar un 10% de los datos de producción, manteniendo en foco que aquellos datos serán los verdaderamente significativos para las pruebas. El 90 % restante debemos generarlos nosotros para garantizar de esta manera la cobertura y la calidad de las pruebas, ya que así estaremos mucho más seguros de cumplir con más caminos del grafo de pruebas.
  3. Evitar que la mayor parte de nuestra generación de datos de pruebas sea manual.
    Es un trámite muy laborioso que se consume gran parte de nuestro tiempo asignado a pruebas del proyecto. También es muy propenso a errores.
  4. Mantener el foco en la calidad de los datos, asegurando que los mismos es una buena representación de la realidad y que la misma puede ser modificada para configurar varios escenarios posibles.
    Cuanto más alta es la calidad de los datos que utilizamos como juego principal para las pruebas, mayor cantidad de defectos se detectan y se evita que los mismos lleguen a producción.

Quien pueda aportar un poco más, bienvenido sea..

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

Fishbowl – parte 2 (Clue Computing)

Posted on 17 noviembre 2008. Filed under: Comunicación, Fishbowl, Herramientas Colaborativas, IT, OpenSpace, Opinión |

Habiendo realizado una apertura sobre la temática en mi primer artículo https://javosantillan.wordpress.com/2008/11/16/fish-bowl-parte-1-desarrollo-de-juegos/ me gustaría compartir la segunda parte del Fishbowl realizado en UTN de Córdoba, Argentina. La temática tratada en esta parte, está relacionada a la muy popular y populosa Clue Computing o Nube Informática.

El debate se abrió con una visión un tanto “oscura y pecaminosa” de lo que son las tecnologías abiertas, donde se pretende llevar al usuario a una dependencia total de los entornos OnLine o Web Based. El expositor argumentó su óptica indicando que no se debería confiar información tan importante como la relacionada a los contactos de negocios, económicos o familiares a organizaciones que hoy ofrecen en forma gratuita sus servicios pero que no ofrecen garantías de que así se sostengan tales servicios. También indicó el expositor, que tales prestadores de servicios incluyen cláusulas en sus CLUF donde está claramente expresado que no son responsables por la pérdida de datos o información y que tampoco se expresa la garantía de sostener el servicio si comercialmente no se obtienen los réditos necesarios.

Desde otras ópticas, algunos argumentaron que ven que los servicios WebBased son una creciente demanda en evolución, donde en muy corto tiempo lo que menos importará es si tales servicios sean pagos. Se mencionó a Oracle como la primer empresa en prestar servicios OnLine y WebBased para soportar el mantenimiento de grandes bases de datos, donde una gran corporación puede confiar sus datos a la infraestructura IT de Oracle. Esto redunda en que una empresa solo debe dedicarse a su negocios sin preocuparse de tener mano de obra especializada ni infraestructura IT costosa.

Se habló de seguridad de datos, de disponibilidad e integridad de los mismos y por sobre todo, accesibilidad (curiosamente los pilares fundamentales de la seguridad informática) y en torno a esos puntos se encontraron posturas dispares pero todas orientadas a determinar cual es el beneficio o perjuicio para el usuario final.

Un última exposición hizo hincapié en los recientes “temas calientes” donde se menciona la privatización de Internet y donde uno de los principales detractores de esta idea es el presidente electo de los EEUU, Obama, quien en uno de sus discursos pre electorales, remarca la necesidad de sostener una red abierta y accesible para todo el mundo y evitar que se genere un “tercer mundo informático” a raíz de servicios diferenciados tanto en los paquetes de software como con el ancho de banda, siendo que se planea que los carriers puedan segmentar por tipos de usuarios para establecer los márgenes de calidad para los servicios de Internet.

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

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