archivo

Archivos Mensuales: octubre 2012

¿Es compatible generar documentación de un proyecto con la aplicación de principios ágiles? Partiendo de la base de que la agilidad está por encima de las metodologías, por supuesto que sí. Ahora bien, si bajamos el nivel y nos ponemos a nivel de métodos o estrategias ágiles mi opinión es que también, si bien habría que tener siempre en cuenta el contexto del proyecto y el tipo de documentación requerida (en ocasiones la exige el cliente según los procesos que tenga establecidos).

En un enfoque iterativo incremental cada evolución tendrá como objetivo realizar una serie de tareas (pila de sprint) que forman parte de un conjunto de tareas más general (pila de producto). Estas tareas pueden ser de distinta índole: construcción, refactorización, testing, configuración de entornos y, ¿por qué no? Documentación que sirva de base para próximas iteraciones (además de documentación que puede ser de utilidad para el mismo sprint, como por ejemplo documentación de entrega del producto que servirá para su instalación, testing, etc… realizado por personas ajenas al equipo.

Desde esa perspectiva sí que es posible generar documentación siguiendo estrategias o metodologías ágiles si bien hay que entender que la excesiva formalización de la documentación (más de la que el proyecto necesita) supone una resistencia para la evolución del producto: más tiempo para documentar, menos tiempo para desarrollar (y no más documentación supone un mejor desarrollo ya que no se trata de cantidad sino de calidad).

Yo soy partidario de que cada funcionalidad a desarrollar se trabaje de manera que tanto usuarios como programadores sepan qué se va a hacer, ¿estrategia? dependerá del proyecto, de los usuarios, del esquema de trabajo, etc… muchas variables. La historia de usuario supone un instrumento que me gusta bastante: trabajo la historia, aplico técnicas de prototipado si es preciso, no es importante la formalidad y sí el contenido, lo importante es que quede claro lo que se quiere hacer. ¿Habrá huecos en la definión? Es posible, preguntemos lo que sea preciso y decidamos si actualizamos o no la historia en función de la respuesta.

¿Qué hacemos con la historia de usuario tras su construcción y tras la iteración? Es importante registrar lo que se ha hecho en cada iteración y no supone mucho trabajo registrar la historia de usuario asignada a cada tarea.

Opiniones sobre esto hay una por cada desarrollador que existe ya que incluso en visiones parecidas puede haber matices más o menos sensibles. Hay quienes prefieren aplicar ingeniería de requisitos (esto nos lleva hacia metodologías más clásicas si bien es compatible con enfoques iterativos e incrementales) y en el otro extremo historias de usuario de usar y tirar. Cada cual aplica sus conocimientos y experiencia al contexto del proyecto, lo importante es satisfacer las expectativas del usuario y hacer un producto de calidad y mantenible, lo demás son instrumentos, con mayor o menor importancia, pero instrumentos al fin y al cabo.

Trabajas en el contexto de una organización, puede que la misma no funcione bien, no preste atención al proyecto o a tu equipo. Lo mismo no es cosa de la organización (o también) y es cosa de tu inmediato superior (o de su superior), ¿qué te queda?, ¿qué os queda? Vuestra fuerza como equipo.

Si os lo ponen imposible será imposible pero si no es así tendréis la oportunidad de luchar por el proyecto, no digo que se consiga sacar adelante porque lo mismo la resistencia es tal que no se consigue vencer.

Un equipo que funciona como tal, compacto, que se autogestiona, donde se entiende que el trabajo no sale adelante sin la colaboración de todos (cada uno dentro de su rol) es muy potente y es capaz de crear una membrana que lo hace resistente a ingerencias o situaciones externas que afectan al equipo y/o al proyecto.

Por eso es tan importante crear un equipo y si el mismo se extiende a otros stakeholders mejores serán los resultados.

Crear equipos no es tarea sencilla porque no solo depende de quien los coordina sino de la actitud de sus componentes y más difícil todavía resulta mantenerlo en el transcurso del proyecto donde seguro habrá problemas y crisis que será necesario gestionar para no romper esa armonía (o para si se abren pequeñas grietas cerrarlas cuanto antes).

Si entiendes que la simple aplicación de una metodología te hace ágil es que no has entendido realmente lo que es ser ágil. El simple hecho de esconderte tras una metodología, de seguirla como si fuera un dogma te deja desarmado ante la adaptación al cambio porque más allá de la misma te encontrarás el vacío.

Precisamente la explosión de las metodologías ágiles ha sido un arma de doble filo, por un lado ha servido para extender el mensaje y por otro ha podido dar lugar a una mala interpretación del mismo por parte de quienes las practican.

La agilidad no tiene ataduras, puedes usar una metodología pero la misma estará a disposición del proyecto y del contexto y no al revés, ¿que hay que cambiar? si hay causa justificada se cambia y no pasa nada.

No siempre vas a poder aplicar metodologías ágiles porque para ello se tienen que dar una serie de circunstancias en el proyecto que no siempre se producen, eso lo sabemos, ¿tenemos que renunciar entonces a ser ágiles? En absoluto. Nuestro background es ágil y si las circunstancias lo permiten tendremos la oportunidad de aplicar sus fundamentos y principios, tal vez no todos, tal vez en parte, tal vez en alguna ocasión.

La agilidad tampoco es ausencia de metodología porque tener unas reglas del juego proporcionan dinamismo al equipo (que se romperá cuando se quiere mantener una reglas que no sirven para el juego que está ahora mismo sobre el tapete).

La agilidad también consiste en entender que puede haber otros puntos de vista, otra forma de hacer las cosas y en la libertad de cada uno de aplicar las prácticas, estrategias y herramientas que consideren más adecuada al contexto del proyecto.

No conozco a ningún desarrollador que cuente todos sus proyectos por éxitos. El desarrollo de software es así, vas aprendiendo, vas adquiriendo experiencia, te crees invulnerable y de pronto el proyecto fracasa. El fracaso está ahí, llegará, forma parte de las reglas del juego, lo más que puedes hacer es seguir aprendiendo, seguir ganando experiencia para que cuando las cosas vengan mal dadas el impacto sea el menor posible y para tratar de solventar de la mejor manera las contingencias y problemáticas de nuestro día a día.

No se trata de bajar los brazos ante la existencia de problemas, se trata de estar preparado ante ellos porque sin duda, vendrán.

En el desarrollo de software nunca se ha aprendido lo suficiente, nunca se tiene suficiente experiencia, nada garantiza el éxito. Lo que sí se pueden tener es buenas condiciones de partida, después la incertidumbre, las decisiones que se tomen y el trabajo del conjunto de personas que intervienen dictarán sentencia.

Un proyecto con éxito o con un fracaso es solo un hito más en el camino. Ambos hay que asumirlos, sus consecuencias también, nada es gratis.

Sobre esto, me parece muy interesante la siguiente reflexión de Winston Churchill: “Ahora no es el final. No es incluso el principio del fin. Pero, quizá, sea el fin del principio”.

Eso es el desarrollo de software: una dirección sin meta.

No veo por qué no. De verdad. O si lo preferís lo digo de otra manera, no sé porque un enfoque clásico tiene que ser más adecuado.

Un proyecto crítico lo que requerirá es una mayor carga de validación y verificación y realmente eso es lo importante.

Por tanto, cada iteración deberá contemplar el tiempo necesario para realizar ese tipo de tareas.

¿Dónde puede estar el problema? Que se haya calculado mal la cantidad de esfuerzo asumible en la iteración y que no se pueda cumplir el hito de entrega en la fecha prevista, algo que personalmente considero importante cuando planteamos un enfoque basado en iteraciones pero que no es lo más importante para productos de estas características (si fuera más importante el proceso estaría por encima del producto y estaríamos fuera de una concepción ágil del desarrollo), donde es fundamental validar y verificar (y corregir las incidencias que impidan alcanzar el umbral de calidad esperado) para tener la seguridad de que la versión del producto que se va a poner en producción no va a tener problemas.

Por tanto, las iteraciones tendrán una menor carga de evolución del sistema para poder dar cabida a las tareas de validación y verificación y ajustar su duración (la que se define a priori, otra cosa es que haya que ampliarla por los motivos indicados en el párrafo anterior) precisamente a la carga de evolución que sea necesario realizar en el sistema de una sola vez (y que no pueda ser divisible o no sea conveniente dividirla).

Hace poco un amigo me contó que tuvo que hacer una recopilación de documentación de un proyecto de tamaño medio/alto donde gran parte de la misma tenía una antigüedad de entre dos y tres años.

Me dijo que le resultó desolador comprobar como cientos y cientos de páginas tenían una utilidad nula en el presente y como tantas y tantas horas de esfuerzo dieron lugar a un sistema de información que se encontraba a años luz de las expectativas que tenían puestas los usuarios. ¿Qué hubiera pasado si ese esfuerzo se hubiera enfocado en otras actividades que hubieran resultado de mayor utilidad?.

Como mínimo es algo que merece una reflexión, por un lado para saber si merece la pena perder mucho tiempo en aspectos formales de documentación que poco después probablemente no sirva, para llegar a la conclusión de que solo hay que documentar lo que de verdad pueda proporcionar valor al proyecto (y nada más) y para demostrar que una documentación aparentemente buena no tiene por qué dirigirnos hacia un sistema exitoso.

Comentan Mary y Tom Poppendieck que: “El rápido desarrollo tiene muchas ventajas. Sin velocidad, no se puede retrasar las decisiones. Sin velocidad, no tenemos información fiable. En el proceso de desarrollo, el ciclo de descubrimiento es fundamental para el aprendizaje: diseñar, implementar, feedback, mejorar”.

Me parece muy interesante que cita como ventajas, inconvenientes o deficiencias propias de otras estrategias de desarrollo: como atrasar casi indefinidamente decisiones que hay que tomar (gusten o no) y que las hipótesis formuladas queden sin ser demostradas durante demasiado tiempo.

Lo que está claro es que un enfoque clásico donde hay que esperar al final del proyecto a que se levante el teĺón para ver si el resultado es el adecuado es un riesgo absolutamente innecesario y que no se ajusta a la naturaleza del contexto del desarrollo de software: incertidumbre y cambio.

Si la solución no es acertada hay que esperar hasta el final, si hay que mejorar cosas (no solo del producto sino también del funcionamiento de las personas implicadas en el proyecto) también hay que esperar al final (es cierto que se pueden corregir deficiencias en ese funcionamiento sobre la marcha pero se escaparán muchas de ellas debido a que no se tendrá conciencia del impacto real que están teniendo en el desarrollo del producto).