3 modelos de contratación ágil

La contratación de proyectos tiene dos extremos:

1. El proveedor asume (casi) todo el riesgo, aceptando un alcance "cerrado" por un precio pactado y que frecuentemente es causa de problemas e insatisfacción tanto para cliente como para proveedor.
2. El cliente asume todo el riesgo, aceptando un proyecto "abierto", sin precio ni alcance pactados (time & materials). Este sería el modelo ideal para los proyectos ágiles, pero plantea lógicos recelos en el cliente.

Bien, parece pues que una opción intermedia sería deseable, que permita acotar el riesgo que corren ambas partes y a la vez facilitar que los clientes puedan confiar en los proyectos basados en Scrum y los beneficios que esto aporta.

El artículo 3 modelos de contratación ágil  propone otras tantas fórmulas que permiten realizar un contrato con un nivel razonable de seguridad jurídica para ambas partes a la vez que permiten compartir el riesgo. Como resumen, estas son:

1. Cambios gratis (Jeff Shuterland). Los cambios son gratis mientras se compense el volumen que éste añadide con otro eliminado equivalente.
2. Dinero para nada (Jeff Shuterland). El cliente puede cancelar anticipadamente el proyecto y pagará como compensación el 20% del valor restante.
3. Variaciones y cambios (Mitch Lacey). El proyecto se parte en dos subproyectos, uno pequeño que sirve para construir el backlog y estimar el proyecto de construcción.

Esto es sólo una simplificación, os recomiendo que leáis el artículo (en catalán o el original en inglés).

Àlex Ballarin

www.cynertiaconsulting.com/scrum

Técnica ágil: CodingDojo

Los CodingDojo son una técnica ágil destinada a aprender e intercambiar conocimientos entre programadores.

Sus características son: 1) Entorno no competitivo sino colaborativo y para pasarlo bien, 2) todos los niveles de participantes son bienvenidos y 3) se aceptan nuevas ideas, aunque salgan mal!

Tienen requisitos muy asequibles, básicamente una sala para los asistentes con almenos un portátil y un proyector.

El proceso (variante ParisDojo) es el siguiente:

• 2 minutos para decidir cuando se hará la siguiente sesión
• 25-30 minutos para analizar en una retrospectiva la última sesión: que funcionó y que fue frustrante
• 10 minutos para decidir que hacer en la sesión actual (el protocolo "siguiente - última - actual").
• 40 minutos o así para programar! (según las variantes PreparedKata -dirigida- o RandorKata -todos lideran-)
• 5 o 10 minutos de pausa para comentar como va la sesión
• 40 minutos para la segunda ronda de programación!

Podéis encontrar más información en la fuente original (codingdojo.org) y en una traducción mía en scrum.cat/2013/04/17/el-codingdojo/.

La guía de Scrum en 1 página

He creado una guía muy resumida de Scrum, que pueda utilizarse para recordar los aspectos más importantes de Scrum al principi de su uso.

Como es una "chuleta", no esperéis un alto nivel de exactitud. Está lo más importante, pero sirve para iniciarse en Scrum. ¡ Espero que os sea útil !

scribd.com/doc/134880180/SCRUM-La-guia-de-1-pagina

La definición de hecho (2): ¿Evitemos el culto?

Discutiendo con compañeros de Agile-Spain.org sobre la Definición de hecho en Scrum (DoD para los amigos) surgieron puntos de duda y debate, como p.e.:

1. ¿Hasta que punto debe ser detallada la DoD?
2. ¿Se puede consensuar una DoD común o compatible entre varios equipos?
3. ¿Existe una variante técnica del Scrum of Scrums donde los "líderes técnicos" de los equipos puedan trabajar en consensuar DoD o intercambiar elementos de esta? ¿Se llamaría Retrospectiva de retrospectivas?
4. ¿Se puede convertir este ejercicio de consensuar DoD en una "maligna" Oficina de arquitectura, también conocida como "Torre de cristal"?

Durante esta discusión, el compañero Harald Messemer nos ha enviado un enlace muy interesante al post del The Cult of Done Manifesto. A pesar que me defino agilista pero fugitivo de las ortodoxias (aunque sean ágiles y guays) lo recomiendo. Contiene muchas verdades. :-)

SCRUM: La definición de hecho

Una visión superficial de Scrum puede dar a pensar que es una metodología sencilla y desestructurada, prácticamente lo mismo que mantener una lista de tareas en una pizarra. Es cierto que Scrum es un marco de trabajo sencillo, con 4 eventos, 3 roles y 2 artefactos estándar, pero a pesar de eso los proyectos suelen salir con un alto grado de calidad y uniformidad, tanto a nivel técnicos como de la documentación generada. ¿No parece contradictorio? Un aspecto importante a tener en cuenta es La Definición de hecho (Definition of Done).

¿Qué es la Definición de hecho?

La Definición de hecho es un acuerdo del equipo que contiene todas condiciones que deben cumplir los ítems del Product Backlog que se aceptan en el Sprint para considerarlos completados. Incluye los aspectos técnicos, de documentación, de pruebas y otros, de manera común para todo el equipo.

Cada equipo crea y mantiene su propia Definición de hecho, que suele evolucionar y refinarse conforme el equipo integra, perfecciona y automatiza sus prácticas de desarrollo. El momento habitual para revisar el cumplimiento de la Definición de hecho y refinar ésta, es la reunión de retrospectiva. Scrum no tiene auditorías, es el equipo quien autogestiona su calidad.

¿Cuál es el valor de la Definición de hecho?

El verdadero valor de la Definición de hecho es garantizar que el trabajo se realiza con un nivel de calidad uniforme, independientemente del miembro del equipo que participe. Es el equivalente al aseguramiento de la calidad en la gestión de proyectos tradicional.

La Definición de hecho aumentar su exigencia en todo momento según las posibilidades y capacidades del equipo. No tiene sentido marcar definiciones ambiciosas que no se pueden cumplir. Lo más importante es la uniformidad y la regularidad.

¿Cuál puede ser un ejemplo de Definición de hecho?

Un ejemplo sencillo e inventado de Definición de hecho es:

1. Cada historia de usuario hecha debe cumplir lo siguiente,
2. Diseño de pantallas (wireframe) actualizado en la wiki
3. Test unitario Junit integrado en montaje (Jenkins) y superado
4. Peer-review de las pruebas funcionales superado
5. Código fuente documentado
6. Wiki de diseño actualizada
7. Diseño explicado en la reunión técnica semanal

Como se puede comprobar, la sencillez de Scrum no tiene relación con la cantidad ni calidad de buenas prácticas de desarrollo que un equipo pueda realizar.

Curso Scrum Master en Barcelona: marzo y abril de 2013

Cynertia organiza periódicamente cursos de scrum master en Barcelona, en 2013 se quieren realizar cursos cada dos meses. En marzo se realizará los días 18, 20, 25 y 27 de 18h a 21h.

Se puede consultar más información sobre Scrum en www.scrum.cat.

Mobile World Congress 2013 Barcelona - Apps y tecnologías emergentes

El Mobile World Congress 2013 comenzó este lunes y, entre sus 70.000 visitantes estimados, hay un fantástico intercambio de ideas, oportunidades y colaboraciones. Esta es la parte más interesante del MWC, más allá de los nuevos terminales y las cifras de ingresos para la ciudad.

En nuestra web hemos recogido una lista de las innovaciones, tecnologías y apps emergentes más interesantes que hemos visto allí.