Este mismo razonamiento debes realizar si estás planteándote cambiar la forma de trabajo de tu departamento de desarrollo para adoptar alguna práctica ágil. Definir qué pretendes obtener en su aplicación es de vital importancia puesto que una u otra práctica tienen "prescripciones" diferentes y por tanto te llevarán a distintas metas.
En este post repasaremos las metas que David J. Anderson en [1] "promete" que podemos alcanzar a través de la aplicación del método Kanban a nuestro proceso de desarrollo de software. Mi opinión personal, después de su aplicación en equipos de desarrollo, es que sí son metas realistas. Probablemente ninguna de estas metas debieran ser fuerzas motrices de tu cambio, pero estarás de acuerdo conmigo que no te hará ningún daño alcanzarlas.
1. Optimizar el proceso existente.
De las ocho esta es la principal puesto que si están afrontando el esfuerzo (los cambios siempre tienen un coste) de cambiar la forma de trabajar de un equipo es porque te interesa mejorar esta forma de trabajo y esto es el proceso. El método Kanban es un agente facilitador que te permite optimizar gradualmente tu proceso, sin cambios disruptivos en la forma de trabajar del equipo ni duros procesos de reingeniería (algo que normalmente genera rechazo).
2. Entregar con Alta Calidad.
Kanban permite establecer claros criterios de calidad como políticas definidas del tablero. No es algo que se deba realizar en la primera semana de aplicación pero gradualmente se pueden incluir esas políticas que "obliguen" a todos los miembro del equipo, por ejemplo, a verificar que no rompemos la Build ni ningún test automatizado antes de poder poner en HECHO una tarjeta o la necesidad de mantener o bajar las alertas de análisis estático de código.
3. Mejorar la predictibilidad de nuestros tiempos de entrega.
Debes tener claro que el mero hecho de limitar el trabajo en curso (WIP) acorta los tiempos medios de entrega. Pero si además de limitar el trabajo reduzco suficientemente bien los tamaños de los trabajos y dispongo de una estimación razonable del esfuerzo de desarrollo de esos trabajos, un vistazo a la situación del tablero y a los tiempos medios de entrega (Lead Time) y de ingeniería (Cycle Time) me permitirán predecir (sin necesidad de bola de cristal) un rango de entrega suficientemente razonable.
4. Mejorar la satisfacción del equipo
Si tu equipo está muy acostumbrado al estrés, a las prisas, a los cambios de foco, notarás que el sólo hecho de limitar el trabajo y definir una serie de medidas objetivas de rendimiento mejora notablemente su satisfacción.
5. Generar “tiempo-libre” para posibilitar la innovación
Como ya comentamos en KANBAN, el origen: The Goal (Theory of Constraint) la definición de diferentes políticas, la limitación del trabajo en curso y la gestión de los cuellos de botella pueden generar tiempos "ociosos" en los miembros de tu equipo. Aprovechar este tiempo libre individual puede ser altamente beneficioso para el grupo y la organización en su conjunto si se reorienta adecuadamente (ver el ejemplo de Spotify comentado en el post de The Goal para más detalles).
6. Simplificar la priorización de los trabajos
La fácil visualización del trabajo (en curso, bloqueado y pendiente), las políticas establecidas en cuanto a los límites del trabajo en curso y la clasificación de los distintos tipos de trabajos nos permitirá, atendiendo a los datos históricos de rendimiento del equipo, priorizar los trabajos de forma prácticamente automática. Si los objetivos y políticas están bien definidos, esta priorización puede ser incluso delegada al propio equipo... Hmm, sí, estoy convencido de que un equipo de ingenieros del software llevan a cabo a diario tareas más difíciles que el seguir unas políticas bien predefinidas para priorizar el trabajo a realizar... si eras tú el que anteriormente hacías ese trabajo...ahora dispones de más tiempo para pensar en otras mejoras...
7. Proporcionar transparencia sobre el proceso y su funcionamiento
Si el método tiene un desempeño correcto, tanto el equipo de desarrollo como el resto de agentes que se relacionan con él (gerencia, operaciones u otros equipos de desarrollo) comprenderán el resultado de sus acciones y evitarán interferir en el buen funcionamiento de la "cadena de montaje", que a su vez es parte de un engranaje mayor (el resto de cadena de valor de la organización) que se verá beneficiada en su conjunto. La gerencia será más consciente de que añadir un trabajo extra al equipo implica superar sus límites de trabajo (demostrados con el tiempo como eficientes) y se cuidará de hacerlo sin un buen motivo (manteniendo al equipo dentro de su foco). Otro equipo de desarrollo y operaciones verá fácilmente las implicaciones que el retraso de alguna de sus tareas conlleva a otro equipo al observar los bloqueos existentes (de hecho, solucionar estos conflictos debe ser prioritario entre las tareas de una gerencia efectiva).
8. Creación de una cultura de mejora continua (esta meta está ligeramente modificada a la planteada por Anderson)
La visualización del proceso y la constante revisión de indicadores, políticas y prácticas unido con el poder que se le debe dar al equipo para definir y modificar su propio proceso hace que comience a emerger la idea de una cultura de mejora continua. El equipo ya no sólo se preocupa de completar tareas para desarrollar nuevos productos o mantener los existentes sino que se replantean continuamente cómo podrían hacerlo un "poquito mejor" la próxima semana: ¿cambiando el límite de la columna de aceptación? ¿añadiendo una de revisión de código? ¿automatizando el proceso de despliegue? ¿reduciendo el tamaño de las tareas? Pequeños pero continuos cambios que hace que el motor suene cada vez mejor.
Sea cual sea tu motivación para el cambio estarás de acuerdo que si Kanban te viene con este equipamiento de serie, al menos es para pensárselo. Como deberías ser cauteloso ante este tipo de ofertas-ganga te dejo el resultado de una pequeña encuesta sobre estos mismos puntos a un equipo de desarrollo tras meses de aplicación. No se trata de Yahoo, Google, Spotify o cualquier otra empresa de las que estamos acostumbrados a escuchar enarbolando la bandera de la agilidad, sino un pequeño equipo de desarrollo dentro de una gran estructura tradicional.
La encuesta es muy básica, una vez explicados los puntos anteriores se le preguntó a cada miembro del equipo que evaluara el grado de consecución de los objetivos en un rango de 0-10. Estos son los resultados, saca tus propias conclusiones.
[1] Anderson, David J. (2010) Kanban: Successful Evolutionary Change for Your Technology Business, Blue Hole Press.
No hay comentarios:
Publicar un comentario