Asegurando la Calidad… estás seguro?

Hace un tiempo, mientras revisaba/corregía las observaciones que el equipo de control de calidad hacia, una de las personas del equipo “contrario” (por así decirlo) fue parte de uno de los diálogos mas interesantes por esos días.
Líneas abajo, un resumen:
– QA: Si, está bien, ahora está todo mas rápido.
– Yo: Y cómo lo determinas?
– QA: Bueno, es lo que parece, no?
– Yo: …
– Yo: Estás seguro?
– QA: (sonrisa) ya bueno, con mi reloj.

dialogo

Por esas fechas una de las observaciones mas importantes tenían que ver con la performance de la aplicación, a lo cual procedimos a ejecutar diversas pruebas, muchas de estas bajo automatización realizada con programas que habíamos construido, mientras que por otro lado, usábamos herramientas que en base a reportes, nos aseguraba, o al menos nos daba una idea del consumo de recursos, administración de memoria, tiempos de respuesta, etc.

Mientras transcurría el proyecto, se resolvían las observaciones y éramos testigos de como el producto comenzaba a integrarse con cada aplicación, por mi parte confirmaba (y lamentaba) una vez más la pobre percepción que tienen muchos profesionales sobre el Aseguramiento de Calidad.
El problema se hace mayor si es que nos damos cuenta de que esta falencia también está sentada en las empresas, no solo en algunos trabajadores, sino en los jefes! 

Lo que pasa es que muchos piensan, creen o aseguran, que asegurar la calidad se determina por la menor cantidad de errores que salgan al probar la aplicación luego de programar un módulo, funcionalidad o peor aun… al terminar de programar todo!

Error!

Asegurar la calidad tiene que ver con:
– Asegurar
– la
– Calidad.

Nada mas que eso!
(no, no estoy bromeando)

Y cómo logras algo tan simple?
Pues primero, tenemos que detenernos un momento y determinar cuales son nuestros estándares mínimos para definir un producto de calidad.
Tranquilidad ante esto, ya que muchas veces estos aspectos ya están definidos por las gerencias de alto nivel.
Lo que se debe hacerse es conversar con el equipo (una vez mas, la comunicación saliendo a flote) sobre estos aspectos ya definidos y ver/encontrar/definir/decidir de que manera se hará un trabajo acorde a esto.

Pero decidir una forma de trabajo que vaya de acuerdo a la idea de los estándares de calidad de la compañía es mucho menos del 50% de lo que tienes que hacer para asegurar la calidad de tus desarrollos.

Debemos en primera instancia mantener un respeto al trabajo de las demás personas, por eso:
– Si alguien usará la librería que estas creando, pues, simula su uso antes de entregarla. Ante esto, la primera palabra clave es: pruebas unitarias, aunque claro, hay mas conceptos, pero al menos ese, no?
– Si ya vas a entregar tu módulo/funcionalidad, realiza algunas pruebas en base a lo especificado funcionalmente y acordado con tu Analista de Pruebas.
– No puedes aducir que no tienes tiempo y que esa ya no es tu tarea, pues tu tarea en realidad es entregar algo que funciona, recuerda, es prácticamente el valor de tu palabra y del compromiso que tienes con el proyecto.
– El Analista de Pruebas tiene como una de sus actividades principales, confirmar las funcionalidades especificadas, no tanto así, como verificar si es que algo está correctamente compilado, desplegado, escrito, diseñado visualmente.
– Escrito: es decir, ortográfica y gramaticalmente hablando, es que acaso ser ingenieros informáticos nos da opción a no saber escribir?
– Diseño Visual: esto es dependiendo del caso, pero si vienes con la mentalidad del “ya luego vemos como le arreglamos el diseño” pues, créeme, estas comenzando mal.
– Lo mencionaré en otros términos, el trabajo del Analista de Pruebas, no es ver si lo que has publicado está listo para probar. Su trabajo es confirmar si está listo para ser publicado.

Si bien es cierto, hasta este momento muchas de estas anotaciones parecen obvias o difíciles de considerar por la naturaleza de nuestro mercado, pero la verdad es que aun no hemos terminado de hablar al respecto.

Pues, queda determinar algo bien claro:
Asegurar la calidad una aplicación no es probar la aplicación.

bug-feature
Cómo es eso?
Independientemente del modelo de trabajo que se esté siguiendo, debemos tener en mente y aceptar que el aseguramiento es constante, que si hablamos de fases, microfases, iteraciones, etc. pues lo que se debe considerar siempre es que todo artefacto debe pasar por un proceso de certificación realizado por un tercero ajeno de manera directa a lo liberado, que asegure que lo se va a liberado:
– Que funcione, si es un módulo.
– Se entienda, si es un documento, procedimiento, proceso
Sea claro, que no requiera explicación
– Responda a los flujos ideales y casos ideales.
– Soporte casos complejos, si es que ya es una versión superior.
Que tenga sustento, sea técnico, funcional o ambos, lo realizado debe tener sustento! no solo se trata de un “así me pareció” o “es que lo otro no me gusta”.

Como podrán notar asegurar la calidad de un producto, desde el punto de vista de construcción de software (tema del cual espero hablar en alguna oportunidad), no tiene mucho que ver con pensar en el producto como un todo, sino en un esquema integral en el cual, cada componente está completamente ligado con la siguiente versión del mismo y del producto en si. 

No podemos olvidarnos de las personas involucradas en la construcción, liberación y certificación de cada artefacto, teniendo muy en cuenta que cada uno no puedo ser juez y parte del trabajo que viene haciendo, que además de nuestro trabajo, está en juego nuestra palabra y el respeto a las demás personas que usarán lo que vayamos liberando (dentro y fuera del proyecto).

measurement-of-code-quality

Y lo mas importante, asegurar la calidad de un producto, no es probar el producto, y mucho menos a ultima hora!

Saludos
@Jersson

Posteado originalmente en JersSoft on the block!

Dejé el sistema funcionando, que ha sucedido?

Es posible que les haya pasado, dejaron un proyecto que se encontraba estabilizado, funcionando ya un tiempo, trabajando con el usuario, y luego de un tiempo los llaman pues hay problemas con los componentes, con algunas librerias o peor aun, con todo el sistema.

En ese momento lo último que uno debe ponerse a pensar es “de quién es la culpa?
Ya que no sirve de nada ponerse a ubicar culpables, que, de existir, posiblemente ya no se encuentren trabajando en la compañía.
Peor aun! ponerte a buscar culpables solo alarga la espera y el tiempo de inactividad del servicio que se viene brindando. 

Entonces, qué es lo primero que se debe hacer?
Pues resolver el problema!!!

Fatal.ErrorY no, esto no significa que uno debe transformarse en el salvador o  alguna deidad similar, nada de eso!
Lo que debe hacerse es un trabajo de diagnóstico e identificación de aquellos factores que generaron el problema (que simple, no?).
Recuerda, en ese momento todo vale! no hay pregunta tonta, si tienes que preguntar si hubo alguna instalación, service pack, idea nueva… todo vale! y debe ser -cuando menos- listado para hacer de esta manera, un breve descarte.

Es cierto, ante problemas escondidos, la solución de alguno de estos no puede ser mostrada por un solo post(seria bueno, pero muchas veces no es posible), pero vayamos al momento en el que se resolvió el inconveniente, llegándose a eliminar incluso las consecuencias de este.

Entonces, resuelto el problema, lo peor que se debe hacer es pensar que todo esta resuelto.

Por qué?
Pues hemos identificado el problema, mas no la raíz de este y el resto de futuros inconvenientes a sucitar.

Qué hacer al respecto? Pues antes de apuntar culpable alguno, deberías preguntarte si lo que dejaste estaba funcionando cómo deberia, pero bueno… seamos mas concientes y hagamos un breve listado de interrogantes que deberíamos considerar antes de dejar un desarrollo “estabilizado” y cambiar de proyecto:
– Existe una manera adecuada para demostrar que lo que se está dejando, está funcionando?
– Esta demotración de funcionamiento, está automatizada?
– Documentada? (cuidado con este termino, puede ser bloqueante)
– Se están considerando tantos casos de prueba como funcionalidades se vayan cubriendo?
– Estos casos se encuentran automatizados?
– Se encuentran documentados? (nuevamente, cuidado con este termino, importante y bloqueante a la vez)
– Se está dejando de manera formal, un responsable que “herede” lo desarrollado?
– Se le ha capacitado correctamente?
– Hay manera de demostrar que fue capacitado? y con esto no solo me refiero a un documento
– En la capacitación se cubrieron desde problemas/casos básicos hasta situaciones del día a día (si son problemas bloqueantes, mucho mejor)
– Cuando se hizo la capacitación, hubo alguna solucion de un problema “en vivo”? es decir, mientras ocurria el problema, mientras el cliente llamaba? (si, que trágico)
– Se mantuvo un historial de incidentes y se mencionó al próximo responsable la utilidad del mismo?
– Se hizo una demo de cómo instalar/desinstalar el componente/herramienta/sistema/etc?
– Esto se encuentra documentado? (mas se menciona el término, mas se odia el término)
– Se identificaron y mencionaron restricciones técnicas, funcionales, de instalación, herramientas, etc?
– Cuando se dejó el proyecto, se acompaño en situaciones futuras? se llamó para preguntar como ivan las cosas? al menos para compartir experiencias? (claro, como si todos tuvieran tiempo)

Un poco larga la lista no?
Pues mientras mas proyectos uno va teniendo, mas recomendable se hace mantener una relación minima de alternativas, información y otras herramientas que permitan evitar entre otras cosas:
– Que nos llamen continuamente para soportes pasados
– Que nos pregunten donde se encuentra tal o cual manual, o peor aun, instaladores
– Que nos digan “y eso cómo lo instalo?”

Es obvio, que mas de una vez nos terminarán llamando, y eso no significa que nuestro trabajo sea malo, pero si logramos que nos llamen menos para estos casos y mas para nuevas oportunidades… pues mucho mejor, no?

Los invito a compartir sus puntos de vista o mejor aun, recomendaciones para mantener vivo este pequeño checklist.

Gracias
@jersson

Posteado originalmente en JersSoft on the block!

Nuevas Perspectivas

Como es ya sabido por mis amigos, hace un tiempo dejé de laborar Arquitecto de Software en una conocida empresa local, la cual, por cierto, me dió la oportunidad de contar con la Jefatura de la Oficina de Arquitectura, y hasta la fecha se habían conseguido logros y aportes, entre los cuales podriamos resaltar:

– Premio a Innovación (I+D), Enfoque 2009, debido al lanzamiento de un marco de trabajo en desarrollo de software.
– Premio a la Excelencia en Investigación y Desarrollo 2007, el cual recibí por liderar el desarrollo de nuevos productos para la compañia, y que lo menciono ahora, ya que creo yo, fue uno de los factores para oficializar el trabajo y creación de la Oficina de Arquitectura.
– Creación de marcos de trabajo para la implementación de Frameworks de Desarrollo, Frameworks de Negocio y Fábricas de Software.
– Marcos de capacitación técnica/funcional hacia los diversos roles involucrados en los proyectos de desarrollo
– Curso de Certificación hacia rol de soporte a la Oficina de Arquitectura, el cual contó con evaluaciones orientadas al perfil psicológico que se habia modelado.
– Soporte Técnico/Funcional a proyectos críticos de la compañía y a propuestas del Area Comercial.
– Control de Calidad y aportes a los procesos de Ingeniería especificados a la fecha.
– Apoyo técnico para la nueva versión del marco de trabajo orientado a certificación CMMI 3.
– Lanzamiento oficial y publicación periódica del Boletin de la Oficina de Arquitectura. 

El ultimo periodo de trabajo, al igual que los anteriores, fue determinado en base a un plan alineado experiencea la estrategia de la compañía, el cual trajo resultados muy interesantes, ademas claro de las siempre bien recibidas, lecciones aprendidas.

A pesar de ello, llegado un momento, tuve la necesidad de mirar a todos lados y preguntarme si me faltaban otras cosas, si debia leer otros libros, conocer otras personas, terminar proyectos internos o continuar incluso con lo poco que conocía de la música, o escribir, o tantas cosas.

dreamsEn fin, luego de una serie de conversaciones internas, externas, con amigos e incluso hasta desconocidos, decidí tomarme un tiempo, renunciar al preciado trabajo, continuar con mis ideales, dedicarle un tiempo a mi familia, respirar un poco de las realidades que uno vive mientras trabaja, pues no todo es color de rosa, y eso creo yo, deberia ser tema de otro post.

De momento me encuentro en proceso de titulación en mi preciada Universidad Nacional de Ingeniería, y sufriendo un poco con los pagos pues a pesar de estar contemplado dentro de mis gastos, me parece demasiado.
Tambien paso mas tiempo con mi familia, llegando a conocer mas a mis primos, los cuales son menores que yo (punto para mi)
He comprado una nueva guitarra, la cual ya sufrió su primer accidente y sus primeras cuerdas rotas son testigos clave de mis intentos de afinamiento experimental.

Frecuento algunas salidas o almuerzos con amigos debido a que antes habia menos tiempo para ello.
Estoy leyendo otras novelas, libros y manejando horarios que a pesar de que en tiempos anteriores gozaba de cierta libertad, siento que ahora todo fluye de manera distinta.

A nivel profesional retomé un proyecto que siempre me llamó la atención, enseñar sobre los temas que me gustan, seguir aprendiendo, ganando experiencias y todo lo que conlleva.

Es por ello, que luego de variadas reuniones con preciados amigos, decidimos formalizar el trabajo colectivo que teniamos en mente realizar y transformar todo esto una empresa, la cual fue formada en base a los siguientes ideales, los cuales transcribo tal como fue decidido:
– La eficiencia es nuestro compromiso: Ya que nos preocupamos por las técnicas y recomendaciones a brindar o utilizar para cumplir con los objetivos del trabajo, siempre buscamos que la calidad sea la mejor.

– Experiencia y creatividad al servicio de todos: Creemos firmemente que nuestra experiencia y creatividad son valores agregados a nuestro servicio que benefician directamente al cumplimiento de nuestros objetivos.

– La calidad no sólo debe suponerse: El problema que hemos identificado es la poca importancia a los niveles de calidad establecidos por el mercado. Debido a ello tenemos un plan para evitar este inconveniente.

El nombre de la empresa es Alphab-IT y los amigos que tengo el agrado de mencionar y a la vez presentar son:
– Roberto Camacho: Arquitecto de Software con amplia experiencia en implementaciones de marcos de trabajo, integración de soluciones y capacitación
– José Ponce: Especialista en Infraestuctura de Soluciones, con experiencia en diseño y configuración de ambientes y servidores de alta disponibilidad.

Con ellos es que iniciamos esta nueva aventura, siendo nuestro lema: Demos el salto con las Tecnologias de Información!
Los invito a entrar a la primera version de nuestro site, cuya direccion es http://alphab-it.com
Aprovecho tambien en invitarlos a los blogs tanto de Roberto (SamuraIT) como José (Blog de Jopoa) y claro, el mio! el cual por cierto, será el oficial desde ahora.

Muchas Gracias por su atencion, Alphab-IT los espera! 
logo.transparenteSaludos.

Jersson