lunes, 20 de mayo de 2013

Curso Métodos y Prácticas Ágiles: Material para profesores

El propósito de este post es compartir mi experiencia en enseñanza de métodos ágiles, es lo que he venido aplicando y refinando en la ETSInf (Escuela de Informática) de la Universitat Politècnica de València, en el Grado de Ingeniería Informática. Gran parte de este material también es utilizado en cursos y talleres dirigidos a empresas y en múltiples seminarios en España y Sudamérica. NO se trata de un curso para autoaprendizaje, mi interés es poder establecer contactos y colaboraciones con otros profesores que están enseñando o están interesados en comenzar a enseñar métodos ágiles
Este enfoque de enseñanza de métodos ágiles se viene refinando desde el año 2000, en docencia , investigación y aplicación en proyectos de desarrollo y asesorías en mejora de procesos. En 1998 ya enseñaba RUP, y a partir de 2002 incorporé Extreme Programming, y más tarde Scrum, Kanban y Lean Development. La estrategia docente desarrollada tiene una marcada orientación hacia la implantación de prácticas ágiles. Si bien se hace hace una breve introducción a los métodos ágiles más populares, gran parte de la asignatura está dedicada a explicar prácticas ágiles (independientemente del método del cual provengan) mediante actividades prácticas, y en paralelo ir aplicándolas en un proyecto de trabajo en equipo. 

Si bien existe en internet y en libros mucha información relativa a métodos ágiles, el material que utilizo no es una mera recopilación de esos contenidos. Las características más destacables de mi planteamiento docente son:
  • Se ofrece una visión global del proceso software aunque centrándonos mayoritariamente en métodos ágiles, con un discurso objetivo y crítico respecto de las ventajas, inconvenientes y desafíos del enfoque ágil.  
  • Se presentan los conceptos y prácticas de Kanban, Lean Development, Scrum y Extreme Programming, pero más que enfatizar los métodos resaltamos las prácticas que hay detrás de los métodos, pues considero más importante el conocer el conjunto de prácticas ágiles y aplicarlas que el enseñar un método ágil concreto. (ver Carta de Prácticas Ágiles).
  • Se da mucha importancia a la estrategia de implantación de prácticas ágiles, ofreciendo pautas al respecto. (ver ¿Revolución o evolución hacia el agilismo? y AGILEV Roadmap)
  • Si bien se explican las diferencias del enfoque ágil respecto del tradicional, no se insiste en el enfrentamiento ágil-tradicional, incluso se deja abierta la posibilidad de realizar mezclas de prácticas ágiles con algunas provenientes del enfoque tradicional.   
  • Se incluyen numerosas actividades y ejemplos para ilustrar las prácticas ágiles, las cuales se han integrado con los contenidos teóricos ofrecidos a lo largo de la asignatura.
  • Con mis colaboradores hemos desarrollado Worki, una herramienta para gestión ágil de equipos de trabajo (Ayuda en línea de Worki), que está totalmente alineada con nuestro planteamiento, aunque esto no impide que pueda utilizarse otra herramienta.
Nuestras asignaturas actuales en el Grado en Informática son Proceso del Software (PSW) y Proyecto de Ingeniería de Software (PIN), ambas en la rama de Ingeniería del Software (ver artículo presentado en JENUI 2013 donde se describe nuestra estrategia docente). En PSW proporcionamos los conceptos e ilustramos las prácticas ágiles, además, trabajando en equipos de 4 alumnos se lleva a cabo la exploración y planificación de un producto software, llegando hasta establecer un Backlog y preparar un primer Sprint de desarrollo (solo se llega a definir las unidades de trabajo con sus bocetos y pruebas de aceptación, no se implementan). El profesor desempeña el rol de cliente y de instructor para cada uno de los equipos. La asignatura PIN se imparte en el cuatrimestre inmediatamente siguiente y están matriculados los mismos alumnos de PSW. En PIN se trabaja en equipos de 6-8 alumnos, y se asocia a cada equipo uno de los productos preparados en PSW. Así, en PIN los equipos realizan 3 Sprints para conseguir una primera entrega de su producto, aplicando en un contexto bastante realista las prácticas ágiles aprendidas en PSW. El profesor desempeña el rol de cliente y de instructor, y mantiene un estrecho contacto con los equipos, participando como cliente en la preparación y validación del trabajo, y como instructor proporcionando apoyo respecto de las prácticas ágiles aplicadas.

Si estás interesado en establecer una colaboración docente respecto en una asignatura dedicada desarrollo de software utilizando métodos ágiles ponte en contacto conmigo (letelier@dsic.upv.es), podrás contar con material, con el uso de Worki en tus clases y con mi apoyo para llevar adelante la "Transformación Ágil" de tu asignatura ;-).


Patricio Letelier

twitter.com/yopolt
linkedin.com/in/letelier
agilismoatwork.blogspot.com
www.tuneupprocess.com 

martes, 14 de mayo de 2013

Actividad: Ball Point Game. Ilustrando un proceso iterativo y su mejora continua


Esta actividad es una adaptación del juego creado por Boris Gloger  y de la explicación ofrecida por Declan Whelan. Este interesante y entretenido juego ilustra la dinámica de un equipo trabajando de forma iterativa y en mejora continua mediante retrospectivas. Para ilustrar  Scrum y su proceso iterativo prefiero otras actividades (ver Scrum + Kanban + conceptos Equipo Self-organizing y Cross-functional). Mi interés por esta actividad es más por lo que respecta al hábito y conveniencia de realizar mejora continua mediante reuniones de retrospectiva.

Esta actividad tiene una duración aproximada de 30 minutos.

INDICACIONES

El objetivo en el juego es pasar tantas bolas como sea posible a través de cada miembro del equipo en 2 minutos. Se contabilizará cada bola pasa a través de todos los miembros del equipo siempre que la primera persona que toque la bola sea también la última en tocarla. Se realizarán 5 iteraciones. Antes de cada iteración el equipo estimará cuántas bolas piensa que va a conseguir pasar hasta el final. Después de cada iteración se registrará el número de bolas conseguidas.

Material
Boris Gloger recomienda bolas de tenis pero podría hacerse con cualquier objeto que pueda ser lanzado con facilidad. Dependiendo de la cantidad de participantes, prever una cantidad adecuada para que no tengan que esperan demasiado a que les lleguen bolas (considerar que las bolas que llegan al final se contabilizan y se vuelven a poner en el circuito).

Reglas del Juego
- Casa bola debe pasar por todos los integrantes
- La bola debe pasar por el aire
- No pasar la bola al vecino a izquierda o derecha
- Integrante de inicio = Integrante de término
- Iteración = 2 min
- Tiempo entre iteraciones = 1 min
- Haremos 5 iteraciones
- Si la bola cae al suelo o no cumple alguna regla se computará un fallo


Guía de la actividad
- 2 min. para introducción
- 2 min. para comentar de normas
- 2 min. para preparar primer sprint
- Realizar 5 iteraciones:
          - Registrar la estimación del equipo
          - Registrar la mejora que se aplicará en el sprint (a partir del segundo sprint)
          - 2 min. de iteración
          - Registrar bolas conseguidas y fallos
          - Aproximadamente 2 min. de retrospectiva
- 10 minutos comentarios finales
Crear una hoja o transparencia para que las reglas del juego estén siempre visibles. 

Revisando la información en internet, vemos que Ball Point Game es usualmente realizada al principio de un curso o seminario de Scrum, principalmente con el propósito de "romper el hielo" entre los asistentes. Para ello solo se forma un equipo con todos los asistentes, esperando intencionalmente que se cree un cierto caos, lo cual también resulta divertido. En nuestro caso el propósito es diferente, nos centramos en destacar el valor de las retrospectivas (después de explicar métodos y prácticas ágiles, en un apartado de Mejora Continua). Así, para asegurarnos que exista posibilidad de realizar buenas retrospectivas, en las cuales todos tengan la posibilidad de participar, nuestra recomendación es que los equipos no tengan mucho más de 10 personas, así pues, realizamos el proceso en paralelo con varios equipos a la vez, yendo todos a la par en cuanto a tiempos, sprints e indicaciones. 

Preparar (para cada equipo) una tabla como la siguiente donde registrar los resultados de cada iteración.


Sprint
Bolas
Estimadas
Bolas Reales
Fallos
Mejoras
1




2




3




4




5





Asegúrese de disponer de un espacio suficiente para que el equipo pueda experimentar diferentes posiciones de sus integrantes.

Indicaciones adicionales
  • Que el instructor registre los resultados y complete la(s) tabla(s) de datos, así los equipos se concentran en los sprints y en las retrospectivas.
  • Recomendable usar StopWatch como cronómetro para la cuenta regresiva de 2 min. en cada sprint.
  • Cuando pregunten ¿se puede hacer tal cosa?, simplemente remitirlos la las reglas del juego diciendo  "es vuestro proceso”.
  • Recuerde registrar las mejoras que realicen en el proceso inmediatamente después de la retrospectiva.
  • Recuerde solicitar una estimación de bolas antes de comenzar cada sprint.
  • Al terminar el sprint antes de comenzar la retrospectiva dejar todas las bolas preparadas para el siguiente sprint, así el equipo estará centrado en la retrospectiva pensando en mejoras. 

COMENTARIOS FINALES

Algunos temas de debate:
  • ¿Qué iteración funcionó mejor?,  pero ¿qué entendemos por “mejor”?
  • ¿Se consiguió una mejora continua, fueron eficaces las retrospectivas?. Es importante valorar las reuniones de retrospectiva puesto que la mejora en productividad y calidad del trabajo, y compromiso y moral del equipo puede ser muy rentable respecto del tiempo invertido en dichas reuniones.
  • Establecer paralelismos entre Scrum y el Ciclo de Deming (Plan-Do-Check-Act).
  • Pull Systems. La mayoría de los equipos establecen de forma natural un Pull System, es decir, no se produce o avanza la producción si no hay demanda desde la parte que recibe bolas. En nuestro caso existe un límite para el WIP, correspondiente a cuántas bolas puede tener una persona en sus manos. 
  • ¿Qué tipo de liderazgo se generó, se tomaron en cuenta todas las ideas?. La energía o ímpetu por proponer mejorar puede llegar a generar conflictos. En el ámbito laboral intervienes otros factores asociados a las iniciativas de mejora, tales como: el reconocimiento, la recompensa, la autoridad, etc.
  • ¿Es siempre posible mejorar el proceso? ¿Existe un ritmo o velocidad natural en cada proceso?. Manteniendo una misma configuración en iteraciones sucesivas, por simple práctica,  se conseguirá mejorar los resultados y reducir los fallos. Sin embargo, sin hacer cambios, cada vez la mejora será menos significativa. Esto es normal, pues un sistema tiene un cierto rendimiento una vez alcanzado su estado de eficiencia, en el cual a menos que se introduzcan nuevos cambios, permanecerá estable y predecible. Es decir, esta situación de estabilidad en eficiencia no es mala, pero no debería llevarnos al conformismo o descartar la búsqueda de nuevas mejoras. Tampoco debemos estresar el sistema presionando por más velocidad de la que puede dar de forma natural.
  • Puede presentarse el caso en el cual con una nueva configuración se obtenga un resultado peor, incluso llegando a abortar la iteración si está siendo desastrosa. Esto no debería verse como un fracaso, es un aprendizaje :-) , y siempre podría volverse a una situación previa de la cual se conocía su desempeño.
  • Respecto de un trabajo de equipo real, la gran simplificación en este juego es que generalmente los ítems de trabajo (las bolas de este juego) no requieren el mismo esfuerzo para procesarlas. En desarrollo de software si dos o más ítems son exactamente iguales, solo se desarrollaría una vez y luego simplemente se reutilizaría. Sin embargo, en muchos casos el equipo se enfrenta a ítems de diverso tamaño y/o complejidad, es decir, el juego equivalente tendría bolas de distinto tamaño, peso, etc., con lo cual quizás el proceso debería adaptarse a las características de cada tipo de ítem.

INSTANTES DE LA ACTIVIDAD




sábado, 4 de mayo de 2013

¿Kanban or Scrum?: that is not the question

Un elemento clave en el éxito de un producto o servicio es la gestión de su Backlog. Independiente del método ágil, siempre tendremos que gestionar el trabajo pendiente y mantenerlo ordenado para facilitar la selección de ítems que el equipo debe abordar. Dicho ordenamiento debe considerar diversos criterios (lectura recomendada Gestión eficaz del Product Backlog). En este post quiero insistir en lo que está siendo un importante obstáculo para la implantación del agilismo en un equipo de trabajo, me refiero al hecho de intentar aplicar de forma excluyente las prácticas ágiles, pretendiendo hacer una implantación "purista" de un determinado método ágil. En varios post anteriores ya he comentado que la estrategia más sensata es seleccionar prácticas independientemente de su origen (sin importar de qué método provienen). Además, los diversos métodos ágiles presentan bastantes prácticas comunes o muy similares. Para no extenderme en explicar aquí esta estrategia recomiendo la lectura de Agile Roadmap. el primer paso para la implantación de prácticas ágiles.

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.
Espero que las reflexiones de este post contribuyan a dirigir el foco hacia la selección y adaptación de prácticas, más que a la selección de métodos, y por último, os recomiendo que hagáis vuestra auto-evaluación de prácticas ágiles, de forma on-line y utilizando nuestra herramienta AGILE Roadmap.

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