archivo

Archivos diarios: diciembre 12, 2011

Y es que son dos cosas distintas. Se puede tener un modelo organizativo orientado al proceso y sin embargo ser lo suficientemente flexible como para ofrecer diferentes opciones en función de las circunstancias y que entre las mismas quepa lo que queremos hacer y si no cabe, tener previsto también esta contingencia.

Es muy complicado que todos los procesos que se definan tengan en cuenta absolutamente todo. Por encima de los procesos están las personas y los proyectos y se trata de compatibilizar los mismos con lo que el proyecto necesita y los objetivos que se persiguen con un modelo de procesos.

Los procesos definen formas de hacer las cosas. Pretenden homogeneizar actividades, darles un orden, hacerlas repetibles.

Los procesos solo son un enemigo si están mal definidos (no se adaptan al nivel de madurez de la organización, a lo que la organización necesita, si son muy rígidos, etc…) y no se está dispuesto a cambiarlos, ahí es donde empieza la obsesión por el proceso ya que es en ese momento donde se ponen por encima del proyecto y las personas.

Documentar por documentar es un problema frecuente en los proyectos de desarrollo de software. También lo es hacer testing por hacer testing, sin orden, sin hacer un planteamiento que permita sacar un rendimiento adecuado al esfuerzo dedicado a hacer esta tarea.

No es cuestión de dedicar más tiempo es cuestión de saber dónde, desde cuándo y cómo se aplica el testing. Es cuestión de trabajar sobre un plan, adaptado al proyecto pero basado en unos procesos implantados y probados en la organización. Si no existen, nunca es tarde para empezar a tenerlos.

Si cada equipo de proyecto aplica el testing de una forma, no se podrá garantizar un nivel de calidad homogéneo en la organización y probablemente tampoco se alcancen regularmente los umbrales fijados por el cliente. No controlar el nivel de calidad de los desarrollos y por tanto no poder establecer un proceso de mejora continua de los mismos, es uno de los factores que está haciendo un daño tremendo a nuestro sector.

La calidad del producto software, la orientación al cliente y al cumplimiento de sus expectativas es un hecho diferencial entre proveedores, lástima que esto no esté entre los objetivos de muchos de ellos.

Sin un testing eficiente, el esfuerzo, mal dirigido, provocará que por regla general la detección de los errores se encuentre lejos del momento en que se produjeron y ahí sí que cuesta dinero corregirlos y, por supuesto, que muchos de ellos lleguen a producción y no me refiero exclusivamente a los típicos bugs, sino a malas ejecuciones o interpretaciones de carácter funcional.