Constatando, como solemos comentar, que la teoría ágil se debe adaptar a cada caso en particular, muchas veces relajando la agilidad, obteniendo la verdadera riqueza y productividad de las múltiples soluciones que ofrece la ingeniería del software.

Lo que me recuerda la keynote que JB Rainsberger dió este año en la Conferencia Agile-Spain 2011.

Rainsberger explica en la keynote cómo, en estos 10 años de Agile, muchos nos frustramos porque no nos funciona nuestra implementación de Agile y por ello comenzamos rápidamente a “innovar” y crear cosas como “post-Agile” pero sin experiencia real en practicar con éxito los fundamentos. Como colofón a su charla, Rainsberger nos aconseja leer sobre eXtreme Programming (XP) y practicar mucho hasta interiorizar los fundamentos. Sólo entonces estaremos en condiciones de adaptar con éxito los procesos a “el mundo real”. Afirmar esto en “el mundo real” parece muy radical, utópico y no sé qué otras palabras más pronunciadas con un tono poco amable, pero lo cierto es que ya era algo que hace un par de años Xavi Gost me avisaba cuando le comentaba mi intención de explorar el Agile coaching y ahora refrendado por la experiencia. Cada vez que me acerco a “el mundo real” y tratamos de hacer Agile (llámese Scrum, XP o lo que sea), el mayor obstáculo es el rechazo de las organizaciones (y las personas que las forman) a cambiar sus procesos. Esos procesos, que presuntamente funcionan, no se pueden cambiar por otros, que siendo “lo que se debería hacer” según ellos mismos, porque los nuevos son muy costosos en el plano de las responsabilidades personales, nos sacan a todos de nuestra zona de confort y nos ponen en la tesitura de atrevernos a equivocarnos (y luego reconocerlo). Y por ello comienzan a retorcer los principios ágiles (los de la parte de atrás del Manifiesto) para hacer el cambio posible y no sé cuantas cosas más, en vez de echar mano de los valores de XP, en particular del coraje y atreverse a realmente intentarlo.

Lecturas recomendadas

Además del seminal de Beck, XP Explained, yo recomendaría también la lectura del de Jeffries, XP Installed, también citado por Rainsberger en esa keynote.

Me gustaría hacer hincapié en el hecho de que el objetivo final de la incepción es llegar a un punto de acuerdo sobre las expectativas del producto que hay que construir. El producto puede ser desde software hasta una silla de madera, eso es lo de menos, lo realmente importante es que todos los que están en la reunión son los que van a construir esa silla de madera, además de los que se van a sentar en ella, los que la van a vender, los que la van a comprar y cualquier otro intermediario. (En un escenario ideal, claro).

Esta semana he hecho una para arrancar un proyecto para el que ya se había hecho una consultoría previa y en la cuál no estaba el cliente ni el usuario final. Eso nos obligó a imaginar mucho sobre los personajes relacionados con el producto. Pero también me obligó a trabajar mucho, como facilitador de la incepción, en tratar de evitar que esa consultoría nos influyera demasiado en la averiguación conjunta de cuál debe ser el plan iterativo e incremental que el equipo debe seguir.

En la otra incepción, el escenario era diferente, aunque quizás no tanto. Se trataba de un producto cuya construcción se ha atascado y no son capaces de poner en producción. Como detectamos que había una discrepancia fuerte entre lo que se entendía que era el producto, planteé esta incepción. Pero durante la sesión fueron saliendo que las discrepancias son muy de fondo. Trabajamos mucho, mucho, mucho en qué no hace el producto y nos centramos sólo en un personaje para tratar de construir el plan para el MVP (Minimum Viable Product) y permitir que construyan sobre él. Wow! Eso costó. Creo, sin embargo, que mereció la pena, aunque sólo el tiempo lo dirá.

Como resumen:

La incepción es una poderosa herramienta si se usa con sabiduría.

Perdón por la pedantería, pero en la práctica he comprobado que no es una receta “for dummies” porque requiere de mucha mano derecha para avanzar y mucha mano izquierda para ayudar a que salgan las discrepancias que permiten avanzar con seguridad. Es una herramienta que puede crear la falsa sensación de tener un buen plan pero, si no se ha sido honesto, puede haber dejado riesgos latentes; o si no se ha contado con todas las personas necesarias (porque es una reunión muy cara) haber construido una imagen falsa del producto.

Esto me recuerda eso de:

Individuos e interacciones sobre procesos y herramientas

P.S.
Si hubiera querido ser psicólogo habría estudiado psicología.

La semana pasada estuve en Altea (Alicante) porque DreamStarCash me pidió que les diera un taller de TDD con PHP. Lo cierto es que yo no he programado nada serio en PHP y me parecía estar fuera de mi zona de confort, aunque estoy tan bien rodeado que así no es posible acomodarse. ¿Verdad Luis?

Para poneros un poco en contexto, DreamStarCash es una muy exitosa compañía que desarrolla software de gestión de contenidos para adultos. Traducido al castellano (y simplificando): se dedican al porno. Pero ojo, no os quedéis en eso simplemente porque os estaréis perdiendo un mundo muy interesante desde el punto de vista del negocio del software. Tienen millones de visitas diarias, que además de mucho dinero (que tienen que repartir con los proveedores de contenidos, los estudios) significa que tienen problemas de escalabilidad, seguridad, trazabilidad legal de los contenidos, calidad de servicio… Es un negocio con mucha competencia y no toda cumpliendo con la legalidad. Rodney, su director de operaciones (COO) y Steve (CEO y fundador) son tipos muy inteligentes y quieren construir una organización capaz de aprovechar las oportunidades de negocio y adaptarse más rápidamente a todos los cambios que se producen en el sector (nuevas leyes, nuevas tecnologías, nuevos competidores…). Por eso se pusieron en contacto con Xavi Gost (beCodeMyFriend) y, a través de él, conmigo. Entre otras cosas, querían consejo para hacer posible este cambio en la organización. Están siempre contratando porque no cubren puestos sino que buscan talento (si estás interesado, habla directamente con Rodney), apuestan por el agilismo, la mejora continua y hasta han salido en el blog de 37signals. Por cierto, si vas a estar por la PHPConference en Barcelona aprovecha y salúdalos.

Bueno, el caso es que al llegar a DreamStarCash (tras un más que agradable chapuzón en la playa) me reuní con Steve (CEO y fundador), Rodney (COO) y Damian (CTO) para explicarles cómo iba a ser el taller y charlar un rato sobre cómo trabajaban ellos normalmente. Fue una conversación muy honesta y eso siempre es de agradecer. Me gusta muchísimo el ambiente de startup (aunque ya no se puede decir que DreamStarCash lo sean) porque tienen esa esencia de “garaje”, de reducción de jerarquías, de buen rollo… vamos, de todo lo contrario al ambiente “enterprise”. En estas empresas puedes meter el cuchillo hasta el corazón porque sabes que tienes muchas probabilidades de ayudar realmente, en cambio, en las grandes corporaciones, la energía se disuelve entre las “politics” y los miedos al cambio.

De resultas de esta charla nos dimos cuenta de que lo que realmente necesitaban (y con urgencia) no era tanto un taller de TDD sino un cambio en su cultura. Ellos ya habían asistido a un curso de certificación en Scrum impartido por Tobias Mayer hace varios años. Con el devenir del tiempo y la búsqueda de la eficiciencia se encontraban en un escenario desgraciadamente muy habitual: una gran deuda técnica y defectos acumulados en su software y una cultura incapaz de buscar la mejora continua. Se estaban arrinconando en el típico enfrentamiento: ellos vs nosotros. “El equipo no se implica con los objetivos” o “los requisitos no son suficientemente detallados”. Y para colmo no hacían retrospectivas regulares ni la mayoría de los rituales de Scrum. Ni tan siquiera estaban haciendo Scrum en apariencia. Estaban haciendo “Scrum In Name Only” (@legnita gratias).

Estuvimos dándole vueltas a la posibilidad de cambiar de planes y hacer algo diferente. Realmente los managers se habían dado cuenta de que, efectivamente, tenían un problema muy serio en la cultura de la empresa en cuanto al desarrollo del software se refería y que tenían que hacer algo. Tras una brevísima retrospectiva, propusimos al equipo hacer durante la semana un proyecto muy pequeño pero haciendo Scrum con iteraciones de 1 día. SÍ, DE UN DÍA. En realidad apenas nos daba tiempo a hacer una preparación del backlog y 3 iteraciones, pero al estresar tanto el proceso yo quería provocar que aquellos “bad ticks” que tenían afloraran con más rapidez y fuerza que en un coaching más “relajado”. Por otro lado, los ciclos de feedback iban a ser mucho más frecuentes, lo cuál nos daría muchas más oportunidades para ver qué pasa en un proyecto normal y cómo reaccionar ante ellos.

Ha sido una de las mejores experiencias de mi vida profesional. Realmente espectacular ver cómo reaccionan las personas ante este tipo de retos. Al final de la semana les di muchísima caña. Los “golpes en las rodillas” (figurado) fueron muchos y algunos seguramente no cayeron demasiado bien. Pero hubo para todos: para el equipo de desarrollo y también para los managers. (Incluso para Steve) Pero cuando las personas son autoexigentes valoran mucho la honestidad. En la retrospectiva final había muchas más opiniones positivas que negativas. Y las negativas estaban identificadas claramente como aspectos que querían mejorar. Ése es justamente el espíritu que trato de transmitir, y ellos lo habían entendido perfectamente. Estoy deseando poder anunciar el resultado de este pequeño proyecto, donde el equipo aprendió a escribir su backlog, historias de usuario, orientarse a construir producto incrementalmente, manejar las tareas y los conflictos durante el sprint, planificar junto al dueño de producto, decidir acciones tras las retrospectivas… vamos, a hacer agilismo del bueno. Claro, como podréis suponer, será [Adults only].

Eso sí, me avergüenza reconocer que tanto el título como el tema están inspirados (ahora se llama así al plagio) en el artículo de Abdul Martínez. Hombre, no es exacto, pero justo es reconocer que (casi sin darme cuenta) su post influyó mucho en el impulso que me llevó a proponer esta charla.

Pero bueno, algo sí pondré de mi propia cosecha. ¡Que no se diga! Así que, partamos de la definición de éxito (o fracaso de un proyecto):

Un proyecto fracasa cuando no se cumplen las expectativas de alguna de las partes involucradas en el mismo.

Los que ya llevais un tiempo en este sector seguro que ya sois sensibles a que en un proyecto hay más partes que solamente cliente y empresa de desarrollo. Hay un grano más fino que incluye a desarrolladores, jefes de proyecto, responsables de productos y marketing, responsables de los equipos de desarrollo, finanzas, etc. Mi intención es mostrar, desde la perspectiva del negocio, cómo es posible mantener una relación sana y sostenible sin necesidad de adoptar una posición defensiva. El objetivo es que todas las partes ganen dinero en el corto y en el largo plazo. Y quiero enseñar cómo esto es posible si desde “el lado del negocio” también se usa un enfoque ágil. Voy a poner énfasis en la vida habitual de un proyecto y en cómo una gestión ágil ofrece un abanico muy poderoso de posibilidades a todos aquellos cuya responsabilidad es manejar de la manera más eficaz un presupuesto. Pretendo ofrecer una caja de herramientas nueva a los que piensan que en “el mundo real” sólo se pueden hacer las cosas de una manera.

Tengo que trabajar mucho en esta charla. No quisiera que se me quedara nada importante en el tintero. En los últimos años he escrito bastante sobre cómo el agilismo puede ayudar a la modernización de España. Pero si queréis darme ideas, sugerencias, experiencias, etc. os aseguro que estaré encantado de enriquecer esta charla con vuestras aportaciones.

Hay retos, claro, si no no sería tan bonito… Tenemos que lidiar con la dispersión geográfica de sus miembros, con las dichosas vacaciones (¡quién las habrá inventado! ) e incluso con retos técnicos como el uso de ExtJS. No son grandes retos, pero suficientes para sacar buenas conclusiones y no poner en riesgo ninguno de los objetivos, tanto el económico de tener éxito con el proyecto para nuestro cliente como el interno de interiorizar buenas prácticas ágiles y, además, tener cierto margen para ir obteniendo artefactos de arquitectura que luego puedan quedarse en la casa para abordar otros proyectos.

Pues bien, en este contexto nos van saliendo conversaciones interesantes que voy a intentar ir sacando en este blog poco a poco en la medida que pueda garantizar la debida confidencialidad. La primera de ellas que me gustaría sacar tiene que ver con la estimación de tareas.

Antes que nada:

¿Para qué estimamos las historias de usuario?

Yo no sé vosotros, pero a mi me gusta saber si el proyecto que tengo entre manos va bien, va mal, le queda mucho para acabar, seré capaz de entregar tal o cuál funcionalidad el mes que viene o dentro de tres meses… será mi pasado oscuro como jefe de proyecto o que es una pregunta muy normal cuando es tu responsabilidad manejar un presupuesto. Así que yo estimo historias y trato de responder a esas preguntas con un “si seguimos a este ritmo parece que sí” o “para ser posible tiene pinta de que tendríamos que hacer algo”. Otro día hablamos sobre cómo ayudo a responder a estas preguntas…

Pues bien, en la primera reunión de planificación surgió lo típico: estimar en horas las tareas.

Y llegamos a la siguiente pregunta (a la que yo realmente quería llegar hoy):

¿Para qué estimamos las tareas?

A mi, personalmente, lo que realmente me interesa es tener un medio de provocar conversaciones que nos permitan reducir las diferencias de expectativas e ideas preconcebidas entre los diferentes miembros del equipo y el dueño del producto a la hora de abordar la historia de usuario en su conjunto y cada una de las tareas en particular. Y consigo este efecto pidiendo que se estimen las tareas… y cuidando de facilitar esas conversaciones, por supuesto.

Así que, al final, yo llego a la conclusión de que no es relevante si la estimación la hacemos en horas, en puntos o en lo que sea. Lo relevante es que salgamos todos alineados y con una conversación lo más rica posible alrededor de cada historia de usuario en el tablón.

LA FOTO: Un guiño a los seguidores de Dr. Who. Ayer vi dos episodios seguidos con niño1 y he terminado hablando con él sobre el continuo espacio-tiempo.

Desde el primer Agile Open Spain 2009 ha llovido mucho (especialmente en las últimas semanas, que hasta me ha granizado) pero gracias al esfuerzo de muchos creo que ahora ya estamos llegando a un nivel de madurez muy interesante. Cuidado, no digamos que estamos maduros sino que estamos en ello. En primera persona estoy viviendo el tipo de comunidad que se está formando alrededor de una idea: ser más felices haciendo lo que nos gusta.

El Agile Open Spain es uno de los momentos más importantes de la comunidad ágil, donde se hace retrospectiva y se renuevan ideas. Es el momento ideal para “desvirtualizar” a gente con la que tienes en común algo más que un mero interés por tu profesión (que también, y mucho). Es un evento donde todos somos iguales, donde todos tenemos las mismas oportunidades de brillar o de decir tonterías. Donde tenemos a nuestro lado a ése que escribe en un blog que tanto nos gusta o a ése que participa en una lista de correo, o incluso a ése que organiza katayunos, merendojos o yo qué sé. Y le podemos preguntar directamente, sin intermediarios. ¿No os parecen suficientes razones?

Por eso el Agile Open Spain está siempre en mi agenda. ¡Nos vemos en Pamplona este año!

P.S.

Si alguien quiere acercarse durante el #aos2011 y charlar conmigo, estaré encantado. Me encanta desvirtualizar gente. Eso sí, ten cuidado porque igual terminas organizando algo cerca de tu casa.

Cada equipo se plantea sus propios objetivos, nosotros, la verdad, no teníamos muchas expectativas cara a ganar el concurso, lo hacíamos más que nada por tener la experiencia y tener la excusa de trabajar juntos. Es un placer trabajar con gente tan madura y con la que no hay luchas de egos ni nada por el estilo. Estuvimos los tres todo el rato muy alineados y disfrutando de lo que estabamos haciendo (aunque alguna vez se cruzaba un impedimento que nos hacía perder el “flow”). Fuimos uno de los equipos que antes “subimos a producción”, probablemente porque teníamos muy claro desde el principio eso de fallar pronto. Hicimos varias retrospectivas y reajustamos nuestros objetivos con muchísima facilidad. En una de las últimas nos dimos cuenta de que en la primera release habíamos puesto Grails en nuestra arquitectura porque una de las historias que queríamos desarrollar requería algo de trabajo de servidor, pero resultó que al ir reajustando nuestras prioridades, aquella historia (“guardar tracks en el servidor”) había perdido completamente la prioridad y la aplicación había quedado en dos páginas HTML más mucho Javascript, es más, en alguna ocasión el tener Grails nos estaba haciendo ir más lentos de lo deseable y nos estaba haciendo pagar más por nuestra instancia en Amazon.

Al final tuvimos el tiempo justo de subir un video a YouTube donde Marcin explica en perfecto castellano con acento polaco cómo funciona TrikTrack.

Bueno, aquí el resultado. Os agradecería vuestros comentarios para mejorar esta charla. Me parece que me sale un poco tostonazo pero me parece que el tema es muy importante y no quisiera que siguiera siendo así de aburrida. ¿Me ayudáis? (Se admiten críticas destructivas)

P.S.

He intentado publicar el video en Vimeo para que os sea más fácil pero desafortunadamente parece que gotomeeting.com genera unos videos con un codec no disponible en Linux y no tengo tiempo para dedicarme a la edición de video ahora mismo. Quizás este verano, que tengo previsto subir mucho del material que tengo recopilado y desordenado desde hace un par de años.

El pasado martes, en la reunión trisemanal del grupo de #madriagil, nos juntamos un grupo bastante numeroso a pesar de las bajas y la dura competencia del fútbol. Quiere ello decir que hay renovación en las personas y que se ha consolidado el trabajo de evangelización que entre todos hemos ido haciendo durante los casi dos años que llevamos. Somos ya tantos que no importa quién viene o deja de venir porque el “retorno de la inversión” para todos los que asistimos (regular o irregularmente) está garantizado.

Jesús Jiménez (aka @jjballano) propuso que hicieramos una sesión práctica sobre historias de usuario pero empleamos la primera media hora en introducir los conceptos más básicos (la mayoría, si no todos, contenidos en el libro de Mike Cohn: “User Stories Applied”; imprescindibles al menos los dos primeros capítulos). Entre otras cosas hicimos mucho hincapié en las tres C (Card, Conversation, Confirmation) y en que una buena historia debe ser INVEST (Independent, Negotiable, Valuable, Estimable, Small and Testable).

He de reconocer que monopolicé mucho la reunión. Las historias de usuario es un tema que me fascina porque es justamente la frontera entre lo púramente técnico y lo puramente de negocio. (Cuando digo negocio no necesariamente hablo de esto sino más bien de esto otro). Además, debo agradecer a Jesús la paciencia que tuvo conmigo porque desde el principio le fastidié provocando una “mini-incepción“. En mi opinión, es un error que cometemos demasiado a menudo: no obligar al dueño de producto (asumimos que tenemos uno) a reflexionar sobre la causa raíz de por qué tenemos que construir la aplicación que nos está encargando. Trataré de reproducir (en la medida que mi memoria me lo permita) la discusión que tuvimos.

El lienzo en blanco

Antes de empezar ya tuvimos una pequeña refriega metodológica: que si empezar directamente por las historias de usuario, que si empezar por los roles o incluso que si empezar por esa mini-incepción que yo proponía. Bueno, como me levanté y me puse en la pizarra rotulador en ristre, pues, ejem, ya os podéis imaginar qué hicimos…  Ahora en serio, exploramos un poco sobre las motivaciones del cliente para arrancar el proyecto como manera para empezar a familiarizarnos con el problema y para establecer una misión para el proyecto. De esa manera, podemos evitar alejarnos del objetivo principal si en algún momento empezamos a escribir una historia que no aporta valor para conseguir esos objetivos declarados del proyecto. Así, cuando se da esa situación, podemos replantearnos los objetivos (que no deberíamos porque se supone que serán bastante sólidos) o revisar si esa historia es oportuna o no en el contexto del proyecto.

Incluso alguien (lo siento, no recuerdo quién fue exactamente) preguntó qué pasa si viene el comercial con una idea del producto y se creó un breve pero intenso debate. <offtopic>Yo, es que cuando oigo la palabra comercial, es que me entra un pitido en los oidos y tardo en recuperar la audición. Es broma, amo a los comerciales, son los que hacen posible que lleguen los proyectos a los talleres… pero, claro, llamar comercial a alguien que vende motos…. Ea, lo voy a dejar que me caliento. </offtopic>

Jesús quería algo así como una aplicación para que el grupo de #madriágil pudiera quedar sin hacer mucho ruido en la lista de Agile-Spain. Para arrancar la discusión empezamos escribiendo ese objetivo en la pizarra y le ofrecí como solución un googlegroup alternativo. Mmm. A Jesús no le gustó. Él quería gastarse su dinero en una aplicación y yo le estaba ofreciendo una solución muy sencilla. Así que seguimos hablando… conversando… y llegamos a que también quería centralizar la información y actividades que hace el grupo en un único sitio. ¡Ajá! Lo escribimos en la pizarra. Y para volver a fastidiar un poco más (y acercarme a los cinco por qué) le dije que en el googlegroup se queda toda la información a modo de histórico.

OBJETIVOS:

• Minimizar los correos a la lista de Agile-Spain para quedar en Madriágil
• Centralizar toda la información que genera Madriágil : elección de fecha / lugar / tema + histórico

Seguimos escribiendo algunos roles que fueron apareciendo durante la conversación y sus responsabiidades principales. Nos salieron el “miembro de madriágil” (que podía identificarse) y “cualquier persona” (que podía ver los eventos publicados). Pensé que íbamos a ir por el camino de las tarjetas de CRC, pero al final aquello no cuajó y avanzamos en la conversación hasta concluir que lo que Jesús quería verdaderamente era simplificar la elección de lugar, fecha y tema para las reuniones del grupo y además tener un histórico que se pudiera consultar de todo eso. ¡Bien! Ya teníamos la primera historia de usuario a punto para ser escrita:

Como miembro de madriágil
Necesito crear un evento
Para que cualquier otra persona pueda verlo (y decidir apuntarse)

(Nota: en las tarjetas que escribimos yo usé el verbo Quiero en vez de Necesito, aunque realmente durante todo el rato hablamos de Necesito.)

Confirmación

En el grupo hubo mucha discusión al respecto porque todos pensaban que se trataba de una historia épica y yo, para provocar (otra vez), les dije que para mi era un 1 y que al llegar a casa la tendría hecha. Mmmm… Era como haber sacado las cartas del planning póker y que todos sacaran un 100 y yo un 1. Algo no encajaba. ¿Qué sabía yo que ellos no sabían? ¿Qué sabían ellos que yo no sabía? ¿Qué estabamos suponiendo cada uno de nosotros? Conclusión: faltaba más conversación. (Otra vez). Para avanzar un poco escribimos la “definition of done” o, para los que echen de menos un poco de español en los términos, “criterio de aceptación” (¿no habíamos dicho “Confirmation” en CCC y “Testable” en INVEST?).

Confirmación:
En una página web (de momento) puedo ver los detalles del evento: Fecha / Lugar / Facilitador.

Llegados a este punto ya el cliente (Jesús) había tomado un montón de decisiones. La más controvertida fue la de que fuera una página web. Luis Fraile, por ejemplo, recuerdo que ofreció mostrar el resultado en un RSS. A mi me parece que eso es tomar demasiadas decisiones en una fase del proyecto donde aún hay mucha incertidumbre. Yo, por otro lado, ofrecí que fuera el equipo de desarrollo el que ofreciera la solución que le resultara más fácil (barata) dentro del timebox de la primera iteración. Al fin y al cabo, hacemos un desarrollo iterativo e incremental justamente para poder dar espacio a la innovación, a explorar aquellas soluciones que al dueño del producto no se le han ocurrido y que si toma demasiadas decisiones evita que aparezcan. Es el principio del “last responsible moment” (ver “Defer Commitment” en el libro “Implementing Lean Software Development” por ejemplo). Jesús se sintió bastante incómodo con mi propuesta. Era como si le estuviera diciendo que él no sabía lo que quería… Curioso, porque realmente Jesús estaba jugando ese papel: el del cliente que no tiene muy claro lo que quiere. Lógicamente, tanto él como yo estábamos haciendo un poco de parodia de la vida real, por lo que nada es ni tan blanco ni tan negro, pero la parodia sirvió muy bien para escenificar cómo existe una tensión entre el técnico-que-sabe-mejor-que-el-cliente-lo-que-el-cliente-necesita y el cliente-que-sabe-mejor-que-el-técnico-cómo-se-deben-hacer-las-cosas. Mi conclusión: hay que tratar de dejar el qué al dueño del producto y el cómo al equipo. En medio, miles de claroscuros y matices que no caben en este ladrillaco.

La potencia del criterio de aceptación es que nos puede servir de guía para la aceptación de la historia de usuario, bien en la demo, bien como guía para el propio proceso de desarrollo si hacemos ATDD y somos capaces de automatizar este criterio de aceptación (p.ej. con Cucumber, Fitnesse, Concordion, etc). Por ello, para que nuestras pruebas de aceptación automatizadas (también conocidas como especificaciones ejecutables) tenga un mayor recorrido, nos conviene no imponernos restricciones tecnológicas muy fuertes. Por ejemplo, decir que los detalles del evento se verán en una página web o en un RSS puede llegar a ser limitante si en el futuro queremos cambiar el enfoque del sistema y basarlo en otra tecnología. (Ya sé, es un caso algo extremo…) En cualquier caso, y para no abundar más en este asunto, os remito a la página 18 del libro de Cohn (“Negotiable” en el capítulo 2) y la 79 (“Keep the UI Out as Long as Possible” en el capítulo 7).

Tras romper la parálisis que siempre asoma cuando la pizarra está vacía y, en parte, superar también esa sensación de agobio por no definir todos los detalles, pasamos a la siguiente historia.

¿Qué más quiere el señor?

Ya habíamos visto que, de alguna manera, el equipo ya podría comenzar a iterar sobre la primera historia, que encajaba bien con el primer objetivo de reducir el ruido en la lista de Agile-Spain a la hora de organizar las reuniones del grupo de #madriagil. Pero claro, no parecía suficiente. Así que seguimos hablando con el cliente y llegamos a algo como esto:

Como miembro de madriágil
Necesito apuntarme a un evento
Para reservar mi plaza

Aquí tuvimos muchísima controversia porque no estaba muy claro cuál era la mejor manera de escribir el valor que aportaba esta historia de usuario. Está claro que el valor (el “para”) debe ser descrito desde el punto de vista del rol que describe esa necesidad. Algunos decían que el valor que aportaba esta historia era que así la organización podía adaptar el lugar de reunión a la cantidad prevista de asistentes. Otros que era la garantía de tener una plaza reservada para asistir a la reunión.

Confirmación:
El miembro X [que realiza la petición para asistir al evento E] tiene reservada su plaza en el evento E.

(Nota: Entre corchetes una modificación que he introducido yo para dejarlo más claro. Pero no fue así exactamente como la escribimos durante la reunión.)

De nuevo vemos que no hemos tomado muchas decisiones y dejamos al albedrío del equipo tomar la decisión técnica. Sin embargo, esto provocó mucho debate porque… ¿desde qué punto de vista se hace esta comprobación de que la plaza en el evento está reservada para el miembro que ha realizado la petición? ¿Desde el punto de vista del sistema? Con una lista de reservas y comprobar que la de la persona en cuestión está presente sería suficiente. ¿Desde el punto de vista del usuario (el que escribe la historia de usuario)? En este caso sería algo como que el sistema proporcionara una confirmación de que se ha efectuado la reserva adecuadamente (bien con un mensaje en la pantalla, bien con un correo electrónico, un SMS…) Lo cierto es que nunca antes me había parado a pensar sobre esta posibilidad, pero después de reflexionar sobre ello, esta última opción tiene más pinta de que otra historia de usuario.

Más sobre el criterio de aceptación

La discusión nos llevó justamente a que Jesús escribiera esta nueva historia:

Como miembro de madriagil
Necesito tener una confirmación de que me he apuntado al evento
Para saber que tengo mi plaza reservada

Y estudiar las pruebas de aceptación que deberíamos hacer nos llevó a otra interesante discusión.

Confirmación:
En el caso de que sí tengo plaza: veo en pantalla un mensaje de confirmación [y recibo un correo-e]
En el caso de que NO tengo plaza: –> ¿cómo sé sabe que no tengo plaza?

Aquí discutimos si era un smell (señal de alarma de que algo estamos haciendo mal) el tener más de una prueba de aceptación para una historia. Personalmente creo que no, aunque sí es cierto que trato de que sea siempre una. En este caso, lo que sí observamos es que para poder implementar esta historia era necesario antes saber cómo distinguir si aún había plazas libres en la reunión o no, lo cuál sí que tiene un cierto tufillo porque se supone que las historias de usuario deberían ser “Independent”. Pero lo cierto es que no tengo una opinión bien formada al respecto, así que me gustaría saber cuál es la vuestra.

PomodoroExhaustedException

El tiempo se acabó y no nos dió tiempo ni de tener suficientes historias para ver cómo priorizar el backlog, ni de estimar las historias ni de ver cómo partiríamos esas historias de usuario en tareas. Sin embargo, creo que la mayoría quedamos muy satisfechos porque hicimos muchas reflexiones en voz alta, las contrastamos con más gente (algunos con mucha experiencia, como es el caso de Luis Fraile), y ése es uno de los grandes valores de estas reuniones: donde profesionales de diferentes orígenes, experiencias, tecnologías, motivaciones… nos juntamos para, en un ambiente generoso y seguro, donde sabemos que nadie nos va a cuestionar por saber más o menos, donde podemos equivocarnos y arriesgarnos sin miedo, podemos compartir nuestras dudas y ofrecer nuestras respuestas y reflexiones.

Retrospectiva

Aunque quede un poco off-topic con el título del artículo, no quería olvidarme de la retrospectiva. Los asistentes más habituales a las reuniones de #madriagil sabemos que no somos un grupo muy disciplinado, lo que se evidencia en nuestro poco respeto a una de las prácticas ágiles más importantes: la retrospectiva. Así que conseguir acordarnos de que debíamos hacer la retrospectiva es remarcable en sí mismo.

Esta vez me apetecía mucho ver a otro hacer una retrospectiva, éramos un grupo muy numeroso y seguro que podría haber aprendido algo, aunque solo sea por estar en el rol de asistente. Ofrecí el rotulador pero no hubo suerte. Así que hice lo que hago últimamente (mi pequeña receta siempre en constante actualización):

1) recordé a todos el objetivo que perseguimos con la retrospectiva: la mejora continua

2) una carita sonriente: para agrupar todo aquello que nos gusta, que nos hace sentirnos cómodos y que queremos seguir repitiendo

3) una carita triste: para agrupar todo aquello que no nos gusta, que nos molesta y que queremos dejar de hacer o que queremos impedir que siga ocurriendo

4) una bombilla: para agrupar todas aquellas ideas que se nos ocurran que nos gustaría probar para mejorar cualquier aspecto de lo que hacemos

5) una flor: para agrupar los nombres de aquellos a los que queremos agradecer algo en especial (esto último lo aprehendí de una visita que nos hizo Angel Medinilla hace ya mucho tiempo al grupo de #madriagil)

El resultado de la media hora fue el que veis en la foto (aunque sea de mala calidad). Cierto es que a esa hora (las 21:30 aprox) ya estábamos bastante cansados y muchos ya con más ganas de ir a por unas cervezas y a ver si veían la segunda parte del Madrid que otra cosa.

Más comentarios sobre la retrospectiva en este hilo de la lista de Agile-Spain. (DISCLAIMER: No me hago responsable del contenido de ese hilo)

Y para terminar una muy amena charla en un irlandés con varios espartanos del proyecto de la muerte y un polaco en bicicleta.

Muchas gracias a Nayade y en particular a Manuel Castro, que siempre ofrece el espacio y parece que siempre rechazamos su oferta. A ver si ahora que ya hay menos peso ágil en IPSA podemos retomar la vieja idea de ir rotando por diferentes localizaciones de Madrid y así favorecer el que, en algún momento que se me antoja no muy lejano, haya más de un grupo agilista en Madrid. Algo como un Madrid Sur y Madrid Norte o Madrid A-6 y Madrid A-4 o Madrid Vallecas y Madrid Chamberí (por dar ideas).

ACTUALIZACIÓN:

Lo siento, olvidé comentar dos cosas:

1. La discusión sobre si identificar al “miembro de madriágil” era una historia de usuario prioritaria. Fue quedando un poco postergada porque no vimos que fuera realmente algo que mereciera nuestra atención aún. Pero tenía pinta de ser una de esas historias de usuario “técnicas” muy socorridas para superar nuestro “horror vacui”.
2. Surgió en la retrospectiva una idea muy interesante que no quería que se perdiera. Creo que fue Rafa de Castro, pero puedo equivocarme fácilmente en la atribución, quien comentó que se podrían hacer UserStoryKatas (y como consecuencia también UserStoryDojos). La idea sería algo así como ejercicios para practicar la escritura de historias de usuario. Es decir, practicar no sólo la escritura de la tarjeta sino, sobre todo, la conversación y la confirmación. (Quizás enlace esto también con el concepto que Gojko Adzic promueve de las sesiones de especificación)

En lo profesional aprendí mucho. Cuando pienso el dinero que me he ahorrado con lo que aprendí ayer… Estuve un día entero preguntando y escuchando a gente como Rachel Davies, Enrique Comba, Rodrigo Corral, Raquel Laina, Teresa Oliver, Jose Ramón Díaz, Jorge Uriarte, Roberto Canales,… no sé, no sigo porque corro el riesgo de que el post me quede más largo que los de Enrique Amodeo. ¿Fotos? Sí, aquí las fotos de Enrique y aquí las de Emma. ¿Y esta otra qué es? Ejem, ejem… mejor no digo nada ahora.

Aprendí, por ejemplo, que en mi “proyecto de la muerte” he intentado cosas que no estaban mal encaminadas y que las ideas que tengo en la cabeza tampoco van mal. También he aprendido que tengo un estilo de coaching “poco coach”, seguramente porque no es lo mismo ser coach que agente de cambio, y porque tampoco es muy compatible con ser jefe de proyecto. En fin, espero que algún día pueda volver a lo que verdaderamente me satisface: programar. (Excelente artículo de Carlos Blé, por cierto).

Tuvimos conversaciones muy enriquecedoras, no sólo en las sesiones propuestas, sino en las improvisadas. En cualquier rincón te encontrabas a gente charlando sobre experiencias y maneras de resolverlas. Seguramente estas conversaciones volverán a salir en la lista de correo que Enrique creó para este evento.

Me llamó la atención cómo Enrique Comba, que vive fuera de España desde hace tiempo y cuyo contacto con la comunidad agilista en España es muy puntual (en los coderetreats que hemos hecho juntos con agilismo.es, en el AOS2010 y a través de la lista de correo de agile-spain), se sorprendió del nivel de madurez y de preocupación de los asistentes. Verdaderamente, tenemos que tomarnos más en serio lo de la lista de correo y pedir a los que escribimos reflexionar más antes de pulsar el botón “Enviar”.

Pero a mi lo que más me gustó es ver cómo, después de apenas dos años, la comunidad agilista tiene un gran dinamismo y, sobre todo, una preocupación más allá del tirón del término “Agile”. Hay una (aún) pequeña cantidad de profesionales que nos preocupamos por nuestra profesión y por dignificarla dando un paso adelante y buscando soluciones. No nos quedamos en los rincones quejándonos de lo mal que está todo. Nos buscamos los unos a los otros y nos encontramos alrededor de eventos de muy diversa índole. La idea de Jesús Jiménez durante el AOS2010 de organizar openspaces temáticos ha sido todo un acierto. Vamos a hacer muchos más. Vamos a llevar el mensaje a mucha más gente y llegará el día (no muy lejos) en el que las grandes empresas que defienden el modelo de competir en precio no puedan competir con las pequeñas empresas que compiten en calidad.

No hay vuelta atrás.