archivo

Archivos diarios: febrero 11, 2012

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.

Existen más posibilidades de acumular más experiencias cuanto más tiempo lleves trabajando, pero son solo eso, posibilidades.

Todo dependerá del tipo de proyectos, clientes, usuarios, compañeros, jefes, etc… con los que hayas trabajado, de la implicación que hayas tenido en tus tareas, de tus deseos de seguir aprendiendo y de cómo hayas afrontado tus errores.

Son muchas variables, tal vez por eso nos vayamos a lo fácil, más años es igual a más experiencia, pero no es necesariamente así y no hace falta que tengamos que buscar mucho para darnos cuenta, ¿acaso nos resulta complicado encontrar ejemplos?.

La experiencia proporciona un bagaje o un background que permite que nuestras actuaciones o decisiones tengan una mayor base práctica, pero es importante tener en cuenta lo siguiente:

– La experiencia puede condicionar pero no debería ser suficiente para no explorar otras alternativas a la hora de tomar una decisión (escuchar otras opiniones, analizar el problema de manera adecuada, etc…).

– Se puede tener una experiencia excepcional en un área pero en otras prácticamente no tener ninguna, siempre existen aspectos comunes entre tareas diferentes (una forma de enfocar un problema, la relación y comunicación con las personas que colaboran contigo, etc…) pero también matices que las hacen distintas.

Nadie es excepcional en todo, nadie tiene experiencia en todo, por tanto, como siempre suelo comentar, es fundamental aprovechar el talento de cada persona en aquellas áreas y tareas donde realmente lo puedan explotar al máximo.