archivo

Archivos diarios: noviembre 4, 2011

El ciclo de vida clásico o en cascada tiene el problema de que el producto final tarda mucho en ser visto (o utilizado aunque sea en un entorno que no sea de explotación) por el usuario final, tal vez demasiado tarde y que eso puede dar lugar a sorpresas muy desagradables, como el hecho de que lo que el usuario se encuentre con algo que está lejos de sus expectativas y eso se puede producir aunque se siga el análisis al pie de la letra.

Esto es una constante en este ciclo de vida, si bien, la experiencia de los desarrolladores en el mismo, lleva al uso de prototipos, a realizar presentaciones al usuario sobre módulos ya terminados, etc…

Barry Boehm cita una anécdota que ilustra muy a las claras el inconveniente de esta metodología de desarrollo. En ella un general de la fuerza aérea americana indicaba lo siguiente sobre la incertidumbre que tenía sobre el producto final que se iba a tener en un proyecto desarrollado con este ciclo de vida (traducción libre): “Tus desarrolladores son como los sastres en la historia del Emperador y su nueva ropa. Cada vez que vengo a ver cómo van las cosas, los sastres me comentan que están tremendamente ocupados tejiendo la ropa mágica y que estaré estupendo cuando la lleve en el gran desfile. Pero sin embargo, no hay nada que pueda ver y no hay forma de saber si cuando yo vaya al frente del gran desfile me encontraré sin nada encima”.

Se realiza una entrega, una eternidad después del análisis, se pone el producto en producción. Cuanto mayor sea el tiempo que transcurre entre la finalización del análisis y la puesta en producción más posibilidades hay de que más parte del trabajo realizado termine tirándose a la basura.

Por mucho que cambien los responsables funcionales no es lo mismo solicitar cambios (o el listón para los caprichos está más alto) cuando un sistema se usa que cuando un sistema aún no se utiliza.

El problema para el proveedor en este caso será, en caso de conflicto (y los hay y muchos), que el cliente empiece a encontrar grietas entre lo que se ha entregado, lo que aparece en el análisis, lo que el equipo de proyecto ha podido interpretar, etc…, porque si las encuentra y aprieta (sobre todo si tiene la sartén por el mango), puede que parte de lo que haya que rehacer lo tenga que hacer gratis.

El ciclo de vida clásico o en cascada presenta ese riesgo.

Es necesario reducir los tiempos y que si se piden cambios sean en base a un proceso definido y sobre una versión del desarrollo realizado o lo que es lo mismo hacer un planteamiento iterativo e incremental de los desarrollos.

Barry Boehm plantea una de las principales críticas que se realizan a las metodologías ágiles y que se basa en el hecho de que prime las personas (y su interacción) sobre los procesos y que el software funcione por encima de la documentación, de manera que el conocimiento se concentra en el equipo de proyecto (en el concepto general no refiriéndose exclusivamente al equipo de desarrollo) y que el mismo empieza y termina en él, sin tener en cuenta que en el futuro, otro equipo, parte de él de otra organización, puede participar en su evolución.

La reflexión que realiza Boehm es la siguiente (traducción libre): “Las metodologías ágiles obtienen buena parte de su agilidad, apoyándose en el conocimiento implícito que posee el equipo, en lugar de traspasar el conocimiento a documentos”.

Las metodologías ágiles no obvian ni los procesos ni la documentación, de hecho son medios e instrumentos de trabajo, pero no son el fin. En mi opinión tan malo es el extremo de no documentar como el hecho considerar a la documentación un fin más dentro del proyecto (esto último podría entenderse en ciertos tipos de proyectos, pero aplicados a la generalidad no resulta práctico).

¿Es bueno que el conocimiento se quede en el equipo de proyecto? La respuesta es que no, ¿es eso, entonces, compatible con las metodologías ágiles? La respuesta es que sí y es el resultado de la suma de varios factores: sí que se documenta (lo que el proyecto necesita acorde a su naturaleza, presupuesto y metodología utilizada), se busca la solución más simple (o al menos se debe) y la codificación pretende ser de gran calidad. Por tanto, las metodologías ágiles, bien aplicadas, permiten una transferencia del conocimiento eficaz (será más o menos complicada en función del tipo de proyecto, pero eso al fin y al cabo pasa también con metodologías no ágiles) y una reducción del tiempo de adaptación a la arquitectura y código.

Tenemos que hacer esto… Estaría bien lo otro… A ver si nos ponemos con aquello…

Resultado: la nada.

Conozco técnicos extraordinarios que pierden buena parte de su talento y eficiencia en su mar de dudas, que ellos mismos se encargan de alimentar. En la mayor parte de los casos, la causa es el miedo al error, pero, ¿no es peor mantener una situación que se sabe que no es buena?.

Las buenas intenciones son solo intenciones si no se concretan, si no se traza un plan, si no se determinan una serie de acciones, tareas y objetivos y es que el cambio solo se produce a través de la acción.

Si tu rol exige tomar decisiones y no las tomas, lo mismo es que tienes asignado un rol equivocado y eso no es bueno ni para ti ni para tu organización.