archivo

Archivo de la etiqueta: manifiesto ágil

Los presupuestos fijos en los proyectos sobre una base de funcionalidades que hay que desarrollar (y que son o pueden ser innegociables) dan lugar a fuertes desviaciones en las previsiones iniciales que se pueden ver reducidas o acentuadas en función del conocimiento del negocio, tecnología y de las personas (componentes de los stakeholders) que van a participar en el proyecto y de la materialización o no de los riesgos previstos e imprevistos.

Cuanto mayor sea la incertidumbre más probabilidad hay de que las estimaciones sean erróneas. Por tanto, cuanto más cerca estemos del inicio del proyecto, más probabilidad de error habrá.

Mike Cohn lo cuantifica de la siguiente manera (traducción libre): “Durante la fase de estimación de la viabilidad de un proyecto la estimación realizada se sitúa entre el 60% y el 160%”.

Sobre esa afirmación se podría pensar que todos los proyectos están abocados al desastre. Tal vez quien piense eso no anda muy mal descaminado, sobre todo si el proyecto se realiza en un contexto de inflexibilidad en el que las distintas partes no se centran en el problema: que es desarrollar un producto software de la mayor calidad posible teniendo en cuenta los recursos disponibles.

¿Qué es ese contexto de inflexibilidad? Este es el presupuesto y esto es lo que hay que hacer, no hay posibilidad de negociación ni voluntad de analizar las causas que han dado lugar a esa situación.

Es importante que tengamos en cuenta lo que nos dice el Manifiesto Ágil al respecto: “Se valora la colaboración con el cliente, por encima de la negociación contractual”, a lo que habría que añadir también que “Se valora la colaboración con el proveedor, por encima de la negociación contractual”.

Y es que las causas hay que analizarlas con el objeto de determinar cuál o cuáles han sido los orígenes de esta situación porque en base a eso hay que dialogar y negociar. Generalmente los problemas de ese diálogo o de esa negociación lo tenemos también como consecuencia de una situación de inflexibilidad y la negativa a reconocer errores por parte del cliente y del proveedor.

Dado que el desarrollo de software es evolutivo soy de la opinión de que el presupuesto en un proyecto debe evolucionar de la misma manera que lo hace el software teniendo siempre presente el cliente y el proveedor el coste de cada actuación. Sobre esta materia recomiendo leer la serie de artículos sobre Contratación ágil que escribí hace un tiempo.

Anuncios

Confundir agilidad con Scrum y Scrum con agilidad es algo muy frecuente. Scrum es solo un marco de trabajo, un contexto que favorece un enfoque ágil, pero lo que realmente marca la diferencia en cuanto a la agilidad son las personas.

Por eso es fundamental incidir sobre las bases de lo que es la agilidad, recogidas en el Manifiesto Ágil, entenderlas es esencial, sentirlas más todavía.

Si dejamos que sea Scrum quién se encargue de la agilidad, estamos dejando todo en manos de su implementación y al final, no se hace otra cosa que seguir una metodología, después el día a día y las actuaciones que se realicen en el proyecto pueden derivar en un enfoque que no tiene nada que ver con la agilidad.

Si extendemos la agilidad más allá de lo que es el desarrollo de software y la extendemos al funcionamiento de un departamento TIC, la implantación de la misma puede empezar por un punto concreto, por ejemplo los proyectos, pero si realmente se quiere un funcionamiento ágil del mismo, no te puedes basar exclusivamente en ese punto concreto: “Utilizamos Scrum y ya somos ágiles”, sino que la agilidad debe implantarse como filosofía y como método en todas las áreas del departamento y para ello es fundamental que las personas entiendan, comprendan y compartan esta forma de trabajar.

La verdad es que resulta muy cool en algunos ambientes empezar a hablar de Scrum, Kanban, XP, Lean, WIP, sprints, pila de producto, kaizen, agile, deuda técnica, etc… porque se da la sensación de que se está al día en un mundo tan cambiante como el del desarrollo de software, aunque otra cosa es que realmente se sepa lo que hay detrás de esas palabras y eso le pasa a muchos porque leer un libro o recibir un curso aunque puede ser importante, no termina de ser suficiente.

Agile hay quien lo considera una moda y no sé si quien piensa eso está equivocado o no, porque si bien es una tendencia sobre la cual hay cada vez más gente interesada en seguirla, no debemos olvidar que el manifiesto ágil es del año 2001 y que sus valores y principios eran ya aplicados por desarrolladores desde mucho antes.

Subirse a la ola del agilismo puede ser algo relativamente sencillo, sin embargo se requiere un tiempo (y experiencias) para poder asimilar sus fundamentos, y de esta manera que realmente llegar a comprender por qué hay cada vez más personas y organizaciones que tratan de utilizarlo en base a los beneficios que proporciona.

La agilidad no es algo a lo que se accede por la aplicación de determinadas prácticas que se puedan considerar ágiles, sino que necesita de algo más, porque realmente se trata de otra forma de entender el desarrollo de software y eso no se consigue de la noche a la mañana.

De esta forma se puede ser ágil en cualquier contexto, incluso en aquellos casos en los que en un proyecto concreto te impongan la aplicación de un enfoque clásico, ya que existirán circunstancias y momentos en los que ante un determinado problema o una determinada decisión se les pueda dar un enfoque ágil y pese a los obstáculos que te puedas encontrar o que te puedan separar con otras personas, nada impide que te crees tu propia visión de las mismas y de cómo debería ser tu relación con ellas.

Con la aplicación de metodologías ágiles se puede empezar a descubrir todo lo que puede aportar a un proyecto y también, por qué no decirlo, a nosotros mismos, porque varía la forma en que interactúan y se comunican las personas dentro y fuera del equipo de desarrollo y se sitúa al producto en el lugar que le corresponde.

El procedimiento o la metodología queda en un segundo plano, como un instrumento, con mayor o menor importancia en cada caso, pero al fin y al cabo como un instrumento.

¿Qué es Scrum?, ¿un proceso o un marco de trabajo?, una cosa es lo que piense y otra lo que se hace realmente.

La agilidad es colaboración entre personas y capacidad de adaptación al contexto y al cambio, esto implica que en esencia y de partida no te debes “casar” con ninguna estrategia, metodología o práctica de desarrollo ya que debes seleccionar aquella que mejor se adapte a las condiciones y contexto del proyecto y cambiarla parcial o totalmente si hiciera falta por la propia evolución del proyecto (por la propia necesidad de adaptación al cambio).

Querer aplicar Scrum sí o sí no es ágil en esencia. Aplicarlo en contextos donde sí sea una estrategia favorable pero limitarte por la ortodoxia de las prácticas tampoco es ser ágil. Lo que es ágil es tener la mente abierta a elegir las prácticas que más pueden convenir al proyecto, adaptar aquellas otras que lo requieran y descartar las que no procedan.

La ortodoxia por encima de todo convertirá a Scrum en un proceso y precisamente no es eso lo que queremos. Por eso siempre insisto a las personas que se están iniciando en el agilismo en que no se limiten exclusivamente a leer o asistir a conferencias y cursos (que por otra parte serán interesantísimos y serán atajos para comprender conceptos y comportamientos que llevan tiempo y experiencia aprender y sobre todo asimilar) sino que experimenten desde las bases del Manifiesto Ágil.

¿Y que tiene que ver la agilidad en todo esto? En admitir una realidad que no es otra que la necesidad de adaptarse al cambio, a esas nuevas circunstancias que nos vamos encontrando en el proyecto y que nos obligan a tomar decisiones que se ajusten a las mismas.

Para ello las personas y el producto tienen que estar en primer plano.

Las personas tendrán que trabajar juntas, interactuando, comunicándose, para resolver las contigencias y problemas del día a día, siempre pensando en el producto y en tratar de conseguir el mayor valor para el mismo, tratando de mantener el clima más favorable para que el proyecto pueda ir hacia adelante.

Por parte del equipo de desarrollo se tienen que gestionar adecuadamente las expectativas, esto requiere transparencia, honestidad y saber comunicar de manera razonada las posibles desviaciones sobre los compromisos. Por parte del área usuaria, se requiere capacidad de comprensión de las circunstancias que la han provocado. Esa comprensión se irá haciendo más fuerte conforme vaya creciendo la confianza.

En el artículo anterior, hablaba de definir unas condiciones contractuales en las que se comparta el riesgo. Esto no solo es compatible con lo que estoy comentando, sino que es absolutamente necesario. Tiene que haber reglas del juego, conocidas, y sobre ellas ir tomando decisiones, siendo flexibles cuando sea necesario y justo.

La colaboración entre cliente y proveedor siempre debe estar por encima de la negociación contractual, tal y como indica el manifiesto ágil, ya que las condiciones de un proyecto varían de la noche a la mañana y el contrato es estático.

Al final, todo queda en mano de las personas, todo se reduce a eso y salvo que las condiciones iniciales del proyecto sean malas de partida (Death March Project) y/o haya grandes fluctuaciones sobre el enfoque del proyecto y sus objetivos, en ellas queda la mayor parte de la responsabilidad de que el proyecto pueda llegar a algún sitio.

Ya he comentado en diversas ocasiones que mi forma de entender el software cambió tras la lectura del manifiesto ágil. Fue como si todas las piezas del puzzle, que años de desarrollo en cascada se encargaron de confundir y desunir, empezaran a encajar.

Es cierto que antes de ese momento ya pensaba que lo importante para que los proyectos salieran adelante eran las personas, su adecuada interacción, comunicación y confianza e intentaba dividir los proyectos en fases y conseguir feedback tanto para mejorar nuestra forma de desarrollar como para mejorar el producto,

No era (ni soy) un iluminado, ni mucho menos, puesto que la tendencia natural de la mayoría de nosotros es intentar mejorar y solo hay que haber trabajado un poco con enfoques clásicos para darnos cuenta cuáles son sus carencias en entornos reales de desarrollo de software.

La lectura del manifiesto ágil puso ante mi la realidad en la que creía y la intensificó por su ánimo no solo de mejorar los resultados en los proyectos sino también de la forma en la que se consiguen(algo que es, para mi, importantísimo).

La base de esta nueva corriente o movimiento (que si bien sentó las bases en el 2001) comenzó mucho antes, mediante la aplicación de estrategias, metodologías y enfoques que eran compatibles con la misma, como resultado de esa huida del orden establecido por los enfoques clásicos.

Es importante entender los fundamentos de esta forma de entender el desarrollo de software, por ese motivo recomiendo siempre empezar por ahí, por la base y ponerla en contraste con los ciclos de vida tradicionales. Es posible que hayas tenido la fortuna de trabajar siempre en entornos ágiles, sin embargo, si no ha sido así, te será fácil hacer ese análisis (y si no, trata de que personas que hayan trabajado en ciclos de vida clásico te expliquen sus experiencias), siempre y cuando tengas el deseo de seguir mejorando y de asumir tus numerosos errores del pasado.

Si entiendes los fundamentos podrás aplicarlos sea cual sea el contexto y sea cual sea el enfoque porque la agilidad es cuestión de actitud. A veces las restricciones existentes en los mismos te limitarán su aplicación pero no podrán minar tu actitud y verás como se presentan situaciones que podrás afrontar desde una visión ágil.

Una historia de usuario no es una descripción de una tarea en un post-it. O tal vez sí. Depende de lo que requiera el proyecto o del contexto actual del mismo.

Sobre esa base, habrá opiniones para todos los gustos. La mía es que las historias de usuario requieren ser descritas con el suficiente nivel de detalle para poder ser estimadas con fiabilidad y para que el programador pueda trabajar con ellas.

Es importante no olvidar que el objetivo no son historias de usuario que lleguen al máximo nivel de detalle, sino la que se necesite. No es fácil alcanzar ese equilibrio pero con la experiencia (desde una visión general) y tras algunas iteraciones (centrándos en el proyecto en el que estamos trabajando) nos iremos aproximando a ello.

Esto desde un punto de vista de la producción, ya que habrá determinados tipos de proyecto que requieran además que el cliente y el proveedor vayan aprobando hitos de trabajo (y su presupuesto correspondiente), en estos casos, el hecho de que las historias de usuario estén por escrito y con el suficiente nivel de detalle es absolutamente necesario.

Puede aparecer que esto contradice en cierto modo el tercer principio el Manifiesto Ágil: “Se valora la colaboración con el cliente por encima de la negociación contractual”, pero hay que tener en cuenta que cuando se contratan nuestros servicios por terceros, el nivel de formalidad vendrá definido por el acuerdo al que se llegue con el cliente y por la experiencia que tengamos en trabajar con ese cliente o con clientes de ese sector. En estos contextos, tener registrado qué se hace y con una aprobación formal por parte del product owner, evitará muchos problemas después.

¿Cómo catalogamos las historias de usuario? Mi recomendación es que las historias de usuario se cataloguen a nivel de sprint, pudiendo estar en un documento independiente o en uno que vaya recopilando los diferentes sprints. Hay que tener en cuenta que no estoy creando un excesivo overhead ya que considero fundamental tener bien especificadas las historias de usuario (cuando digo bien especificada siempre hago referencia a lo que la historia de usuario necesita que en función del estado del proyecto puede requerir más o menos nivel de detalle).

Volviendo a la catalogación de las historias de usuario, se tratarían de documentos que no se modificarían como consecuencia de la evolución del sistema, ya que son fotos de cada sprint. Se pueden hacer trabajos de consolidación para hacer fotos no ya a nivel de sprint sino a nivel de sistema en determinados momentos del tiempo, serán las necesidades del proyecto, del producto y de los participantes las que dicten la necesidad o no de hacer esa actividad.

Con las historias de usuario volvemos al lenguaje natural, lo que no limita la utilización de prototipados de interfaz, subconjuntos del modelo de datos, etc…, sin olvidar que su objetivo y funcionamiento debe ser entendible por el product owner (independientemente de que haya especificaciones concretas para los desarrolladores).

Las historias de usuario deben detallar la tarea y también describir las comprobaciones que debe hacer el product owner para dar por válida la misma (antes las deberá hacer el equipo de desarrollo y testers especializados si existen en el proyecto), es importante señalar que una historia de usuario debería ser válida o no válida y no deberían existir estados intermedios como “casi válida”, recordemos que queremos mantener un ritmo sostenido de desarrollo y eso requiere no estar continuamente dejando flecos abiertos.