Hay quien piensa que buscar una pared, llamarla DashBoard y pegar Post-its va a ser la solución a todos sus males: vamos a utilizar Scrum y ahora todo irá bien. Cumpliremos fechas, no habrá bugs y el equipo estará motivado.
Es fácil perder el rumbo con tan vistoso elemento, pero no debemos dejarnos llevar y tenemos que hacer un esfuerzo por ver el tablero como la herramienta que es. Debemos darle su importancia, cuidarlo, trabajarlo, respetarlo... al igual que las demás herramientas: Daily meeting, TDD, calidad del código, pair programming, pruebas, definition of done...
Si solo tenemos tiempo para producir líneas de código y tenemos que aprovechar las escapadas al baño para mover post-its de una columna a otra, lo único que tendremos será un bonito panel para las fotos, pero no habremos mejorado mucho más. Tendremos los post-its en la pared, pero también un par de ellos pegados en los ojos.
Cuando veo a algún equipo sobrecargado de historias de usuario, que va cayendo en la típica espiral de generación de código sin probar para llegar a fechas en una iteración, que seguirá igual en la siguiente, añadiendo el agravante de tener que resolver los bugs encontrados en la anterior... lo que veo es que tienen también post-its en los ojos. ¿No sería más fácil reconocer que la velocidad del equipo no es la esperada y replanificar las entregas? ¿No podríamos decir que en el primer sprint se ha visto que la velocidad estaba mal calculada? Seguro que habría alguna buena explicación como la falta de conocimientos funcionales, mayor complejidad técnica de la esperada, el equipo podría estar siendo menor a la previsión inicial, o simplemente la gripe podría haber desacelerado una tarea curso.
Si solo tenemos tiempo para programar, eliminamos las reuniones diarias porque nos quitan tiempo... es que también tenemos los post-its pegados en los ojos.
Si solo podemos pensar en por qué no se ha movido un post-it a la columna siguiente en lugar de eliminar las dificultades del equipo, no estaremos ayudando. Y significará que también tenemos los post-its pegados en los ojos.
viernes, 4 de febrero de 2011
viernes, 28 de enero de 2011
Kanban con departamentos externos
Es complejo trabajar con kanban cuando no tienes el control de todos los procesos. Muchas veces las tareas quedan paradas en una parte del proceso al depender de otros departamentos.
En nuestro caso, tenemos que realizar los despliegues vía tiquet a otro departamento. La resolución de los mismos no es inmediata. Esto hace que los límites de WIP (work in progress) no siempre puedan ser aplicables. No podemos mantener esas tareas dependientes en la columna de "En proceso" porque restan capacidad de trabajo, pero la dependencia de la acción del departamento externo en nuestro flujo de estados (para pasar la tarea al estado "En pruebas" después y luego al estado "Finalizado") hace que tengamos que guardar el estado de esa tarea. No podemos por tanto ni devolverla a la columna de Pendiente con alguna anotación añadida, ni dejarla En proceso.
Esta problemática hacía que me cuestionara la viabilidad de utilizar Kanban con el proyecto actual, hasta que he dado con una posible alternativa que a priori, resolvería esta casuística:
La solución que planteo es crear una nueva columna con el estado "Despliegue Externo", pero sin WIP. Esto nos permite poder mover allí todas las tareas que finalicemos en el estado previo "En Proceso", aunque se vayan acumulando. Como el departamento externo, podría llegar a realizar los despliegues en bloque, y necesitamos guardar el estado de desplegado, podemos crear 2 subcolumnas: "Pendiente" y "Desplegado". Con la 2º subcolumna creamos un pequeño buffer para poder retomar las tareas y continuar con los procesos de nuestro departamento.
En nuestro caso, tenemos que realizar los despliegues vía tiquet a otro departamento. La resolución de los mismos no es inmediata. Esto hace que los límites de WIP (work in progress) no siempre puedan ser aplicables. No podemos mantener esas tareas dependientes en la columna de "En proceso" porque restan capacidad de trabajo, pero la dependencia de la acción del departamento externo en nuestro flujo de estados (para pasar la tarea al estado "En pruebas" después y luego al estado "Finalizado") hace que tengamos que guardar el estado de esa tarea. No podemos por tanto ni devolverla a la columna de Pendiente con alguna anotación añadida, ni dejarla En proceso.
Esta problemática hacía que me cuestionara la viabilidad de utilizar Kanban con el proyecto actual, hasta que he dado con una posible alternativa que a priori, resolvería esta casuística:
La solución que planteo es crear una nueva columna con el estado "Despliegue Externo", pero sin WIP. Esto nos permite poder mover allí todas las tareas que finalicemos en el estado previo "En Proceso", aunque se vayan acumulando. Como el departamento externo, podría llegar a realizar los despliegues en bloque, y necesitamos guardar el estado de desplegado, podemos crear 2 subcolumnas: "Pendiente" y "Desplegado". Con la 2º subcolumna creamos un pequeño buffer para poder retomar las tareas y continuar con los procesos de nuestro departamento.
martes, 21 de diciembre de 2010
La presa se rompe siendo ágil
Cuántas veces hemos visto cambiar el modo de trabajo cuando un proceso en cascada queda bloqueado en una especie de presa y no se cumplen los plazos de entrega…
De pronto aparece un Product Owner que sabe exactamente qué es estrictamente necesario para salir a producción.
El gerente, repentinamente, comienza a hacer seguimiento diario de las tareas:
- ¿ya está acabada la tarea que tenías ayer?
- Hoy vas a hacer esto
- ¿qué problemas tienes para acabar la tarea?
El cliente se involucra al 100% validando la aplicación en cuanto le presentamos algo visible. Además está disponible 24x7 para resolver dudas (ahora le va el cuello en ello).
Los ciclos se vuelven rápidos y se presentan modelos cada semana o cada dos.
Todos estos cambios, sospechosamente se parecen a algunas prácticas implantadas en las metodologías ágiles. Por lo que yo me pregunto qué hubiera pasado si se hubieran utilizado estas técnicas desde el principio. Tal vez hacia el final del proyecto el equipo hubiera podido trabajar “solo” 8 horas.
lunes, 20 de diciembre de 2010
Refactorizando Proyectos
Hoy me han estado hablando de un proyecto que aparentemente utiliza SCRUM. En la propuesta comercial se ha vendido como metodología, y a los desarrolladores se les ha comentado que usan Scrum. He oido anécdotas bastante sorprendentes y me gustaría realizar mis primeras prácticas como Scrum Master aunque sea desde las sombras.
- Caso: El jefe de proyecto ha llamado a primera hora para suspender la reunión de seguimiento diaria (Daily stand up meeting o Daily Scrum). No iba a poder asistir
- Refactor: La base es el equipo, y la comunicación entre el mismo. Si el jefe de proyecto no puede asistir, el equipo debería seguir con la reunión. Sobretodo bajo el concepto de que un equipo de Scrum es autogestionado. Es más, debería aplicar la pertinente penalización a la persona que no ha asistido (flexiones, monedas en el bote, etc.) Otra cosa es que el Jefe de Proyecto haga las veces de Scrum Master (creo que en un proceso de adaptación de roles ese debería ser el rol del perfil). En ese caso me pregunto si se puede realizar un Daily Scrum sin Scrum Master. Es una gran pregunta que realizaré en los foros de Agile Spain, porque no tengo la respuesta.
- Caso: El proyecto tiene los perfiles de Jefe de Proyecto, Analista Funcional, y luego están los desarrolladores.
- Refactor: Habría que comentar que la traducción al castellano de Scrum es "Melé". Los equipos ágiles son equipos planos, sin roles jerárquicos.
- Refactor 2: La figura de analista funcional desaparece. Ese es un rol típico del diseño en cascada (Waterfall). Se profundiza en las defiiniciones funcionales antes de cada sprint.
- Caso: Me contaban que en una reunión para tomar una decisión de rediseño de la base de datos no permitieron la entrada al desarrollador responsable de la reimplementación.
- Refactor: las decisiones de arquitectura y diseño se realizan con todo el grupo, bajo el concepto de que la masa sabe más que el experto.
- Casos de estudio pendientes: me gustaría informarme sobre si se utiliza TDD para el desarrollo. Otras prácticas de XP como el trabajar 8 horas o el Pair Programming ya se que no. Me falta información sobre qué prácticas si se realizan para saber el grado de aproximación a Scrum.
Esto no pretende ser una crítica, sino un ejercicio de mejora, ya que cuesta implantar una metodología. Y cuesta mucho más seguirla después. En alguna ocasión he comentado que Ágil no quiere decir desorganizado. Las metodologías ágiles son incluso más rígidas que las tradicionales, en búsqueda de la calidad.
Solo espero que no piensen que los resultados del proyecto, el grado de satisfacción del cliente y sobretodo el del equipo se deban al uso de Scrum. Básicamente porque Scrum no se utiliza.
- Caso: El jefe de proyecto ha llamado a primera hora para suspender la reunión de seguimiento diaria (Daily stand up meeting o Daily Scrum). No iba a poder asistir
- Refactor: La base es el equipo, y la comunicación entre el mismo. Si el jefe de proyecto no puede asistir, el equipo debería seguir con la reunión. Sobretodo bajo el concepto de que un equipo de Scrum es autogestionado. Es más, debería aplicar la pertinente penalización a la persona que no ha asistido (flexiones, monedas en el bote, etc.) Otra cosa es que el Jefe de Proyecto haga las veces de Scrum Master (creo que en un proceso de adaptación de roles ese debería ser el rol del perfil). En ese caso me pregunto si se puede realizar un Daily Scrum sin Scrum Master. Es una gran pregunta que realizaré en los foros de Agile Spain, porque no tengo la respuesta.
- Caso: El proyecto tiene los perfiles de Jefe de Proyecto, Analista Funcional, y luego están los desarrolladores.
- Refactor: Habría que comentar que la traducción al castellano de Scrum es "Melé". Los equipos ágiles son equipos planos, sin roles jerárquicos.
- Refactor 2: La figura de analista funcional desaparece. Ese es un rol típico del diseño en cascada (Waterfall). Se profundiza en las defiiniciones funcionales antes de cada sprint.
- Caso: Me contaban que en una reunión para tomar una decisión de rediseño de la base de datos no permitieron la entrada al desarrollador responsable de la reimplementación.
- Refactor: las decisiones de arquitectura y diseño se realizan con todo el grupo, bajo el concepto de que la masa sabe más que el experto.
- Casos de estudio pendientes: me gustaría informarme sobre si se utiliza TDD para el desarrollo. Otras prácticas de XP como el trabajar 8 horas o el Pair Programming ya se que no. Me falta información sobre qué prácticas si se realizan para saber el grado de aproximación a Scrum.
Esto no pretende ser una crítica, sino un ejercicio de mejora, ya que cuesta implantar una metodología. Y cuesta mucho más seguirla después. En alguna ocasión he comentado que Ágil no quiere decir desorganizado. Las metodologías ágiles son incluso más rígidas que las tradicionales, en búsqueda de la calidad.
Solo espero que no piensen que los resultados del proyecto, el grado de satisfacción del cliente y sobretodo el del equipo se deban al uso de Scrum. Básicamente porque Scrum no se utiliza.
Suscribirse a:
Entradas (Atom)