Agile-Alicante. Febrero 2011.

Scrum, Scrum & Kanban & ScrumBan. Con este título se convoco la segunda reunión del grupo agile de alicante. Y, tomándolo como la excusa perfecta para hacer un viaje de los que me gustan, intensos y rápidos,  me cogí el coche para meterme 1100km en dos días y conocer y compartir experiencias y conocimientos.

Y he de reconocer que ha merecido la pena y mucho.

La reunión estuvo asistida por 7 miembros, más quien escribe estas lineas. Y estaba compuesto por muy un compendio impresionante de sectores de la industria. Dos BI, un investigador, uno de atención al público, uno de hard y soft de televisión, un director de proyectos (de los de verdad), un IT. Y todos con un nivel… que ha sido todo un honor poder disfrutar de la sobremesa –de la cual hablaré más adelante-.

La primera ponencia la presentó Jorge Muria – nuestro anfitrión – que trató sobre Kanban. Para que no se perdiera la costumbre de las reuniones Agile, nos pasamos el 60% de la ponencia charlando, opinando y compartiendo. Entre las múltiples cosas que he aprendido, me gustaría señalar dentro de los artefactos el uso de subpipelines, el concepto de Wip (Work in progress), la sutil diferencia entre Push (cola->wip) y Pull(wip->completado) y los límites (máximo, mínimo y temporal). Estos dos últimos limites me asombraron por desconocerlos y por la potencia que añaden a los límites Kanban. Por último nos hablo del pipeline de emergencia en utilizado para, como su nombre indica, emergencias..

A continuación Gustavo nos dio otra breve ponencia sobre Kanban a Scrum, llena de referencias, comentarios y opiniones por el resto del grupo. Pero de las que saqué varias valiosas conclusiones –no todas relacionadas con Kanban-:
* Las historias de usuario son INVEST
* El compañero de al lado, un IT, nos comentó el ejemplo extremo y real de el concepto HEROE. Una compañía en donde tres “informáticos” tenían, por contrato, viajar en el mismo avión. O, el caso del BDsys que tuvo que volver urgente de sus vacaciones en la India porque “alguien” cayo en la cuenta que aquel era el único que tenia los permisos de administración sobre las BD.
* Gustavo nos comenta que sus Kanban están centrados en el Flow del proyecto completo, incluyendo columnas para la conceptualización, sistemas, etc. Incluso de BD y Sistemas, que en el workFlow, pueden causar cuellos de botella.

Por último, Jorge nos ofreció una exposición final sobre scrumban incluyendo una visita al otro lado de la sala en donde tiene su panel real de scrumban. Nos explicó las prioridades del panel Kanban que amplia el panel Scrum (asap, prioritario y fire). Y nos mostro el título de su tablero Kanban: Brown Dispatcher. (bueniiiiiiisimo, jeje).

Aunque lo intentamos, no hubo forma de hacer la retrospectiva, por lo cual hago la mía propia:

(+)

• El grupo era muy interesante y completo. En nivel alto. La conversación interesante.
• El ambiente fue de los mejores que me he encontrado.
• Una vez más, me llevo muchas cosas nuevas aprendidas.

(-)

• Que está a casi cuatro horas de Madrid.
• Nos moríamos de ganas por compartir experiencias y durante las exposiciones interrumpimos demasiado.

No voy a poner deltas, porque no creo que pueda mejorar esta reunión. Ha sido muy buena.

A partir de ese momento nos bajamos al restaurante Vinícolas en donde nos enseñaron la enorme e impresionante colección de vinos. Y, como colofón, nos invitaron a comer un menú degustación que es de lo mejorcito que he comido nunca. Que nivel!!

En la sobremesa se formó uno de esos momentos “mágicos” en donde fluye el conocimiento en todos los sentidos. Y que fue bruscamente interrumpido al darnos cuenta que ya era la una y media de la madrugada. Que rápido pasa el tiempo cuando se está agustito!!

Muchas gracias!!

Madrid-Agile 22/02/2011 Historias de Usuario

Reunión en Nayade a la que llegué tarde, y menos mal que llegué, a causa de un amigo indómito al que le voy a echar una mano con su dominio, su web y todas aquellas cosas que le ayuden a salir del agujero en donde está metido.

Primera sorpresa… que montón de gente!!

Yo que pensaba que íbamos a ser cuatro gatos, me encuentro con la sala petada de peña, todos con unas ganas de aprender tremendas. JMB ya estaba de pié haciendo de jefe de proyecto (mira que le gusta) y había muchas caras nuevas y caras de gente ya largamente conocidas. Quiero señalar a Luís Fraile que demostró de largo porqué es un MVP de Microsoft y que no solamente sabe un rato, si no que es un muy buen comunicador.

Mr. Ballano tomo el rol de cliente e hicimos, siguiendo la batuta de JMB, una primera puesta en común de lo que es una historia de usuario. A continuación, siguiendo los dictados del “limonchelo” nos embarcamos en tres pomodoros para ir construyendo historias de usuario según las indicaciones del cliente. Lo cual resulto muy, muy fructífero al revisar cada paso desde múltiples ángulos y experiencias. Y no dudar en detenernos hasta quedar todos conforme del porqué y del cómo de las historias que iban surgiendo. Finalmente completamos dos y casi tres historias, en un interesante diálogo constante. Y que condenso en las siguientes conclusiones:

Historias de usuario

• Las reuniones iniciales con el cliente han de ser con pocas personas.
• El uso de las palabras en inglés no tiene sentido si la conversación se hace en castellano. Es decir utilizar As a role, ability, benefit queda muy “guay”. pero al final lo que usamos es “Cómo”, “quiero” y “para”.  Vamos, mi sensación de que hay mucho esnobismo se ha reforzado. Teniendo en cuenta que soy bastante “taliban” del uso del castellano en el software (toma contradicción)
• El glosario del dominio lo debe construir el cliente y nosotros lo debemos seguir de forma lo más natural posible para que no halla errores de apreciación como entre las palabras  “ver” o “consultar” un resultado. Lo importante es lo que signifique para el cliente y nosotros asumir ese significado como lenguaje del dominio.
• Tengo que tener más paciencia. Acostumbradísimo como estoy a tratar con clientes de todos colores y sabores, con cuatro preguntas y media obtuve la misma información que se tardo media hora en alcanzar más tarde. Y me apresuré y “saque los pies fuera del tiesto”. Lo bueno es que me di cuenta de mi impaciencia en ese momento y no volví a salirme del timming.
• Al principio del dialogo con el cliente sobre lo que quiere, lo que se obtienen son historias épicas. Osea, aquellas que no tienes claro el cómo se van a desarrollar. Y de las cuales van a salir historias de usuario concretas.
• Los roles van emergiendo en la propia construcción de las historias. Si bien hay que tener unos roles “épicos” al principio, siguiendo el principio de tomar las decisiones en el último momento, hay que esperar que dichos roles se definan a sí mismos según las historias vayan adquiriendo más precisión. Aquí JMB nos hizo gala de lo que ocurre en un equipo cuando un miembro sale “por peteneras”… que el resto del equipo pasa de el (eso sí, con mucho cariño). Y se entra en un dialogo de conflicto con el cliente. Trampa en la que hay que tener mucho cuidado en no caer cuando piensas que sabes más que tu cliente sobre su producto y que, además, se lo tienes que demostrar.
• Es importante la primera premisa “Como”. Es decir el rol va a marcar el resto de la historia de usuario ya que puede no ser la misma dependiendo de quien la realice. Yo caí en la confusión de cambiar el rol de acuerdo a la premisa en que estábamos y me monté un lio yo solo que de forma muy satisfactoria el resto de los asistentes (los que hablaban claro) me ayudaron a clarificar.
• Mi gran descubrimiento de la reunión: “Confirmación”. O la prueba de validación. A primera vista es algo tan simple como que el cliente diga cuales son las condiciones que se han de cumplir para que se de por realizada la historia. Pero, es curioso, con esta premisa hace emerger mucha más información de la esperada. Primeramente, al ser dependiente del rol, conduce al cliente a ponerse en la situación de dicho rol y a marcar las diferencias con otros roles -emergen las características propias del rol-. A continuación, las pruebas de aceptación inducen a encontrar nuevas historias de usuario o requisitos, ya que es ver el cubo desde otro punto de vista. Y, como en el caso de la tercera historia de usuario, si existen aceptaciones dependientes o condicionales, te permite “oler” que van a surgir aún más historias de usuario o requerimientos que en las premisas anteriores era mucho más difícil de obtener.

Mi retrospectiva (+)

• La idea de Ballano ha sido muy buena.
• Me he quedado con ganas de más.
• El nivel de los participantes era alto. Quien no aportaba experiencia, aportaba conocimientos. Pero no hubo grandes “salidas de tiesto”.
• He aprendido mucho. Ha sido una buena reunión.

Mi retrospectiva (-)

• El facilitador debió de ser Ballano. JMB, con toda su buena intención, se convirtió en un proxy de ideas y decidía cual y de qué manera se plasmaban. Dirigió en demasía, para mi gusto, la actividad.
• Hubiera querido que nos ajustáramos al guion de la reunión y hacer grupos de trabajo. Para sentarnos en circulo y quitarnos la palabra el uno al otro (menos los que levantaban la mano) podíamos irnos a tomar cervecitas. Suena estricto, pero es que en dos horas hubiéramos echo más que dos historias de usuario. Y centrar un poquito más las disertaciones, que al final nos vamos por los cerros de Úbeda.
• La retrospectiva fue terrible. No se hablo por turnos, por lo cual hablamos los que hablamos siempre. Por lo cual muchos no hicieron retrospectiva. JMB saco finalmente el látigo y obvió todo aquello que a sus oídos no le parecía correcto o con suficiente interés. Por lo cual en el tablero se leía lo que el pensaba y no lo que el grupo decía. Por lo cual el grupo no se sintió identificado con la retrospectiva y es como si no la hubiéramos echo. Y así se levantó la reunión, sin ninguna conclusión más que “esto se ha acabado. Vamos que nos vamos”.

Mi retrospectiva (Λ)

• Hacer otra reunión o incluso una User History Dojo.
• El cliente debe ser el facilitador. Podría ser una pareja. Y debe ser mucho más contundente.
• Quitarle el lápiz a JMB.
• Buscar un sitio más grande que Nayade. Que petamos su sala.
• Incentivar que la gente callada hable más.
• Un token para el turno de palabra. Y así evitar un poquito que los de siempre estemos rajando todo el rato y no caer en corrillos. Que, aunque poco, caímos todos.

 

Y ahora, este viernes, nos vemos en alicante!!