LUGAR DE ENCUENTRO
Ciudad: Valladolid
Hora: Desde 19:30 a 21:00
Punto de encuentro: Cafetería Púrpura (en la parte de arriba)
- C/ Las Mercedes, 7 (en el portal) 47006 Valladolid
OBJETIVOS
- Conocer KANBAN y sus diferencias con SCRUM.
- Debate sobre su incorporación a nuestro trabajo actual.
- Actualizar la lista de temas a tratar.
REFERENCIAS
Traducción de “Kanban vs Scrum” de Henrik Kniberg.
Vídeo y Presentación de la charla de Agustín Yagüe en el grupo local de Madrid
Presentación utilizada en el Encuentro
AGENDA
- Presentaciones individuales
- Presentación de Kanban (promovido por Jorge Jiménez)
- Retrospectiva de la reunión.
- Actualización de Backlog de temas para los encuentros
ASISTENTES
- Jorge Jiménez Pérez
- Amalia Hernández García
- Jezabel González Diez
- Alfonso Bernal
- Isidro Merayo
- Pencho Herrero
- Francisco Pascual
- Javier Acero
- Olivier Salmon
- Alvaro García
RESUMEN
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.
