archivo

Archivo de la etiqueta: ciclo de vida

La primera posibilidad que vamos a estudiar implica dejar muy claro a nivel contractual lo siguiente:

– Catálogo de objetivos y requisitos marco, debidamente priorizados por el cliente y con una valoración de esfuerzo realizada por el proveedor. Este catálogo de objetivos y requisitos, debe tener un nivel de detalle adecuado para poder ser evaluado de manera objetiva por el cliente y también para que pueda ser valorado por el proveedor.

Acertar con el nivel de detalle es importante, ya que no se pretende realizar un análisis en profundidad del sistema (de lo contrario estaríamos desarrollando en un híbrido entre la cascada y un enfoque iterativo incremental en la construcción), pero debe ser suficiente para que la valoración sea lo más acertada posible y para que no existan solapamientos entre requisitos o confusiones sobre su alcance real.

Es muy importante hacerle entender al cliente que resulta fundamental acertar con las prioridades, ya que permitirá obtener antes una versión del producto con sus aspectos más críticos ya implementados y tendrá margen de maniobra presupuestaria para poder hacer los ajustes que considere necesarios.

Lo anterior debe ser recordado al cliente durante todo el proceso de desarrollo.

Además se deberá presupuestar los costes de gestión por parte del proveedor al final de cada iteración: replanificación del proyecto en función de los cambios sobre el plan inicial o sobre el plan establecido hasta el momento, realización de un primer análisis y valoración de nuevos requisitos, revaloración de requisitos ya establecidos, etc…

Este catálogo de objetivos y requisitos, debe ser contratado aparte y antes de comenzar el proceso de desarrollo.

– Compromisos por parte del proveedor respecto a su participación en el proyecto: Esto podrá variar en función de la metodología utilizada, en algunos casos será suficiente su participación al principio de cada iteración (detallar los requisitos) y al final de la misma (evaluación de los resultados obtenidos y definición del alcance de la siguiente iteración), en otros casos requerirá que además de lo anterior, tengan participación dentro del propio equipo de desarrollo o tener un nivel de disponibilidad absoluto ante consultas o peticiones realizadas por los desarrolladores.

– Marco para el cambio del catálogo de objetivos y requisitos inicial y para la gestión de conflictos. Para reducir o evitar los conflictos es importante que quede claro y por escrito, cómo tratar las situaciones más comunes que se pueden producir en el proceso de desarrollo:

Cambio de prioridades. No tendría coste imputable al cliente.

Corrección de defectos. No tendría coste imputable al cliente.

Cambio de un requisito por otro nuevo, ampliación del alcance de un requisito ya existente y reajuste de un requisito ya implementado. Se tendría que evaluar el coste del cambio e intercambiarlo por requisitos todavía no implementados que tengan en suma un coste equivalente (sin pasarnos nunca del presupuesto restante para el proyecto).

Reducción del alcance de un requisito y eliminación de un requisito. Se generaría un “crédito” a favor del cliente que podría ser utilizado para los cambios indicados anteriormente.

Costes de gestión. Si los costes de gestión no superan el presupuesto establecido en cada iteración, pasarían a formar parte de ese “crédito” a favor del cliente. Si los superan y existe circunstancias motivadas para ello (cambios de enfoque en el proyecto, etc…) tendrá que compensarse el coste por créditos existentes o por requisitos.

Cumplimiento de plazos y de la calidad del producto. Siempre y cuando no existan circunstancias externas al proveedor, se debe garantizar por parte de éste un acuerdo de nivel de servicio que podría tener clausulas de penalización y también clausulas de excelencia.

En las relaciones cliente/proveedor, uno de los aspectos que más complicado resulta a la hora de enfocar un proyecto siguiendo un enfoque iterativo incremental lo tenemos en el marco contractual.

Teniendo en cuenta la incertidumbre que existe en el proceso de desarrollo de software y que el objetivo final debería ser cumplir las expectativas de los usuarios a los que va dirigida la aplicación, la situación ideal sería ir facturando por iteración hasta conseguir la versión final del producto.

Es decir, a priori, no tendríamos ni límite presupuestario ni límite de plazos. Muy pocos clientes aceptarían un marco de trabajo como ese, entre otras cosas porque ellos sí que se tienen que ceñir a un presupuesto y en la mayoría de las ocasiones (con mayor o menos flexibilidad) a unos plazos.

Por tanto, va a resultar necesario adaptar los trabajos a un marco limitado en presupuesto y también en plazos, pero resulta absolutamente necesario que el cliente sea consciente de qué es lo que se va ejecutar con ese presupuesto y que el proceso de desarrollo de software es adaptativo, evolutivo y bajo incertidumbre o lo que es lo mismo, que el planteamiento inicial que se haga puede variar (de hecho variará).

Se pueden aplicar diferentes fórmulas para realizar una contrato ágil, en próximos artículos veremos algunas posibilidades.

Tras haber sufrido durante años el desarrollo de software siguiendo ciclos de vida en cascada y la tendencia cada vez mayor a ir orientando los trabajos, siempre que era posible, a los ciclos de vida iterativos e incrementales, me quedaba cada vez más claro que los proyectos de desarrollo de software estaban sometidos a una situación de incertidumbre tal que requerían metodologías que facilitasen la adaptación al cambio y por encima de ellas un cambio de mentalidad.

Lo que más trabajo me costó fue precisamente el cambio de mentalidad y en ello sigo porque uno no se convierte en ágil de la noche a la mañana, uno no puede cambiar de hábitos de manera tan rápida. Además, no se trata solo de cambiar el chip, sino de entender que me debo a un contexto laboral concreto que influye en la aplicación de ciertas prácticas.

Se puede ser parte del cambio, incluso motor, pero salvo que tengas un puesto de responsabilidad que permita acelerar los acontecimientos, la aplicación de tu nueva mentalidad estará contextualizada por el funcionamiento de tu organización, de los proyectos, etc… En cualquier caso, incluso con estas restricciones, siempre tendrás oportunidades de aplicar principios ágiles.

Cuando leí el manifiesto ágil, cuando empecé a estudiar más sobre el tema, me sentí identificado enseguida con lo que este movimiento representa, creo que la mayoría de los que se hayan formado en metodologías y enfoques de gestión de proyectos clásicos y después hayan estado trabajando con ellos durante años, encontrarán en la agilidad su nirvana, su liberación.

La agilidad no constituye por sí misma la solución a los problemas del desarrollo de software, es un instrumento más, pero un instrumento muy importante porque no solo aporta metodologías, aporta una actitud ante el proyecto, ante los problemas, ante el cambio y antes las personas.

Este antipatrón puede considerarse una ocurrencia concreta de otros antipatrones, como por ejemplo “morir planificando” o “parálisis del análisis“.

A mi me parecería más apropiado llamarlo “ingeniería orientada a papel”.

Es muy común encontrarlo en metodologías clásicas como el ciclo de vida en cascada en el que el desarrollo está completamente dirigido por la documentación y en el que se invierte una cantidad de tiempo muy importante en generar la misma, la cual queda obsoleta ante el primer cambio que ocurra en los requisitos, algo que sucederá antes o después (y en repetidas ocasiones) a lo largo del proceso de desarrollo.

Con esto no quiero decir que la documentación en un proyecto sea algo malo, lo que es malo realmente son los excesos o los defectos y es complicado determinar a priori, sin entrar a analizar un proyecto concreto y su contexto qué es mucho y qué es poco.

A este antipatrón se llega por el exceso:

– Cuando se trata de llegar a una solución depurada del sistema de información mediante un feedback basado en la documentación.

– Cuando se dedica tiempo a perfeccionar documentos invirtiendo más esfuerzo que el valor que se obtiene de la realización de esa actividad.

– Cuando se rompe el principio ágil de valorar más “El software que funciona, por encima de la documentación exhaustiva”.

Uno de los grandes problemas de los proyectos que siguen el ciclo de vida en cascada o que siguen un proceso iterativo incremental con ciclos o sprints de larga duración es que al hecho de que son más susceptibles a contingencias que se puedan producir (no porque estas sean menos probables sino porque se es menos flexible o adaptable a las mismas) se le suma el hecho de que se suelen vivir en los mismos dos tipos de velocidades, la que se vive en medio del proceso de desarrollo y la que se vive poco antes de la entrega, ambas relacionadas entre sí y que fuera de unos umbrales razonables resultan muy perjudiciales.

De eso va este antipatrón, de las situaciones donde la velocidad de desarrollo cae en una situación de letargo en medio del proyecto o de la iteración, de la cual despertamos cuando se aproxima la fecha de entrega (como si fuera un simulacro de incendio), donde todo son prisas, donde se intenta terminar lo que habría dado tiempo a hacer si se hubiera sido medianamente productivo antes.

Es un hecho que las prisas en el desarrollo de software no suelen llevar a ningún lado.

Incluso en el mejor de los casos donde realmente sean relativamente pocos los cambios a realizar en el producto software una vez entregado, siempre será necesario disponer de un presupuesto para el mantenimiento del sistema de información.

Si esto sucede incluso en la mejor de las situaciones, ¿qué pasa con esos proyectos mastodónticos desarrollados en cascada donde han existido infinidad de contingencias y en los cuales no ha existido una previsión para el mantenimiento del sistema o la previsión se ha quedado muy lejos de lo necesario?.

Pues que probablemente el sistema fracase o que tras mucho, mucho tiempo empiece a ver la luz. Eso sí, tras un desgaste tremendo por parte del equipo de desarrollo que tendrá que trabajar con un sistema mucho más grande que lo que puede abarcar y en un entorno de producción donde las presiones del área usuaria y de la dirección serán constantes.

Me resulta muy curioso cómo determinados directores usuarios se niegan a pagar el mantenimiento del sistema porque entienden que ya han pagado lo suficiente y todo eso a pesar de que son conscientes de que han estado cambiando especificaciones hasta el final y que muchas de ellas no han resultado acertadas.

Al final, uno descubre que se trata, en gran parte, de un problema pedagógico y es que una de las líneas de actuación (tal vez no la más importante, pero sí a tener en cuenta) para empezar a dignificar nuestra profesión, mejorar el resultado de nuestros productos y a la vez la satisfacción del cliente y luchar contra la crisis del software es empezar a formar a los stakeholders no desarrolladores en la realidad de los proyectos de desarrollo de software.

Tenemos la tendencia optimista (e inocente) de que los proyectos van más avanzados de los que creemos y lo que es todavía peor, tendemos a exagerarlo aún más al usuario o a los clientes.

En desarrollos siguiendo planteamientos iterativos e incrementales con sprints cortos, el avance del proyecto entre los participantes en el mismo sean o no desarrolladores es más objetivo, ya que hay entregas con cierta continuidad y se sabe a ciencia cierta qué funcionalidades están cerradas, cuáles están aún abiertas y cuáles no se han tocado todavía.

Otra cosa es que a la dirección de cada stakeholder que probablemente tengan una relación muy superficial con el proyecto se les venda otra cosa.

En “desarrollos en cascada o siguiendo otras metodologías con entregas tardías, el problema es bastante más serio, ya que la posibilidad de error en el avance es mayor y el riesgo del optimismo exacerbado y/o el miedo a decir la verdad sobre el estado real del desarrollo situarán las expectativas en un lugar, probablemente, que no le corresponde.

Y a todo lo anterior hay que sumarle la incertidumbre inherente a todo proceso de desarrollo software.

¿Soluciones? Intentar en cada momento conocer de la manera más objetiva posible el alcance del proyecto, informar del mismo, tal cual, al cliente o al usuario, darle a conocer a los mismos los riesgos existentes en cada momento del proyecto e intentar llegar a una situación donde no se demoren en el tiempo las entregas.