Categoría: como_empezar / transformación Agile

Contratos agiles – XXIII encuentro ágil en Barcelona

A continuación aparecen las fotos del encuentro.

grupo

 

contratos-agiles

 

fundamentos-contratos-agiles-1

 

fundamentos-contratos-agiles-2

 

fixed-price-fixed-scope

 

fixed-price-fixed-scope

 

var-price-var-scope

 

var-price-fixed-scope

 

Agradecer a everis la cesión de sus instalaciones, los snacks y las bebidas.

 

Para apuntarse a los próximos encuentros en Barcelona sobre temas ágiles: http://agile-spain.wikidot.com/quedadas-barcelona

Artículos relacionados

 

 

Agilidad es calidad y competitividad

Este artículo se tomó como base para el mini keynote de apertura del Agile Open Spain 2009.

Agilidad es calidad

 

La agilidad es mayor satisfacción para TODOS los que participan en un proyecto:

    • Nuestros clientes, que reciben un mejor servicio.
  • Los trabajadores (nosotros), que podemos realizarnos profesionalmente en nuestro trabajo y que disfrutamos más.

Esto es lo que venden muchas las metodologías, pero con diferencias fundamentales en cómo entendemos y conseguimos esa calidad:

  1. Calidad es satisfacer las expectativas de nuestros clientes, y para ello no hay nada mejor que priorizar los objetivos del proyecto en función de los que aportan más valor al cliente, enseñarle de manera regular el producto final (una aplicación funcionando) y siendo flexibles a cambios (control empí­rico en contraposición al control predictivo de metodologías más tradicionales, que suponen que es posible conocer desde el principio todos los detalles del sistema a construir y que, por tanto, estos no van a cambiar durante el desarrollo).
  2. Calidad es que lo que nuestros productos puedan crecer de manera sostenible, que estos cambios tengan un impacto controlado, de manera que estos cambios sean baratos. Para ello:
    1. Utilizamos prácticas de ingeniería (patrones de diseño, peer reviews, pair programming, coding standards) y cuidamos la calidad interna de nuestros productos empezando primero por las pruebas (TDD, refactoring).
    2. Mientras construimos nuestros productos, comprobamos de manera continua que se comportan de  manera adecuada. Para que esas comprobaciones sean baratas (dado que hay que repetirla infinidad de veces) automatizamos integraciones y pruebas.
  3. Las metodologías ágiles no se olvidan del capital humano que lo hace posible. Nosotros creemos que la calidad de un proyecto depende de la calidad de TODAS las personas que trabajan en él y de cómo colaboran, mucho más que de tener procesos bien definidos y documentados.

 

Agilidad es competitividad

 

Por otro lado, nunca podremos competir con India o China en precio. La agilidad nos puede ayudar a tener un país más competitivo, es decir, a ser más innovadores, a proporcionar mayor calidad y a ser más productivos. Necesitamos adoptar modelos de gestión que nos permitan adaptarnos de manera continua a un entorno de incertidumbre, en continua evolución, y ser muy ágiles en el desarrollo de iniciativas. La clave vuelve a ser:

  • Modelos dirigidos por valor.
  • Flexibilidad a cambios.
  • Potenciación del equipo, multidisciplinar y autogestionado, para que aporte creatividad en el producto y que sus sinergias y la mejora continua le hagan más eficiente a través de la colaboración de sus miembros.

 

¿Qué se necesita para que una empresa sea ágil?

 

Para que una empresa empiece a ser ágil es conveniente realizar los siguientes requisitos:

  • Un cambio de cultura profundo en individuos y organizaciones, y especialmente en las direcciones y los gestores de las empresas. En lugar del ordeno y mando, para poder crear este tipo de equipos superproductivos y motivados se necesita cambiar a un modelo de gestión basado en la facilitación de la colaboración entre las personas que participan en los proyectos, así como el coaching del equipo, para que adquiera conocimiento de forma colaborativa, que desaprenda, se equivoque y que vuelva a aprender.
  • En esta misma lí­nea, hay que transformar las relaciones de cliente/proveedor en relaciones de socios de proyecto en que todos tenemos que colaborar y todos  tenemos que ganar.
  • A nivel de ingeniería, facilidad para realizar cambios.
  • Enfocarnos en proporcionar valor en todas las tareas que hacemos, desde que aparece la idea del producto hasta que el usuario final o consumidor lo reciben.
     

Todo esto acabamos de ver es, esencialmente, el Manifiesto Ágil, Scrum, eXtreme Programming y Lean Software Development.

 

¿Quien hace Agile?

 

Hoy dí­a, las metodologí­as ágiles se están extendiendo en paí­ses punteros en tecnología (EEUU y su área de influencia, países del norte de Europa y potencias emergentes como India o China).

 
Entre las empresas que han realizado este cambio de paradigma para ser más competitivas y atraer talento podemos encontrar a Google, Amazon, Nokia, British Telecom, Microsoft, SAP, IBM, Bank of America, General Dinamics, Blizzard, Ubisoft, etc. y españolas como Telefónica I+D, Double You, Plain Concepts, Proyectalis, Biko2, Gailén, Autentia, etc.

De cualquier manera, en España las metodologías ágiles todavía son poco conocidas. En poco tiempo, nuestros profesionales y empresas pueden no ser competitivos y ni siquiera colaborar con empresas extranjeras porque no nos habremos adaptado a estas nuevas formas de trabajar.
 

En resumen

 

La agilidad es una gran oportunidad para tener empresas más competitivas y a la vez disfrutar más de nuestros trabajos, oportunidad que no deberí­amos perder para no quedarnos atrás como país.

 
 

Para saber más

 

 

Scrum: un proceso de trabajo 3.0

Autor: Xavier Albaladejo

Revisor: João Gama

Scrum es un conjunto de prácticas especialmente combinadas para dar soporte a la creación de productos innovadores y enfocar el trabajo del equipo en producir valor directo para el cliente final. El uso regular de estas prácticas (entregas frecuentes priorizadas por valor, potenciación del equipo de trabajo, mejora continua de producto y de proceso, etc.) permite que los cambios dentro de un proyecto sean aceptados de manera natural y proporciona al cliente margen para flexibilidad e innovación así como productividad y calidad.

Las metodologías tradicionales ya mencionaban las prácticas y conceptos utilizados en Scrum, llegando a utilizarlos en mayor o menor medida y prometiendo también un mejor resultado en los proyectos. Pero una cosa es reconocer que estas prácticas son buenas y otra muy diferente es actuar en consecuencia [1], es decir, utilizar todas estas prácticas situándolas en el centro del proceso. 

  • El desarrollo iterativo e incremental ya existía antes. La diferencia es que en Scrum la planificación del proyecto hace explícitos los objetivos del cliente y los prioriza en función del ROI (Return of Investment), es decir, balanceando el valor aportado al cliente respecto a su coste de desarrollo, y minimizando el trabajo en curso (Work In Progress) necesario para obtener un resultado. Si en las metodologías tradicionales el cliente tenía que esperar a tener todo el valor de un proyecto el último día de la última fase, habiendo acumulando todos los retardos de todas las fases, en cambio con Scrum el cliente puede dirigir de manera sistemática y regular (cada iteración) los resultados que va obteniendo del proyecto. De esta manera (y siguiendo la ley de Pareto en que el 20% del esfuerzo proporciona el 80% del valor), el cliente puede empezar antes a recuperar su inversión (y/o autofinanciarse) comenzando a utilizar un producto al que sólo le faltan características poco relevantes, puede sacar al mercado un producto antes que su competidor, puede ir adaptándolo mejor a las necesidades de los clientes y hacer frente a urgencias o nuevas peticiones.
  • La orientación a personas ya se practicaba antes, sólo que se basaba en aspectos relacionados con la ejecución de cada persona y condicionados a la subjetividad del evaluador. En Scrum, en cambio, dado que el equipo es multidisciplinar (incluye a todas las personas necesarias para llevar a cabo el proyecto) el planteamiento es de potenciación del equipo (team empowerment), de darle responsabilidad y autoridad para que decida cómo funcionar de la manera más eficiente posible, mejore su entorno de trabajo y pueda mostrar resultados de manera regular, así como permitirle aportar innovación al producto que está desarrollando, cosa que facilita la motivación y realización personal de cada uno de sus miembros.
  • La planificación con tareas, tiempo y personas ya se hacía antes, sólo que en las metodologías tradicionales las tareas, las asignaciones y los tiempos las decidía un jefe de proyecto. Sin embargo, en Scrum la planificación de proyecto se hace orientada a objetivos del cliente (y no a tareas) y la realiza el equipo utilizando técnicas muy rápidas de estimación (por ejemplo planning poker). Asimismo, la planificación de iteración también la hace el equipo, quien identifica y estima de manera conjunta las tareas a realizar y se las autoasigna. De esta manera, las estimaciones son mucho más fiables por que se realizan en base a las experiencias e información de todos los miembros del equipo y dado que las han proporcionado ellos se convierten en compromiso.
  • El control del progreso del proyecto orientado a tareas ya se hacía antes, con el jefe de proyecto preguntando a cada persona el estado en que se encuentran sus tareas. Sin embargo, en Scrum el equipo se compromete y reporta diariamente su avance y problemas respecto al resto de miembros del equipo, con lo que la sinergia, la transferencia de información, de experiencias y de soluciones es mucho más alta. En Scrum, en lugar de un responsable del equipo/proyecto hay un facilitador que garantiza la colaboración entre todos los participantes.
  • La gestión de cambios ya existía antes, era un control férreo para impedir que el proyecto se moviese tanto en alcance, como en tiempo como recursos. En cambio, el planteamiento que se hace en Scrum, es el de aceptar que los cambios son naturales y permitirlos en el inicio de cada iteración (ya que todavía no se ha desarrollado nada respecto a futuros objetivos), una vez se ha demostrado al cliente los resultados obtenidos en la iteración anterior, para darle más flexibilidad en la adaptación del producto a sus necesidades (siguiendo unas reglas de alcance variable que permiten que tanto el cliente como el proveedor ganen [2]).
  • Las retrospectivas y los análisis “post mortem” (para mejorar los proceso de trabajo) ya se hacían antes, sólo que normalmente al final de un proyecto o  de una gran fase. Sin embargo, en Scrum las retrospectivas se hacen al final de cada iteración, de manera que el equipo pueda aprender y sea más productivo dentro del mismo proyecto.
  • El timeboxing era una herramienta conocida anteriormente. La diferencia ahora es el uso de timeboxing para todas las actividades de Scrum, de manera que facilite el enfoque en resultados y la toma de decisiones.
El enfoque de Scrum exige utilizar estas prácticas de manera regular y frecuente para así proporcionar flexibilidad , productividad, innovación y calidad, teniendo como base la colaboración entre las personas que participan. En el pensamiento ágil prima la colaboración y transparencia con el cliente y entre el equipo, para así reducir riesgos, cubrir al máximo posible las expectativas del cliente, mejorar de manera continua los productos y procesos, ganar en creatividad y disfrutar más en la realización del trabajo [3].
 
Aplicar estas prácticas de forma sistemática en el día a día de los proyectos puede no ser fácil (e incluso puede no ser idóneo), bien por que la cultura de la empresa no está alineada (no se trata de una cultura colaborativa [4]) o bien por qué se desconocen las técnicas sobre cómo aplicarlos. Afortunadamente, para iniciarse en el mundo ágil actualmente ya existe abundante material [5], tanto gratuito como de pago, así como comunidades y eventos para el intercambio de experiencias.
 
 
[1] Esta manera alternativa de realizar proyectos proviene de un estudio sobre equipos altamente productivos e innovadores que produjo un cambio de enfoque en la aplicación de estas prácticas.

Para saber más

Agradecer a João Gama, Product Owner y coach, las matizaciones en el enfoque de este artículo.

Agradecer a Gemma Hornos la recomendación del libro de Juan Carrión «Culturas innovadoras 2.0», donde he visto bastante reflejada mi vida anterior y de donde he sacado bastantes ideas para el futuro.

Iniciativas resultado del primer encuentro ágil en Barcelona

Resumen

El punto principal que se trató en el encuentro fue por qué no son más conocidas las metodologías ágiles:

  • Cambio cultural y de valores. Respeto y reconocimiento a quien es válido. Las metodologías ágiles “aplanan” la jerarquía de la empresa.
  • Factorías de software jerárquicas.
  • La universidad enseña waterfall.
  • La mayor parte de los recursos están en inglés.
  • Poco conocimiento de metodologías en general en las empresas, y menos si son “nuevas”.
 Iniciativas propuestas para dar a conocer las metodologías ágiles:
 
  • Hacer un evento a nivel nacional con casos de éxito de empresas españolas.
  • Divulgar las metodologías ágiles en clientes y quien toma las decisiones en las empresas, explicando los beneficios y casos de éxito.
  • Crear un directorio de empresas ágiles españolas.
  • Crear contenidos en español donde explicar cómo trabajar con metodologías ágiles, problemas y soluciones.
  • Hacer talleres donde aprender y practicar técnicas ágiles.
  • Fomentar la formación en metodologías ágiles en la universidad.
  • Directorio de herramientas de gestión y de desarrollo.
 

 

Los participantes

 

14 personas que aplican metodologías ágiles en desarrollo de software y consultoría desde hace 6 meses a 2 años, con resultados positivos.

 Algunos de los participantes:

 
Por qué no son más conocidas las metodologías ágiles

 

  • Cambio cultural y de valores.
    • Respeto y reconocimiento a quien es válido, premiar al competente.
    • Las metodologías ágiles “aplanan” la jerarquía de la empresa. Hay mandos que no están dispuestos a que sus equipos tengan más responsabilidad y autoridad, que les digan qué y cómo se hacen las cosas.
  • Factorías de software jerárquicas.
  • La universidad enseña waterfall.
    • La enseñanza universitaria está basada en “waterfall”, ya que es un proceso con las mismas fases que otras disciplinas de ingeniería entienden (pero asumiendo que los requisitos iniciales son conocidos, por ejemplo, en la construcción de un edificio).
    • Da la sensación de que las metodologías ágiles no son formales (sin embargo, tanto XP como Scrum definen procesos, que ayudan a certificarse en CMMi 3).
  • La mayor parte de los recursos están en inglés (libros, revistas, artículos en Internet), cosa que no predispone a algunas personas.
  • Poco conocimiento de metodologías en general en las empresas, y menos si son “nuevas”. También hay que tener en cuenta que la adopción de una metodología de manera más o menos general tarda años.

 

Otros temas tratados 

 

Otros temas que se trataron o hubo interés en tratar en futuros encuentros

  • Cómo hacer participar al cliente en el proyecto. El cliente quiere resultados y no le importa tanto la metodología, por lo que a veces es difícil involucrarlo en el desarrollo (sin embargo, las metodologías ágiles necesitan de su tiempo y participación regular, cambiando el paradigma de cerrar el alcance, coste y tiempo al inicio del proyecto, para dejar abierto el alcance).

  • Cómo hacer testing en metodologías ágiles y, especialmente, en outsourcing.

  • Cómo definir el business case y la visión de producto según metodologías ágiles dado que, por ejemplo, el business case es anterior al proceso de Scrum y queda fuera de su alcance.

  • Cómo aplicar los principios de la agilidad en “operaciones”, gestión de sistemas y Data Centers. Existe un vacío en esta área y podría definirse alguna metodología ágil siguiendo sus valores.

 

Iniciativas para dar a conocer las metodologías ágiles

 

  • Hacer un evento a nivel nacional con casos de éxito de empresas españolas.

    • En este momento participarían: Telefónica I+D (quien cedería sus instalaciones) y DoubleYou.
    • Otros (a contactar): Rally Software, Códice Software, Juan Palacio, Proyectalis, Jorge Fernández (Agile Business Intelligence), …
    • Key Note: Se propone a Ángel Medinilla y algún speaker internacional.

  • Divulgar las metodologías ágiles en clientes y en quien toma las decisiones en las empresas (CEOs, CIOs, mandos medios, jefes de proyecto, etc.), explicando los beneficios y casos de éxito.

  • Crear un directorio de empresas ágiles españolas.

  • Crear contenidos en español donde explicar cómo trabajar con metodologías ágiles, problemas y soluciones.

  • Hacer talleres donde aprender y practicar técnicas ágiles como, por ejemplo, coding do jo’s: una empresa lo patrocina cediendo una sala de reuniones. Se define algo que hacer y en qué lenguaje. A partir de aquí una persona toma el rol de cliente y los demás, haciedo programación por pares y TDD en iteraciones van dando forma al producto. Estas reuniones están muy bien para dar a conocer estas prácticas, para dar a conocer cómo se trabaja con ciertas metodologías ágiles (para gente que no tenga mucha experiencia) o para aprender un nuevo lenguaje o framework (para aquellos que no lo conozcan aunque tengan experiencia con metodologías ágiles).

  • Fomentar la formación en metodologías ágiles en la universidad.

  • Crear un directorio de herramientas de gestión y de desarrollo (se podría utilizar el drigg para poner comentarios y puntuarlas).

 

Próximos encuentros ágiles en España:

 

 

 

Un contrato ágil para Scrum

El ejemplo de cláusulas que se muestra a continuación permite formalizar, en una petición de ofertas a proveedores (RFP, Request For Proposals) o en un contrato, cómo deberá de ser la relación entre cliente y proveedor en la ejecución de un proyecto ágil utilizando Scrum.

Aunque el lugar natural de Scrum es el contrato de un equipo por meses (pago por iteración – 2 iteraciones de 2 semanas o mensual), en muchos casos el cliente prefiere o necesita que tanto el alcance como el coste como la fecha de entrega del proyecto se fijen de antemano (ver Triángulo de Hierro). En estas situaciones, para no perder los beneficios que aporta Scrum respecto a flexibilidad y adaptación y gestión del Retorno de Inversión (ROI), se pueden definir cláusulas específicas de Cambios de requisitos y de Finalización anticipada del contrato. Con esta última en especial tanto el cliente como el proveedor ganan en términos económicos: el cliente puede ahorrar dinero y el proveedor ve premiada su productividad.

En el siguiente ejemplo, como parte del proyecto también se deberá elaborar la lista de requisitos priorizada (Product Backlog).

Proceso de control y seguimiento del proyecto
Control y seguimiento del proyecto basado en objetivos
El proyecto se ejecutará en iteraciones incrementales con una demostración del producto al finalizar cada iteración. De esta manera se podrá conocer de forma objetiva el estado del proyecto (si el desarrollo de los requisitos cumple con las expectativas de <<el cliente>>, si la calidad es la esperada o si hay retrasos), con lo que <<el cliente>> podrá tomar decisiones informadas.
Los requisitos se desarrollarán priorizados por el valor aportado a <<el cliente>>, de modo que en las primeras iteraciones se obtendrán los objetivos más importantes del proyecto y se podrán realizar ajustes al respecto con la suficiente antelación.
El control y seguimiento del proyecto se basará en los requisitos completados en cada iteración. Se entenderá un requisito como completado si incluye todos los entregables asociados realizados (documentación, etc. [1]) e integrados con los entregables de las iteraciones anteriores, de manera que el producto sea susceptible de ser entregado a <<el cliente>> con el mínimo esfuerzo. Por esta razón, cada requisito deberá ser:
  • Independiente del resto de requisitos, en la medida de lo posible.
  • Demostrable, de manera que sea claro cómo comprobar con <<el cliente>> que el requisito está completado y que se cumplen sus expectativas.
  • De un grado de esfuerzo para ser completado semejante al del resto de requisitos, de manera que <<el cliente>> pueda realizar una extrapolación del progreso del proyecto.

Iteración 0 – Elaboración de la lista de objetivos/requisitos y planificación

Duración: <<2 semanas .. 1 mes .. lo que se considere necesario para obtener una visión de alto nivel>>.
Objetivos:
  • Planificar y distribuir los objetivos y alcance del proyecto en iteraciones, de manera que los requisitos estén priorizados balanceando el beneficio que aportan a <<el cliente>>, su coste de desarrollo y los riesgos del proyecto. De esta manera, las primeras iteraciones del proyecto podrán acomodar los requisitos más importantes y mitigar los riesgos más altos.
Actividades
  • Identificación de los objetivos del proyecto y de los requisitos iniciales de alto nivel que permiten la consecución de estos objetivos. [2]
  • Priorización de los requisitos en iteraciones y entregas considerando los siguientes criterios:
    • El valor aportado por cada requisito para <<el cliente>>. Deberá ser explícito quien es el actor o usuario beneficiario de cada requisito y qué valor le aporta.
    • El esfuerzo necesario para desarrollar cada uno de los requisitos, de manera que en las primeras iteraciones se desarrollen los requisitos que proporcionen el máximo valor con el mínimo esfuerzo y que puedan encajar en la periodicidad de las iteraciones.
    • Las dependencias inevitables entre requisitos.
    • Minimizar los riesgos del proyecto respecto a desarrollo de los requisitos, disponibilidad y grado de implicación de los actores y beneficiarios implicados, interacción con otros equipos (proyectos en paralelo, compras de material e infraestructura, encargados de entregar el proyecto a los usuarios finales), etc.
    • Maximizar la cohesión del contenido de cada iteración, identificando los puntos de acoplamiento y las dependencias entre los diferentes incrementos de manera que sean mínimos, para poder dar por realmente completados los requisitos desarrollados en cada una de las iteraciones.
  • Calcular la duració de cada uno de los incrementos desarrollados de manera que puedan encajar en la periodicidad de las iteraciones (que deberán ser de la misma duración de <<2 semanas ..1 mes>>.

Entregables

 
Iteraciones de desarrollo
Duración: Todas las iteraciones de desarrollo serán <<mensuales>>.
Objetivos:
  • Completar un incremento de producto que sea demostrable a <<el cliente>> al finalizar la iteración, de manera que pueda tomar decisiones informadas y objetivas sobre el estado del proyecto (si el desarrollo de los requisitos cumple con las expectativas de <<el cliente>>, si la calidad es la esperada o si hay retrasos).
Actividades

En el inicio de cada iteración:

  • <<El cliente>> y <<el proveedor>> mantendrán una reunión para consensuar los objetivos y contenido de la iteración, en función de los criterios de priorización indicados anteriormente, así como para dar detalle a los requisitos seleccionados en la medida en que cada una de las dos partes necesiten. De manera general, cada requisito deberá tener asociado un conjunto de condiciones de aceptación para poder considerar que el requisito ha sido completado. [3]

Al finalizar cada iteración:

  • <<El proveedor>> deberá hacer a <<el cliente>> una demostración de los requisitos completados. En esta demostración participaran los interesados que <<el cliente>> designe; entre ellos se podrá encontrar, por ejemplo, a los promotores del proyecto, al responsable funcional, al responsable técnico, a usuarios finales seleccionados, etc. <<El cliente>> hará una aceptación de estos requisitos realizando las comprobaciones de calidad oportunas.
  • <<El cliente>> podrá repriorizar el conjunto de requisitos del proyecto y consensuará con <<el proveedor>> el contenido de las siguientes iteraciones según lo estipulado en la clausula de «Cambio de requisitos» << dado que además de ser fijos el alcance y el tiempo del proyecto también es fijo el su coste para el cliente (y por tanto lo que va a cobrar el proveedor)>>. En particular, los elementos que se repriorizarán serán: requisitos inicialmente identificados del proyecto, modificaciones a estos requisitos, nuevos requisitos que aparezcan durante el proyecto, problemas de calidad detectados, etc.
Entregables
  • El producto desarrollado hasta ese momento, incluyendo todos los entregables asociados completados (documentación, etc. [1]) e integrados con los entregables de las iteraciones anteriores, de manera que el producto sea susceptible de ser entregado a <<el cliente>> con el mínimo esfuerzo. [4]

Cambios de objetivos/requisitos

Para que esta cláusula sea efectiva, <<el cliente>> se compromete a colaborar con <<el proveedor>> en todas las iteraciones y, especialmente, en las reuniones de recogida de requisitos (como, por ejemplo, las reuniones de planificación de iteración) y en las reuniones de demostración.

  • Los cambios en prioridades de la lista de requisitos no implicarán ningún coste adicional a <<el cliente>> siempre que se mantenga el cómputo total de horas del contrato.
  • La adición de nuevos requisitos (tras las demostraciones) no implicará ningún coste adicional a <<el cliente>>, siempre que se retiren del contrato requisitos no iniciados que computen las mismas horas. 
  • No se consideran cambios las subsanaciones por parte de <<el proveedor>> de los defectos de calidad del producto.

 

Finalización anticipada del contrato

  • Con el objetivo de mantener un Retorno de Inversión (ROI) aceptable en cada iteración, <<el cliente>> podrá finalizar el contrato en cualquier momento siempre que abone a <<el proveedor>> un 20% de las horas de proyecto pendientes de realizar. [5]
  • Los requisitos que previamente fueron acordados por las dos partes para ser entregados con anterioridad al momento de la finalización del contrato y que estén sufriendo un retraso de entrega atribuible a <<el proveedor>> quedan excluídos del cómputo de horas pendiente a realizar y deberán ser entregados por <<el proveedor>> sin incurrir en ningún pago adicional por parte de <<el cliente>>.
  • Sea como fuere, <<el proveedor>> se compromete a entregar un 80% de los requisitos del proyecto en la fecha inicial de entrega, cumpliendo los criterios definidos en las condiciones de aceptación para poder considerar que los requisitos han sido completados, siempre que no se produzca alguna desviación por causas que estén fuera de la responsabilidad de <<el proveedor>>. 

contrato-agil-money-for-nothing

[1] En el caso de proyectos de desarrollo de software: análisis funcional, diseño técnico, código, pruebas (unitarias, de integración, de rendimiento, funcionales, de regresión, etc.).

[2] En el caso de proyectos de desarrollo de software, para ayudar y guiara conseguir este objetivo, en la iteración 0 ser interesante realizar una primera versión de muy alto nivel de los siguientes modelos:
  • Modelo de actores, procesos y flujo de información.
  • Modelo de Casos de Uso (funcionalidades).
  • Modelo de Dominio (entidades de información y sus relaciones).
  • Modelo de interfase de usuario (GUI), línea de diseño gráfico, hojas de estilo, guía de usabilidad y diseño de interacción, etc.
  • Modelo de arquitectura y de componentes (solución tecnológica), identificando componentes de uso común y reutilizables.
  • Modelo de seguridad (autenticación y autorización para acceder a las funcionalidades).
  • Modelo de gestión de cambios de la configuración.
  • Modelo de control de la calidad.
  • Modelo de gestión del cambio (comunicaciones a beneficiarios, formaciones y soporte).
Esto NO implica realizar un análisis funcional y/o un diseño técnico del proyecto en la iteración 0. Si en el proyecto es necesario realizar un análisis funcional o un diseño técnico, también se elaborará de manera incremental, iteración a iteración: «se entenderá un requisito como completado si incluye todos los entregables asociados realizados (documentación, etc. [1]) e integrados con los entregables de las iteraciones anteriores, de manera que el producto sea susceptible de ser entregado a <<el cliente>> con el mínimo esfuerzo.
También puede ser conveniente realizar las siguientes actividades:
  • Identificar el grado de configuración y parametrización del producto para cubrir las necesidades de <<el cliente>>, así como los mecanismos para conseguirlo.
  • Definir los patrones de diseño, estándares de codificación, guías de uso de los componentes de infraestructura tecnológica a utilizar o cualquier herramienta a utilizar en el desarrollo.
  • Para reducir el riesgo tecnológico lo antes posible, realizar una prueba de concepto de arquitectura, componentes tecnológicos más arriesgados, infraestructura, GUI, etc. en la iteración 0 o en la primera iteración de desarrollo.
[3] En el caso de proyectos de desarrollo de software, para ayudar a reducir la incertidumbre de la iteración, minimizar la dependiencia de <<el cliente>> durante ella y garantizar la usabilidad de la solución, puede ser necesario aprobar previamente a cada iteración el prototipo navegable de la interfase de usuario (GUI) que se desarrollará en esa iteración y acompañarlo de una descripción de comportamiento, redactada como pruebas de aceptación asociadas a cada requisito. Es de especial importancia que este prototipo lo validen tanto el responsable funcional del proyecto en representación de los promotores del proyecto como una muestra representativa de los usuarios finales (con los objetivos de obtener su feedback y de garantizar su productividad de trabajo con la herramienta).
[4] En el caso de proyectos de desarrollo de software, <<el proveedor>> deberá entregar el código fuente, scripts de instalación y la batería automatizada de pruebas (unitarias, de integración, de rendimiento, funcionales, de regresión, etc.), de manera que sea sencillo auditarlas y repetirlas, tanto por <<el cliente>> como por el proveedor que se encargará del mantenimiento evolutivo y correctivo del sistema.
[5] En lugar de perder el 100% del coste de las horas pendientes en requisitos que no le aportan suficiente valor, a <<el cliente>> le resulta más conveniente abonar un 20% de las horas a <<el proveedor>> para así ahorrarse un 80%. Cuanto mejor se haga Scrum, más salen ganando ambas partes: el cliente, por no dedicar más dinero del necesario al proyecto, y el proveedor, por recibir un pago final (y aumentar su margen) sin dedicar ningún recurso.
Para más información: