archivo

Archivo de la etiqueta: agilidad

La agilidad no consiste en no documentar. Cada proyecto tendrá sus propias peculiaridades y necesidades, no obstante en la mayoría de los casos lo que sí puede variar es ese enfoque tradicional de la documentación orientado a la utilización de soluciones ofimáticas por otro soportado por herramientas colaborativas y/o CASE.

En cualquier caso y sea cual sea la estrategia que utilices y/o requiera el proyecto (no siempre estarán alineadas) lo que sí es importante entender es que el conocimiento de un proyecto debe ir más allá de la documentación, de hecho debería considerarse en un segundo nivel con respecto a lo que debe suponer el principal objetivo que no es otro que el conocimiento esté distribuido en el equipo, de manera que cada cual sepa qué papel juegan las tareas que realiza tanto en el proyecto como en el producto, consiguiéndose de esta manera una mayor eficacia y una reducción de la dependencia respecto a determinadas personas.

Puede que no parezca el camino más corto pero a la larga el número de kilómetros que se recorren con este tipo de estrategias es mucho menor.

Es razonable que unos sepan más que otros en determinados aspectos pero la visión general debe ser compartida (independientemente de que existan diversas percepciones) y la particular, al menos, conocida, no debiendo quedar ningún elemento estratégico o crítico en manos de una sola persona. Este tipo de situaciones, en las que se crean parcelas de conocimiento (que al fin y al cabo es poder), no solo suponen un riesgo desde el punto de vista de la continuidad de determinadas tareas o de capacidad de adaptación al cambio sino que terminan por fracturar a los equipos.

Otra vez más, no será la última, vendrán muchas más, en la que he tenido que escuchar, que cómo es posible que tal proyecto esté en unas condiciones tan lamentables si se ha desarrollado siguiendo una determinada metodología ágil.

Todo eso teniendo en cuenta que se hace esa afirmación sin datos suficientes de si efectivamente se ha aplicado esa metodología, ciertas prácticas de la misma o algo totalmente distinto, pero que los desarrolladores o alguien de manera equivocada lo han llamado así. Tampoco sin tener en cuenta qué es lo que realmente ha fallado, si la metodología, el enfoque, la arquitectura, la tecnología, el equipo de desarrollo, los responsables funcionales, ¿algunos?, ¿todos?.

Ni Scrum, ni ninguna metodología asegura nada, son solo instrumentos. Tampoco es infalible ni es la mejor solución en todos los casos. Pero, ¿por qué tanto ruido cada vez que un proyecto desarrollado o supuestamente desarrollado siguiendo enfoques ágiles falla?, ¿por qué hay que estar pasando continuamente un examen?.

¿Por qué no pasa lo mismo con los fracasos tras fracasos de muchos proyectos realizados en cascada?.

Supongo que será por salirse de la norma, pero no considero los enfoques ágiles como un acto del rebeldía contra nada sino como otra forma de entender el desarrollo de software, que si ha terminado enfrentándose con los enfoques clásicos ha sido como consecuencia de la difícil convivencia de dos culturas diferentes, en la que hay extremos, pero muchos puntos intermedios, ya que la transición a la agilidad, en muchos casos ha sido paulatina, partiendo primero de un cambio de actitud y tras él la aplicación de determinadas prácticas de desarrollo o, al revés, si bien soy de la opinión de que para ser ágil hay que entender primero qué significa.

Yo vengo de los enfoques clásicos, de muchos proyectos desarrollados de esa manera, de una formación donde era la única alternativa que te enseñaban y he sentido lo que es trabajar de esa forma y los problemas derivados de la misma, por tanto, tengo criterio suficiente para saber que el desarrollo de software pide y necesita otros enfoques, sin que por ello se deba descartar su aplicación si realmente se determina que puede ser la solución más apropiada para un proyecto.

No me siento atado ya por las enfoques clásicos, tampoco lo estoy por los enfoques ágiles por mucha que sea mi atracción sobre ellos. Solo hay que sentirse atado por las necesidades del proyecto, siempre con una mente abierta para tratar de aplicar, equivocadamente o no, la opción que entendamos más válida.

Sí y muchísimo. Y también dentro de las propias prácticas ágiles hay prácticamente una infinidad de alternativas.

No olvidemos lo siguiente: El proyecto se realiza bajo un contexto y el producto que se tiene que obtener a partir de él tiene unas características. Nuestro objetivo es aplicar la estrategia que mejor convenga al proyecto dentro de ese contexto y del conjunto de restricciones que tengamos.

Lo mismo lo más conveniente para el proyecto o las restricciones del mismo nos empujan a un enfoque clásico. Se trata de ser pragmático y pensar en cumplir los objetivos.

¿Por que defiendo entonces la agilidad? En primer lugar porque se trata de una actitud ante los proyectos que es prácticamente independiente de su enfoque. Incluso en un enfoque clásico puedo tomar decisiones o aplicar determinadas estrategias propias de metodologías ágiles. Esa actitud pienso que es positiva y se adapta a la propia naturaleza del desarrollo de software.

¿Por qué la agilidad es válida en más escenarios? Precisamente por su flexibilidad y por su versatilidad.

Yo he trabajado en muchos proyectos con enfoques clásicos y he sufrido muchísimo con ellos, de hecho (y así lo he comentado en el blog) cuando descubrí el agilismo fue como una bocanada de aire fresco porque precisamente es hacia allí donde se dirigía el enfoque que estaba intentando darle a los nuevos proyectos solo que todavía estaban dominados por enfoques clásicos.

¿Qué quiero decir con esto? Pues que tanto he sufrido con los enfoques clásicos que perfectamente podría pensar en mandarles a paseo y olvidarme de ellos, sin embargo, es algo que ni puedo ni debo hacer porque la aplicación de estrategias y/o metodologías ágiles de manera integral no siempre es posible y cuando esto ocurra tenemos que aplicar otro tipo de enfoques (sin olvidar que siempre podremos hacerlo desde una actitud ágil).

Es evidente, no hay nada más que ver la gran cantidad de conferencias, seminarios, certificaciones, etc… que tras el agilismo hay también un negocio. Muchas personas contrarias al movimiento ágil lo utilizan como argumento para deslegitimarlo: “…si la agilidad es algo tan positivo no entiendo porque es necesario darle tanto bombo”.

A mi no me parece mal que haya quienes quieran ganar dinero o ganarse la vida mediante la divulgación de este enfoque de desarrollo de software ya sea desde un punto de vista generalista o mediante la divulgación de estrategias o metodologías concretas y, por tanto, no entiendo que eso pueda ser utilizado como arma arrojadiza contra el agilismo.

¿Qué hay cierta saturación? Es posible pero no por ello tiene que ser negativo. Cada desarrollador, cada profesional expresa su punto de vista basado en su experiencia (contextualizada por los tipos de proyectos, tipos de clientes y la cultura de la región o regiones en las que ha trabajado) y su conocimiento y lo hacen a través de publicaciones, artículos, seminarios, conferencias, etc… Cada cual tiene algo que decir y probablemente tenga cosas que aportar con respecto a los demás porque se habrá encontrado con circunstancias diferentes que le habrá llevado a trabajar de una determinada manera o incluso trabajando en circunstancias similares ha podido aplicar un enfoque o un estrategia diferente.

Lo que sí hay que tener en cuenta que cada uno de esos expertos expresa su punto de vista, influido por el contexto o contextos en los que ha trabajado por ese motivo lo importante es reflexionar sobre lo que te cuentan, aplicar aquellas prácticas que consideres interesantes y no perder la atención si no consigues encajar lo que te cuentan con tu entorno laboral (tal vez no puedas llevar a la práctica lo que te dicen tal como te lo dicen pero es posible que haya ideas que permitan que en determinadas circunstancias puedas enfocar mejor los proyectos o determinadas contingencias dentro de los mismos).

Tener la capacidad de responder a un cambio de contexto lo antes posible, incluso de anticiparse o tener la capacidad de crear una tendencia solo puedo hacerse desde unas bases flexibles que permitan actuar de forma rápida.

Estas bases son los propios procesos organizativos pero también es cuestión de mentalidad (en general de la organización porque la adaptación al cambio es un esfuerzo común pero sobre todo de las personas que tienen poder de decisión tanto en la dirección como en los mandos intermedios). Es más, me atrevería a decir que es casi más mentalidad que procesos porque estos siempre dependerán de personas que harán más flexibles o rígidos los procesos o que incluso, llegado el momento los pueden obviar si fuera necesario.

Ahí es donde entra en juego la agilidad.

La importancia de adaptarse rápidamente al cambio no solo es cosa del desarrollo de software sino en general a cualquier aspecto de la vida. En el mundo de los negocios y de las empresas no adaptarte rápido al nuevo entorno o a un nuevo segmento de mercado puede suponer tu desaparición como organización o la insignificancia más absoluta de tu organización dentro de él.

A todo esto hay que añadirle el hecho de que los cambios de contextos, de tendencias, la aparición de más competencia y con nuevas ideas, etc… es algo continuo, no va a parar. En ocasiones requerirán menos esfuerzo de adaptación y en otras supondrá el replanteamiento o redefinición completa de determinadas líneas de actuación de la organización.

La siguiente cita de Jim Highsmith resume en pocas palabras esta circunstancia: “La agilidad es la capacidad tanto de crear como de responder a los cambios con el objetivo de obtener beneficios en un entorno empresarial turbulento”.

¿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.