Guía Práctica Nivel Inicial

Guía Práctica Nivel Inicial

Tabla de Contenidos Nota del Autor... 3 Qué es la metodología Ágil o Agile?... 4 Qué es Scrum?... 8 Un ejemplo práctico en SCRUM:... 9 Todo bien, pero Qué es Scrum?... 12 Empirismo... 12 Los Pilares de Scrum... 14 Compromiso... 14 Concentración... 15 Franqueza... 15 Respeto:... 15 Coraje... 16 El Equipo Scrum... 17 El Dueño de Producto... 18 El Equipo de Desarrollo... 19 El Scrum Máster... 20 Lista de Producto en Scrum (Product Backlog)... 21 Los requerimientos del cliente... 21 Qué contiene una Lista de Producto?... 23 Cómo le ayudamos al Dueño del Producto a elaborar la Lista de Producto?... 24 Lista de Tareas de Sprint (Sprint Backlog)... 27

Refinamiento de la Lista de Producto... 30 El Sprint o la Iteración en Scrum... 32 Planificación del Sprint... 35 La Meta del Sprint... 36 El Scrum Diario Daily Scrum... 38 Retrospectivas en Scrum... 41 Revisión del Sprint Sprint Review... 44 Típica Agenda: Reunión de Revisión... 46 KANBAN... 48

Nota del Autor Muchas gracias por ser parte del Proyecto de Cadena Crítica. Este es la primer guía, de las tres que están en carpeta sobre el tema Agile & Scrum. Aquí vas a encontrar las definiciones formales pero también muchos consejos prácticos aprendidos de años trabajando en este tipo de proyectos. Espero que te resulte entretenido. Si no has descubierto esta guía a través de www.cadenacrítica.com, te invito a que te acerques y descargues todo el material que te parezca interesante. Atentamente Carlos Diaz Calvi

Qué es la metodología Ágil o Agile? Dicen que el resultado de un proyecto está íntimamente ligado con la calidad de las relaciones entre los miembros del equipo. Quizás lleven razón. Lo cierto es que en los proyectos que existen equipos en los que da gusto trabajar, y otros en que no vemos la hora de volver a casa, o que se termine de otra vez. Si eso afectó la calidad de mi trabajo, no lo sé. Pero ciertamente no tenía más ganas de estar allí. Otras veces son factores externos los que hacen el proyecto insufrible. En particular proyectos largos, donde el objetivo se pierde, y más que avanzar estamos día tras

día luchando con estructuras muy fijas, etapas, documentación, plazos tallados en piedra que fueron poco realistas desde su concepción; a veces meses antes. De ahí que surgió una nueva forma de trabajar; de esto ya casi quince años: La metodología Ágil. Aunque algunos también la llaman XP (Extreme Programming), o Programación Extrema, entre otros nombres. Básicamente la palabra Ágil, es usada para englobar una estrategia de desarrollo de Software que tiene como premisas la estrecha colaboración de los equipos, los ciclos de desarrollo y el compromiso del equipo como un todo. Sigue los lineamientos de las proposiciones escritas en el Manifiesto Ágil: 1. Los Individuos e interacciones por sobre los Procesos y Herramientas 2. El Software Funcionando por sobre la Documentación Extensiva 3. La Colaboración con el Cliente por sobre la Negociación Contractual 4. La Respuesta Ante El Cambio por sobre el Seguir un Plan El Manifiesto Ágil da más importancia a los ítems de la izquierda que a los de la derecha, pero ambos siguen siendo necesarios.

Y hace énfasis en los siguientes principios Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara. El software funcionando es la medida principal de progreso.

Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial. Las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia. Scrum es uno de los métodos Ágiles que se desarrollaron tras el manifiesto.

Qué es Scrum? Confieso que hasta hace muy poco yo pensaba que era una de esas formas de trabajo, medio bohemia y "a lo que salga, que podía ser utilizada solo en empresas pequeñas, con proyectos poco importantes. Pero en realidad Qué es Scrum? Todos los proyectos que venía haciendo yo en consultoría, por más de quince años, fueron solo en Cascada, y no solo eso: Cascadas muy pero muy elaboradas, como la de la Compañía de Energía, que tenía su propio manual de metodologías tipo PMP para la entrega de proyectos.; eso sobre el Manual que ya llevaba yo de mi propia empresa de como entregar proyectos en cascada según nosotros. PERO al final - ESTABA EQUIVOCADO AL PENSAR ASÍ.

Tuve oportunidad de hacer cursos de SCRUM, tanto como DESARROLLADOR como también de SCRUM MASTER (el que facilita y lleva a término cada una de las iteraciones); el Jefe de Proyectos de la forma de trabajo SCRUM. Luego tuve la suerte de trabajar dentro de un proyecto ágil por un par de iteraciones. Y al final tuve que ir con una pala a enterrar todos mis preconceptos y malas ideas sobre el tema. Es un marco de trabajo magnifico. Un ejemplo práctico en SCRUM: Para que lo entendamos con claridad. Una vez que tenemos el objetivo que nos da el cliente (una página web, una serie de componentes, lo que sea), debemos sentarnos a preparar el proyecto Scrum, conseguir el equipo adecuado, y dividir el

trabajo que nos pide el Dueño del Producto (Product Owner, o PO) normalmente el cliente -, trozándolo en tareas más pequeñas en una Lista de Producto (Product Backlog). Todo el equipo hace un ejercicio de estimación de esfuerzo para cada una de esas tareas, al menos las iniciales. Se decide cuantos Sprints (o Iteraciones) haremos, de acuerdo al tiempo de proyecto, y por ende cuantas Entregas (Releases, a producción). Por ej.: Un proyecto de 8 semanas, con Sprints de dos semanas y dos releases, una a la 4 (cuarta) y otra a la 8 (octava) semana. Entonces cada lunes que comienza un sprint de dos semanas, se reúne el equipo y elige que tareas de la Lista de Productos va a realizar durante esas dos semanas, en esa iteración. Las tareas se reparten intentando cubrir las prioridades dadas por el Dueño del Producto, pero no hace falta tomar la #1. Entonces de una lista de 100 tareas totales, elegimos 10, por ejemplo, de distinta complejidad. La estimación del esfuerzo que hicimos antes nos permite intuir que podemos hacer entre todos los del equipo unas 2 tareas complejas, 4 de mediana complejidad, y 4 simples. Entonces cada uno trabaja en esas tareas con el objetivo de terminarlas bien, de darlas por Terminada, testeada, integrada, potencialmente entregable al usuario final (sino no se considera terminada por más que casi casi ya este). Hay reuniones muy cortas todos los días llamada el Scrum Diario (el Daily Scrum), y cada miembro del equipo tiene la oportunidad de contar lo que hizo el día anterior, lo que espera hacer hoy, y que obstáculos le preocupan. Es tarea del Scrum Máster el quitar esos obstáculos del camino (llamados también impedimentos); luego se encarga de promover el dialogo, facilitar el trabajo.. y por ultimo no menos importante ocuparse de escudar/proteger el equipo de cualquier interacción con el mundo

exterior, el cliente, o nuevos requerimientos, hasta que las dos semanas se terminen. Al final del Sprint, o Iteración, (al final de la segunda semana) se presenta lo Terminado y solo lo terminado, nada a medias al Dueño del Producto, que da sus impresiones; se realiza luego otra reunión de Retrospección para hablar todos con honestidad y decir que se hizo mal (estimaciones por ejemplo), y como mejorar esas cosas. Las lecciones aprendidas. Y por ejemplo, decidir que la próxima iteración tomaremos mas o menos trabajo respecto al esfuerzo que hemos calculado. Esto define lo que es la Velocidad del equipo (podríamos llamar productividad). Entonces cuando empiece el próximo Sprint, el lunes siguiente, el ejercicio se vuelve a repetir, la toma de tareas pendientes, la re-estimación de esas tareas basándose en lo que hemos aprendido, y a trabajar nuevamente.

Todo bien, pero Qué es Scrum? Empecemos por el principio, pero no voy a hacer historia, tranquilos. Todos conocemos de la metodología en Cascada (o Waterfall) para la entrega y desarrollo de proyectos, esa que va paso a paso, desde la toma de requerimientos, control, ejecución, test, y producción, básicamente. Pues lo que tiene de efectiva, lo tiene de aburrida. Y tienda a matar lisa y llanamente a la creatividad. De ahí que grandes empresas se hayan planteado utilizar metodologías más dinámicas, agiles y entre ellas, la más usada es esta, llamada SCRUM. Al ser un marco, no una metodología que hay que seguir a rajatablas, SCRUM puede ser adaptado a las necesidades del proyecto, es flexible, y tiene en la mira permanentemente el tema de la mejoría incremental del producto que se pretende entregar. Entonces, en vez de tener que esperar hasta la Etapa de Producción (o Mantenimiento), dentro de varios meses, lo que SCRUM promueve es que al final de cada iteración (o Sprint) haya una serie de componentes que el dueño del producto pueda presentar a los usuarios; esto es en una, dos o tres semanas, y entonces volver a repetir el proceso y entregar algo mejorado luego, y así sucesivamente. Empirismo Es la palabra clave que describe de que se trata SCRUM. Que en realidad significa que conoceremos mejor aquello que experimentamos, por tanto iremos

mejorando nuestra calidad, cantidad, capacidades, y muchos otros parámetros tras cada iteración del proyecto. Y entonces se apoya en tres pilares que hay que tener siempre en cuenta: TRANSPARENCIA, INSPECCION y ADAPTACION Transparencia: Que todos los interesados, el equipo, el dueño del producto (el cliente); todos sepan cómo está la situación en cualquier momento dado. Que las reglas sean claras, por ejemplo la de los criterios que usaremos para dar por Terminado un trabajo. Tiene que haber sido testeado? Tiene que haber sido revisado por un colega? etc. Todo muy claro, si es posible, impreso y a vista de todos en la oficina. Inspección: Que tenemos que controlar, revisar, permanentemente como estamos ejecutando los procesos y utilizando los artefactos que nos provee la técnica SCRUM. No tan frecuente como para que lleve mucho tiempo, pero lo suficientemente efectiva como para que cada nueva iteración (o Sprint) notemos una mejora. Adaptación: Como resultado de la Inspección, quizás tengamos que cambiar, y eso es muy bueno. Cuanto antes lo hagamos, mejor.

Los Pilares de Scrum Lo primero que me viene a la cabeza cuando pienso en los Pilares de Scrum es precisamente una imagen de una batalla de caballeros honorables. El rival, en este caso, sería la sobre-planificación. Para trabajar en un proyecto Scrum tenemos que entender cuáles son los pilares de los proyectos Scrum. Y estos son: Compromiso, Concentración, Franqueza, Respeto y Coraje... lo necesario para ir a cualquier batalla. Es importante que entendamos porqué son fundamentales: Compromiso

Que el equipo tenga un deber con la calidad; con la colaboración y el deseo de aprender e intentar ser cada día mejores, más eficientes en su trabajo. Que no sea una obligación pero un acuerdo ser profesionales, auto-organizarse, y el compromiso de entregar un software funcional, ni más ni menos. Sentirse atados a la definición de trabajo Terminado, y qué es lo que significa para el resto del equipo. Jurarse entregar un producto de valor al cliente; y finalmente, el compromiso a tener autocritica, mirar como grupo hacia adentro y sacar las mejores conclusiones y lecciones para el próximo ciclo. Concentración: Y foco en lo que sabemos, en nuestras capacidades. También en lo más importante. Y principalmente en aquellas cosas simples que agregan valor a nuestro trabajo. Desmontar el bosque, árbol a árbol. Franqueza: Ser transparentes ésta es una palabra clave en Scrum -. Ser sinceros en el estado actual de nuestro trabajo. Y ser abiertos a dar una mano al compañero que puede necesitarla. Dar opiniones leales, y aceptar valoraciones de nuestro trabajo por parte de otros miembros del equipo. Respeto: Estar siempre consciente que todos somos distintos. Y en organizaciones globales, especialmente, el hecho que los miembros del equipo pueden provenir de culturas

distintas. Y, en particular, respetar la experiencia y forma de pensar del otro; sus derechos y sus responsabilidades. Coraje: Mostrar audacia por ejemplo en no hacer una tarea que no aporta ningún valor al producto final. Bravura en ser sinceros y transparentes, aunque nos afecte. Admitiendo que nadie es perfecto, y que podemos equivocarnos Y cambiar de rumbo si fuera necesario. Y, por último, en saber pedir ayuda.

El Equipo Scrum Vaya diferencia de roles para un Jefe de Proyectos, el participar en un proyecto Scrum. Pasas de ser el que toma las decisiones a ser un pobre tipo que la misma metodología quiere hacer desaparecer. No lo dicen abiertamente, pero los creadores de SCRUM tienen en claro que se quieren sacar a los Jefes de Proyectos de encima. Un buen equipo Scrum es auto gestionado, auto controlado, se inspecciona a si mismo y elige como mejorar para la próxima iteración (o sprint). El equipo Scrum consta de tres roles muy bien definidos:

El Dueño del Producto (o Product Owner, o PO) El Scrum Máster (el Facilitador) El Equipo de Desarrollo (Development team). y una muy buena aclaración: En Scrum, la palabra Desarrollador no connota a un Programador, todos desarrollan algo en Scrum, ya sea un experto en Bases de Datos, o un Arquitecto. En sí, el Equipo de Desarrollo es el que trabaja en cada ítem y lo desarrolla. Los equipos auto gestionados eligen ellos que trabajo hacer; cómo hacerlo; y que criterios usar para darlo por Terminado en cada Entrega Incremental La idea es que un equipo Scrum no necesite de otras personas (externas) para entregar el producto/programa objetivo. El Dueño de Producto No hablamos de un equipo, siempre de una persona, incluso cuando esta sea la cabeza visible de un equipo del cliente, o de analistas de negocio, detrás de él. Lo dicho, normalmente es parte del cliente, pero puede ser una persona que conoce muy bien el negocio, y el sistema a ser entregado; lo suficiente como para definir granularmente las tareas a ser completadas. Es la única persona que es RESPONSABLE de gestionar la Lista de Producto (Product Backlog) o sea, la lista discreta de tareas que el Scrum Máster y el Equipo de Desarrollo debe entregar sprint a sprint. Aunque puede delegar esa tarea, la responsabilidad no se delega. Entre sus objetivos están:

Crear y mantener la Lista de Producto Ordenarla y Priorizarla Clarificarla, que nadie tenga dudas, y todos entiendan cada ítem. Al ser el único responsable, es también el único que puede venir con nuevos requerimientos de parte del cliente. Y es trabajo del Scrum Máster de controlar que esos nuevos pedidos no interfieran con lo que el equipo ya esta haciendo en este periodo (sprint) El Equipo de Desarrollo Son las personas que tienen que entregar las tareas de cada iteración o sprint en un formato Terminado. No a medias tintas. Se trata de un equipo multidisciplinario y jerárquicamente plano. No hay títulos para nadie, todos son Desarrolladores, aunque haya arquitectos, programadores, testers, etc. No existen tampoco sub-equipos. Y todos, TODOS, son responsables del objetivo del sprint, por más que se distribuyan las tareas. Así que idealmente tienen que ayudarse entre sí. En cuanto a su número, se acuerda que tiene que estar entre 4 y 9 miembros (ni tan pocos como para que haya problemas de capacidad al realizar las distintas tareas, ni tantos como para que no puedan trabajar en equipo). A esto hay que agregarle que no podemos agregar nuevos miembros durante el sprint porque rompe con la sinergia del grupo (y obligatoriamente debemos re-comenzar el sprint si así fuera)

El Scrum Máster Aunque exista la tentación de pensarlo como un Jefe de Proyectos, el Scrum Máster es un Facilitador. Alguien que se encarga de que todos los miembros del Equipo Scrum se adhieran a su marco de trabajo. Es un líder AL SERVICIO del equipo. Entre otras tareas tiene que: Ayudar al Dueño de Producto a lograr una Lista de Producto aceptable. Facilitar durante los eventos del Scrum (las reuniones, etc.) Guía (no ordena) al Equipo de Desarrollo para que se auto gestione Eliminar obstáculos que el Equipo vaya encontrando. Guiar a la Organización, a la Compañía, en lo que significa un proyecto Scrum, y manejar sus expectativas. Motivar a que haya mejoras en cada iteración. En otras palabras, es quien debe dar la cara ante la Organización, pero por sobre todo llevar el librito bajo el brazo para explicar una, y mil veces, que es Scrum y cómo sacarle mayor valor a la experiencia de utilizarlo.

Lista de Producto en Scrum (Product Backlog) Los requerimientos del cliente No hay nada peor en Scrum que tener un Dueño de Producto (Product Owner) que no le da importancia a la Lista de Producto en Scrum (Product Backlog). Recordemos, la Lista de Producto es una lista ordenada de tareas (o en realidad: acciones) que son necesarias para completar el producto final. Esto es, creación del webservice, por ejemplo, o creación de la pantalla principal. La importancia de la Lista de Producto radica que en Scrum es el único listado de Requerimientos válido.

Se puede tener un mal Dueño de Producto (o inexperto); para eso está el Scrum Máster, para ayudarlo a entender y adueñarse de ese listado de requerimientos y su priorización. El Dueño de Producto es el único responsable de la Lista de Producto, de su contenido, su disponibilidad, y el ordenamiento, claro. Cada Ítem de la Lista de Producto sería el equivalente al WBS (Work Breakdown Structure) o EDT (Estructura de Decomposición de Trabajos) en los sistemas de Cascada. En definitiva: El listado de todo lo que hay que hacer, componente por componente, pantalla por pantalla.

Qué contiene una Lista de Producto? En una Lista de Producto suele contener características, funciones, requerimientos, mejoras y correcciones que aún están pendientes para completar el sistema (o producto). Obviamente de ese listado saldrán las tareas que elegiremos en cada Sprint o Ciclo de nuestro proyecto Scrum. Cada uno de esos items suele llamarse PBI (Product Backlog Item) o ILP (Ítem de la Lista de Producto).

Cada Item debería tener las siguientes características: Deben estar expresados en un lenguaje claro (tanto para el equipo Scrum como para el negocio del cliente. Tener valor esto es fundamental -. Recordemos que en Scrum no hacemos nada al divino botón. Puede ser creado o desarrollado por (casi) cualquiera. Deben ser propiedad del Dueño de Producto. Deben estar ordenados de una forma coherente para alcanzar el objetivo. El esfuerzo debe ser estimado por el Equipo Scrum (no por el Dueño) Cómo le ayudamos al Dueño del Producto a elaborar la Lista de Producto? Aunque un PBI puede ser una pantalla, un requerimiento, o un error-bug incluso una historia de usuario, no es sencillo a veces obtener un listado de parte del cliente. Por eso es importante que el Product Owner el Dueño de Producto sea realmente un Analista de Negocio (Business Analyst), o alguien con profundo conocimiento de las necesidades del cliente. Una buena forma de lograr descomponer la solución es mediante el uso de Historias de Usuario, a las que le dedicaremos un artículo en breve. Mediante las historias de usuario que son de un nivel muy alto podemos extrapolar acciones, y de esas acciones, finalmente tareas (que son las que necesitamos en nuestro PBI.

Las Historias de Usuario, en general tienen una estructura estable: Como un <tipo de usuario>, necesito <alguna funcionalidad> con la finalidad de <razón o resultado>. Por ejemplo: Una historia de Usuario podría ser: Como usuario, necesito poder enviar un correo electrónico, con la finalidad de confirmar la participación del evento. Esto nos lleva a inferir las siguientes acciones: 1. Pantalla para enviar correo. 2. Detalles del formulario con Selección del Evento 3. Botón de Envío y funcionalidad. Y de esas, podemos concluir los siguientes ítems. 1. Agregar opción de enviar correo (botón) 2. Diseño del Botón 3. Codificar la Re-dirección a la nueva pantalla 4. Testear Botón 5. Crear formulario-pantalla para detalles del correo 6. Configurar la Base de Datos para los nuevos campos 7. Crear Procedimientos Almacenados para la n 8. Agregar campos y opciones a la pantalla de acuerdo a documento de diseño. 9. Comprobar que el destinatario del correo es usuario valido. 10. Configurar textos, títulos, contenidos y validaciones del correo electrónico.

11. Codificar el envío del correo. 12. Testear el formulario 13. integrar la solución 14. Hacer pruebas del correo 15. Y así seguiríamos pero ya son ítems accionables por parte de los desarrolladores (diseñadores, expertos de base de datos, programadores y testers). Imagen de Ejemplo: Ejemplo de Descomposición de Historia de Usuario a Tarea.

Lista de Tareas de Sprint (Sprint Backlog) La Lista de Tareas de Sprint (o de una iteración o ciclo) está muy unida a la Rapidez (Velocity) de nuestro equipo. Cuánto trabajo puede dar por "Terminado" en el período de tiempo convenido del Sprint. Hablaremos de la Rapidez en otro artículo, pero debo insistir en cuán importante es: La Rapidez o Velocity es lo que nos va a decir que podemos tomar sólo cuatro o cinco tareas del total que hay en la Lista de Producto.

Por definición una Lista de Tareas de Sprint (Sprint Backlog) son una serie de ítems seleccionados (PBIs), incluyendo un "plan" para entregarlos, o terminarlos al finalizar el Sprint. En realidad es también un "pronóstico" en sí mismo, que incluye un subconjunto de funcionalidades que el equipo espera terminar en este ciclo o incremento, y el trabajo que hay que hacer para lograrlo.

Podemos ver el trabajo pendiente por cada día del Sprint. Cada día se actualiza la Lista de Tareas de Sprint, con el trabajo pendiente. El plan debe tener suficiente detalle como para poder ser seguido, evaluado, mientras avanza su desarrollo durante el Sprint. Para eso es común utilizar una pizarra con columnas, así nos vamos ubicando en qué estado está cada ítem en un momento dado. Cada vez que se identifica una nueva tarea (por ejemplo: la corrección de una funcionalidad entregada anteriormente, un nuevo bug, puede ser agregada a la Lista de Tareas del Sprint. Sólo el Equipo de Desarrollo puede agregar tareas durante el Sprint (nunca el Dueño de Producto, que debe saber esperar; ni mucho menos el Scrum Máster, que está sólo para facilitarle las cosas al equipo). La Lista de Tareas de Sprint es muy visible, ya que casi siempre está puesta en la pared, con sus papeles de colores moviéndose hacia la columna de "Terminado". Siempre hay riesgo que el equipo tome demasiados ítems (o por el contrario muy pocos) durante los primeros ciclos o Sprints. Esto sucede hasta que encuentre su "Rapidez" y pueda pronosticar mejor cuánto trabajo puede realizar en ese período. En el ejemplo que vemos a continuación, el Gráfico de Pendientes (Burndown Chart), que veremos en otro artículo, nos indica que inicialmente el equipo tomó demasiadas tareas, y por tanto no podía completarlas. Entonces, de acuerdo con el Dueño de Producto, y con tal de entregar varios "Terminados" al final del ciclo,

accede a quitar algunos ítems de la Lista de Tareas de Sprint y así lograr los objetivos propuestos. Cómo lograr una mejor selección de las tareas que vamos a hacer en un Sprint?: Una alternativa son las reuniones de Refinamiento de la Lista de Producto Refinamiento de la Lista de Producto Como sabemos, la mayoría de las reuniones en Scrum tienen la duración muy restringida, para que el equipo empiece a trabajar cuanto antes en las tareas. Hay una nueva corriente de pensamiento que cree que en crear una reunión semanal periódica, de "Refinamiento de la Lista de Producto". Una reunión

donde todos (incluso el Dueño del Producto) puedan sentarse a discutir y agregar detalles a cada una de las tareas. Hay un alto riesgo que ser termine con más ítems en la cola de tareas, así que hay que estar muy atentos. Esta reunión puede ayudar a la hora de elegir las Tareas que vamos a incluir en un Sprint. El objetivo de este refinamiento tiene que ser: Una lista de tareas bien definidas. No es necesario que sean todas las del Sprint o o Logran una buena estimación del esfuerzo. Un entendimiento profundo de cada tarea, al punto que el equipo de desarrollo pueda tomarla sin miramientos, Importante: No perder mucho tiempo en el diseño. Recordemos que en Scrum, todo es incremental. o o Dividir las tareas donde haga falta. Agregas Historias de Usuarios y Detalles. Lograr que haya suficientes detalles en los ítems de la Lista de Producto, que el equipo pueda tomar esos ítems en - por los menos - dos futuros Sprints.

El Sprint o la Iteración en Scrum No existiría Scrum si no fuera por los Sprints. Eso está claro. El Sprint o Iteración (o Ciclo) es el Evento más importante y primario de la metodología Scrum. El Sprint es el corazón de la práctica Scrum, un evento con un tiempo acotado (de hasta un mes) en el que se debe entregar "Terminado" una serie de componentes. Terminado se entiende como aceptable por el cliente, debidamente testeado y probado (aunque sea limitado en sus funcionalidades). Todo lo que se entrega, tiene que estar funcionando. Lo que no está "Terminado" no se muestra. Los Sprints deben tener una duración estable durante a lo largo del proyecto. Y un nuevo Sprint comienza ni bien termina el anterior, tantas veces como se haya decidido al principio.

Dentro del Sprint se definen una serie de Eventos que son todos fundamentales: La Planificación del Sprint La Ejecución en sí misma. Los Scrums Diarios (Reuniones rápidas de alineación) La Revisión del Sprint. La Retrospectiva del Sprint. Durante un Sprint, no puede haber cambios que afecte el Objetivo del Sprint. Por ejemplo, no puede agregarse más gente al equipo - por más que se pudiera pensar que eso es algo favorable. La naturaleza dinámica y complementaria de las capacidades del grupo hace que el agregar un nuevo componente rompa la relación del grupo (ya que no sabemos probadamente que capacidad aporta). Tampoco deben bajarse las expectativas de calidad, durante el Sprint. Lo que se considera como "Completo y Terminado" es constante. Lo único que es flexible es la Negociación de los Objetivos (en particular de las Tareas del Sprint), junto al Dueño del Producto, en caso que se note la necesidad. De cierta forma, podemos considerar cada Sprint como un mini-proyecto en si mismo; un "mini-proyecto" con un mes de horizonte, como máximo. La razón por la que se limita la duración máxima de un Sprint a un mes es porque, sencillamente, el alargar provocaría más complejidad, mayor riesgo - por lo menos eso se ha comprobado. Es mejor tener horizontes cercanos para poder sentarse a revisar, discutir, corregir errores y comenzar otro nuevo Sprint.

Quizás esa sea la característica más loable de los Sprints cortos: Mayor predictibilidad, ya que vamos a estar inspeccionando el progreso y adaptándonos a los cambios al menos una vez al mes (normalmente dos). También eso implica que el riesgo de pérdida - o el costo de lo que se haya hecho mal, decrece a un mes. Una práctica común es comenzar un Sprint los martes, miércoles o jueves. Ya que los lunes y viernes son considerados días menos productivos. También, cuando los equipos están repartidos en diferentes ubicaciones geográficas (no recomendado). Es común que las reuniones de Revisión de Sprint (muestra de resultados), la de Retrospectiva (corrección de errores) y la de Planeamiento del - próximo - Sprint, se realicen al mismo tiempo. Pero no es necesario que estas se lleven a cabo el mismo día, ni mucho menos.

Planificación del Sprint Como ocurren en los proyectos en Cascada, cuando se planifica mal, se acaba mal. La Planificación del Sprint es igualmente importante. Después de todo es - como decíamos antes - un mini proyecto en sí mismo. El trabajo que tenemos que realizar durante una Iteración, o Sprint, se planea precisamente en la reunión de Planificación del Sprint. Todo el equipo debe participar: El Equipo de Desarrollo, el Dueño del Producto y el Scrum Máster. Como todos los demás eventos en Scrum, la reunión de Planificación del Sprint tiene un tiempo muy acotado, en promedio de 8 horas por cada mes de Sprint (así que si tenemos Sprints de dos semanas, debemos sentarnos en esta planificación el primer día, y por un máximo de cuatro horas).

Por cierto, no sé si lo mencioné antes, en Scrum el "Resultado" que se entrega al final de cada Sprint se llama "Incremento". Los Objetivos de la Reunión de Planificación son: Decidir qué vamos a entregar (Terminado) en el Incremento resultante del Sprint. Cómo vamos a trabajar para lograr alcanzar ese Incremento? La Meta del Sprint Después que el Equipo de Desarrollo haya decidido que ítems incluir en la Lista de Tareas del Sprint, tienen que ponerle nombre a la "Meta del Sprint". Por ejemplo: Mejorar la experiencia del usuario en las Páginas de Mis Pedidos. La Meta del Sprint es un objetivo que se debería alcanzar, si se finalizan todas las tareas que pusimos en la Lista, y proveen una guía al Equipo de Desarrollo como referencia de porqué está creando ese Incremento en particular. Una orientación y motivación. Al mismo tiempo, una buena Meta de Sprint, da al Equipo de Desarrollo cierta flexibilidad en cuanto a la funcionalidad que tiene que incluir en el Sprint, y por tanto intenta ser lo que "une" todo lo que los diferentes miembros del equipo está haciendo por separado. Otros ejemplos:

Hacer que la aplicación funcione tanto en la Web como en un teléfono móvil. Mejorar la habilidad del Panel de Control Mejorar los tiempos de respuesta de la Aplicación. Como vemos, las Metas de Sprint suelen ser bastante "generales" o difusas, Y ASÍ DEBEN SER. La idea es que si bien nos podemos ver forzados a quitar un ítem de la Lista porque no llegamos con el tiempo, podamos decir al Dueño del Producto, en la Revisión del Sprint, que la Meta ha sido cumplida.

El Scrum Diario Daily Scrum El Scrum Diario, el momento en que comentamos cómo va la serie o la peli que vimos la noche anterior. Naah, es broma. Es en esta mini reunión (de quince minutos, no más) en la que nos ponemos al día de cómo va el proyecto. Consejo: El scrum diario tiene que ser siempre en el mismo lugar y a la misma hora. Es más, propongo hacerlo de pie, que sea dinámico, frente a la pizarra. Que nadie se ponga cómodo. En el scrum diario tienen que estar todos, el Dueño del Producto, el Scrum Máster, y claro... el Equipo de Desarrollo. Puede haber otros invitados, pero están sólo para observar. Es el momento donde se discute todo lo que hay que hacer en el día, el momento de informarse qué es lo que tiene que pasar hoy. Cada miembro del equipo tiene que responder a tres preguntas:

Qué hiciste ayer? Qué planeas hacer hoy? Qué obstáculos tienes en el camino para hacerlo? El scrum diario - o daily scrum - no es para "controlar" lo que cada uno está haciendo. Sino el momento donde cada miembro del Equipo de Desarrollo se compromete, cara a cara, a hacer lo que dice. Este punto es muy importante, es donde nuestro compromiso queda grabado en la memoria de todos. No podemos fallarles. Otra alternativa, en vez de ir persona por persona, es ir ítem por ítem en la Lista de Tareas. Asi hay más oportunidades de interactuar para cada persona. Otro punto importante - si eres el Scrum Máster - es el de los impedimentos (u obstáculos). En los que tienes que adueñarte de los problemas e intentar solucionarlos. Ese es tú trabajo. Si no lo puedes hacer inmediatamente te debes encargar de pedir ayuda. Si algo no se puede resolver en 24 hs, el Scrum Máster debe elevarlo en la compañía. La reunión de scrum diario debe ser de 15 minutos, no más. No hay que perder el tiempo. Lo que necesite más tiempo para ser discutido debe ser agregado al listado de tareas y punto. Y recuerda, si eres Scrum Máster, estás allí sólo para facilitar, no para gestionar ni asignar tareas. Si ves a alguien yendo a la reunión de scrum diario apesadumbrado, o sin ganas de estar ahi. Es claramente una señal que hay problemas. La idea del scrum diario es

que salga todo el mundo motivado tras escuchar los progresos de los demás. Es más, procura tener chocolates, o caramelos, como premio. Hacer la reunión entretenida. Otro consejo que me han dado, que aún no puedo llevar a la práctica, es el de NO HACER CONTACTO CON LA MIRADA, con quién está reportando su trabajo. Lo de hacer contacto visual es humano, natural, pero si así sucediera estaríamos forzando la imagen del manager-examinador a los miembros del equipo; y Scrum no se trata de gestionar, sino de facilitar. Los miembros del Equipo de Desarrollo están reportándose a sus pares, no al Scrum Máster. Y finalmente, como en toda reunión de Scrum, puedes jugar a darles el trabajo de facilitador a otros miembros del equipo para crear "entendimiento" con el rol que te toca como Scrum Máster.

Retrospectivas en Scrum Cuando escuché por primera vez lo de Retrospectivas en Scrum supuse que cada uno tenía que ponerse a pensar en que hizo mal, o bien, como ir al confesionario... y eso que hace rato no piso una iglesia. Una especie de momento de relajación zen para luego compartir lo descubierto con el equipo. Pero me encontré con algo mucho más interesante. En Scrum, el proceso de Retrospectiva (que se hace al final del Sprint, luego de que se enseñasen los resultados al Propietario del Producto - el cliente -), es un ejercicio para re-alinearse con las nuevas lecciones aprendidas. En particular, tiene que ser una charla abierta, sincera y honesta, entre todo el equipo. Preguntarse: Qué funciono bien?

Qué cosas deberíamos intentar mejorar en la próxima iteración (sprint)? Qué lecciones hemos aprendido? Y MUY IMPORTANTE: contarle al Scrum Master, el Facilitador, cuales son los obstáculos previstos (para que se ponga a trabajar en removerlos) El objetivo es que gracias - y mediante - el ejercicio de Retrospectiva, todo el equipo de Scrum se beneficie de un crecimiento sostenido, en calidad, productividad, y motivación. Lo que suele suceder - lamentablemente - es que mucha gente dentro del proyecto piense que el ejercicio de Retrospectiva no sirve para mucho, y entonces desperdician ese tiempo (aunque suelen reservar ese espacio ya que creen que es una de las partes necesarias - por definición - de un Scrum). Para no perder el tiempo en una Retrospectiva, tenemos que focalizarnos en lograr Puntos de Acción por cada ítem, decidir que vamos a hacer al respecto. Algo debemos haber aprendido de la última iteración (sprint). Si la respuesta a todo es "Va Bien", "Hubo problemas", o expresiones no "accionables" o concretas, seguro será una pérdida de tiempo. La cuestión es no ver la Retrospectiva (en Agile, Cascada, lo que sea) como una reunión OBLIGATORIA sino como una NECESARIA. Hay varias formas de hacer las Retrospectivas entretenidas y hasta divertidas; hay muchas diferentes técnicas también, ninguna en particular más útil que la otra. Como la de la Estrella de Mar (que veremos luego).

Pero también es un problema hacerlo "divertido"; Hay muchos consultores, o programadores, que se toman sus trabajos muy enserio y que suelen esconderse o desconfiar si ven alguna actividad de grupo que parezca divertida. Pero necesitamos de esas cosas. Está claro. Organizar una reunión de Retrospectiva no es fácil. Hay que crear el ambiente y pensar en actividades para "extraer" la información y lograr puntos de acción. Una buena alternativa, para jugar un poco con los roles, es asignar a una persona distinta, cada tanto, para que haga de "Facilitador" de la Retrospectiva. Puede darse cuenta lo complicado que es, o puede extraer otro tipo de información del equipo. No solo se trate de escuchar lo que el equipo dice, sino también de lo que no dicen, de los gestos corporales, las inquietudes aparentes, o el tono de voz. El consejo que Norm Kerth - un gurú en estos temas - da, respecto a Retrospectivas, es intentar que todo el equipo vaya a ellas con el pensamiento de que cada uno de los demás presentes ha hecho lo mejor posible para lograr sus objetivos; evitar estar a la defensiva, pensando en los prejuicios o pre-conceptos que tenemos de esa persona, o que tienen una agenda (o plan ulterior) y que no es sincera. Es como que nos pusiéramos filtros, y realmente no "escuchamos".

Revisión del Sprint Sprint Review Al fin y al cabo, lo único importante en Scrum es lo que está "Terminado", lo que el cliente puede empezar a usar ya mismo si quisiera. Para eso, debemos pasar la Revisión del Sprint - Sprint Review. La reunión de "presentación" del Incremento, o en otras palabras, de lo que hemos logrado, del resultado del ciclo. El objetivo de la reunión de Revisión del Sprint es la de inspeccionar el Incremento, si es necesario volver a analizar la Lista de Producto (la lista general de tareas). Es una reunión informal, de máximo cuatro horas al mes (o dos horas si nuestro ciclo - o sprint - tiene dos semanas). En esta reunión tiene que participar todo el mundo: El Dueño de Producto, el Scrum Máster, el Equipo de Desarrollo... e incluso expertos del negocio, u otros invitados que puedan dar una opinión al respecto.

Lo fundamental es que en la reunión sólo mostraremos Software que esté funcionando. Que agregue valor al cliente. No mostraremos nada a medio terminar. Mi recomendación es preparar la presentación de forma que las pantallas se muestren o proyecten desde un segundo monitor, en especial si estamos mostrando algo en debugging. EVITAR QUE EL CLIENTE VEA EL CÓDIGO FUENTE en todo momento. Otra opción es capturar pantallas y hacer una presentación PowerPoint (aunque este último punto, lo de preparar una presentación, suele ser muy discutido ya que va a contramano del carácter "informal" que se espera de la reunión" Como decíamos, es ésta una reunión informal, para mostrar progresos y captar comentarios; refinar si acaso el Backlog. Otros conceptos para tener en cuenta en la Reunión de Revisión del Sprint: El Dueño del Producto es quien decide al final qué fue lo realmente "Terminado" y lo que aún no lo está. El Equipo de Desarrollo discute cuales fueron los problemas que se encontraron y cómo los resolvieron. Hay que hacer una demostración en pantalla de lo Terminado. Discutir unos momentos cómo luce ahora la Lista de Producto, y qué expectativas hay para el próximo Sprint con las experiencias del que acaba de terminar. Todos deben discutir sobre qué es lo próximo para hacer.

Recuerda: El resultado de esta reunión es una Lista de Producto (la general - insisto -) refinada, y ya una buena idea de qué ítems van a ser incluidos en la Lista de Tareas de Sprint del próximo ciclo. Es durante la reunión de Revisión del Sprint también que todos evalúan si la META del Sprint se ha cumplido o no.?? Recuerdan? La meta es aquel nombre - un tanto genérico - con el que bautizamos el objetivo que teníamos para ese ciclo. Y por último, insistir en una premisa: No se trata de cómo funciona la pantalla o el software en el que hemos trabajado, sino de qué valor tiene para el cliente, en qué le es útil. Hay que contarles historias, ejemplos, un poquito de actuar diferentes roles para que se entiendan los beneficios. Un poco de Show, pero... a no olvidarse, todo lo que se muestre tiene que estar funcionando. Típica Agenda: Reunión de Revisión 1. El Scrum Máster abre la reunión y recuerda a todos el objetivo de ella o o o Muestra lo que se ha conseguido Cuenta historias, la experiencia del usuario Pide opiniones a los presentes. Qué piensan del producto? 2. El Dueño de Producto explica cuáles eran "sus objetivos" para ese sprint o o o Describe la Meta del Sprint Explica por qué es tan importante esa meta para el negocio. Hace referencia a dónde estamos en el panorama del proyecto. 3. El Scrum Máster presenta el Sprint. o Cuenta la historia de cómo fue todo durante el período. Con qué problemas se encontraron, nuevos miembros del equipo, etc.

o Da un estado del Sprint y cuenta qué tareas se completaron, y cuáles se quitaron o modificaron. 4. Finalmente las Demos. El Equipo de Desarrollo elabora cada historia de usuario. o o o o El presentador explica qué se intentó hacer con esa historia de usuario. Demostrar el funcionamiento en el sistema real. Responder preguntas. Repetir este punto por cada historia de usuario. 5. El Scrum Máster cierra la reunión.

KANBAN KANBAN Un placer tener que escribir sobre Kanban. Pocas veces uno se encuentra con un sistema "nuevo" - por así decirlo - que pueda agregar mucha productividad a un equipo de trabajo. Así de útil resultó ser, en Proyectos Ágiles, una pizarra Kanban. Básicamente el término Kanban viene de Japón y significa más o menos "Tarjeta Visual", y en sí es un sistema que ya viene siendo usado hace sesenta años en la producción de productos y el abastecimiento de partes. Ahora bien, poniendo esos conceptos al servicio del software, nos encontramos con una metodología de

trabajo que nos permite hacer que las componentes vayan "fluyendo", lenta y sostenidamente, desde la concepción hasta la producción. A ver si puedo dar un ejemplo: En las metodologías Ágiles, como en Scrum, una de las partes importantes de cada ciclo o Sprint es cuando los desarrolladores escogen una tarea (o más) de la Lista de Pendientes. En Scrum esto se suele hacer de modo voluntario, de acuerdo a las capacidades de cada persona en el equipo. Ellas se encargan de llevar esa tarea a un nivel necesario (definido por lo que el equipo considera como "Terminado". Hasta ahí lo que sabíamos, y nos iba muy bien. En una pizarra Scrum, normal tenemos una columna para las tareas: Pendientes / En Desarrollo / Finalizadas. En Kanban, reemplazamos esa columna del medio "En Desarrollo" y la dividimos en tantas columnas como nuestro "flujo de trabajo" o Workflow necesite, por ejemplo en: Pendientes / Especificaciones / Diseño / Ejecución / Test / Finalizadas

Hasta ahí no parece que hiciéramos mucho más, pero el secreto está en que, de acuerdo a la capacidad de nuestro equipo, demos a cada columna un "Tope" de capacidad. Por ejemplo que no podamos estar "Diseñando" más de tres componentes en un momento dado, y que si quisiéramos meter un cuarto ítem, deberíamos mover a Ejecución alguno. De esa forma se crea un flujo de ítems que se van "empujando" unos a otros, como si fueran una cadena de producción hasta que se den por finalizadas todas las tareas. Terminaríamos con algo así: Pendientes (10)/ Especificaciones (3) / Diseño (3) / Ejecución (4) / Test (2) / Finalizadas La ventaja que tiene este modelo es que vamos generando ítems finalizados constantemente. Aquí algunos ejemplos (podemos ver arriba, donde está el nombre de la columna, la cantidad de ítems que puede aceptar)

La característica principal que tiene Kanban, es que limita el trabajo que se puede hacer en un momento dado. Es más realista que otros paradigmas.