Roles de Scrum - Parte I: Responsabilidades involucradas

En esta Parte I me centraré en explicar brevemente la motivación de este par de posts y presentaré la definición de los roles de Scrum. En la Parte II explicaré nuestra estrategia para implantar los roles de Scrum.

Si bien existen innumerables referencias y definiciones a los roles de Scrum poco se comenta respecto de cómo llevarlos a la práctica. Por lo visto existe una idea generalizada que basta con formación (y certificación) para conseguir gente que desempeñe eficazmente dichos roles. Además, se pasa por alto el desafío que significa migrar a las personas desde sus roles actuales. No se trata sólo de una cuestión de estrategia para convencer de las bondades del agilismo o de cómo enfrentar a quienes puedan estar en contra explícita o implícitamente de la implantación del agilismo. Conseguir que un equipo sea  self-organizing puede ser más o menos difícil, pero conseguir que un equipo sea cross-functional con miembros que no están preparados para (ni dispuestos a) abandonar sus "títulos" correspondientes a sus roles fijos, esto sí que puede ser un gran desafío.

De entre los tres roles de Scrum, el que se lleva la palma en cuanto a polémica a su alrededor es el Product Owner. Recomiendo los siguientes post para así ahorrarme el contar en detalle la problemática asociada: The Product Owner Problem, The Mythical Product Owner role.

A continuación se presenta la definición del los roles de Scrum, extraida y traducida desde la Scrum Guide (octubre de 2011).

Product Owner (PO)
Es responsable de  gestionar el Product Backlog, lo cual incluye:

• Expresar claramente los items del Product Backlog
• Ordenar los items del Product Backlog para conseguir objetivos y misión del producto
• Asegurar el valor del trabajo que realiza el Development Team
• Asegurar que el Product Backlog es visible, transparente, y claro para todos, y mostrar en qué es lo que trabajará próximamente el Scrum Team 
• Asegurar que el Development Team entiende los items contenidos en el Product Backlog

El PO debe hacer respetar sus decisiones en la organización y proteger al Development Team de las solicitudes o influencias de los stakeholders

Scrum Master (SM)

Es responsable de asegurar que Scrum es entendido y aplicado. El SM es un sirviente-líder para el Scrum Team.

Servicios del Scrum Master para el Product Owner

• Encontrar técnicas para la gestión efectiva del Product Backlog
• Ayudar a comunicar claramente la visión, objetivos e ítems del Product Backlog al Development Team
• Enseñar al Development Team a crear ítems claros y concisos en el Product Backlog
• Ayudar a comprender la planificación a largo plazo en un ambiente empírico
• Ayudar a comprender y aplicar agilidad
• Apoyar durante el sprint y las reuniones según se le requiera o sea necesario

Servicios del Scrum Master Service para el Development Team

• Entrenar en self-organization y cross-functionality
• Enseñar y dirigir hacia la creación de productos de alto valor
• Eliminar los impedimentos para su avance en el trabajo
• Apoyar durante el sprint y las reuniones cuando se le pida o sea necesario
• Entrenar para enfrentar ambientes organizacionales en los cuales Scrum aún no ha sido completamente adoptado y entendido

Servicios del Scrum Master para la Organization

• Liderar y entrenar la adopción de Scrum en la organización
• Planificar implantaciones de Scrum dentro de la organización
• Ayudar a los empleados y usuarios a comprender  e implantar Scrum y el desarrollo empírico de productos
• Provocar cambios que aumenten la productividad del Scrum Team
• Trabajar con otros Scrum Masters para incrementar la efectividad de la aplicación de Scrum en la organización

Development Team

• Es self-organizing. Nadie (ni siquiera el Scrum Master) le dice cómo convertir el Product Backlog en un incremento de funcionalidad potencialmente entregable
• Es cross-functional, tiene como equipo todas las habilidades necesarias para crear un incremento del producto
• No tiene títulos más que el de Developer, independiente del trabajo que esté realizando la persona, no hay excepciones a esta regla
• Los miembros pueden tener habilidades y áreas de especialización pero ellas cuentan para el Development Team como un todo 
• No contienen sub-teams dedicados a dominios particulares como testeo o análisis de negocio
• Tiene entre 3 y 9 miembros (obviamente sin contar el PO y SM)

Si el equipo es de nueva formación, si sus miembros tienen conocimiento y experiencia en métodos ágiles o bien si tienen la habilidades y motivación para iniciarse en el agilismo, y si las condiciones de contexto cliente-producto son favorables para el agilismo, con todo ello, la opción más interesante sería implantar Scrum a fondo en el equipo. Sin embargo, dicho entorno propicio para el agilismo suele ser una excepción, con lo cual una estrategia de revolucionaria conllevaría riesgos importantes e incluso podría ser contraproducente de cara a conseguir un cambio sostenible en el proceso de desarrollo de software. Así pues, en la Parte II de este post comentaré nuestra estrategia evolutiva para implantar estos roles en un equipo que ha trabajado hasta ahora con roles y bajo un entorno de caracter más tradicional.

Patricio Letelier

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

Gestión "Ágil" de Requisitos

Esta es la tan recurrida imagen usada para explicar la motivación de la Ingeniería de Requisitos. Es simplemente una exageración de lo que puede ocurrir en términos de degradación de una especificación cuando es transferida y manipulada secuencialmente entre diferentes participantes en un proyecto. En el contexto del desarrollo de un producto software esto tiene mayor probabilidad de ocurrir mientras más secuencial sea el proceso de desarrollo, mientras más personas distintas intervengan en la cadena de producción y mientras menos puntos de validación se establezcan (validación se refiere a comprobar que el producto satisface las expectativas del cliente, es decir, cumple con los requisitos acordados con el cliente).

La solución de la Ingeniería de Requisitos clásica está centrada en la especificación y validación temprana del producto. Por temprana me refiero a antes de programar :-). Esta validación tiene así un gran inconveniente, el cliente no validará respecto de un producto construido sino que lo más real o cercano que tendrá serán prototipos. Esto es así porque la Ingeniería de Requisitos tradicional en general asume un proceso en cascada, en el cual las actividades de análisis o especificación de requisitos coinciden con un período del proyecto, lo cual se delata cuando se denomina "Fase" de Análisis o similar.

La situación es bastante diferente cuando el modelo de proceso es iterativo e incremental, modelo en el cual se basan todas las propuestas metodológica modernas (sean ágiles o tradicionales). Sin embargo, se suele asociar a las metodologías tradicionales con un modelo de proceso en cascada porque desafortunadamente en muchos casos se aplican de esta forma. En un proceso iterativo e incremental el trabajo de desarrollo se divide ítems los cuales se agrupan en iteraciones (sprints), cuyo resultado es un incremento del producto que incluye cambios respecto de la versión previa. La actividad de especificación de requisitos está presente en cada uno de los ítems de trabajo, y  convenientemente se podría realizar en cualquier momento antes de pasar el ítem a una iteración para ser implementado. La especificación de requisitos no se debería concentrar en un período del proyecto, es decir, no habría una "fase de Especificación de Requisitos", sino más bien la actividad Especificación de Requisitos se realiza continuamente preparando ítems antes de que se implementen en una iteración. Así pues, los ítems que se incluyen en una iteración deberían estar idealmente ya definidos (especificados sus requisitos). Pues bien estos ítems en métodos ágiles corresponden usualmente con las denominadas Historias de Usuario. Aunque la literatura respecto de Historias de Usuario está un tanto sesgada respecto de asociar una Historia de Usuario con un "Nuevo Requisito", lo cierto que en el contexto de una iteración las Historias de Usuario también pueden representar "Mejoras" o incluso "Correcciones de fallos" en requisitos ya implementados.

El reconocer dichos diferentes tipos de Historias de Usuario ("Nuevo Requisito", "Mejora" o "Corrección de fallo") nos lleva directamente a entrar en "Gestión de Requisitos". La especificación de requisitos no es estática, va evolucionando en la medida que el comportamiento del producto lo hace. Es en este punto en el cual los métodos ágiles "renuncian" a la gestión de los requisitos una vez implementados en el producto. Con esto me refiero a que una vez que una Historia de Usuario (del tipo que sea) se implementa en una iteración, simplemente se tira a la papelera su especificación, o si se guarda, es sólo por una cuestión de registro histórico. Es decir, el comportamiento asociado a un requisito implementado y posteriormente mejorado o corregido debe averiguarse yendo directamente al código y la base de datos. No me consta que en alguno de métodos ágiles más populares se proponga almacenar y gestionar las Historias de Usuario ya implementadas con el propósito de servir de especificación actual del comportamiento del producto, puesto que de ser así debería realizarse algún tipo de síntesis de todas las Historias de Usuario asociadas a un requisito, desde su origen hasta la actualidad, pasando por todas sus mejoras y correcciones (no solo tener una colección de pos-it :-) ).

El tener que acudir al código y base de datos para conocer el comportamiento actual del producto podría no ser un gran problema si todo el equipo se desenvuelve a nivel de programación, pero muchas veces esto no ocurre. Además, el mismo cliente querría saber con precisión el comportamiento del producto. Ojo que dicha precisión no suele ser ofrecida por un Manual de Usuario, porque un manual debe orientar a un usuario para sacarle provecho al producto, no es su propósito describir en detalle la lógica asociada a cada funcionalidad del producto. Sin embargo, en mi opinión el disponer de una especificación de requisitos actualizada y más abstracta que la implementación se hace más necesaria aún cuando la envergadura o complejidad del producto es significativa, cuando difícilmente un miembro del equipo es capaz de conocer toda la funcionalidad del producto ni puede fácilmente investigar en código el impacto de los cambios.

Podríais pensar que después de lo comentado voy a apostar por gestión de requisitos "clásica", pues no! :-), ya que tampoco la gestión de requisitos clásica (en mi opinión) aborda de forma satisfactoria la evolución de la especificación de requisitos. Preguntadle a quienes utilizan Casos de Uso y Matrices de Trazabilidad si consiguen de manera efectiva y eficiente (a un costo razonable) mantener actualizadas sus especificaciones de requisitos :-). Si respondieran que están satisfechos sospecharía que no utilizan un proceso iterativo e incremental, o que tienen la suerte de desarrollar software en un contexto donde no hay cambios en los requisitos durante la construcción del producto, o donde el producto no tiene mantenimiento. Dicho contexto no creo que exista, al menos para un producto que tiene usuarios aprovechándolo.

Llegados a este punto no os voy a dejar sin una propuesta de solución :-), que sea factible y coherente con los métodos ágiles. En nuestro caso, desde que comenzamos a experimentar y aplicar métodos ágiles nos dimos cuenta del potencial que tenían las Pruebas de Aceptación (PAs) como especificación de requisitos, XP ya proponía derivar PAs para cada Historia de Usuario y utilizarlas como criterio de éxito de su implementación. En realidad la idea ya existía y es en sí el concepto de PA de toda la vida :-). Después de ver cómo en la medida que queríamos ser precisos en la descripción de una Historia de Usuario en su texto comenzaba a incluirse la lógica que debería derivarse posteriormente en términos de PAs. Así, resultó evidente que en lugar de hacer descripciones "novelescas" para Historias de Usuario era mejor escribir ese detalle directamente como PAs. De esta forma, para cada ítem de trabajo en una iteración, sea del tipo que sea (nuevo requisito, mejora o corrección), establecemos una descripción muy breve (y opcional), hacemos bocetos de interfaz cuando corresponde y básicamente nos centramos en definir PAs (incluso a veces, y puntualmente, utilizamos modelos). Con esta estrategia estamos "matando dos pájaros de un tiro", conseguimos un adecuado nivel de precisión en la definición de la Historia de Usuario y evitamos que posteriormente se tenga que hacer una interpretación adicional para extraer las PAs para poder realizar dichas pruebas. Pero esto solo es una parte, pues además teníamos que facilitar la gestión de los requisitos ante los cambios. En nuestro enfoque donde los requisitos están basados en PAs, para cada producto se establece una  estructura de grafo cuyos nodos representan requisitos, siendo cada uno de ellos un contenedor de PAs que definen el comportamiento del requisito. Así pues la gestión de requisitos se integra en el desarrollo iterativo e incremental de forma natural de la siguiente forma: cada ítem (Historia de Usuario) de una iteración se define como un cambio en la estructura de requisitos, con lo cual cada ítem puede implicar añadir, eliminar o modificar nodos, y correspondientemente añadir, modificar o eliminar PAs en dichos nodos. A nuestro enfoque lo denominados Test-Driven Requirement Engineering (TDRE) y está descrito en detalle en un artículo que publicamos en las JISBD en el 2010. El resto de la historia y los detalles corresponden a cómo hemos hecho realidad esta propuesta ofreciendo un soporte para ella en nuestra herramienta TUNE-UP Process. En el siguiente enlace puedes ver algunos ejemplos de pruebas de aceptación gestionadas en el contexto de un producto software como esencia de la especificación de requisitos.

En resumen, en mi opinión la única forma viable de gestionar los requisitos en un producto que está en continuo cambio (por estarse desarrollando iterativamente o por estar en mantenimiento) es que dicha gestión de requisitos esté totalmente integrada en la gestión del producto (en su planificación y desarrollo iterativo e incremental). Además, identificar y definir progresivamente las PAs de un cambio como parte esencial de la correspondiente especificación de requisitos resulta más rentable que invertir esfuerzo en otras formas de especificación detallada, pues de partida nos ahorra el esfuerzo de derivar PAs desde esas otras especificaciones.

Lectura recomendada: un post relacionado con este ¿Cuál y cuánta documentación/especificación es suficiente?.


Patricio Letelier

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

Estimación en un proyecto ágil, Parte I: Una estrategia pragmática

Esta figura representa lo que se denomina el "Cono de la Incertidumbre" e ilustra cómo la variabilidad en las estimaciones de esfuerzo se va reduciendo en la medida que nos adentramos en la implementación.

Este post no pretende ser un tratado de la estimación en proyectos, sólo me centraré en las técnicas más populares y que están más en sintonía con el enfoque ágil. Para tener una visión global de estimaciones en proyectos de software recomiendo el libro Software Estimation de Steve McConnell y en el caso específico de métodos ágiles mi sugerencia es el libro Agile Estimating and Planning de Mike Cohn. Desafortunadamente. Si bien estos libros son muy interesantes, considero que en la práctica aún quedan cuestiones por resolver, y esto es precisamente lo que me ha motivado escribir este post.

Estimar el esfuerzo asociado cada ítem de trabajo antes de abordarlo es en sí un esfuerzo y debería ser rentabilizado. A continuación se indican algunos beneficios que podríamos obtener de la estimación de ítems.

• Establecer un plan coherente en cuanto a equilibrar esfuerzo requerido versus Capacidad del equipo para abordarlo en un determinado tiempo.
• Prever decisiones, alternativas y/o desafíos asociados a dicho trabajo. Al estimar siempre, en alguna medida, estamos adentrándonos en el conocimiento del ítem.
• Tener un factor adicional para considerar al momento de seleccionar trabajo. Por ejemplo, realizar cuanto antes un trabajo porque requiere muy poco esfuerzo, o buscar el momento adecuado para llegar a cabo un trabajo que requiere mucho esfuerzo.   
• Realizar el seguimiento del trabajo restante, contrastando el progreso del trabajo respecto de la estimación, o simplemente descontando el esfuerzo estimado de un ítem una vez éste se haya terminado. 

Siguiendo un enfoque ágil, para la estimación del esfuerzo tenemos varias alternativas. El equipo de trabajo, para CADA uno de sus líneas de trabajo, debería elegir la alternativa de estimación que mejor se ajuste. A continuación se comentan algunas alternativas o aspectos que deben considerarse.

1. NO estimar. Si no existe compromiso de entrega o si éste es flexible podemos permitirnos no estimar el trabajo. El contexto más sencillo para el el enfoque ágil es aquel donde el equipo de tiene una estrecha colaboración con el cliente, y cuando se presentan cambios en los requisitos, el cliente entiende y acepta las modificaciones respecto de lo previsto. En este contexto ideal, las ventajas de estimar se diluyen puesto que, si bien pueden existir entregas frecuentes, ellas pueden modificarse sobre la marcha en cuanto a su alcance, plazos o recursos. Así, el plan se transforma en una hoja de ruta sin constituir un compromiso cerrado. Por otra parte, si no se trabaja en el marco de Sprints o Proyecto sino que el trabajo se aborda según va llegando (priorizándolo respecto del trabajo pendiente), la necesidad de estimar se hace prescindible. En caso de NO estimar, ya no hay que tomar más decisiones al respecto :-).
2. Estimar "a ojo". Si existe un compromiso flexible se puede hacer una estimación superficial del esfuerzo en conjunto del trabajo que se pretende abordar. Correspondientemente, dicho esfuerzo intuitivo puede contrastarse con la capacidad del equipo (percibida informalmente). Esto básicamente es preguntarse si podemos o no abordar un cierto conjunto de trabajo para un determinado tiempo de entrega. Si bien esta alternativa no ofrece una argumentación cuantitativa para establecer un compromiso, para un equipo experimentado puede ser bastante certera. Buscando siempre la sencillez, si esta alternativa es suficientemente efectiva no habría que descartarla.
3. Estimar usando alguna unidad de medida para el esfuerzo. Las unidades más usadas son Puntos, y Horas Ideales. La unidad de estimación del esfuerzo debe ser la misma que se utilice para medir la Capacidad del equipo. Los Puntos son una medida de tamaño relativa entre ítems de trabajo, es decir, se establece un ítem de referencia con ciertos Puntos y el resto de ítems se valoran en Puntos comparándolo con el ítem de referencia. Los Puntos son una valoración global del tamaño asociado a un ítem de trabajo, es decir, no diferencian esfuerzo en las diferentes actividades que deben realizarse sobre un ítem. Las Horas Ideales son horas ininterrumpidas de trabajo, no coincidirán con las horas cronológicas u horas de contrato. Por ejemplo, 8 horas ideales puede que se realicen en varios días de trabajo, aunque la persona encargada por contrato trabaje 8 horas diarias. Un programador con un contrato de 40 horas por semana, posiblemente no llegará a programar mucho más de 30 horas netas por semanas, con lo cual éstas serían su Horas Ideales de programación por semana. Las Horas Ideales, a diferencia de los Puntos, conviene que se asocien a un determinada actividad. Usando Horas Ideales, la Capacidad de un equipo se puede medir, por ejemplo, en Horas Ideales de programación por semana. Así pues, si tenemos un conjunto de ítems de trabajo que se estima que suman 500 Horas Ideales de programación, y tenemos un equipo con una Capacidad de alrededor de 200 horas de programación por mes, podríamos afirmar que dicho trabajo se podría abordar en alrededor de 3 meses (considerando un margen de holgura de medio mes). Cuando se usan Horas Ideales podríamos tener estimaciones para cada actividad por la que pasará un ítem, por ejemplo, análisis, diseño, programación, pruebas, etc. Correspondiente mente la Capacidad del equipo podría estar descompuesta en cada una de dichas actividades. Sin embargo, el esfuerzo asociado a conseguir este detalle probablemente no aportará mayor precisión ni utilidad. Mi recomendación es centrarse en una actividad (o poco más), aquella que suela ser la más limitante en el proceso de los ítems, en aquella que suele faltar capacidad del equipo. Por ejemplo, en desarrollo de software recomiendo usar de partida la estimación y la Capacidad referida a la actividad de Programación. 
4. Seguimiento basado en estimaciones. Una vez iniciado el trabajo, las estimaciones nos pueden ayudar a monitorizar el progreso del trabajo. La pregunta clave del seguimiento es ¿llegaremos a cumplir nuestro compromiso?, y en cualquier momento el equipo podría responderla contrastando la estimación del trabajo restante con su Capacidad desde ese momento hasta la fecha de entrega. En caso de utilizar Puntos el esfuerzo restante es la suma de Puntos de todos los ítems no terminados. Hay que destacar que en este caso los Puntos de un ítem se descuentan solo cuando el ítem está terminado, es decir, no se hacen descuentos parciales. No tiene sentido preguntarse cuántos Puntos quedan para terminar un ítem. En caso de usar Horas Ideales el esfuerzo restante puede establecerse de dos formas:  a) como la diferencia entre el esfuerzo estimado y el esfuerzo ya invertido, o b) como el esfuerzo estimado restante establecido en cada momento. Por ejemplo, si un ítem se estimó en 10 Horas Ideales de programación y ya se han invertido 6 horas, se esperaría que el esfuerzo restante sea de 4 Horas Ideales de programación. La otra alternativa es que al finalizar una jornada de trabajo si se estuvo trabajando en un ítem y no se terminó, se haga una estimación de las Horas Ideales restantes para terminarlo. En cualquier caso, la re-estimación de ítems es importante, si en cualquier momento se sospecha que una estimación no es apropiada debe actualizarse. En el enfoque ágil el seguimiento cuantitativo de un compromiso de trabajo se visualiza utilizando una Gráfica Burndown. 
5. Estimar ítems de trabajo y/o tareas asociadas al ítem. Debe decidirse si la estimación se llevará sólo a nivel de los ítems de cambios acordados con el cliente (p.e. Historias de Usuario) o también se computará a nivel de tareas (unidades en las cuales el equipo puede descomponer dichos cambios, usualmente asociado a trabajo en partes de la arquitectura interna del producto). En términos generales sugiero NO dividir los ítems en tareas, normalmente tampoco es necesario puesto que si los ítems son pequeños pierde sentido el dividirlos aún más. Trabajar con dos niveles de estimación (ítem y tareas del ítem) complicará la gestión, especialmente cuando el número de ítems y/o tareas es alto. Además, al trabajar en estos dos niveles, debería mantenerse coherencia entre la estimación de ítem y la suma de estimaciones de sus tareas. 

Una cuestión que parece estar consensuada es que en el contexto ágil la estimación se hace mediante "el juicio del experto", es decir, la decide el equipo que ejecutará el trabajo, de forma individual o consensuada con todo el equipo de desarrollo (p.e. usando la técnica Planning Póker).

Este post continua en "Estimación en un proyecto ágil: Parte II, Algunas diferencias respecto de estimación tradicional".


Patricio Letelier

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

Más práctica y menos teoría

Me decidí a escribir este post después de leer el artículo "Más práctica y menos teoría" aparecido en el País Semanal del 23/10/2011, escrito por Jenny Moix (con la ilustración adjunta de Alberto Vásquez). Lo tenéis en http://bit.ly/nHWLlG.

Hace bastante tiempo me había dado cuenta del hecho que cada vez estaba leyendo más y quedándome con menos. Me explico con un ejemplo, me pongo a leer 4 capítulos de un libro, unas 30 páginas y voy apuntándome notas, al final de mi lectura no he escrito más de 10 frases. Más aún, al recorrer dichas frases ya ni siquiera me parecen de valor y termino tirando el papel. Sin embargo, la lectura me pareció interesante, ... aparente contradicción ¿o no?. La misma situación me ocurre en la mayoría de las charlas a las que asisto, apunto un par de frases o ni siquiera eso. Obviamente lo que no voy a pensar es que ya lo sé todo, probablemente lo que tendría que hacer es acceder a información más especializada. De todas formas tanto en la lectura como en la asistencia a charlas el beneficio no sólo está en el contenido sino en el estado de reflexión al cual te somete la situación y por supuesto en el caso de las charlas, el poder contactar con gente que comparte intereses, al menos eso siempre es un buen aliciente.

¿A qué viene esto?, ¿qué relación tiene esto con el enfoque ágil?. Pues simplemente que dichos libros y dichas charlas en mi caso son sobre agilidad, lo cual ocupa una parte importante de mi dedicación actual :-). Si a lo comentado le sumamos la enorme cantidad de información que puedes encontrar sobre este tema en internet, te obliga a ser más selectivo, pero el problema es que todo a priori parece interesante.

No se trata de que no deba existir literatura y charlas introductorias, son imprescindibles para quienes comienzan con el enfoque ágil. Aquí los gurús tienen un rol protagonista en cuanto a saber explicar fortalezas y debilidades del enfoque, dando la motivación inicial para convencernos que vale la pena probarlo. ¿Pero cuál sería la literatura o charlas avanzadas?. Podrían ser las historias de éxito, pero resulta que en este caso la gran mayoría son "triunfalismo puro", tal como en las entrevistas que hacen a los actores durante la promoción de su película, frases del estilo "trabajar juntos ha sido un gran desafío, hemos dado lo mejor y todos mis compañeros son geniales". Temas asociados a dinámica de grupo, reuniones, liderazgo, coaching, etc., es prácticamente literatura de auto-ayuda, sin ánimo de subvalorarla, puesto que en este caso sí que a priori soy consciente que no se trata de encontrar una respuesta-receta. Por otra parte, las versiones de la Scrum Guide tienen cada vez menos páginas :-), y además te dicen "en otros sitios se explicará la estrategia, aquí sólo están las reglas", es decir, "bienvenida a la interpretación de esto!!" :-).

A continuación explicaré por qué pienso que en el terreno de las herramientas y su aplicación me parece que deberían estar las respuestas más concretas acerca de cómo debe hacerse en detalle la implantación del enfoque ágil. Probablemente con la frase anterior os saltaría la alarma: violación del primer principio; "Las personas y su interacción por sobre los procesos y las herramientas". Bueno, al margen de la interpretación más o menos radical que se le quiera dar a este principio, al menos estaremos de acuerdo que las herramientas son, en general, útiles y necesarias. Por supuesto que se deben primar las personas y su interacción, particularmente lo que esto conlleva en términos de: disciplina de comunicación, de reuniones, proactividad de los miembros, equipo auto-organizado, etc., pero esto puede y debería acompañarse con un adecuado apoyo de proceso y herramientas. Esto se hace aún más importante cuando las condiciones ideales de aplicación de una metodología ágil como Scrum no pueden conseguirse en su totalidad o profundidad, por ejemplo si el equipo está distribuido, si el trabajo sobre el Backlog no lo realiza el cliente sino que debe asumirlo el equipo de desarrollo, si los miembros del equipo no trabajan en un solo producto, si el volumen de ítems en una iteración es alto, etc.

Comencé en el año 2000 a interesarme por el enfoque ágil, en esa época lo más popular era XP. Lo introduje en mi docencia e investigación. En el 2004 comencé a aplicarlo en proyectos industriales y en paralelo fuimos desarrollando una herramienta de apoyo. Hemos experimentado y aplicado Scrum en docencia y en proyectos reales. Ya en esos años comenzamos a desarrollar una herramienta. Las herramientas de apoyo a procesos (no sólo a actividades concretas como puede ser un entorno de programación o de pruebas) no son fáciles de implantar. O bien deben ser muy configurables para que en cada contexto se usen de forma muy diversa o bien deberían imponer una forma específica (y conveniente) de trabajo a la cual debes adaptarte. En nuestro caso hemos optado por esta última estrategia, hemos desarrollado una herramienta que conlleva una metodología de trabajo y que deja sólo unos pocos aspectos claves configurables (workflows y gestión del esfuerzo). Esto nos llevó a definir en mucho detalle no sólo la herramienta sino la forma de trabajo asociada a la herramienta.

Cuando tienes una herramienta muy configurable como por ejemplo JIRA, tienes un "arma de doble filo" puedes hacer con ella lo que te parezca pero queda en tus manos la metodología de trabajo, el equipo debe establecer cómo se integrará la herramienta en su trabajo. Así pues, cuando no tienes un método de trabajo definido y no tienes o no te das la oportunidad para definirlo podrías quedarte sólo en usar JIRA casi como una hoja de cálculo :-). Si por el contrario tienes definido tu método de trabajo, especificarás workflows, consultas, dashboards, etc., todo muy adaptado a tu forma de trabajo. Pero en este último caso ¿cuál es la configuración que deberías hacer?. Aquí volvemos al punto de la literatura y charlas sobre el enfoque ágil. En general, en ellas encontrarás muy pocas pistas respecto de cómo debes configurar tu herramienta (o grupo de herramientas) para dar soporte a tu método de trabajo. Por otra parte, la mayoría de las herramientas ha optado por ser muy configurables, quedando claro que la definición del proceso está en manos de los usuarios.

Me reafirmo en que lo importante no es la herramienta ni el proceso, sino qué se consigue con ellos, el objetivo final es aportar el máximo de valor al cliente. Sin embargo, y asociado a mi reflexión acerca de la teoría y la práctica, en nuestro caso ha sido el desarrollo y la mejora de una herramienta, y en su utilización en la práctica la que nos ha obligado a enfrentar muchos desafíos específicos que no suelen ser tratados en la teoría.

Un ejemplo: Desde que me inicié en el métodos ágiles con XP, me sedujo su énfasis en las pruebas de aceptación, éstas deberían especificarse al mismo tiempo que se define la Historia de Usuario pues son su criterio de finalización. Comenzamos aplicando esta idea en docencia trabajando con fichas de papel para las Historias de Usuario y escribiendo en su parte posterior las pruebas de aceptación, pero inmediatamente detectamos las limitaciones que presentaba este soporte. Luego utilizamos intensivamente pruebas de aceptación en la especificación de requisitos para productos industriales, registrándolas en documentos asociados a los cambios (que ya gestionábamos con una herramienta). Vimos que estábamos siendo ineficientes puesto que toda la especificación de comportamiento que representaban las pruebas se quedaba en la especificación del cambio (en la Historia de Usuario), y era difícil aprovechar dichas especificaciones en futuros cambios. Debido a esto, implementamos un soporte para poder gestionar eficazmente las pruebas de aceptación. A día de hoy, y después de sucesivas mejoras, tenemos un soporte muy completo para gestionar pruebas de aceptación como elemento principal de la especificación de requisitos, además, todo el proceso gira en torno a las pruebas de aceptación. Uno de los productos con los que trabajamos tiene ya más de 15.000 pruebas de aceptación. En este aspecto seguimos haciendo mejoras tanto al proceso como a la herramienta. La idea estaba planteada desde un principio, lo difícil ha sido desarrollarla y llevarla a la práctica. En este camino de mejora continua mucho de este conocimiento ha quedado en la herramienta.

Espero que llegado a este punto de la lectura no te pase lo mismo que a mí, y que al menos habrás apuntado una idea interesante :-). Quédate al menos con el enlace de nuestra metodología y herramienta TUNE-UP www.tuneupprocess.com, donde sí que encontrarás respuestas específicas para todos los detalles que conlleva una implantación del enfoque ágil :-).



Patricio Letelier

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

www.tuneupprocess.com 

Actividad: Scrum + Kanban + conceptos Equipo Self-organizing y Cross-functional

En esta actividad se ilustran las situaciones que se pueden enfrentar trabajando con Scrum + Kanban = Scrumban, es decir, escenarios de trabajo de un equipo que aplica Scrum, particularmente aquellos generados en la utilización de un tablero kanban.

Para simplificar nuestra actividad vamos a trabajar solo con un sprint abierto y el resto de los ítems pendientes en el Product Backlog. 

Preparación del Material

Material

Velcro en gorras y carteles

Velcro en ítems

Dorsales

En este fichero tienes los carteles para formar el tablero kanban y para poner en las gorras, además de los ítems. Te recomiendo pegarlos sobre cartulina para conseguir más resistencia y rigidez. Corta pequeños trozos de velcro y pega una sus caras a los carteles e ítems, la otra cara la pondrás en la pared y en el frente de las gorras. En lugar de utilizar gorras para los miembros del equipo (dependiendo de la audiencia, esto puede suponer alguna molestia), los carteles indicando la actividad que cada agente está realizando se pueden adherir con velcro en la parte inferior de cada dorsal.

Tienes que poner alrededor de seis trozos de velcro en cada columna para poder ir poniendo los ítems que lleguen a ese estado en la correspondiente actividad. El tablero que debemos preparar corresponde al siguiente diseño.

Este es un tablero kanban minimalista, reconoce sólo las tres actividades esenciales asociadas a un ítem de cambio en el producto (Definir, Programar y Testear). El trabajo de definición (idealmente y en gran medida) se realizará en el Product Backlog (este trabajo se denomina "grooming" del Product Backlog). Se procurará tener una lista ordenada de ítems en la columna Done, preparadas para ser incluidas en dicho orden en el siguiente sprint.. 

Considerar unos 15 minutos previos a la actividad para preparar el Scrumban en una pared poniendo todos los carteles y trozos de velcro.

El instructor desempeñará el rol de Scrum Master. Existirá un Product Owner y entre 3 y 5 miembros del Development Team. En caso de más participantes sugiero ir turnándolos en los diferentes sprints, quedando como observadores cuando no sea su turno.

Realizaremos 3 sprints. La actividad en total dura alrededor de una hora y media. En cada Sprint introduciremos ciertas variaciones para producir ciertas situaciones que deban ser comentadas.

Primer Sprint

Configuración:

• Sin estimaciones.
• Seguimiento basado solo en el tablero kanban
• Con pre-asignación de agentes (el equipo auto-organizado se distribuirá el trabajo antes de comenzar el sprint, acordando los ítems y actividades en los cuales trabajará cada agente). 
• El Product Owner realiza todo el trabajo de definición y ordenamiento del  Product Backlog.
• Roles fijos. Remarcar que cuando los miembros del equipo desempeñan un rol fijo se está contradiciendo la parte del concepto Cross-functional referente a promover que todos los miembros del equipo puedan realizar cualquier actividad, aunque puedan ser más especialistas en alguna de ellas. La otra parte del concepto Cross-functional se refiere a que todas las habilidades deberían estar dentro del equipo, esta asumiremos que la cumplimos.

En el Product Backlog ya se tienen algunos ítems en TO DO, en DOING y en DONE (en esta última columna al menos 6 ítems). En cada columna del Product Backlog remarcar que los ítems están ordenados de arriba a abajo, y que deben siempre cogerse en dicho orden.

Poner el cartel de Sprint Planning Meeting en una pared cercana al tablero y llevar al equipo a dicha posición. En la primera mitad del Sprint Planning Meeting se simulará el hecho que el Product Owner comenta y aclara los ítems que coge de la columna DONE de la actividad Definir del  Product Backlog y los pone en la columna TO DO de la actividad Programar (en el Sprint Backlog), esto se repite hasta que el Development Team indica que es suficiente respecto de su capacidad (en este caso no tenemos estimaciones con lo cual lo haremos "a ojo" y simplemente con 4 ítems pararemos). En la segunda parte de la Sprint Planning Meeting se simula que el equipo se organiza para trabajar durante el Sprint considerando los ítems incluidos. Remarcar el concepto de Self-organizing. Son los propios miembros del equipo quienes deciden cómo abordar el trabajo del sprint teniendo la posibilidad de crear tareas (trabajo técnico asociado a los ítema y que no requiere acordarlo con el cliente) para los ítems que considere conveniente hacerlo, en nuestro caso para no complicar la actividad no crearemos tareas haremos.

En este primer Sprint y para ilustrar típicas ineficiencias, se hará la pre-asignación de miembros a actividades de cada ítem a las actividades Programar y Testear), y además cada miembro tendrá un rol fijo (Programador o Tester). Tener en cuenta que no debería testear el mismo que ha programado. Para representar la pre-asignación, cada participante eligirá un avatar y los pondrá sobre las letras P y T que indican la actividad que realizará en los ítem. Aclarar también que las actividades de un ítem podrían abordarse con más de una persona trabajando en paralelo.

Arrancar el Sprint.

Cuando un miembro realice la actividad de un ítem debe poner un papel en su dorsal con el número del ítem y además mover dicho ítem a la columna DOING de la correspondiene actividad.

El Product Owner durante el sprint continuaría definiendo ítems para próximos sprints. Además, cada cierto tiempo añadirá nuevos ítems al TO DO del Product Backlog, o los moverá a DOING. El Development Team a demanda del Product Owner comentaría ítems de Product Backlog y antes de que se pasen a DONE deberían ser estimados por el equipo. . El Product Owner mantiene siempre ordenados los ítem del Product Backlog, en particular la columna DONE pues se trata de ítems perparados para ser incuidos en un sprint. Todo este trabajo de gestión del Product Backlog se denomina "grooming", y se realiza de forma constante en paralelo al trabajo del sprint en curso.

Resaltar y comentar los casos en los cuales un miembro del equipo queda "ocioso", a la espera de algún ítem que está en una actividad previa. En esta situación dicha persona podría acudir al Product Owner para ayudarle con el "grooming" del Product Backlog. También podría ayudar a algún compañero en otra actividad (que corresponda con su rol fijo) o incluso podría reemplazar a un compañero que había sido pre-asignado a un ítem.

En este primer Sprint, para simplificar las explicaciones, no haremos Daily Scrum.

Remarcar lo que ser haría en la Sprint Review Meeting (la revisión con el Product Owner del resultado del sprint).

Hacer la Sprint Retrospective Meeting comentando lo siguiente:

• Plantear como mejora el hacer pre-asignación sólo para algunos ítems. La pre-asignación puede resultar interesante cuando el desafío que implica un ítem requiere de un especialista. Pero su inconveniente es que resta flexibilidad y provoca tiempos de espera. En consecuencia para ce sensato que sólo se realice pre-asignación en cierto ítems.
• Destacar la inflexibilidad que constituye el desempeño de roles fijos, cuando un participante se ha quedado ocioso y no puede coger trabajo pendiente en actividades que no corresponden a su rol.
• Resaltar que una deficiencia que podríamos tener en este caso es que el Product Owner no tenga las habilidades y conocimientos para expresar adecuadamente los ítems, además de actuar como cliente esperamos que se un experto en requisitos. El Scrum Master debería apoyar al Product Owner enseñándole cómo hacerlo pero puede que con esto no baste para que lo haga. Además, probablemente el cliente ni siquiera esté dispuesto a asumir dicha carga de trabajo. Ante estos inconvenientes en el próximo sprint dejaremos el trabajo del Product Backlog en manos del Development Team, aunque el Product Owner se mantiene como responsable y encargado de tomar todas las decisiones importantes.
• Cuestionar el hecho que cuando se esté por terminar un Sprint, deberían existir suficientes ítems preparados para ser incluidos en el siguiente Sprint, de lo contrario o bien se producirá un parón antes de comenzar el próximo sprint, o nos veríamos obligados a incluir ítems que no están bien definidos. En consecuencia, debe reservarse cierto esfuerzo para hacer dicho grooming en paralelo al trabajo de implementación del sprint actual.

Segundo Sprint

• Sin estimaciones
• Seguimiento basado solo en el tablero kanban
• Sin pre-asignación, los agentes se asignarán a actividades cuando éstos vayan a realizar la actividad
• El Product Owner toma decisiones respecto de los ítems en el Product Backlog, sin embargo, el trabajo de definición y ordenamiento lo realiza el Development Team, colaborando con el Product Owner, quien mantiene la responsabilidad y la toma de decisiones más importantes.

Realizar la Sprint Planning Meeting.

Provocar interrupciones cortas, que no obligan a dejar el trabajo actual, y largas, aquellas que obligan a dejar el trabajo actual y ponerse en el nuevo, lo cual conlleva cambio de carteles en el dorsal y a marcar el ítem en el tablero kanban para señalar que ya hay alguien que ha comenzado a trabajar en él en la actividad correspondiente.

Recrear la detección de un fallo detectado en testeo. El ítem se devuelve DOING en Programar si es difícil continuar testeando en presencia de dicho fallo. Si el fallo no impide seguir testeando, se notificará al encargado de programar la WU que tendrá que corregir el fallo pero se continuaría testeando. Remarcar que éstas son situaciones de re-trabajo, y que podrían afectar a cualquier actividad.

Parar en algún momento para simular una Daily Scrum. Que cada miembro del equipo responda a ¿qué hice el día anterior (minunos antes)? ¿qué haré durante este día (próximos minutos)? ¿qué impedimentos tengo?

Hacer la Sprint Review Meeting. Resaltar que el mejor criterio para dar por buena una versión ("DONE" del sprint) sería que cada ítem tenga definida sus pruebas de aceptación y que éstas se hayan aplicado satisfactoriamente.

Realizar la Sprint Retrospective comentando lo siguiente:
Vamos a suponer que el compromiso de plazos y resultado del Sprint es muy rigido,  lo cual nos exige un seguimiento más preciso para anticipar desviaciones que pongan en riesgo el cumplir dicho compromiso. Así pues, no nos bastaría con el seguimiento básico ofrecido por la visualización del tablero kanban donde se ve el estado de cada ítem, sino que pasaremos a estimar el esfuerzo de los ítems en las actividades que podrían resultar más críticas en cuanto a esfuerzo (en este caso lo haremos sólo para la actividad Programar). Utilizaremos una gráfica Burndown para supervisar el grado de avance del sprint y hacer una previsión de cumplimiento en base al esfuerzo restante y el tiempo disponible hasta el fin del sprint.


Tercer Sprint

• Con estimaciones y seguimiento basado en esfuerzo restante
• Seguimiento basado en el tablero kanban y en la gráfica Burndown
• Sin pre-asignación de agentes a actividades
• El Product Owner toma decisiones respecto de los ítems en el Product Backlog, sin embargo, el trabajo de definición y ordenamiento lo realiza alguien del equipo, colaborando con el Product Owner quien mantiene la responsabilidad.

Cuando se requiere realizar un seguimiento diario y más preciso del estado de avance del sprint probablemente lo más indicado sea realizar estimaciones y re-estimaciones, y reflejar el estado de progreso en una gráfica Burndown. Como unidad de esfuerzo yo prefiero utilizar horas ideales (horas contínuas, sin considerar interruppciones) en lugar de puntos pues debido a que diariamente habría que preguntarse cuánto esfuerzo restante queda en cada ítem del sprint, me parece más razonable y sencillo establecer cuántas horas ideales quedan, en lugar de cuántos puntos.

Lo ideal sería que el equipo realizara la estimación de los ítems en el Product Backlog, cuando los ítems que están en la columna DONE de la actividad Definir, es decir, una vez que ya están definidos. Así, durante el sprint y parte del trabajo de gooming del Product Backlog, el equipo debería dedicar algún tiempo para estimar ítems próximos a ser incluidos en un sprint. Si no se estiman los ítems durante sprints previos, el equipo se verá obligado a hacerlo en la Sprint Planning Meeting, quizás demasiado tarde porque el ítem ya está siendo considerado para incluirse en el sprint.

Cuando pasamos a incluir estimaciones, debemos como contraparte tener una noción de la Capacidad. La Capacidad de un equipo es el esfuerzo que el equipo puede abordar satisfactoriamente en cierta unidad de tiempo. Si estimamos en horas ideales, la Capacidad podría establecerse en términos de horas ideales por semana. Las horas ideales por semana tendría como límite el número de horas contractuales semanales del equipo. Sin embargo, por tratarse de horas ideales, siempre estarán por debajo de dicho límite. La Capacidad es una medida histórica y que debe considerar posibles variaciones que la afecten, por ejemplo, el equipo, el producto, la tecnología, etc. Cuando se mantienen constantes dichos factores, la capacidad del equipo puede ser bastante sencilla de calcular y fiable respecto del histórico de los últimos sprints. Por otra parte, las estimaciones, a pesar de poder hacerse para cada actividad, recomiendo centrarse en las que podría ser cuello de botella, y en este ejercicio, para simplificar más aún vamos solo a estimar esfuerzo para la actividad Programar. Para adecuarlo a la duración de la actividad, haremos un sprint de 10 minutos y estimaremos en minutos ideales.

Para no complicarlo demasiado, supondremos que el equipo tiene una Capacidad de 30 horas ideale por semana y considerando un sprint de 3 semanas, con esto tendríamos una Capacidad de 90 horas para el sprint. Con esto, asignar estimaciones ficticias (entre 10 y 30 horas ideales) a los ítems en la columna DONE del Product Backlog, de forma que se tengan más ítems que los que se podrían introducir en el sprint (que sobrepasen en conjunto las 90 horas ideales que se podrían incluir).

Hacer la Sprint Planning Meeting cogiendo hasta un máximo de 90 horas ideales de esfuerzo.

Preparar la Gráfica Burndown, en el eje Y el esfuerzo restante y en el eje X los días del sprint. Dibujar el primer punto en el eje Y en la posición correspondiente al esfuerzo de partida. Trazar una línea de referencia desde dicho punto hasta el punto de esfuerzo 0 en el último día del sprint.

Arrancar el Sprint.

Detener el trabajo varias veces simulando diferentes días con los correspondientes Daily Scrum. Actualizar el tiempo restante de cada item tachando el valor antiguo y poniendo el nuevo. Llevar la suma del tiempo restante al gráfico Burndown como un nuevo punto en el día correspondiente e ir trazando una línea entre los puntos de esfuerzo restante.

Comentar en el Burdown respecto de desviación respecto del progreso ideal representado por la línea de referencia. Comentar los eventos que pueden afectar al esfuerzo restante, tales como: falta estimar algún ítem, se ha superado la estimación de un ítem y esto no se ha reflejado en su estimación restante, se ha re-estimado un ítem (incremento o disminución de esfuerzo), ítems añadidos o quitados del sprint, ítems eliminados o desestimados. No es necesario simular todo el sprint, es más interesante comentar la tendencia de esfuerzo restante en la gráfica Burndown.

Conclusiones

La realización de esta actividad es todo un desafío, sin embargo, el éxito está prácticamente asegurado pues es sin lugar a dudas entretenida. Aunque puede tener momentos un tanto caóticos por la cantidad de situaciones y dudas que surgen a la vez, haciendo las correspondientes pausas para comentar las situaciones se puede reconducir adecuadamente. Al respecto, es crucial no incluir muchos participantes en la actividad, no más de 5, y si los asistentes son más de 5 se pueden ir intercambiando los participantes en cada Sprint. El resto de los asistentes que no está trabajando en el sprint debe estar atento para detectar situaciones y hacer comentarios como observadores de la actividad.

Para sacarle el máximo de provecho a esta actividad es necesario tener presente el catálogo de situaciones que pueden presentarse para estar atento a cuando surgen y comentarlas. En este sentido, podéis consultar una lista de debilidades para un tablero kanban físico (de pared).

Esta actividad está principalmente enfocada a equipos de desarrollo de software. En el caso de equipos trabajando en otros contextos, o como actividad introductoria para desarrolladores de software, recomiendo la actividad  Kanban y Scrum construyendo una Lego City.

Espero que este material os sea de utilidad. Si tienes dudas o sugerencias, o simplemente quieres compartir experiencias acerca de la aplicación de esta actividad no dudes en contactarme.

Fotos de la Actividad

Patricio Letelier

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

Actividad: Lo básico de Kanban y Scrum construyendo una Lego City

En este post compartiré con vosotros mi experiencia en la enseñanza de los conceptos básicos de Kanban y Scrum a través de una entretenida actividad de trabajo en equipo para construir una Lego City. Esta actividad la he venido refinando en su aplicación en mis clases con alumnos de Ingeniería Informática y también en talleres dirigidos a empresas.

El objetivo de esta actividad es doble, por un lado se consigue ilustrar los conceptos básicos de Scrum y Kanban y la dinámica de trabajo en equipo asociada, y por otro, sirve para romper el hielo en equipos donde los integrantes acaban de conocerse o que no estaban acostumbrados a trabajar en un contexto de agilismo.

Tal como en la mayoría de las simulaciones de Scrum con Lego que se pueden encontrar en internet, las primeras ocasiones cuando realicé esta actividad me esforcé por incluir muchas situaciones de gestión en el Kanban puesto que quería introducir al mismo tiempo todos los conceptos de Scrum. Con la experiencia la he ido simplificando hasta llegar a su estado actual, en el cual el propósito es menos ambicioso en cuanto a conceptos de Scrum pero más efectivo en cuanto a iniciar la dinámica de trabajo del equipo. Además, para ilustrar aspectos específicos de Scrum tengo otra actividad que realizo posteriormente y la cual queda perfectamente acoplada a esta primera actividad. Esta otra actividad la denomino Scrum + Kanban con un equipo self-organizing y cross-functional.

Espero que esta información os sea de utilidad. No dudéis en contactarme para dudas o sugerencias!!

Preliminares 

La actividad tal como os la planteo os ocupará una hora y media. Debéis elegir un espacio apropiado, comenzando con una mesa o agrupación de mesas que ofrezcan un espacio amplio para trabajar, que tenga la posibilidad de montar el panel Kanban en una superficie junto a las mesas de trabajo.

Las construcciones Lego tienen diferentes niveles de dificultad y correspondientes tiempos de ensamblado. Es importante que según esto los componentes estén semi-ensamblados, de lo contrario será muy frustrante para los participante no terminarlos en el tiempo establecido (esto de todas formas ocurrirá, pero crea demasiado ruido que suceda masivamente). En el caso de Legos que puedan tener una descomposición natural, tenerlos ya separados, por ejemplo, un restaurante de tres plantas, tener separadas las piezas de cada planta (estos casos se sugerirán como desarrollo incrementan en diferentes sprints), otros casos como componentes múltiples, por ejemplo Banco + Camión Blindado + Coche de Policía, es conveniente que sus piezas estén separadas. Por otra parte, se sugiere tener bloques, ventanas y puertas independientes para las Historias de Usuario que impliquen crear elementos no predefinidos. Finalmente, otro ingrediente interesante es dejar disponibles las instrucciones de montaje (que tienen su analogía con especificaciones precisas de desarrollo), además, en algunos de los contenedores de las piezas dejar un recorte de la caja de Lego correspondiente que da una visión del resultado esperado (en algunos casos bastará con esto pues loe componentes estarán semi-ensamblados).

Escribir en post-it todas las Historias de Usuario (ítems de trabajo) que se abordarán para conseguir la Lego City. En este documento tenéis una lista de ítems de trabajo sugeridos, agrupados por características y subcarácterísticas deseadas para la Lego City, ahí se señalan algunos matices adicionales para ítems. Se recomienda no poner directamente todos los ítems sugeridos uno en cada post-it, sino que agrupar algunos, para que esto obligue a trabajar en paralelo, dividir Historias de Usuario y/o crear tareas asociadas a dichas Historias de Usuario de mayor envergadura.

Poner todas las Historias de Usuario en la columna TO DO.

Sobre folios unidos con celo o sobre un papel más o menos amplio hacer un trazado de calles y un río en una esquina en diagonal.

Cuenta con unos 15 minutos para hacer toda la preparación indicada, intenta tenerlo todo preparado antes que lleguen los participantes.

El número recomendado de participante para esta actividad es entre 4 y 6, con menos serán poco evidentes ciertas situaciones y con más la actividad puede resultar caótica. En caso de tener un grupo más numeroso sugiero armar equipos que se turnen en cada uno de los round que se describen a continuación. Así, en el round participa sólo un equipo y el resto observa y comenta con el instructor las situaciones que se van presentando.

Primer Round

Explicar la visión de la Lego City en términos de características que se desea que ésta tenga. Pueden señalarse las sugeridas en el mismo documento indicado antes.

En este primer round no controlaremos tiempo (sin time-box). La idea es ilustrar Kanban y el interés en generar flujo de trabajo terminado. De paso el equipo conseguirá tener una noción del esfuerzo que implica el armado de componentes.

Dar por iniciado el round y el instructor (que se adjudicará el rol de Cliente o Product Owner) irá cogiendo post-it y los pasará a la columna DOING, de uno en uno, dando tiempo para que se cree la indecisión de los miembros del equipo respecto de si trabajar cada uno en un ítem (y esperar a que aparezcan más en DOING) o trabajar entre varios en un ítem. Comentar esta situación e indicar que los ítems pueden realizarse en conjunto o individualmente. Animar a que los participantes se auto-organicen. Seleccionar ítems variados en cuanto a su grado de especificación (que estén asociados a componentes que tengan instrucciones, que sólo dispongan de la imagen del resultado final y que no estén predefinidos).

Con las condiciones que he mencionado antes, bastaría con entre 15 y 20 minutos para que terminen los ítems. De todas formas, dejarlos que se tomen el tiempo que necesiten para ello, no presionarlos al respecto.

Advertir que los ítems no se deben quitar del panel y que cuando estén finalizados deben moverse a la columna DONE.

Ir comentando sobre la marcha respecto de las analogías de la construcción con legos y el desarrollo de software. Comentar el hecho que algunos ítems tienen especificaciones precisas, otros una imagen de referencia y otros deben crearse de forma aparentemente libre. Insistir en que según el caso debería ser más o menos crucial la interacción con el cliente para asegurar la aceptación final del componente.

Cuando esté todo lo propuesto construido y puesto en el trazado de la ciudad hacer una inspección objetando aspectos que no fueron acordados con el cliente y advirtiendo que por esto podrían no ser aceptados, sin embargo, por esta vez aceptarlos :-).

Segundo Round 

Esta vez simularemos un sprint con un time-box de 10 minutos.

Antes de comenzar empujaremos al equipo a hacer estimaciones en minutos de cada uno de los items restantes en la columna TO DO. Con un rotulador escribirán la estimación sobre el post-it. Si un item tiene más de 10 minutos de estimación debería ser dividido o de antemano prever que deberá realizarse por más de unos o dos personas a la vez.

Una vez estimados todos los ítems de la columna TO DO, preguntar al equipo cuánto sería su capacidad, en este caso expresada en minutos de trabajo que pueden abordar en 10 min. Obviamente el máximo teórico será 10 por el número de participantes (por ejemplo, con 5 participantes tendrían un máximo de 50 minutos de trabajo por abordar). Sin embargo, se trata de una estimación en términos de tiempo ideal, es decir, debería ser menos que el máximo. Sugerir que consideren, por ejemplo alrededor de un 70% de capacidad respecto del máximo posible. Por ejemplo, si tienen 50 minutos máximos, que consideren sólo 35.

A continuación, el instructor irá pasando ítems a la columna DOING. El equipo llevará en cuenta la suma de estimaciones de los ítems en dicha columna e indicará al instructor cuándo se ha alcanzado o se estará apunto de sobrepasar su capacidad en minutos (para un sprint de 10 minutos).

Antes de comenzar el sprint hacer que el equipo reflexione respecto a si verdaderamente cree posible abordar todo el trabajo incluido en la columna DOING. En caso de no esta seguros acordar quitar ya ítems. No deberían valer frases del estilo "dejémoslo y ya veremos si alcanzamos a hacerlo". En caso de quitar (o añadir) ítems modificar la capacidad antes acordada.

Arrancar la cuenta regresiva e ir informando períodicamente el tiempo restante.

Estar atento a situaciones nuevas debido a la limitación de tiempo, por ejemplo, que recurran al cliente para acordar alguna reducción de dificultad en caso que se vaya complicando la construcción y se acabe el tiempo disponible.

Al terminar el tiempo el cliente revisar el trabajo que haya quedado incompleto. Podría aceptarse parcialmente definiendo un nuevo ítem correspondiente a la parte faltante, el cual se pondría nuevamente en la columna TO DO. Si el ítem en gran medida no está acabado o ni siquiera empezado devolverlo a la columna TO DO. Revisar además todo el trabajo añadido a la columna DONE y ser riguroso en cuanto a lo que pueda no estar completo o correcto, actuando de forma similar a lo hecho con los ítems que quedaron en la columna DOING.

Según los resultados de la revisión, modificar la capacidad del equipo, la cual se utilizará para el siguiente sprint.

Tercer Round

El tercer sprint pretende llegar a una situación de proceso controlado. Para esto el equipo habrá alcanzado una noción más realista de su capacidad y es de esperar que en este sprint se encuentre más cómodo, menos presionado por el tiempo.

El Produt Owner vuelve a poner en DOING ítems sin sobrepasar la capacidad del equipo.

Volvemos a simular un sprint de 10 minutos de time-box.

Conclusiones

Comentar brevemente los conceptos y situaciones que se presentaron en la actividad, entre ellos:

• Kanban y la idea de flujo de trabajo terminado
• El equipo self-organized y cross-functional
• Las analogías construcción con Lego y desarrollo de software
• Situaciones específicas de particionamiento de ítems, uso de tareas, trabajo incompleto, trabajo rechazado por el cliente, interacción y validación continua con el cliente
• Algunos elementos de Scrum: roles (Product Owner y Development Team), Sprint, reuniones (Sprint Planning Meeting y Sprint Review Meeting, time-box, ítems de trabajo, capacidad del equipo.

Materiales

Una cantidad suficiente de Legos para mantener ocupado al equipo (más abajo se detallan los que utilizo y son suficientes para un equipo de máx. 6 personas), una paquete de post-it, rotuladores para escribir en ellos, una superficie donde los post-it se adhieran (obvio pero importante :-) ) y donde se puedan señalar tres columnas etiquetadas por TO DO, DOING y DONE.

Los Lego no son baratos. Esta actividad podría hacerse con otros elementos alternativos, incluso sólo con papel y lápiz haciendo dibujos de lo que se va a construir. Sin embargo, si tenéis la posibilidad de hacerlo con Legos os lo sugiero pues hay aspectos interesantes que tienes por defecto: la connotación de estar jugando pues es en sí un conocido juguete, el rango de posibilidades desde seguir una especificación de construcción hasta realizar algo totalmente salido de la imaginación y habilidad del participante, el desafío y competitividad/colaboración que despierta de forma natural, etc. Además, he preferido utilizar Lego pues mis hijos ya eran expertos en Lego y han estado muy contentos de participar en la compra y pruebas de los compomentes :-). A continuación presento la lista de componentes que uso en esta actividad. El costo aproximado ha sido 200 €, ... hasta ahora los considero bien rentabilizados :-). Esta es la lista del material que utilizo.

Algunos momentos de la actividad

Es importante resaltar cómo naturalmente se pueden en gran medida evitar los tiempos sin trabajo pues los agentes pueden ayudar a otros cuando terminan con su trabajo y no queda más trabajo por asignar. Esto es posible porque es un equipo cross-functional, "todos pueden hacer de todo" (que en este caso sólo se trata de construir con Lego).

En el siguiente tablero kanban utilizamos post-it de color verde pegados junto a las Historias de Usuario para representar tareas asociadas. Las etiquetas en rosa indicaban el nombre de quien estaba realizando la Historia de Usuario o tarea (podía haber más de un a persona asociada). De todas formas, como indiqué antes, en mis últimas aplicaciones de esta actividad con Legos la he simplificado dejando todos los ingredientes más específicos de Scrum y Kanban para otra actividad específica para ilustrar Scrumban.

Cuando se añade el "time-boxing" viene muy bien utilizar y poner visible un reloj con cuenta regresiva. Os recomiendo http://www.online-stopwatch.com/

Otros momentos de la actividad ...

Patricio Letelier

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

¿Cuando y cómo el trabajo de arquitectura cobra protagonismo en el contexto ágil?

Existen variadas definiciones o perspectivas del concepto "arquitectura". En este post el concepto arquitectura se refiere a la organización externa e interna del producto software. Organización externa en cuanto a los requisitos del producto e interna en cuanto a los elementos/capas/componentes de código del producto.

Una buena arquitectura facilita no sólo el desarrollo del producto sino que especialmente su mantenimiento, facilitando las modificaciones, pruebas y reutilización.

Una de las diferencias técnicas más destacables del enfoque ágil con respecto al tradicional es que en el primero la arquitectura del producto se va definiendo y mejorando con refactorización a lo largo del proceso de desarrollo. En cambio, en el enfoque tradicional la arquitectura en gran parte se establece tempranamente, antes de entrar en las iteraciones de construcción del producto. Ambas estrategias son válidas de cara a conseguir al final una buena arquitectura. En el caso del enfoque ágil su estrategia le permite casi de inmediato comenzar a programar el producto, mientras que en el enfoque tradicional se dedica un tiempo considerable al establecimiento de dicha arquitectura (en base a modelado y especificación del producto que se va a construir) antes volcarse en la programación. La inversión temprana en arquitectura pretende evitar en lo posible que cambios durante el desarrollo tengan alto impacto en lo ya implementado. En el enfoque ágil se asume este riesgo asociado al impacto de los cambios y se paga con continua refactorización.

Las situaciones en las cuales es muy útil realizar un trabajo previo de arquitectura y el cómo hacerlo es un tema escasamente tratado en el ámbito ágil. Gran parte de la literatura ágil está centrada en la gestión de cambios (llamados Ítems, Historias de Usuario, Unidades de Trabajo, o similar) que son de mucha granuralidad, muy pequeños, lo cual ocurre normalmente cuando el producto ya ha alcanzado una cierta estabilidad en su arquitectura, es decir, en  cuando cada cambio individualmente no requiere gran trabajo de arquitectura, especialmente pues se trata de pequeñas mejoras o correcciones de fallos. Sin embargo, cuando se trata de un cambio de gran envergadura (reconocido como "Historia de Usuario Épica"), o en particular cuando se debe establecer y llevar a cabo la primera entrega del producto (primera puesta en producción), es altamente recomendable definir los Ítems con una perspectiva más global e integradora, junto con establecer una arquitectura global que sea adecuada para soportar en conjunto a dichos Ítems.

Si para desarrollar un producto sólo necesitamos definir y concentrarnos en un sprint se simplifica significativamente la planificación y seguimiento (y su explicación). Esta es la situación típica de mantenimiento en la cual cada versión (resultado de un sprint) suele coincidir con una entrega (versión pasada a producción). Todos los cambios enfrentados durante el desarrollo bien se incluyen en el sprint actual (sólo en caso que sean imprevistos urgentes) o bien se incluyen y ordenan dentro del Product Backlog. Sin embargo, cuando enfrentamos el desarrollo de la primera entrega de un producto, o cuando se realiza un cambio de gran envergadura en un producto (posterior a su primera entrega), probablemente se tendrá que trabajar durante varios sprints. En este caso es muy recomendable realizar un trabajo previo de arquitectura tanto desde el punto de vista externo (requisitos y su organización) como interno (componentes de la estructura interna). Este trabajo no tiene porqué igualarse al realizado por un enfoque tradicional, al menos en cuanto a detalle y duración. Para mantener el espíritu ágil, dicho trabajo en arquitectura debería ser más general, corto e intenso en comunicación dentro del equipo.

Con lo anterior hemos establecido el "Cuándo" la arquitectura coge protagonismo, que es precisamente cundo se trabaja cambios asociados a nuevos requisitos o importantes modificaciones de funcionalidad, y particularmente cuando éstos son de gran envergadura, es decir, pueden tener un alto impacto en el producto. Veamos ahora el  "Cómo".

Frente a un nuevo desarrollo o un cambio de envergadura, antes de comenzar a definir Ítems que descomponen dicho trabajo (Historias de Usuario), el equipo se debe concentrar en establecer la Visíón del Producto (o del cambio). Esto conlleva identificar la motivación para realizarlo, problemas que resuelve, necesidades que satisface, características principales, tipos de usuarios que se verán afectados. Desde el punto de vista interno debe definirse a modo general qué capas, frameworks, componentes u otros elementos tendrán que desarrollarse y/o integrarse.

Para este trabajo previo podemos definir un ítem del tipo Épica o realizar este trabajo de visión y arquitectura en paralelo a los sprints que estén en curso (en el caso de un nuevo requisito o mejora de cierta envergadura). Incluso, si se trata de un producto nuevo, este trabajo puede plantearse como una breve fase previa a la planificación de la entrega y al comienzo del desarrollo iterativo.

Dos comentarios finales:

• En muchos contextos de desarrollo ya tiene un reconocimiento explícito el rol "Arquitecto". ¿que hacemos con él? :-). La respuesta sencilla y coherente con el planteamiento de Scrum sería no reconocer ese rol como un título fijo para una persona. El arquitecto estaría dentro del equipo de desarrollo (en rol genérico Development Team) pero sería reconocido como especialista en arquitectura. Así, cualquier miembro del equipo podría realizar trabajo de arquitectura pero teniendo como apoyo al especialista en arquitectura cuando se requiera por las características del cambio involucrado.
• El trabajo de mejora y supervisión contínua de la arquitectura es importante en todos los cambios del producto, sin embargo, se hace más patente en los grandes cambios. Este trabajo puede hacerse de forma ágil, en el sentido que su intensidad y profundidad sea acorde al riesgo del posible impacto del cambio, y acorde también con el consecuente "castigo" que conllevaría la correspondiente refactorización. No hay recetas específicas, pero claramente conocemos los extremos: invertir mucho en arquitectura para rentabilizarlo (o no rentabilizarlo) en el futuro, o invertir poco en arquitectura y pagar mucho (o poco) por el refactoring en el futuro (debido a la llamada Deuda Técnica o Technical Debt). Lo sensato sería evaluarlo para cada situación y tomar la decisión asumiendo el correspondiente riesgo.

Patricio Letelier

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

Entrega (release), Iteración (sprint), Proyecto: ¿cuál es su relación?

Una pregunta recurrente que se hace gente que viene de gestión de proyectos "tradicional" cuando enfrenta la implantación de un enfoque ágil es ¿cuál es la equivalencia del término "proyecto" en este contexto?. Los conceptos son importantes, especialmente cuando se trata de explicar (e implantar) nuevos enfoques. Si bien no me atrevo a ser categórico, al menos puedo aportaros mis definiciones al respecto, las cuales hasta ahora he aplicado y me han resultado efectivas.

En cualquier enfoque ágil un pilar fundamental es realizar entregas (releases) frecuentes al cliente, es decir, poner en producción nuevas versiones del producto. El trabajo de desarrollo es organizado en iteraciones (sprints) cuya duración no debería ser superior a un mes (la frecuencia recomendada por XP o Scrum). Cuando el producto ya está en producción (se ha hecho al menos una entrega al cliente) las siguientes entregas podrían coincidir con las iteraciones, es decir, cada versión resultante de la iteración podría ser puesta en producción. Sin embargo, cuando se trata de la primera entrega del producto, o cuando se trata de una reforma de envergadura, probablemente no será suficiente con un mes de trabajo para conseguir un nivel operacional mínimo para ponerla en producción. Así pues, para respetar el hecho de que cada iteración (sprint) no debería extenderse más allá de un mes, en el caso de entregas que no puedan desarrollarse en una sola iteración, éstas requerirán ser abordadas en una serie de iteraciones.

La primera entrega del producto podría coincidir con la idea tradicional de proyecto de desarrollo. Pero una vez que el producto está en producción el objetivo será conseguir una siguiente entrega a través de una o más iteraciones. Estas siguientes entregas podrían llamarse "proyectos" pero parece más natural llamarlas entregas, o simplemente versiones cuando coinciden con ser el resultado de una sola iteración.

Hay una situación particular en la cual el concepto de proyecto resulta adecuado en el contexto de desarrollo iterativo e incremental. Esta es cuando se hace un cambio de envergadura en el producto, el cual obliga a organizar una serie de unidades de trabajo en varias iteraciones, quizás incluso dedicando recursos específicos para dicho cambio. Así, durante sucesivas iteraciones, de forma exclusiva o en conjunto con otros cambios, se lleva a cabo el trabajo asociado al proyecto. Los cambio asociados al proyecto podrían incluirse en las posibles entregas que se realicen durante la duración del proyecto o pueden hacerse disponibles sólo en la entrega que coincide con el término del proyecto. En el ámbito ágil este concepto de proyecto coincide con el término theme, el cual se refiere a un conjunto de Historias de Usuario relacionadas en cuanto a la funcionalidad o características que involucran.

Según lo explicado, queda en evidencia que cuando se utiliza un enfoque iterativo e incremental, el foco se centra en el producto más que en un determinado proyecto asociado al producto. Este matiz es similar al que se puede establecer al diferenciar un Product Manager respecto de un Project Manager. El trabajo del Product Manager está más orientado a los clientes del producto y dicho trabajo persiste mientras existe el producto. Por contraparte, la duración del trabajo del Project Manager es la duración del proyecto y su interés se centra en la gestión exitosa del proyecto, la cual debe estar alineada con la visión del producto pero restringida a unos plazos, alcance y costos específicos del proyecto. En Scrum el Product Owner tiene ingredientes de ambos, de Product Manager y de Project Manager, pero en mayor medida se acerca al primero.

Finalmente, ¿cómo se lleva a la práctica el concepto de proyecto cuando se trabaja con ítems (unidades de trabajo) en el Product Backlog o ítems en una determinada iteración (en el Sprint)?. En mi experiencia ha sido suficiente con asociar a un ítem su proyecto (si lo tiene) y luego al consultar ítems poder aprovechar dicho dato para realizar agrupaciones, filtros y selecciones de ítems. Otra característica que nos ha resultado útil es que un proyecto pueda tener asociado trabajo en diferentes productos. En este caso, cada producto tiene sus propias unidades de trabajo, y contando con el dato del proyecto se pueden tomar decisiones de coordinación entre las versiones de varios productos. En TUNE-UP Process estas funcionalidades están disponibles, y además se ofrece la posibilidad de realizar un seguimiento detallado del proyecto mediante un dashboard para este fin, el cual incluye entre otra información una gráfica Burndown para el proyecto, la cual permite supervisar su alcance global, es decir, más allá de la supervisión de cada sprint.



Patricio Letelier

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