Sprint #2 - Aceptando el riesgo

Os presento la segunda planificación del ScrumBlog. Si no leistéis la primera planificación podéis echarle un ojo ahora (Allí explico un poco los roles de Scrum y las fases de la planificación). Doy eso por sabido y me meto directamente a planificar.

Planificación de la iteración
Voy a intentar que todas las iteraciones duren lo mismo, por lo que esta también durará 15 días. Quedan las fechas del sprint como siguen:
Planificación - Miércoles 27 de Enero
Inicio de Sprint - Jueves 28 de Enero
Fin de Sprint - Jueves 11 de Febrero
Retrospectiva - Viernes 12 de Febrero

Disponibilidad del equipo
Tal y como señale en la retrospectiva, la velocidad del equipo es de 11 puntos de historia cada 15 días. Dado que la disponibilidad del equipo es la misma que en la iteración anterior, fijamos los puntos de historia en 11.

Estimación de las historias
Veamos el estado de la pila de producto:

El equipo ha estimado las historias pero, si os fijáis bien, la historia de FitNesse aparece con un símbolo de exclamación. Esto es debido a que dicha historia tiene un factor de riesgo alto debido al desconocimiento del equipo en la tecnología a utilizar. La idea es hacer un ScreenCast cuando nunca he hecho ninguno. Es muy probable que mi estimación sea mala pero, es la mejor que puedo hacer.
¿Qué hacemos con este tipo de historias? Existen varias alternativas. Las que yo considero más adecuadas son las siguientes:

• Fijar un limite de tiempo a dedicar a dicha tarea (en este caso 4 horas) de forma que, si mientras estamos investigando como realizar dicha historia nos damos cuenta de que la complejidad es mucho mayor que la que estimamos, dejemos dicha historia para la siguiente iteración.
• Dividir la historia en dos. Por un lado tendríamos una historia para la formación del equipo y otra historia para la ejecución.

En este caso, tras hablarlo con el dueño de producto optamos por la primera de las opciones (algo más arriesgada). Si al final se lía la cosa el cliente como el equipo tendrán claro el por qué.

Selección de las historias del sprint
Estas 4 historias suman 12 puntos y solo tenemos 11 disponibles. Volvemos a encontrarnos con que no entran todas en el sprint. Sin embargo, esta vez, después de acaloradas discusiones entre el equipo y el dueño de producto, se decide aumentar el nivel de compromiso del equipo para que entren las cuatro historias en la iteración, por lo que las proximas entradas del blog serán:

1. Principios ágiles #5. Importancia de la motivación de, la confianza hacia y el apoyo a las personas involucradas en el proyecto.
2. How To: Primeros pasos con FitNesse. Mi primer ScreenCast. Espero que no sea el último :D Además, este ScreenCast lo añadiré al resumen de la reunión de Madrid para completarlo un poco más.
3. Principios ágiles #6. Comunicación cara a cara como método más eficiente y efectivo para que fluya la información.
4. How To: Mockeando llamadas asíncronas con easymock. ¿Os habéis planteado como hacer TDD con llamadas asíncronas? Intentaremos explicarlo en esta entrada.

Burndown
Por último, falta el burndown de la iteración. Iré actualizándolo regularmente con los avances :D

1. Reunión Diaria (Scrum diario) del 28 de Enero: Al ser la primera, lo único que se hace es que cada miembro del equipo elija la tarea en la que quiere trabajar. Voy a intentar escribir la entrada sobre el quinto principio ágil. Al menos el primer borrador
2. Reunión Diaria (Scrum Diario) del 29 de Enero
• ¿Qué hiciste ayer? Comence con el quinto principio, pero avancé menos de lo que esperaba. Me quedan un par de horitas todavía
• ¿Qué vas a hacer hoy? Hoy espero terminar la entrada
• ¿Algún impedimento? No
3. Reunión Diaria (Scrum Diario) del 30 de Enero
• ¿Qué hiciste ayer? Nada :( Las cañas de los viernes pudieron al blog
• ¿Qué vas a hacer hoy? Hoy espero terminar la entrada
• ¿Algún impedimento? No
4. Reunión Diaria (Scrum Diario) del 31 de Enero
• ¿Qué hiciste ayer? Pues hice un poquito más de la entrada de los principios. pero aún le falta una horita
• ¿Qué vas a hacer hoy? Nada
• ¿Algún impedimento? No
5. Reunión Diaria (Scrum Diario) del 1 de Febrero
• ¿Qué hiciste ayer? Pues jugar al COD. Menudo vicio.
• ¿Qué vas a hacer hoy? Hoy acabo la entrada sí o sí
• ¿Algún impedimento? No
6. Reunión Diaria (Scrum Diario) del 2 de Febrero
• ¿Qué hiciste ayer? ¡Terminé la entrada!
• ¿Qué vas a hacer hoy? Pues investigar un poco como va lo de los screencasts
• ¿Algún impedimento? No
7. Reunión Diaria (Scrum Diario) del 3 de Febrero
• ¿Qué hiciste ayer? Pues al final no me dio tiempo a hacer nada.
• ¿Qué vas a hacer hoy? Creo que tampoco me va a dar tiempo a hacer nada, pero igual preparo el guión del screencast
• ¿Algún impedimento? No
8. Reunión Diaria (Scrum Diario) del 4 de Febrero
• ¿Qué hiciste ayer? Terminé el guión del screencast.
• ¿Qué vas a hacer hoy? Hoy me voy de concierto, así que nada
• ¿Algún impedimento? No
9. Reunión Diaria (Scrum Diario) del 5 de Febrero
• ¿Qué hiciste ayer? Nada
• ¿Qué vas a hacer hoy? Hoy voy a ver a los Arctic Monkeys, así que nada
• ¿Algún impedimento? No
10. Reunión Diaria (Scrum Diario) del 8 de Febrero
• ¿Qué hiciste ayer (y antes de ayer y antes de antes de ayer)? Pues no pude ponerme con el screencast porque vinieron invitados a casa pero al menos saqué tiempo para avanzar con el sexto principio ágil. Le queda una horia más a esa entrada.
• ¿Qué vas a hacer hoy? Quiero intentar el screencast, a ver si tengo tiempo.
• ¿Algún impedimento? No

Foto de "portada":  Galería de boo_licious en Flickr, bajo licencia Creative Commons.

Retrospectiva #2

Bueno, pues parece que hemos terminado la primera iteración del ScrumBlog :D Vamos a "retrospectivar" un rato sobre dicha iteración.

¿Por donde empezamos?
Vamos a empezar calculando la velocidad del equipo y su eficacia. Para ello vamos a basarnos en el burndown de la iteración. Podemos ver que la velocidad del equipo se corresponde a 11 puntos de historia y su eficacia es de un 100%. Estos datos nos servirán como base para la próxima planificación.

Parece que ha sido una buena iteración ¿no? Veamos que opina el equipo (Como ya hicimos en la retrospectiva anterior, vamos a hacer a basarnos en 3 preguntas para llevar la retro).

¿Qué nos ha gustado de este sprint y queremos seguir haciendo?

• El compromiso. Ha sido "duro", pero ha merecido la pena.
• Por fin hemos metido una historia técnica. No se si os habrá gustado, a mi sí :D. Me parece una idéa muy interesante, la verdad. Además, el tener una historia técnica me ha servido para iniciarme en git.

¿Qué estamos haciendo mal?

• La priorización de las historias. No puede ser que la segunda historia más prioritaria no pueda empezarse hasta un par de días antes del final de la iteración
• Aunque hemos aumentado la tasa de entradas, sigue siendo un poco baja.
• Los Scrum diarios no han sido tan diarios :D Ha sido un poco despendole...
• La plantilla del blog no permite leer bien el código :(

Acciones

• Las historias bloqueantes hay que priorizarlas teniendo en cuenta dicho bloqueo.
• Fijar una hora para realizar el Scrum diario. Si es posible, por la mañana
• Modificar la plantilla del blog para que el código se pueda leer decentemente.

¡Que poquitos problemas! :D Se nota que esta primera iteración ha salido bien. Veremos las siguientes...
Si queréis proponerme algún tema para la próxima iteración dejad un comentario en la entrada antes de la planificación de mañana :D De momento, en lo más alto de la pila están el quinto principio ágil y una introducción a FitNesse.

11º Encuentro Agile-Madrid. Definition of Done (Pruebas de aceptación automatizadas)

Entre todos los asistentes a la reunión hemos creado un resumen en el sitio google del grupo. Leedlo antes de continuar :D

Dado que el resumen ya está hecho, voy a escribir un poco qué supuso para mi la reunión.

Preparativos
En un principio, mi labor para esta reunión era preparar un ejemplo de automatización de pruebas de aceptación en FitNesse y presentarlo (Tengo que decir que, aunque conocía FitNesse, nunca lo había usado y, esta reunión me ha servido para aprender un poco de que va ese rollo :D Me ha gustado bastante y puede que para la próxima iteración del blog escriba un "How To" sobre FitNesse).
Unos días antes de la reunión, José Manuel Beas me dijo que no iba a poder ir y me pidió que me encargarse yo de la charla. Me cedió tanto la presentación como el ejemplo de Concordion que iba a presentar.
No estoy acostumbrado a hablar en público y soy bastante tímido, así que me puse un poco nervioso. Aún así, el tema era muy chulo y me apetecía hablar de él, por lo que acepté :)

El encuentro
Acudimos unas 20 personas, entre las que había bastantes caras nuevas (lo que aumentó el miedo escénico :D). No se lo que piensan los demás, pero para mi la reunión fue bastante entretenida (Me sentí bastante cómodo mientras casi improvisaba la presentación) y la gente debatió bastante. Como ya he dicho, el resumen podéis leerlo en el sitio del grupo, pero os apunto las conclusiones a las que llegamos por si sois un poco vagos :P

• Las pruebas de aceptación deben comprobar las reglas de negocio (Qué y no cómo).
• Las pruebas de aceptación deben producirse mediante la colaboración de cliente y equipo (Negocio y desarrollo juntos).
• Es deseable que las pruebas de aceptación se escriban antes que el desarrollo, ya que ayuda a focalizar dicho desarrollo.
• Utilizar un framework que ayude a automatizar las pruebas de aceptación es deseable.
• Entre Concordion y FitNesse no sabemos con cual quedarnos. Ambos tienen aspectos positivos y negativos. Probadlos y decidid :D

Futuro
El haber dado esta charla me ha enseñado que no es tan duro hablar delante de la gente. Te puede salir mejor o peor, pero lo importante es compartir. La verdad es que me he animado bastante y creo que voy a proponer alguna charla más e, incluso, algún taller (A ver si hablo con Alfredo Casado y organizamos algo de TDD, que ya me lo ha dicho un par de veces. José Manuel Beas quiere montar uno sobre Concordion y creo que estaría muy bien).
Además, después de haber entrado un poco más a fondo en las pruebas de aceptación, queremos empezar a utilizar algún framework para automatizar las pruebas de aceptación en mi trabajo. Yo me decanto por FitNesse, que me parece más sencillo de cara a un usuario no técnico, pero algún que otro compañero prefiere Concordion. ¿Que haremos? De momento creo que vamos a probar FitNesse porque me voy a encargar yo de hacer esas pruebas :D Ya os contaré nuestros avances y nuestros problemas.

Animaos y venir a las reuniones, a los coding-dojos, a los talleres, etc. Son gratis y de verdad que merecen la pena.

How To: Contract Tests (Pruebas de Contrato)

El diseño de un API es un problema bastante complejo. Hay que tener multitud de cosas en mente (modularidad, escalabilidad, extensibilidad, usabilidad, simpleza, etc). Si os interesa el tema os recomiendo este libro de Jaroslav Tulach (uno de los arquitectos de NetBeans). Es un libro difícil, como el problema que aborda, pero muy bueno.
En dicho libro conocí el concepto de Contract Tests(Pruebas de Contrato). Sin embargo, aunque me pareció una buena idea, no le dí mucha importancia en aquel momento (hace un año, aproximadamente). Antes de fin de año, J.B. Rainsberger twitteaba el vídeo de Ben Rady escribiendo Contract Tests en Junit 4 y todo el tema volvió a mi cabeza.

¿Qué son las Pruebas de Contrato?
J.B. Rainsberger lo explica en este artículo (Que escribió en el 2005, menudo crack). Básicamente, las Pruebas de Contrato son una batería de pruebas que especifican el comportamiento de un determinado interfaz (o clase abstracta). Cualquier implementación de dicho interfaz (o cualquier clase derivada de la clase abstracta) debe superar dicha batería de pruebas para ser considerada correcta.

¿Qué problema resuelven las Pruebas de Contrato?
Normalmente, cuando se crea un interfaz (o una clase abstracta) es para que tenga varias implementaciones (o clases derivadas). Sucede lo mismo con un API, puede tener más de una implementación pero un único interfaz.
Si no se define un comportamiento general, es posible que las implementaciones no sean intercambiables entre sí, violando así el principio de sustitucion de Liskov y, lo que es más importante, dejando a los clientes de dicho interfaz con el culo al aire. Dicho comportamiento es lo que se define como contrato. Podemos escribir dicho contrato como un documento más, con los problemas que ello conlleva (Código y documentación desincronizada, interpretaciones subjetivas de lo escrito, etc) o podemos escribir dicho contrato mediante pruebas.

¿Por qué me interesan las Pruebas de Contrato?
Imagino que estaréis pensando:

Vaya chapa nos está metiendo el Peña.

Así que voy a contaros un poco mi motivación. Mi pensamiento tras ver el vídeo de Ben Rady fue:

¡Coño! Que bueno. Si lo hubiera aplicado antes a mi proyecto ahora sería mucho más feliz.

El proyecto actual de mi equipo consiste en diseñar (e implementar, testear, etc. Nada de waterfallismo :D )un API y crear varias implementaciones de dicho API (y diseñarlas, testearlas, etc. :D ).
Cuando comenzó el proyecto no le dimos importancia a esto de las Pruebas de Contrato (Sobre todo por desconocimiento). Tampoco pasaba nada, solo existía una implementación para la cual teníamos una batería de pruebas.
Más adelante añadimos una segunda implementación y, en lugar de convertir los test de la anterior implementación en Pruebas de Contrato, hicimos un corta-pega del demonio (Me da vergüenza escribir esto, pero de los errores se aprende).
No os recomiendo este enfoque :D Las pruebas huelen a DRY que tiran de espaldas.
Además, aceptamos pequeños cambios en el comportamiento de las implementaciones ya que, al definir el contrato en un wiki en lugar de hacerlo con pruebas, malinterpretamos ciertos detalles (algunas veces a propósito :S ).
Le he planteado al equipo que, las nuevas pruebas funcionales que creemos sean Pruebas de Contrato, a ver si conseguimos eliminar duplicaciones.
NOTA: Tengo que aclarar que estoy muy contento con la marcha del proyecto :D Lo que pasa es que mi nivel de exigencia aumenta cada mes. De hecho, nuestro equipo es famoso por lo mal que habla de su propio código, estando dicho código bastante por encima de la media. Somos un equipo muy autoexigente y muy autocrítico.

Un caso práctico: El interfaz Collection con JUnit 4
Después de todo este rollo, vamos a la chicha.

Vamos a hacer unas Pruebas de Contrato para el interfaz Collection (No vamos a hacer el contrato entero porque nos puede dar un chungo).
Normalmente, las Pruebas de Contrato se añaden al proyecto que contiene los intefaces a definir. Las clases que ejecutan las pruebas para cada implementación se añaden al proyecto que contiene dicha implementacion. Como yo no tengo acceso a dichos proyectos, me he creado uno propio. He metido todas las clases en ese proyecto, pero he hecho una separación en paquetes para que entendáis un poco la distribución de las clases. Podéis verlo aquí (Es de NetBeans. A mi me gusta mucho, pero Xavi Gost me diría que madurara... Aún así, es tan sencillito que no creo que de problemas :D ).

Lo primero es crear una clase abstractra que contenga todos los test de contrato y un método abstracto que devuelva un objeto Collection. Yo he hecho la siguiente:



Como podéis ver, el método nuevaColeccion se llama en el setUp para no tener que escribirlo en cada prueba. Además, dicho setUp es final para que no pueda ser sobreescrito por las clases hijas.

Si ahora lanzamos las pruebas obtenemos el siguiente resultado:

Si os fijáis, la clase abstracta que hemos creado no termina en Test, así que JUnit 4 no la tiene en cuenta a la hora de ejecutar las pruebas.

Ahora vamos a probar las implementaciones. Empezamos por ArrayList, para lo que añadimos la siguiente clase:



Lo mismo para HashSet:



Si ahora pasamos las pruebas obtenemos:

¡Bien! Pasan todas las pruebas :D Eso quiere decir que ambas implementaciones cumplen con el contrato y todos somos un poco más felices.
Hay que destacar que las pruebas se están contabilizando en cada clase de prueba de cada implementación (Todas las Pruebas de Contrato se ejecutan en ArrayListTest y en HashSetTest). A la hora de contabilizar pruebas la clase base no existe :D

Vamos a ponérselo un poco más difícil a las implementaciones. Añadimos la siguiente prueba a la clase que define el contrato:



Si ahora pasamos las pruebas de las implementaciones obtenemos:

¿Rojo? mmmmm Huele a violación de los principios S.O.L.I.D.
La implementación HashSet no supera la nueva prueba que hemos añadido. Hemos definido un contrato demasiado estricto y algunas implementaciones no lo soportan.
En este caso, no podemos suponer lo que hará una colección cuando se le añada el mismo objeto varias veces. Depende de la clase derivada. Claramente, las implementaciones de Collection violan el principio de Liskov :D

Podríamos seguir añadiendo pruebas y tal, pero imagino que ya ha quedado más o menos claro ¿No? Ya veis que no sería muy complicado organizar las pruebas que ya tenemos para obtener unas cuantas Pruebas por Contrato. Espero poder hacerlo en mi equipo :D (Me temo que esto es deuda técnica).

Conclusiones

• Las Pruebas de Contrato son una especificación del API.
• Las Pruebas de Contrato se pueden usar como documentación del interfaz. La documentación escrita en prosa "a la antigua usanza" es mucho más fácil de malinterpretar.
• El contrato puede ser todo lo estricto que queramos. Hay que aplicar el sentido común para saber cuando parar.
• Mediante Pruebas de Contrato eliminamos duplicidad de código de test. Las pruebas hay que seguir escribiéndolas tengamos o no Pruebas de Contrato y, escribir las mismas (o parecidas) en cada una de las implementaciones es una perdida de tiempo y un infierno a la hora de mantenerlas (lo digo por experiencia).
• Definir unas Pruebas por Contrato puede ayudarnos a descubrir problemas de diseño en el API. Una violación del principio de Liskov es un problema en el API

Esto es todo amigos. Espero que os haya gustado mi primera entrada técnica :D

Foto de "portada": Galería de Mark, bajo licencia Creative Commons

Principios Ágiles #4

Siguiendo con la temática de los principios ágiles, hoy voy a hablar del cuarto de ellos:

Business people and developers must work together daily throughout the project.

La gente de negocio y los desarrolladores deben trabajar de forma conjunta diariamente a lo largo del proyecto.

¿Gente de Negocio y gente de desarrollo?

Cuando se comienza un nuevo proyecto es lógico que el equipo de desarrollo (encargado de implementar una solución) no sea experto en el negocio del cliente. Por otro lado, un experto de negocio (encargado de explicar las reglas de negocio) casi nunca se interesará por el aspecto técnico (desde luego, ninguno que yo conozca). Ambos mundos están bastante separados, al menos sobre el papel, lo que provoca que sean incapaces de entenderse. No poseen un lenguaje común.

¿Por qué trabajar juntos de forma conjunta?
Obligar a que ambos mundos trabajen juntos de forma continua provoca que la separación entre ambos se reduzca. Obviamente, el objetivo no es que un desarrollador se convierta en un experto de negocio ni viceversa. Siempre existirá una cierta separación. El objetivo es construir un lenguaje común mediante el cual ambos grupos consigan entenderse y resolver sus dudas. Actualmente en el mundo ágil, dicho lenguaje común se plasma sobre todo en las pruebas de aceptación, definidas por la gente de negocio con ayuda del equipo técnico (Si queréis saber más sobre pruebas de aceptación pasaos por la próxima reunión de Agile-Spain Madrid).
Cuando ambos grupos empiezan a colaborar se empieza a reducir la brecha que los separa. Comienza a aparecer un sentimiento de equipo y una visión global del producto.

¿Por qué diariamente?
No vale con reuniones esporádicas, debe ser un esfuerzo continuo. No vale que los grupos se reunan una vez al mes para tratar ciertos temas y que después cada uno se marche a su cubículo. Si un desarrollador se encuentra con que tiene que tomar una decisión de negocio debe acudir a los expertos de negocio para que se la resuelvan. Si un experto de negocio quiere conocer que tal va el desarrollo de una funcionalidad X debe acudir al desarrollador para que le informe. Obviamente, esta colaboración no se puede llevar a cabo sin confianza y transparencia. No me sirve de nada que los desarrolladores estén siempre disponibles para el experto de negocio pero le mientan sobre el estado del proyecto.
Este trabajo diario no es sencillo de llevar a cabo. Muchas veces los desarrolladores no queremos levantar la cabeza del ordenador. Otras muchas los expertos de negocio no tienen tiempo (ni ganas) de reunirse con los "frikis". Por eso, es necesario un compromiso por ambas partes. Si alguno de los dos no se compromete se deja de ser ágil.

Conclusiones
El cuarto principo ágil:

• Busca que la gente de  negocio y la gente técnica hablen un lenguaje común que favorezca el entendimiento.
• Refuerza el sentimiento de equipo aumentando la confianza entre sus componentes.
• Implica compromiso.
• Obliga a la transparencia.

Imagen de "portada": Galería de thinkpublic, bajo licencia Creative Commons.

Sprint #1 - Planificando enero

Como ya escribí en la retrospectiva, voy a intentar aplicar una especie de Scrum al blog. Tanto José Manuel Beas como Juan Quijano apuntaron en los comentarios de la anterior entrada los problemas que veían al aplicar Scrum para un blog. Es cierto que Scrum está orientado a productos desarrollados por equipos de varias personas y que no cuadra muy bien con un blog personal. Aún así, se que me va a servir para mejorar el ritmo de entradas, que es lo que busco. Además, los post de planificación y retrospectivas pueden ayudar a entender la parte de gestión de Scrum (que no es que sea muy difícil) A ver que tal sale, probablemente sea un "fail", pero voy a probar.

Roles de Scrum
En Scrum hay basicamente tres roles:

1. Dueño de Producto - Gestiona la pila de producto
2. Scrum master - Elimina los obstáculos que impiden que el equipo cumpla sus compromisos.
3. Equipo - Desarrolla el producto.

Normalmente cada persona involucrada en el proyecto tiene asignado un único rol y existen varias restricciones.

• Solo hay un dueño de producto (Se puede argumentar que puede ser un comité de expertos de negocio los que implementen dicho rol pero vamos, lo más adecuado es que sea una única persona de ese comité el dueño de producto. Personalizar ese rol en una persona ayuda al equipo, que tiene más claro a quien dirigirse).
• Solo hay un Scrum Master.
• El equipo está formado por una o más personas (En realidad, el equipo siempre es de más de una persona. He puesto una porque en este caso el equipo soy yo solo).

Yo haré de Dueño de producto, de Scrum master y de equipo :) Me voy a volver loco...

La Pila de Producto
Tenemos nuestro dueño de producto y nuestro equipo. Ahora necesitamos una pila de producto. Para no aburriros con muchos datos, solo voy a contaros los temas que he metido en la pila (si continúo con el blog-scrum la presentaré en futuros posts) mientras llevaba puesto mi gorro de dueño de producto.
Voy a seguir con la serie de principios ágiles y con el resumen del libro "Agile Testing". También he añadido unos cuantos temas técnicos (Orientados sobre todo a testing, aunque hay algo de TDD). Además, he incluido una historia para el resumen de la reunión del día 19 de Agile-Spain Madrid.

Planificación de la iteración
Creada la pila ¡podemos empezar a planificar la primera iteración!
Sigo con el gorro de dueño de producto. Lo primero que tengo que decidir es la duración de este sprint. Como quiero incluir la historia con el resumen de la reunión he pensado en una iteración de dos semanas. Quedan las fechas del sprint como siguen:

• Planificación - Miércoles 6 de Enero
• Inicio de Sprint - Jueves 7 de Enero
• Fin de Sprint - Jueves 21 de Enero
• Retrospectiva - Viernes 22 de Enero (Creo que esta se puede alargar al fin de semana del 22...)

Ahora toca ver que entra en la iteración. Para ello primero debo conocer la disponibilidad del equipo y las estimaciones de las historias. Me pongo mi gorro de Scrum master y os cuento que, para simplificar un poco, voy a igualar los puntos de historia a horas ideales (Se que no está muy bien, pero voy a empezar así).

Disponibilidad del equipo
Me pongo ahora el gorro de equipo. Como es el primer sprint aún no conozco mi velocidad así que voy a ponerme una a ojo. Una persona durante quince días dedicándole unas seis horas a la semana me dice que, más o menos, mi velocidad es de 12 puntos de historia.
Estimación de las historias
Todavía con mi gorro de equipo estimo las primeras historias de la pila:

Selección de las historias del sprint
Una vez estimadas las historias vuelvo a ponerme el gorro de dueño de producto para decidir que historias de las estimadas entran en el sprint.
Estas 4 historias suman 15 puntos y solo tengo 12 disponibles ¿Qué hago? Tengo varias opciones:

• Puedo intentar convencer al equipo para que aumente su nivel de compromiso y acepte hacer los 15 puntos. He estado discutiendo conmigo mismo (cambiando de gorro mientras lo hacía, menudo cuadro) y he decidido que el equipo no puede aumentar su compromiso (Hay que hacer más cosas en la vida...)
• Puedo reordenar las historias de forma que las tres historias con estimación 4 entren en la iteración. El problema de esta opción es que uno de los requisitos era tener al menos una historia técnica por sprint.
• Puedo regalarle un punto al equipo y que hagan las 3 historias más prioritarias. Me quedo con esta opción.

Decidido entonces. Las proximas entradas del blog serán:

1. Principios ágiles #4. Continuamos con la serie sobre principios ágiles. Esta vez toca "Negocio y tecnología deben trabajar juntos" (traducción libre :) ).
2. Resumen reunión 19 Enero Agile-Spain. Podéis ver toda la información sobre la reunión en esta página. Animaos y venid.
3. Contract tests. Una idea muy buena que ya leí en "Practical API design: Confessions of a Java framework architect" y que he recordado gracias a este post de J.B. Rainsberger :) Qué son y como se hacen con JUnit.

Burndown
Por último, falta el burndown de la iteración. Iré actualizándolo regularmente con los avances :D

1. Reunión Diaria (Scrum diario) del 7 de Enero: Al ser la primera, lo único que se hace es que cada miembro del equipo elija la tarea en la que quiere trabajar. Yo elijo la tarea "No hacer nada porque no tengo tiempo". 
2. Reunión Diaria (Scrum diario) del 8 de Enero
• ¿Qué hiciste ayer? Nada. Como no hice nada no reestimo la duración de las tareas quedando un burndown plano. Como siga así veras que risa.
• ¿Qué vas a hacer hoy? Hoy voy a intentar empezar el post sobre el cuarto principio ágil.
• ¿Algún impedimento? Nop.
3. Reunión Diaria (Scrum diario) del 9 de Enero
• ¿Qué hiciste ayer? Empecé la historia de los principios ágiles. Reestimo que me quedan unas 3 horitas. Esta reestimación hace que el burndown de reestimación baje un poquito, hacercandose al ideal. Sin embargo el de terminado sigue plano ya que aún no he acabado ninguna historia.
• ¿Qué vas a hacer hoy? Voy a continuar con dicho artículo, aunque no se si voy a poder hacer mucho.
• ¿Algún impedimento? Ninguno, de momento.
4. Reunión Diaria (Scrum diario) del 10 de Enero
• ¿Qué hiciste ayer? Pues al final no hice nada. Me pudieron las ganas de darle caña al modern warfare 2. ¡Que vicio!
• ¿Qué vas a hacer hoy? Hoy voy a avanzar sí o sí con la historia de los principios ágiles.
• ¿Algún impedimento? No.
5. Reunión Diaria (Scrum Diario) del 11 de Enero
• ¿Qué hiciste ayer?
  He creado el esqueleto del post. Yo creo que con un par de horitas más lo acabo
• ¿Qué vas a hacer hoy? Nada, me parece que hoy toca ver una peli.
• ¿Algún impedimento? No
6. Reunión Diaria (Scrum Diario) del 12 de Enero
• ¿Qué hiciste ayer?
  Nada :(
• ¿Qué vas a hacer hoy? Hoy espero terminar una primera versión de la entrada
• ¿Algún impedimento? No
7. Reunión Diaria (Scrum Diario) del 13 de Enero
• ¿Qué hiciste ayer? He seguido avanzando en la entrada de los principios y casi la tengo lista :)
• ¿Qué vas a hacer hoy? Hoy espero terminar la entrada
• ¿Algún impedimento? No
8. Reunión Diaria (Scrum Diario) del 14 de Enero
• ¿Qué hiciste ayer? Terminé la historia de los principios ágiles :D y empecé con la de la reunión, pero no la puedo hacer porque ¡todavía no hemos hecho la reunión!
• ¿Qué vas a hacer hoy? Hoy puede que empiece con la de "Contract tests"
• ¿Algún impedimento? No puedo hacer la historia más prioritaria...
9. Reunión Diaria (Scrum Diario) del 15 de Enero
• ¿Qué hiciste ayer? He creado el borrador de Contract Test, pero no he podido escribir nada :D Por lo menos me he registrado en github, donde dejaré el código de los ejemplos
• ¿Qué vas a hacer hoy? Hoy voy a crear los ejemplos para "Contract tests" y, si me da tiempo, escribiré algo
• ¿Algún impedimento? No
10. Reunión Diaria (Scrum Diario) del 16 de Enero
• ¿Qué hiciste ayer? Además de ver perder al Madrid he estado trabajando en la entrada de Contract Test. Con un poco más de esfuerzo la tengo lista para el lunes :D
• ¿Qué vas a hacer hoy? Seguir con la entrada. Tengo que hacer los ejemplos y poner el código en el post
• ¿Algún impedimento? No
11. Reunión Diaria (Scrum Diario) del 17 de Enero
• ¿Qué hiciste ayer? ¡Acabé la historia de las Pruebas de Contrato!
• ¿Qué vas a hacer hoy? Hasta despues de la reunión no creo que haga nada :D
• ¿Algún impedimento? No
12. Reunión Diaria (Scrum Diario) del 18 de Enero
• ¿Qué hiciste ayer? Nada. Bueno, preparar la reunión de Agile-Madrid
• ¿Qué vas a hacer hoy? Nada
• ¿Algún impedimento? No
13. Reunión Diaria (Scrum Diario) del 19 de Enero
• ¿Qué hiciste ayer? Nada. Bueno, preparar la reunión de Agile-Madrid
• ¿Qué vas a hacer hoy? Nada
• ¿Algún impedimento? No
14. Reunión Diaria (Scrum Diario) del 20 de Enero
• ¿Qué hiciste ayer? Hice la presentación sobre Definition of Done al grupo de Madrid. También he escrito el resumen en el sitio de Agile-Madrid
• ¿Qué vas a hacer hoy? Hoy terminaré la entrada sobre la reunión en el blog :D
• ¿Algún impedimento? No
15. Reunión Diaria (Scrum Diario) del 21 de Enero
• ¿Qué hiciste ayer? Termina la historia de la reunión de agile Madrid :D
• ¿Algún impedimento? No
Hoy no preguntamos que vamos a hacer porque esta reunión simplemente identifica lo que nos ha dado tiempo a terminar el último día de sprint :D. ¡Nos vemos en la retro!

Foto de "portada":  Galería de Wyscan en Flickr, bajo licencia Creative Commons.

Retrospectiva #1

Desde que entré en esto del agilismo he aprendido muchísimas cosas. Una de las más importantes es kaizen, más conocido por mejora continua. En este caso, quiero mejorar mi forma de llevar el blog.
Una de las formas de mejorar es reflexionar sobre lo que has hecho. Para eso (y muchas más cosas) sirven las retrospectivas. Hay infinidad de formas de realizar una retrospectiva. Actualmente en los equipos en los que estoy lo hacemos como sigue:

1. ¿Qué estamos haciendo bien y queremos seguir haciendo? Empezar por lo que se hace bien ayuda a crear un buen ambiente en la reunión y sirve para celebrar los pequeños éxitos (a nadie le amarga un dulce)
2. ¿Qué estamos haciendo mal? Es necesario identificar en qué nos estamos equivocando para intentar evitarlo en un futuro.
3. Acciones para mejorar lo que hacemos mal. Si queremos mejorar debemos actuar. No vale con identificar los errores, hay que solucionarlos.

Siguiendo estos pasos voy a hacer una retrospectiva de lo que llevo de blog (un par de meses, creo). Animaos y contribuid a la retro, los comentarios están abiertos :)

¿Qué estamos haciendo bien y queremos seguir haciendo?

• Sin duda, lo mejor ha sido empezar el blog :D Pensaba que no iba a darle continuidad y, aunque debería escribir más, no está del todo mal. Ocho publicaciones en dos meses :)
  
• Otro puntazo fue que Lisa Crispin leyera el post sobre su libro y lo publicitara en twitter :) Que buena gente. Realmente, le pedí permiso y, tras dármelo, me pidió el enlace al post, pero aún así :D
• Publicitar las entradas en twitter me parece dabuti. Muchos de vosotros retwitteais y ayudáis a difundirlo. Gracias a todos ;)

¿Qué estamos haciendo mal?

• La periodicidad de las entradas. Hago una a la semana aproximadamente, pero es de milagro. De hecho, no me había dado cuenta hasta ahora... Menuda potra.
• Ningún contenido técnico de momento. Soy el programador féliz y todavía no he enseñado ni una linea de código... Eso no está bien.
• No aplico el agilismo a la hora de crear entradas. Voy a lo cowboy.
• La interacción con los lectores (clientes) es casi nula. ¡No se qué os gusta y qué no! :P
  

Acciones

• Aplicar Scrum con el blog. Ya tengo cliente (vosotros). Voy a tener una pila de producto, voy a hacer iteraciones y voy a hacer retrospectivas. Lo de hacer demo no creo :) Aquí tengo algunas dudas... 

• ¿Cuanto debe durar la iteración? Voy a empezar probando con iteraciones de un mes, a ver que tal.
  
• ¿Publico el plan de cada iteración? Voy a crear un post con el resultado del plan para cada iteración.
• ¿Hago reuniones diarias? En el post con el plan iré actualizando un burndown. A ver que tal sale :)
  

• En esa pila priorizaré algo de contenido técnico. Al menos una entrada técnica por iteración (menudo lío).
• Dado que voy a aplicar Scrum, necesito un dueño de producto. De momento, el dueño de producto seré yo, pero actuaré como proxy de mis verdaderos clientes, vosotros. Por eso, si tenéis en mente algún tema del que queráis que escriba no dudéis en escribir en los comentarios.

Pues nada, me estoy metiendo en un lío pero merece la pena.
La primera planificación la haré a lo largo de esta semana (Probablemente comience la iteración el miércoles 6 de Enero). Animaos y proponed historias para la pila de producto :D