A continuación, y de acuerdo con lo planteado, expondré una cuestión fundamental que debe decidirse a nivel de equipo de trabajo y de cada línea de trabajo encargada al equipo. La decisión es respecto a cómo se organiza el trabajo del equipo, es decir, cómo y cuándo se abordan los ítems pendientes . Ante esta decisión es muy importante no tener restricciones o sesgos que nos lleven a interpretarla como si estuviésemos ante la selección de un método ágil u otro (Kanban o Scrum).
Las dos alternativas básicas en cuanto a cómo se cogen los ítems desde el Backlog:
a) Sin agruparlos (sin cogerlos agrupados en un Sprint). El equipo, cuando puede abordar nuevo trabajo, simplemente lo coge del Backlog siguiendo el orden establecido.
b) Agrupándolos en Sprints, para los cuales se hace una previsión o compromiso de entrega, acorde con la capacidad del equipo. Idealmente, el equipo prepara los ítems de un Sprint antes de implementarlos, es decir, requiere definirlos y estimarlos previamente para contrastar el esfuerzo requerido respecto de su capacidad.
A primera vista, la lectura de (a) versus (b) podría parecer Kanban versus Scrum :-). Pero ¿por qué NO hay que tomarlo como la selección de uno de esos métodos?. Si se plantea en esos términos cerraríamos la posibilidad de mezclar prácticas (si nos pusiésemos "puristas" en la aplicación del correspondiente método), o por contraparte asumiríamos otras prácticas del método seleccionado que podrían no interesarnos. Más aún, puede que el método en su propuesta nos obligue a un nivel de aplicación de una práctica el cual no nos resulte factible o conveniente de implantar considerando el contexto actual del equipo.
Lo que es evidente es que en (a) basta con priorizar los ítems antes de abordarlos, y en (b) además de priorizar, se planifica acorde a la capacidad. En (b) se requiere algún mecanismo de estimación de los ítems y correspondientemente algún nivel de definición del ítem (al menos para poder establecer su estimación). PERO, lo anterior no descarta que en (a) pueda existir la conveniencia de definir y estimar (en alguna medida) los ítems antes de abordarlos, tampoco descarta en (b) la conveniencia de NO definir (ni estimar) en detalle los ítems antes de abordarlos. Es decir, el nivel de detalle en el cual se lleva a cabo la definición y estimación puede dar cabida a dichas actividades, independientemente de si la estrategia es concentrarse solo en generar flujo de entrega de trabajo terminado (enfoque Kanban), o si, además, se quiere realizar entregas de trabajo agrupado en sprints (enfoque Scrum).
En (a) podríamos NO tener todos los ítems necesariamente definidos y estimados antes de abordarlos. Así, en el caso (a) un ítem podría incluso alcanzar su prioridad y comenzar a ser abordado, y ya en ese momento definirlo y acordar con el cliente el detalle necesario. Sin embargo, en (b) lo ideal sería tenerlos todos definidos y estimados antes de abordarlos en un sprint. Así, en el caso (b) cuando un ítem esté próximo a ser incluido en un sprint sería conveniente definirlo en mayor detalle y estimarlo (por ejemplo, en Puntos u Horas Ideales) para poder hacer una previsión de si se conseguirá o no entregarlo en un sprint (considerando el resto de ítems que se incluirían en dicho sprint).
En cualquiera de los casos (a) o (b) es importante tener presente el riesgo que supone definir y estimar de forma anticipada ítems que no están comprometidos y/o que no formarán parte de una próxima entrega. Dicha definición y estimación puede quedar obsoleta, el ítem podría perder prioridad o incluso ser desestimado. En ambos casos también es importante que la posible descomposición o estructuración del trabajo asociado a un ítem de gran tamaño (Épica) también se postergue hasta que el ítem esté próximo a ser abordado por el equipo y ser entregado al cliente. Así pues, no nos debería incomodar tener ítems en el Backlog que no tengan una definición o estimación detallada (o que incluso no la tengan), ni que tengan un tamaño relativamente grande, mientras NO estén próximos a ser cogidos para ser implementados. Por ejemplo, se podría tener un ítem por un tiempo en el Backlog sólo con una breve definición y opcionalmente una estimación a priori (en Puntos, Tallas o algo similar) para advertirnos si se trata de una Épica.
Por otra parte, para abordar una Épica existen varias alternativas, por ejemplo, mantenerla como tal en el Backlog y de ella ir paso a paso derivando ítems más pequeños que se van abordando hasta finalizar la Épica, reemplazarla por un conjunto de ítems relacionados (que pueden corresponder a incrementos sucesivos y/o partes), o simplemente abordarla con más personas a la vez y de forma colaborativa.
Insistiendo en las mezclas de prácticas y su adaptación al contexto, a continuación comento escenarios que ilustran que aún en el caso (a) o (b) hay más variedad posible :-):
- Podría darse un caso (a) en el cual interese poder consultar el histórico del trabajo asociado a un producto o servicio, y para esto sea conveniente definir sprints a posteriori, es decir, que una vez ya entregados los ítems, que éstos queden agruparlos bajo el nombre de un Sprint (por tener asociado un período de tiempo y/o la versión del producto en la cual se entregaron ciertos ítems).
- Podría interesar disponer de estadísticas de tiempos invertidos en actividades asociadas al trabajo en los ítems, y por esto, independiente del caso (a) o (b) podrían registrarse dichos tiempos, para luego ser explotados estadísticamente (por ejemplo, para calcular la capacidad en horas del equipo).
- Podríamos estar en el caso (b), y además, disponiendo de flexibilidad (y complicidad con el cliente) respecto del alcance del Sprint (ítems incluidos en el Sprint), los ítem podrían ser definidos y estimados de forma muy preliminar antes de comenzar el Sprint, y luego durante el Sprint asumir que podrían algunos de ellos no alcanzarse a implementar y tener que ser devueltos al Backlog, o considerados para el siguiente Sprint.
- Quizás la mezcla más evidente (y comúnmente aplicada) es la de utilizar un Scrumboard cuando se trabaja con Sprints. Scrum en su propuesta original no ofrece ningún mecanismo para la visualización del trabajo dentro del Sprint, debido a esto es muy recomendable siempre usar un tablero kanban (que es el mecanismo básico del método Kanban). Esta mezcla tiene la denominación (más o menos aceptada) de Scrumban.
Una explicación detallada de como aprovechar la esencia del método Kanban (su tablero kanban) en el marco de un proceso iterativo la detallo en este post.
Patricio Letelier
No hay comentarios:
Publicar un comentario