El peligro de un (1) usuario descontento

En numerosas ocasiones hemos tenido la virtud de resolver inconvenientes a nuestros bien aventurados clientes, usuarios de nuestros sistemas en distintos niveles. Ellos agradecidos de nuestras prontas respuestas e inteligentes resoluciones, toman vigor en el uso y recomendación de las nuevas funcionalidades, se adentran en las opciones que ofrecen nuestras soluciones y generan nuevas propuestas de cambios que inyectan un flujo de trabajo a nuestras empresas.

Pero muchas veces sucede lo contrario, nuestro cliente esta insatisfecho y todas las acciones en las que podamos incurrir le parecen pocas o de "soluciones facilistas". No es necesario pensar en "el cliente" como la masa corporativa que adquirió nuestro producto, sino en sujetos individuales que en algún punto del mapa organizacional provocan una suerte de ruido nocivo.

Independientemente de que se trate de un grupo de usuario o un único usuario, nuestra organización se moviliza en múltiples aspectos. Desde que "bajan" los incidentes y hasta que "suben" las soluciones, el hilo conductor del descontento de nuestro usuario, pasa por las distintas áreas provocando diferentes reacciones que a su vez producen diferentes resultados.

Los primeros resultados son conversaciones con demandas poco constructivas, con acusaciones sin sentido práctico y respuestas reactivas poco esclarecedoras.
En un ambiente así nadie muestra el más ínfimo ápice de satisfacción.

Este comportamiento primario e incial denota la inmaduréz del grupo, del área, de conjunto gerencial y finalmente de la empresa completa.

Es posible que no se asuma que los fallos son posibles, existen y no se ven en muchos casos sino hasta que los detecta el usuario final luego de mucho tiempo de no ser detectados. Aún peor, cuando la organización no asume inclusive que nuestros clientes tienen al menos "dos tipos de jugadores en sus filas" y que al menos uno de ellos gusta solo del "lenguaje de los buenos tratos e inclinaciones de reverencia", entonces la organización vive en una fantasía y sus reflejos se adormecen, o si no es así, hiere a los ejecutores de soluciones y provoca un "sangrado interno" que dudasamente sicatrice con rapidéz.

Adoptar una "postura inflexible hacia adentro" creyendo en esa ficción del "cliente siempre satisfecho", crea nebulosas que rodean al cojunto de las personas, fabrican desconfianzas infundadas y desvalorización el capital humano y profesional, aunque nuestras acciones no caigan ni una millonésima ante nuestros clientes.

Pero... ¿el peligroso es nuestro "usuario descontento" o nuestro descontento organizacional por falta de maduréz?

CMMI-Agile. Un híbrido que se viene

He sido participe de certificaciones CMMI 4 en una empresa del Cluster Informático de Córdoba en Argentina y actualmente estoy como Responsable de Calidad y Mejora de Procesos en una empresa donde intentamos implantar metodologías ágiles.

Conceptualmente son dos modelos distintos en cientos de aspectos, siendo imposible considerarse ágil al modelo CMMI. Quiero ser tajante en la diferenciación de esto, pues ahora se habla mucho de CMMI Agile y tal concepto no es más que un hibrido y no está formalizado. Esto es así, por que habría que decidir que parte de CMMI utilizamos y que proceso de los existentes tomaremos para recoger lo mejor de los ágiles. Notemos que los frameworks que la gran mayoría de las empresas ofrecen, se enfoncan en uno u otro modelo.

Pero vamos a ejemplos vivos. Bajo CMMI, siendo líder de testing, no tenía más participación que la ejecución de las pruebas, previo planning encapsulado y siguiendo una estricta ERS, no era partícipe a nivel horizontal del planning inicial y los criterios de calidad no se establecían por el líder de testing sino hasta que la documentación tuviera ya un alto grado de definición (documento maduro) e inclusive la participación de mi rol seguía siendo escueta y debía tomar los criterios establecidos por el arquitecto. Posteriormente, en CMMI, los cambios de requisitos no son aceptados con la amplia libertad con la que son aceptados en un proceso ágil y por lo general deben ser de bajo impacto para que ingresen en el catálogo de requisitos y siempre bajo un estricto circuito de análisis y revisiones de un comité de cambios, el cual está formado por una cantidad de personas y roles que en empresas que pueden seguir un proceso ágil, no hay.

Las reuniones (ICE) en CMMI tienden a ser verticales y la participación de los roles transversales no es tan significativa como lo es en un proceso ágil, es decir que las decisiones normalmente pasan por una situación elitista donde desarrolladores y testers no tienen una grandilocuencia aceptada. Esto se contrapone con el precepto que indica que para ser ágil se debe tener un fuerte énfasis en las pruebas sobre la aplicación que se desarrolla y una continua integración de sus componentes. Con esto no pretendo decir que en CMMI no se tenga énfasis en las pruebas, pero se llega a ser tan robótico que la creatividad se destruye y proyecto tras proyecto tienes la misma documentación, los mismos estilos de pruebas, los mismos resultados y esto ya da para la desconfianza.

En procesos ágiles debes anticiparte por eso participa todo el equipo de pruebas en las primeras reuniones donde se definen criterios de calidad, métodos de pruebas posibles, modos de fallos y otros elementos que puedan definir mejor la calidad de los productos. Recuerdo que trabajando bajo el proceso CMMI todo esto me venía llovido, y se suponía que el líder del testing era yo, un elemento SQA.

Otro precepto que aleja CMMI de ágile (keep it simple). Uno más, documentar solo lo estrictamente necesario y centrarse en lo más crítico del producto, que es el código fuente.

Por otro lado y para ir cerrando al menos este post, si un híbrido CMMI-Agile debe existir, ya sabemos que partes podemos tomar de CMMI según su nivel, pero... ¿que parte de Àgile tomamos? ¿Programación Extrema, Scrum, DSDM, Crystal Clear?

Hablando de Framworks, hay algunos que ofrecen la posibilidad de trabajar con una metodología Ágile con documentación formal y que mediante un esfuerzo (considerable) se podría alcanzar un nivel CMMI-3 en el mejor de los casos, utilizando otra parte del mismo Framework. Es más complejo que eso.

Pero aqui me acoplo a lo que algunos dicen por la red. Lo más importante que toda organización o persona debe tener en cuenta, es que no existe una metodología ideal para cualquier escenario en la que se aplique. La metodología de desarrollo que se seleccione, bien sea ágil o no, siempre dependerá directamente del equipo de trabajo, la cultura organizacional, lo cambiante del medio ambiente y la aceptación del usuario final.

Podredumbre del software

¿Qué le pasa al software? El diseño de muchas aplicaciones comienza con una imagen clara en la mente del diseñador. En este estado el diseño es claro, conciso y elegante. Diseñadores y programadores desean verlo funcionar. Algunos de estos proyectos mantienen esta pureza de diseño hasta la primera versión.

Pero algo comienza a pasar. Al principio apenas es perceptible. Un parche por aquí, una ñapa por allá, aunque el diseño todavía mantiene la filosofía inicial. El software comienza a pudrirse. Las ñapas continúan y poco a poco el software se corrompe mas y mas hasta llegar un punto en el que afecta a toda la aplicación. El programa se convierte en una ingente masa de código que cada vez es más difícil de mantener. Entonces el esfuerzo requerido para hacer el más simple de los cambios es tal que los responsables de producto se plantean hacer un rediseño de la aplicación.

Los rediseños normalmente no fructifican. Aunque las intenciones de los diseñadores son buenas se dan cuenta de que es una tarea imposible. El sistema continua evolucionando, cambiando y el nuevo rediseño nunca termina. Un día la cantidad de problemas vuelve a ser tal que se los diseñadores lloran por otro rediseño.

Síntomas de un mal diseño

Hay cuatro indicios principales que nos indican que el software se esta pudriendo. No son independientes y están relacionados unos con otros, son: rigidez, fragilidad, inmovilidad y viscosidad.

Rigidez. Es la tendencia del software a ser difícil de cambiar, incluso en las cosas más sencillas. Cada cambio produce una cascada de cambios en módulos dependientes. Lo que parecía un cambio de dos días en un módulo resulta ser varias semanas de cambios de módulos tirando del hilo a través de la aplicación.

Cuando el software toma este camino, los gestores temen decir a los programadores que arreglen pequeños problemas que no son críticos. Esto ocurre porque ellos no saben con seguridad cuando acabaran los programadores. Todo el mundo hace "check-in" y nadie hace "check-out".

El miedo del gestor puede llegar a ser tan agudo que se niegue a realizar modificaciones en la aplicación. De manera que, lo que empezó siendo un diseño ineficiente acaba siendo una mala política de gestión.

Fragilidad. Muy relacionada con la rigidez está la fragilidad. La fragilidad es la tendencia que tiene el software a romperse por muchos sitios cada vez que se cambia algo. Muchas de las roturas ocurren en sitios que no están relacionados conceptualmente con el área que se está cambiando. Cada vez que los gestores autorizan un cambio tienen miedo de que el programa se rompa por algún lugar inesperado.

Conforme la fragilidad empeora, la probabilidad de que el software se rompa incrementa con el tiempo, acercándose cada vez más a 1. Este software es imposible de mantener. Cada arreglo lo hace peor, introduciendo más problemas de los que son solucionados.

Este software causa que los gestores y los clientes tengan la impresión de que los desarrolladores han perdido el control del software, perdiéndose así la credibilidad de los desarrolladores. Y frases como "Rompes más de lo que arreglas", comienzan a ser habituales.

Inmovilidad. La inmovilidad es la resistencia del software a ser reutilizado en otros proyectos o parte de otros proyectos. Pasa muchas veces que un programador descubre que necesita un módulo que es muy parecido a otro que ha desarrollado otro programador. Sin embargo, también pasa muchas veces que el módulo en cuestión depende demasiado de la aplicación en la que está integrado. Después de mucho trabajo los desarrolladores descubren que el trabajo necesario para separar las partes reutilizables de las partes no reutilizables es demasiado alto. Y entonces el software simplemente se rescribe en vez de ser reutilizado.

Viscosidad. La viscosidad de diseño es la dificultad de mantener la filosofía del diseño original. Cuando se afronta un cambio los programadores encuentran normalmente más de una manera de realizarlo. Algunas de estas formas preservan la filosofía del diseño y otras no. Cuando las formas de implementar el cambio preservando el diseño son más difíciles de realizar que las que no lo preservan, entonces la viscosidad del diseño es alta. Es fácil hacerlo mal y difícil hacerlo bien.

Estos cuatro síntomas son reveladores de un diseño de arquitectura pobre. Cualquier aplicación que muestra estos síntomas adolece de un diseño pobre.

¿Qué causa que el diseño se deteriore?

Requisitos cambiantes. La causa de la degradación del diseño es muy conocida. Los requisitos han ido cambiando de manera que no estaba previsto en el diseño inicial. A menudo los cambios necesitan hacerse rápidamente y hechos por programadores que no están familiarizados con el diseño original. Entonces, aunque los cambios funciona, violan el diseño original. Poco a poco los cambios continúan y las violaciones se acumulan hasta que el diseño se rompe.

Aún así no podemos echar la culpa a que los requisitos cambian y cruzarnos de brazos. Como desarrolladores, todos sabemos que los requisitos van a cambiar. Así que debemos realizar un diseño que soporte modificaciones sin que este pierda su consistencia.

Control de dependencias. ¿Qué tipos de cambios hacen que un diseño se pudra? Los cambios que introducen nuevas e imprevistas dependencias. Cada una de las cuatro causas mencionadas anteriormente están relacionadas directa o indirectamente con dependencias entre módulos del software. Son las dependencias de la arquitectura lo que se degrada y con ellas el mantenimiento del software.

Para anticiparse a la degradación de las dependencias del diseño de la arquitectura, deben ser controladas las dependencias entre módulos de una aplicación. Este control consiste en la creación de "cortafuegos" de dependencias. A través de estos cortafuegos las dependencias no se propagan.

El diseño orientado a objetos esta repleto de principios y técnicas que nos permiten construir estos cortafuegos y controlar estas dependencias.

En posteriores artículos examinaremos estos principios y técnicas (patrones de diseño) que ayudan a controlar las dependencias de la arquitectura.

Rescato este artículo del sitio Ingenieros del Software

Por Joaquin Gracia
Basado en un artículo de Robert C. Martin
22 de Agosto de 2004