miércoles, 17 de abril de 2013

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/.

martes, 9 de abril de 2013

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 !


domingo, 7 de abril de 2013

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. :-)


The cult of Done Manifesto

miércoles, 3 de abril de 2013

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.