archivo

Archivos diarios: enero 26, 2013

La definición clásica de este antipatrón es que es el resultado de una mala combinación entre el modelo en cascada y las prácticas ágiles y que como consecuencia de ello, el proyecto termina en una espiral de falta de control y coherencia en los desarrollos, esfuerzo malgastado, alta deuda técnica y en un más que probable fracaso.

¿Dónde empieza el problema? Todavía se piensa en el desarrollo en cascada, se conocen algunos de sus inconvenientes y se tratan de resolver aplicando determinadas prácticas ágiles a modo de parches y sin entender muy bien las consecuencias. Es decir, se quiere dar un salto a la agilidad sin haber terminado de comprender bien sus valores y principios.

La evolución natural hacia esquemas menos rígidos pasa por ir realizando una división en fases del proyecto (se reduce el alcance del objeto de trabajo y se puede aprovechar el conocimiento de la fase anterior como entrada para las siguientes) como una primera aproximación a un ciclo de vida iterativo incremental.

Una mala práctica que termina en avalancha consiste en no entender o no organizar de manera adecuada la iteración (teniendo en cuenta que serán más pesadas a nivel de proceso, ya que todavía se sigue orientando a entregables documentales), comenzando unas sin tener cerradas otras, solapando alcances entre iteraciones de varios equipos que están trabajando en el proyecto, comenzar una iteración de manera sistemática sin tener la materia prima (requisitos o historias de usuario) preparadas, acumular versiones entregadas pero que todavía no se han podido pasar a producción, multiplicación de entornos, etc…

Y todo ello manteniendo viejas costumbres (no achacables a los enfoques clásicos y sí a las formas tradicionales de trabajar), como la falta de comunicación entre todos los implicados, la gestión desde la distancia, la falta de flexibilidad, papeles secundarios o inexistentes para el feedback, las retrospectivas y la refactorización, etc…

Esa situación lleva al caos, porque si no se pone remedio (y cuesta hacerlo cuando ya se ha entrado en esa inercia), el problema será cada vez más grave.

Uno de los problemas de que a los desarrolladores se les trate como ganado es que de esta forma es muy complicado que vean un propósito que les sirva como elemento motivador en su día a día. De esta forma solo ven tareas, una tras otra y nada más.

Un desarrollador puede ser productivo de esa manera, pero será menos consistente y más irregular, y tendrá que ser bastante fuerte para no dejarse vencer por la tentación de convertirse en un cumplidor o todavía peor en alguien que aparente cumplir (muchos más frecuentes estos últimos).

El desarrollo de software produce mucho desgaste porque los problemas no se terminan cuando sales de la puerta del trabajo sino que te lo llevas en tu cabeza y tardan en desaparecer (si es que lo hacen). Si detrás de esto no hay algo que te motive, te terminas convirtiendo en un robot.

El propósito no se toma en pastillas, ni se construye con cuatro gestos bien intencionados o de cara a la galería. El propósito es creer en un proyecto (es algo más amplio que un proyecto concreto de desarrollo de software), en una forma de hacer las cosas, en sentir de verdad que tu trabajo hace mejor y te hace mejor. Además debe alimentarse de un trato justo por parte de la organización porque de lo contrario se pierde equilibrio.

El problema de todo esto es que muchos gestores piensan que con el salario ya se ha conseguido todo y no es así.

En un ciclo de vida iterativo (o en un enfoque iterativo), se trabaja sobre un conjunto de funcionalidades y se perfeccionan, sin incluir nuevas funcionalidades.

En el ciclo de vida iterativo incremental se van añadiendo funcionalidades.

En el enfoque iterativo existe feedback, se pueden realizar retrospectivas, pero se trabaja sobre componentes, subsistemas o productos completos.

Se puede considerar que el enfoque iterativo podría ser una siguiente fase a la cascada: “tengo una primera versión del producto, vamos a mejorarlo”.

Es un modelo eminentemente teórico porque incluso en modelos que prevén unos requisitos (posteriores funcionalidades) estables, como el clásico, hay variaciones sobre las especificaciones iniciales.

Comenta Stephen Hawking que: “La inteligencia es la habilidad de adaptarse a los cambios”. Y es así, si no lo haces, estás abocado a no evolucionar, a esperar sentado a que otros (personas y circunstancias) decidan tu suerte.

Adaptarse al cambio requiere tener mentalidad abierta, no estar atado a prejuicios y contemplar más posibilidades que las que nos pueden parecer, a priori, más válidas.

En los proyectos de desarrollo de software trabajamos en un entorno de incertidumbre, en el que las condiciones cambian, en donde se pasan de situaciones supuestamente bajo control a otras que se nos escapan de las manos, en donde las que eran las mejores decisiones la semana pasada requieren ser revisadas.

Adaptarse al cambio no es improvisación sino entender la propia naturaleza del desarrollo de software. Ahora bien, la línea que la separa ambos conceptos es muy delgada, de ahí que sea una habilidad la adaptación al cambio, primero por la detección de la necesidad (y la inteligencia y el valor para darnos cuenta de que tenemos que actuar en consecuencia) y en segundo lugar porque todo se debe tratar de hacer con intención, no vale cualquier respuesta, la que tomemos, pese a estar equivocada, no debe basarse en un prueba y error, salvo que no seamos capaces de detectar que una de las opciones sea la mejor.