• C/ Las Mercedes, 7 (en el portal) 47006 Valladolid

• C/ Las Mercedes, 7 (en el portal) 47006 Valladolid

Nueva reunión del grupo de Agile-CyL para tratar la metodología ágil Kanban, exponente claro de los principios Lean y que fue presentada por Jorge Jiménez.
Se abrió debate sobre la metodología desde los primeros momentos de la exposición, con lo cual fue bastante interactiva la presentación exponiendo cada uno de los presentes las dificultades y ventajas que le veían a esta metodologÌa.

Dudas que surgieron y diferentes respuestas aportadas por los asistentes fueron:

¿Quién marca la velocidad? Siempre va a estar definida por la fase más lenta del workflow, compartido por todo el equipo. Por esto influye en el tiempo de entrega de las tareas.

¿Kanban es ajustable a nivel de tarea? No piensan en tipo de desarrollo, cascada o agil, piensas en un desarrollo constante. Olivier recalcó que lo importante es el flujo del proyecto.

Jeza le ve un peligro cuando se dice que no es tan prescriptivo como Scrum en cuento a los equipos multifuncionales, permitiendo equipos especializados ya que cuando sólo participas en una parte del proceso, no es como scrum en que tienes una visión completa del proyecto. Es como un operario en una cadena de montaje en que sólo vas a hacer una tarea sin aprender de las demás y del resto del equipo.

Pencho- que tiene más experiencia en sectores muy diversos aportó su visión en contraposición del símbolo de la melé en Scrum, indicando que  Kanban es como una melé abierta, en cualquier momento se pueden incorporar recursos al sistema para darle valor y mejorar el flujo según las necesidades del proyecto. Es más flexible a modificaciones del equipo.

En soporte o mantenimiento de software la aplicación de Kanban es donde todo el mundo estaba más de acuerdo en que lo veía más ajustado. En este caso, Pencho explicó el caso de Indal como proceso industrial, en que usaban gráficas similares a las de Kanban (Cummulative Flow Chart) para en la incorporación de nuevos trabajadores meterlos en la “curva de trabajo”, es decir, en coger el ritmo para la entrega de producto en los tiempos de ciclo definidos por el proceso.

Entregas en cualquier momento:
- Positivo: en tener actualizaciones en cualquier momento, el tratamiento de parches sobre el producto de manera instantánea.
- Kanban se ve poco factible en producción pero sí en mantenimiento de producto.
- Olivier (con su gorra de cliente): si el proveedor da información de sus necesidades futuras, facilita la comunicación para estar preparado ante nuevas peticiones u órdenes de trabajo, tareas…

Estimaciones:
- Se usa una velocidad que puede no ser real, ya que el cycle time es valor en términos de media.
- Hay flujo de dinero y de trabajo a la par, aunque no haya estimaciones se puede pagar por lo que se entrega.
- Mentalidad española: no dejar que la gente utilice todo el tiempo  estimado que tiene para ese desarrollo, hay que seguir el flujo y no provocar parones.
- Puede funcionar bien con perfiles comerciales sin objetivos a conseguir, sino que cuanto más hagas mejores recompensas tendrás, pero no marcas mínimos (ejemplo aportado por Pencho acerca del Banco Popular en los años 80 y primeros 90).
- Malo por no tener tareas homogéneas que su resolución y el tiempo de finalización o de avance en el flujo sea muy diferente entre ellas.

Scrum / Kanban

Sugió el clásico problema del tratamiento de las incidencias. Una incidencia no da valor al cliente, es un error del equipo que no debe ser asumido por el cliente.
En Scrum, Olivier comenta la posibilidad de meter un 7% del tiempo para incidencias en el Sprint, es un colchón previo antes de que aparezcan. Jorge opina que es engañar al cliente, aunque se pueda compensar entre Sprints, pero le cobras por anticipado un tiempo dedicado por tus errores. Javi trata las incidencias desde el principio, dentro de los Story Points del Sprint y asumen que las incidencias se tratan ahí, es el equipo quien se las “come”.

Fran comentó que Kanban es teoria de colas y de procesos, sin iteraciones, sin backlog y es como el Scrum llevado al limite. Para él, al fin y al cabo, al usarlo para temas de incidencias es como reflejar en un tablero cualqueir herramienta de gestion de incidencias, como Mantis o Bugtrack.

Alvaro dijo que hay una variante que consiste en mezclar Kanban y Scrum, con lo que se denomina Scrumban en proyectos sobre todo muy grandes, con varios cajas departamentales y varios tableros kanban.

Pencho aboga por el uso de Kanban utilizado como metodología de trabajo para saber cómo se ha trabajado midiendo eficiencia no eficacia aunque no es necesario utilizar Kanban para realizar esas medidads.

Comentando las diferencias entre kanban y scrum, Jezabel definía kanban para trabajos repetitivos con tiempos muy definidos, y scrum es más parecido a una consultoría artesana. Su frase que puede definir el tema de la reunión fue:
Kanban es más una forma de trabajo de consultoría industrial mientras que Scrum es un proceso mucho más artesanal.

• C/ Estadio, 2 (esquina c/ Las Mercedes) 47006 Valladolid

Como es habitual la reunión comenzó con la presentación de cada uno y su relación con las metodologías ágiles. En esta ocasión contamos con tres nuevos componentes del grupo que acudían por primera vez a nuestros encuentros ágiles.

Empezamos la charla preguntando por problemas que tenemos o casos que nos hemos encontrado y tratando esos temas para ver cómo entre todos llegábamos a algún tipo de conclusión.

Nos encontramos con este caso en la mayoría de las situaciones, una de las herencias de tantos años de waterfallismo. El cliente no quiere conocer nada de metodologías ágiles y sólo espera tener el proyecto en las fechas concretadas en el contrato.

En este caso no contamos con un product owner proporcionado por la empresa cliente, de manera que en la mayoría de los casos en las metodologías ágiles este rol lo asume una persona de la empresa que desarrolla el proyecto. Normalmente el papel lo toma el jefe de proyecto que es el mas cercano al cliente y el que debe saber las necesidades del mismo para darle soluciones y ponerse en su papel. En caso de dudas siempre estará cercano al cliente para completar la información que le falte. Otra persona que puede asumir este rol es el consultor por el conocimiento que tiene del negocio para el que se desarrolla el producto.

Al final seguimos escondiendo la metodología ágil ante clientes con los que no tenemos confianza o seguridad para ser claros. Es algo que con el tiempo se debe superar, quizás explicando claramente las ventajas que para el cliente puede tener el desarrollar proyectos con estas metodologías, con un mayor conocimiento del trabajo desarrollado en ciclos más continuos y cortos.

Siempre se puede traer al cliente a estas metodologías sin necesidad de darles un nombre, porque al final nadie se opondrá en ver en qué invierte su dinero, o en aclarar cualquier duda en las reuniones de seguimiento de proyecto. Esto escuchado por un cliente “prefiero saber lo que se hace día a día o semana a semana que no esperar 3 meses y ver lo que se me entrega, teniendo la fecha de cierre de proyecto más cercana y sin tiempo de rectificación”.

Si el cliente está al alcance del equipo, involucrarle en los artefactos de scrum, tanto spring meeting como en la demo al final del sprint.

Es fundamental la comunicación entre product owner y equipo.

La priorización de tareas es fundamental que sea realizada por el cliente y no sustituido por otra persona. Hacerlo mal podría equivocar las prioridades del cliente y dar un resultado poco interesante para el cliente final cuando ejecute la demo del producto. Hay que aportar valor en cada iteración según las necesidades del cliente: dar más valor en las primeras iteraciones para aumentar el ROI del cliente.

Una persona desplazada en cliente puede asumir el rol de producto owner al tener conocimiento de lo que se necesita, sería una solución a la falta de involucración del cliente.

Hay una opinión generalizada de que no se pude tener al cliente de manera continua en contacto con el cliente o en todas las demos. Hoy en día hay solución para este problema, utilizando herramientas remotas como Skype o videoconferencia.

Para realizar las estimaciones hubo un criterio casi general: estimar sólo por tareas extraídas de las historias de usuario, eso marca cuántas historias pueden meterse en el sprint. No hacerlo desde el punto de vista de estimación las historias del product backlog y una vez que se sepan las historias que entran en el sprint estimar sus tareas. Según se dijo era más fácil y a largo plazo se estima mejor que a corto plazo.

¿Qué hacer ante proyectos a precio cerrado? En este caso es complicado hacer estimaciones ya que siempre hay que terminar en un tiempo fijo para compensar los costes del proyecto. Puede que la estimación real te lleve a más tiempo que la estimación ideal realizada en preventa. Hay que intentar huir de ese tipo de proyectos

Existe un problema en las metodologías ágiles, donde parece que se está trabajando por complacer al cliente y esto puede provocar que haya clientes que se tomen “barra libre”. Hay que fijar claramente al inicio del proyecto su alcance, y para ello será necesario un documento donde estén reflejados los requerimientos del sistema pedido por el cliente.

Se aclara que Scrum no se ajusta a trabajar en mantenimiento de productos, al aparecer tareas nuevas a lo largo del sprint que hay que solventar en cuanto aparecen.

Estas tareas-incidencias son asumidas por el equipo y dependiendo de la importancia de la incidencia se ataca inmediatamente o se postpone para el sprint siguiente.

Siempre se deja un colchón al final del sprint por si no se llega para poder tener tiempo y solucionar este tipo de tareas emergentes.

Las estimaciones se realizan mediante planning poker, siguiendo la serie de Fibonacci, pero siempre hay un vicio en estimar lo que uno terminaría, no lo que cualquiera del equipo podría tardar.

Si no hay claridad en la definición de la historia las estimaciones sufrirán.

Si dura mucho el sprint meeting y se sale del timeboxing fijado es un coste muy elevado para el proyecto. No discutir soluciones técnicas.

Se habló de la dificultad de trabajar en Scrum con equipos distribuidos pero los casos reales que se explicaron reflejan que no hay impedimentos la usar herramientas como IM o Skype para las reuniones de equipos, manteniendo una reunión dentro del sprint con presencia física de todos los componentes del proyecto

¿Qué pasa cuando el cliente pide sacar a alguien del equipo o desde la propia empresa se saca a gente del proyecto?

Es un problema que hay que resolver intentando mantener en lo posible al equipo mediante intento de negociación. Si hace tiempo hubo un problema con alguien hay que dar la oportunidad nuevamente por si ha cambiado y puede ser ahora importante para la resolución del proyecto.

Lo normal es lo contrario, es pedir que alguien en concreto se incorpore al equipo por el conocimiento y experiencia que puede aportar.

Hay que luchar con las gerencias para el mantenimiento de los equipos y que no se modifique su composición durante un proyecto o por lo menos durante un sprint, aunque el movimiento de personas en nuestro sector es muy común y es complicado hacer equipos estables.

La charla derivó a discusiones sobre técnicas de integración contínua, ramas, tags y desarrollo por features o por desarrollador que quedan fuera de este encuentro.

• Avenida Ramón y Cajal, 14 47005 Valladolid

El punto dos puede cambiarse hasta el día 10 de Diciembre si alguien quiere exponer o tratar otro tema. Solo tiene que proponerlo en la lista y se vota . Había otros temas propuestos para tratar en un futuro:

XP

TDD

Integración Continua

Scrum

Técnica Pomodoro

GTD

Kanban

Manifiesto Agil

Todo un éxito este encuentro, tanto por asistencia como por primer encuentro en que tratamos un tema interesante y que habría un debate posterior muy enriquecedor.
El tema presentado de manera muy didáctica y efectista por Amalia fue la técnica Pomodoro para la gestión óptima del tiempo de trabajo.
Se presentó con un reloj de cocina con forma de tomate rojo y comenzó a explicar la técnica dando cuerda al reloj durante 25 minutos, en lo que duró su exposición. Además nos repartió a todos un resumen de la ténica así como las dos listas a tener en cuenta durante la ejecución de la técnica:

• Lista de Inventario de Actividad
• Lista de tareas a realizar en el día (To Do Today)

La verdad es que la explicación de la técnica es muy sencilla, parte de la visión de que el tiempo es nuestro gran enemigo cuando acometemos una tarea y la aproximación la podemos hacer desde dos puntos diferentes, primero como una serie de tareas que se realizan en el tiempo o como un eje
temporal en que vamos ejecutando tareas. la verdad es que dicho así parece lo mismo, pero no lo es y así nos lo explicó.

Hay que ver el tiempo de una manera diferente, como el marco dentro del cual queremos ser más productivos ejecutando tareas (muy en consonancia con el concepto de timeboxing de las metodologías ágiles). Hay que hacer un uso eficiente del tiempo y de una manera continua.

Aunque nos explicó que la duración del pomodoro (timeboxing para la ejejcución de una tarea) es de 25 minutos, tuvimos un debate abierto sobre si ese tiempo es el correcto o depende de cada persona, llegando a la conclusión que se podría aumentar, pero siempre sin pasar de 45 minutos ya que la mente humana no sería capaz de concentrarse al 100% más allá de ese tiempo.

Otro aspecto a destacar fueron los descansos, el marcar descansos de 5 minutos tras cada pomodoro y de 15-20 minutos tras un set de 4 pomodoros. Y haciendo el descanso de verdad, es decir, dejando de lado el trabajo, las tareas que se estén ejecutando y todo lo relacionado con ellas. Puede ser algo complicado en un entorno laboral en que los compañeros requieran tu atención, aunque siempre está la excusa de hablar del futbol o de una peli que hayamos visto.

Se nos explicó las diferentes interrupciones que podemos sufrir a lo largo de un pomodoro, clasificadas en internas y externas. Las peligrosas son las internas, ya que son las que tú produces y te quitas concentración tu mismo. Esto es lo que hay que evitar.

Un aspecto que sugió ante trabajos como el de Jezabel o el de Pencho es la dificultad de definir qué es una tarea, si deben estar continuamente atendiendo llamadas de teléfono, contestar emails, preparar documentación para clientes, etc… La respuesta de Amalia es que siempre pueden agrupar esas tareas que tengan planificadas a primera hora y realizarlas en un pomodoro, dos o los que necesiten. Luego saldrán tareas emergentes que tendran que planificar igualmente en la lista de To Do Today.

Al finalizar la charla salió el tema de GTD (Getting Things Done) donde Jezabel y Pencho nos hablaron de su experiencia en esa técnica para no olvidar tareas, o más bien, apuntarlas para poder recuperarlas más adelante cuando tengan tiempo para ejecutarlas. El problema mayor: se crea una lista enorme de cosas que querrías hacer más adelante y al final no haces nada.

Conclusión de la charla: es necesario un entrenamiento personal, esta técnica es buena para personas con necesita cierta disciplina. Todos estábamos de acuerdo en que se mejora la productividad personal usando una técnica en que aprovechas mucho mejor intervalos fijos de tiempo para realizar tareas que tienes planificadas previamente.

Posteriormente se habló ligeramente de las estimaciones a la hora de preparar un presupuesto para un concurso, y de lo irreal que puede ser hacerlas sin tener una experiencia previa en ese tipo de proyectos.

Jezabel nos explicó el significado de la iniciativa Iniciador, que en Valladolid está comenzando a tener mcho eco, y nos invitó a las reuninoes que celebran los segundos martes de cada mes, indicando que ya tienen preparados los ponentes para los próximos meses, eso sí es profesionalismo

Por último establecimos una serie de propuestas de charlas para las siguientes charlas.

• Avenida Ramón y Cajal, 14 47005 Valladolid

La reunión comenzó con algunas ausencias, pero satisfechos de saber que hay gente que en próximas reuniones acudirán si pueden o por lo menos que han mostrado su interés.
Comenzamos con la presentación de cada uno, indicando su nombre, su relación con las metodologías ágiles y lo que esperaban de la reunión. Con esta pesentación vimos que inicialmente todos eramos personas con ganas de aprender y aplicar las metodologías en cuanto tuviéramos ocasión para ello.
La reunión continuó explicando un poco el sentido de las metodologías ágiles y el contexto a nivel nacional en que nos encontramos, referenciando el portal de Agile Spain, así como la reciente creación de diversos grupos locales. La verdad es que se notó nuestra falta de experiencia porque todo se fué volviendo a contar casos personales o nuestra situación actual frente a estas metodologías…y siendo la primera toma de contacto el tema del timeboxing se nos fue de las manos.

A continuación Amalia y Jorge hablaron un poco de la experiencia del Agile Open Spain al que acudieron con cierto interés y dudas sobre lo que se iba a tratar pero que fue una experiencia bastante positiva y con ganas de repetir por su parte

Despues de exponer el motivo de creación del grupo y compartir las ideas de los asistentes se comenzaron a decir los temas de futuras charlas, para ir creando una lista de inquietudes del grupo. Los temas son:

1. XP
2. TDD
3. Integracion Continua
4. Scrum
5. Pomodoro
6. GTD
7. Kanban
8. Manifiesto Agil

Se marca la fecha de la proxima reunion para el martes 15 de Diciembre, antes de las Navidades.
Y por ultimo no podia faltar la retrospectiva de nuestra primera reunion.

Entre las cosas a mejorar la gestión del tiempo, y el seguir el guión sin entrar en desviaciones dialécticas que no conducen a nada (o sí).

Entre lo positivo de la reunión, la respuesta de la gente, tanto de los asistentes como de los que por motivos laborales, personales o de salud no pudieron acudir en el último momento. Fue la sensación de sentir que “no estamos solos” en esta región.

Y gustó el tener un guión preparado con el tema de la reunión, aunque no se siguiera al pie de la letra y no se guardaran los tiempos predefinidos.
En conclusión, para ser la primera reunión muchos aspectos positivos y muchas ganas de poner la maquinaria en marcha.