archivo

Archivos diarios: diciembre 21, 2011

Se trata de iterar en el lugar equivocado.

Iterando en el análisis lo único que estaremos haciendo será depurar cada vez más unos requisitos que no son más que meras hipótesis (con más o menos fundamento) de lo que quiere el usuario.

Un prototipo, otro prototipo, tal vez algún esqueleto andante, una nueva versión del catálogo de requisitos, otra, otra, para que después, cualquier circunstancia (cambio de interlocutores, cambio de prioridades, cambio de los procesos que se pretenden informatizar, etc…), todo se pueda desmoronar y el proyecto, con una gran cantidad de esfuerzo invertido se quede sin nada o casi nada.

Para que la iteración tenga utilidad requiere de una entrega completa, que pueda ser usada por el usuario y de ahí obtener el feedback necesario para obtener una versión y más completa en el siguiente incremento.

Otro antipatrón relacionado con la falta de simplicidad en la solución obtenida.

Son ya unos cuantos. Para quienes no crean que las mejores soluciones son las más simples que resuelvan un problema, creo que debería dar lugar, como menos, a reflexión.

Y os lo dice alguien que alguna que otra vez ha provocado este antipatrón por el deseo de agradar al usuario y que después se ha tenido que arrepentir por el esfuerzo invertido en hacer algo que no ha aportado prácticamente nada y que encima ha provocado problemas, es decir, el deseo por agradar a algún usuario provocó, aunque sea temporalmente, desagradar a otros y encima se requirió bastante trabajo para implementar las funcionalidades.

No se trata de no hacer lo que pide el usuario, sino de que este conozca las implicaciones que tiene el desarrollo que solicita y el coste que tiene consigo, con el objeto de que piense bien si realmente va a necesitar lo que está pidiendo.

Este antipatrón, va más allá de añadir funcionalidades que se podrían obviar, ya que hace referencia sobre todo a que esas funcionalidades se incorporen a costa de otros factores, como por ejemplo la calidad (que ya de por sí se ve afectada directamente por el incremento de la deuda técnica que tienen aparejadas esas nuevas funcionalidades que no se van a utilizar).

También llamado huida hacia adelante y se trata de otro fenómeno muy común en los proyectos de desarrollo de software.

Consiste en no dar marcha atrás ante una decisión errónea, estando todavía a tiempo de poder hacerlo (es menor el daño de volver atrás que continuar con el resultado o con la ejecución) de la decisión tomada y siendo consciente de que se ha elegido una alternativa equivocada.

El miedo a reconocer los errores y sus consecuencias provoca que determinados gestores prefieran continuar con ellos e intentar como sea salvar la situación.

Al final, ocurrirá lo más probable, todo habrá ido a peor y además con un mayor esfuerzo invertido.

Un buen gestor no es aquel que acierta siempre, sino aquel que aprende de sus errores y es capaz de reaccionar a tiempo cuando detecta uno, anteponiendo el bien general al individual.

En el ciclo de vida en cascada, por su naturaleza, por el hecho de que el usuario empieza a ver las funcionalidades implementadas muy tarde (poco antes de la entrega) existe la tendencia a querer abrir puertas que ya se consideraban cerradas, es decir, a retocar especificaciones, en algunos casos serán cosas menores e incluso asumibles y en otros casos, se requerirá un trabajo muy importante realizar su implementación.

Y eso sucederá por muchos prototipos con los que hayas trabajado con el usuario. Es cierto, que el uso de prototipos disminuye el riesgo de posibles discrepancias entre el producto final y las expectativas del usuario, pero también lo es que durante el proceso de desarrollo pueden pasar muchas cosas que hagan que algunas (siendo generoso) especificaciones iniciales ya no valgan, que el usuario que te las haya definido se haya ido de la organización o se haya cambiado de departamento y sobre todo que hasta que no se trabaja con el producto el usuario no termina de ver claro lo que necesita (e incluso requerirá varias iteraciones hasta alcanzar con una solución que empiece a satisfacerle).

¿Qué hacemos entonces?, ¿dejamos las puertas abiertas o cerradas?. Probablemente si se dejan cerradas el producto desarrollado fracase porque por muy bien que se haya hecho, no hará o funcionará como el usuario quiere que lo haga.

Ahora bien, lo que no puede ser es que el proveedor asuma con la carga. ¿Se han desarrollado todas las funcionalidades pactadas de la manera en que está recogida en los diferentes items documentales del proyecto que a su vez ya han sido aprobados por sus responsables? Sí, pues entonces el proveedor no puede, ni debe asumir esa carga.

Debe asumir lo que no haya hecho y los errores de lo que haya hecho, pero no debe asumir errores de terceros.

El problema de todo esto es que cuando esto ocurre, en lugar de asumir lo que hay, de responsabilizarse de lo hecho y de aplicar un mayor presupuesto al proyecto, se recurre al desgaste cliente (área técnica)/proveedor para intentar que esas funcionalidades se hagan, mientras que el área usuaria, suele salir impune, actuando como un espectador que ve una película en la mejor localidad, con palomitas y refresco gratis y que actúa como un crítico implacable.

Estas situaciones son demasiado frecuentes y dan lugar a proyectos que no dejan satisfechos a nadie, que no producen buenos resultados económicos y que han originado un gran desgaste entre las partes. Por motivos como este, es necesario huir de las cascadas como metodología y por otro hace necesario un proceso de educación importante en el área usuaria antes de iniciar el proyecto para que entiendan cuál es su papel en el mismo y la responsabilidad de las decisiones que toman.

El desarrollo dirigido por quien prueba se puede producir de diversas formas.

Una de ellas es que el área usuaria no se centre en definir de manera adecuada las funcionalidades, especificando las mismas sin pensar de manera adecuada qué quiere, cómo lo quiere y cuáles son las posibles alternativas.

El feedback es la esencia para conseguir un sistema que cada vez se aproxime más a las expectativas del usuario, sin embargo, el feedback no debe basarse en un prueba y error, sino que cada iteración debe realizarse con una intención. En caso contrario nos habremos gastado el presupuesto inicial del proyecto, situándonos lejos del alcance esperado e incluso de la implementacion de todas aquellas funcionalidades consideradas prioritarias.

También nos podemos encontrar esta situación, cuando ante la inacción del área usuaria en el proceso de desarrollo de la aplicación, nos encontramos con que cuando empiezan a utilizar la solución empiezan a informar de incidencias y mejoras que tratan de aproximar más el producto a lo que necesitan.

Otra posibilidad es que ya sea por la no participación del área usuaria o por el hecho de que el equipo de proyecto y equipo de testing quieran sacar a relucir su creatividad, se extraen conclusiones de cada iteración de testing para incluir nuevas funcionalidades o mejorar las existentes.

Es muy frecuente encontrarnos en situaciones donde en el código aparecen determinados números o expresiones que resultan complicados de entender en el contexto de un comportamiento que una clase pretende implementar.

Esos números mágicos parece como si fueran los alfileres que sostienen los métodos en los que se encuentran, de manera que su posible refactorización resulta, en ocasiones compleja, al no entenderse su naturaleza.

El desarrollador trata de ejecutar trabajo y muchas veces olvida que su código, probablemente deberá ser accedido en un futuro, por otra persona o por el mismo y que en la medida de lo posible debe ser lo suficientemente expresivo como para poder ser entendido sin tener que recurrir a comentarios en el código (si es que se deciden poner).