Las ceremonias

Manteniéndose fiel a los principios del manifiesto ágil, Scrum obliga solo unas cuantas ceremonias, pero son obligatorias todas. Las juntas de Scrum tienen todas como característica principal que están estrictamente limitadas a los tiempos preestablecidos obligando a los involucrados a ser efectivos y hacer uso inteligente del tiempo. Es algo difícil de lograr, pero cuando se logra se obtiene la efectividad de los equipos; lo anterior sucede tan pronto como el 2do sprint y tan tarde como el 4to dependiendo de los impedimentos que se presenten y la agilidad que el equipo logra.

Las ceremonias son:

 La junta de planeación del sprint  El scrum diario

 La revisión del sprint  La retrospectiva del sprint. La junta de planeación del sprint

Scrum es un proceso cíclico de sprints donde el resultado de cada uno debe ser una pieza de software funcionando por encima de diagramás, textos de diseño, etc. Para lograr lo anterior de forma exitosa, la planeación es clave. Sin embargo se planea solamente el esfuerzo que se puede realizar durante la duración de un sprint. La reunión de planeación tiene dos objetivos:

 Definir el objetivo del sprint. Este objetivo es una descripción textual de una meta tipo SMART que tanto el dueño del producto, el scrum master y el resto del equipo puedan fácilmente visualizar.

 Hacer una estimación del tiempo de los requerimientos de más alta prioridad y seleccionar sobre esa base cuantos se pueden lograr terminar en el sprint. Para hacer lo anterior, el equipo y el scrum master desglosan las tareas de programación necesarias para poder considerar terminado cada uno de los requerimientos aceptados para el sprint.

El resultado de la planeación del sprint es lo siguiente:  La meta del sprint

La duración de la junta de plantación del sprint debe ser suficiente para poder hacer el análisis y las estimaciones de los requerimientos de más alta prioridad. Si es necesario, el dueño del producto debe re priorizar el backlog del producto para obtener lo que sea de más valor para la empresa. En general se puede obtener una buena plantación con un día completo de trabajo separado en 2 partes.

 Análisis, evaluación, re priorización y estimación del backlog del producto

 Desglose y estimación de las tareas de los requerimientos aceptados por el equipo. No se recomienda extender esta planeación más allá de un día laboral completo, scrum depende de que las fechas y los compromisos sean respetados por todos.

El Scrum diario

Las bases teóricas de scrum tienen su origen en el control empírico de procesos. Esté indica que la inspección frecuente y la adaptabilidad son clave para la creación de nuevos productos. Scrum facilita este principio por medio de la segunda ceremonia, el Scrum diario o junta de paraditos.

Esta junta de paraditos se conoce así porque se realiza prácticamente con todos los miembros del equipo parados alrededor de un pizarrón o pared de control del proyecto. Al igual que el resto de las ceremonias, el scrum diario está estrictamente limitado en su tiempo y para este caso es de 15 minutos, no más y no menos. Ocurre todos los días laborales a la misma hora y en el mismo lugar.

Cada uno de los miembros del equipo y el maestro scrum tienen la responsabilidad y obligación de asistir todos y cada uno de los scrum diarios, por ello un equipo scrum debe estar 100% dedicado al proyecto. El dueño del producto puede asistir para informarse sobre el proyecto, pero no esta obligado a responder las 3 preguntas.

Un aspecto clave de esta reunión es que cualquier interesado en el proyecto puede asistir a los scrums diarios con la única condición que no pueden interrumpir de ninguna forma el trabajo del equipo durante esos 15 minutos. Scrum provee diversos mecanismos por medio del cual los interesados en el proyecto pueden conocer el progreso del proyecto y agregar sus propios requerimientos al backlog del producto. La junta diaria de paraditos es uno de los mecanismos de transparencia de scrum y uno muy poderoso que no debe ser desaprovechado por los interesados o el dueño del producto.

Durante estos 15 minutos cada miembro del equipo responde a tres preguntas:  ¿Qué hiciste/lograste ayer?

 ¿Qué vas a hacer/lograr hoy?

 ¿Qué impedimentos tienes para lograrlo?

Las primeras 2 preguntas son en base a tareas del backlog del sprint. Los equipos scrum son auto-administrados y cada miembro toma libremente tareas de la lista del backlog del sprint en lugar de ser asignadas por el scrum master; por lo anterior, la respuesta a las primeras 2 preguntas giran alrededor de tareas que se lograron terminar en las ultimás 24 horas y cuales se pueden lograr durante las siguientes 24.

El desglose de cada requerimiento se hace en tareas que no son mayores a 12 horas o menores a 4; de forma que los miembros del equipo pueden comprometerse a terminar una o más tareas en el tiempo entre dos scrums o juntas de paraditos.

El scrum diario no debe convertirse o manejarse como el mecanismo tradicional de control y rendición de cuentas de un gerente de proyectos. Cada miembro del equipo en respuesta principalmente a la segunda pregunta asume un compromiso personal con cada uno de los miembros del equipo de terminar lo que dice que puede terminar. Si no puede terminarlo debe tener la honestidad, la integridad y el coraje de aceptar que no puede terminarlo, determinar que SI puede terminar y comprometerse a ello.

El maestro scrum tiene la responsabilidad de registrar los impedimentos que el equipo haya señalado y de eliminarlos a toda costa. Si la lista de impedimentos no se disminuye con cada scrum o si peor aún empieza a crecer, el maestro scrum no está haciendo una de sus funciones principales. En tal caso el equipo puede sugerir que se interrumpa el sprint de forma extraordinaria.

Cada miembro del equipo debe conocer a detalle lo relacionado con los requerimientos y en base a ese conocimiento se auto-asigna tareas y se compromete a terminarlas de un scrum a otro.

La redacción de las preguntas dice que hiciste ayer y que vas a hacer hoy, sin embargo en términos prácticos significan:

 ¿Qué hiciste/lograste desde el ultimo scrum y este?  ¿Qué vas a hacer/lograr entre este scrum y el siguiente? La revisión del sprint

La revisión del sprint se programa anticipadamente como resultado de la planeación del sprint, todo el equipo está enfocado en lograr la meta que se definió para el sprint, de ahí su nombre, scrum. Al final de los 30 días, el equipo hace una demostración de la funcionalidad de la pieza (o piezas) de software que se terminaron durante el sprint. Esta demostración se hace directamente en las computadoras del equipo de desarrollo sin mucha preparación previa. La preparación necesaria se hizo a lo largo del sprint y lo que se presenta es lo que interesa al dueño del producto y el resto de los interesados.\

Los invitados a esta reunión son:  El dueño del producto  El maestro scrum  Todo el equipo

 Cualquier interesado en el proyecto

La duración de esta demostración debe ser por lo menos de 4 horas y de 8 como máximo. El equipo de desarrollo hace las pruebas de funcionalidad para cada uno de los requerimientos aceptados para el sprint en la planeación que se hizo 30 días antes. Los asistentes hacen preguntas y discuten el resultado del sprint. Si se descubren nuevos requerimientos durante la revisión del sprint como resultado de la misma, estos se integran al backlog del producto para ser priorizados por el dueño del producto antes de la reunión de planeación del siguiente sprint. El dueño del producto debe aprovechar esta reunión para conocer las opiniones del resto de los interesados, integrar sus propios requerimientos y adaptar el proyecto en base a las nuevas condiciones (si las hay) del entorno de negocios. De esta forma se cumple con el segundo principio fundamental del control empírico de procesos, adaptabilidad. Cada 30 días se tiene la oportunidad de dirigir el esfuerzo de desarrollo y alinearlo a las necesidades actuales de la empresa.

Fundamental para esta y cualquier otra metodología es la retroalimentación, el aprendizaje y la experiencia. Después de la revisión del sprint, el equipo se reúne para evaluar el desempeño durante el sprint recién terminado y como se puede aprender de lo que acaba de terminar para mejorar lo que esta por empezar.

Cada uno de los miembros del equipo hace una retrospectiva del sprint contestando las siguientes preguntas:

 Que SI funciona para seguir haciéndolo...  Que NO funciona para dejar de hacerlo y...

 Que podemos empezar a hacer para que funcione MEJOR

4.5.4. Los artefactos o documentos

Muchos de los esfuerzos de formalizar el proceso de desarrollo de software han incluido la creación y mantenimiento de diversos "artefactos" documentales que pretenden dar tangibilidad a un proceso de producción de intangibles. La gestión tradicional de proyectos, resultado de los métodos predictivos de control de procesos no cuenta con las herramientas adecuadas para controlar el desarrollo de nuevos productos como lo es el software.

Scrum propone y obliga solo 3 documentos fundamentales que son usados tanto para gestionar el proyecto y sus tareas como para dar seguimiento, visibilidad y transparencia al proceso:

 El backlog del producto o bitácora priorizada de requerimientos  El backlog del sprint o bitácora priorizada de tareas

 La grafica de burndown

Se proponen documentos adicionales a los anteriores como la gráfica de Burnup, la bitácora de impedimentos y otros, sin embargo estos tres son fundamentales para el buen funcionamiento de un equipo Scrum.

El backlog del producto

Uno de los retos más grandes que ha enfrentado la ingeniería de software ha sido el análisis y definición de requerimientos; se han definido, estudiado, implementado y refinado diversos mecanismos para poder saber y registrar lo que el cliente quiere del software. El estudio y la experiencia nos han demostrado que frecuentemente, el cliente es el menos indicado para definir la solución de su problema y por ende la dificultad de conocer lo que necesita; es decir, si el mismo cliente no sabe lo que quiere, como podemos nosotros programarlo. Las metodologías tradicionales enseñan que los requerimientos deben fijarse al principio del proyecto y definirse de tal forma y con tal alcance que no haya dudas, mal entendidos o cambios en los mismos; he ahí la raíz del problema, si hay una constante en el universo es que las cosas cambian y no podemos esperar desarrollar sistemas funcionales y que den valor a nuestros clientes si exigimos una definición exhaustiva de los requerimientos y una congelación de los mismos mientras desarrollamos el producto.

Es ya muy conocido que el cliente al ver el producto visualiza la solución de forma distinta, es decir, la misma solución crea nuevos requerimientos o cambia los existentes. Querer obligar lo contrario es anti-natural y produce sistemas inflexibles que obligan al cliente a adaptarse al sistema. El manifiesto ágil abre las puertas del cielo e invita el cambio, lo provoca y lo incentiva. Scrum define el Backlog del Producto para este fin.

En su forma más esencial el Backlog del producto o bitácora de requerimientos es un simple listado de requerimientos expresados en forma de Historias de Usuario (User Stories) y estimados en alguna unidad representativa del tiempo. Este listado se puede fácilmente llevar y controlar en una hoja electrónica. Estas Historias de Usuario deben estar expresadas exclusivamente en el lenguaje del negocio y deben aportar un valor real al mismo que pueda ser definido y visualizado por cualquiera que conozca el dominio problema.

Este listado es priorizado por el dueño del producto de manera permanentemente y estimado por el equipo en cada reunión de planeación.

El backlog del producto debe incluir el mayor número de requerimientos (User Stories) que se puedan obtener de los usuarios y demás interesados del proyecto a través del dueño del producto y en base a las estimaciones del equipo de programación sirve para estimar el número de sprints necesarios para terminar con el proyecto u obtener versiones implementables en entornos productivos. El backlog del producto es la herramienta principal para desarrollar y estimar el plan de liberación del producto.

De este backlog el equipo selecciona los requerimientos de más alto nivel que puede completar en 30 días en base a su capacidad y velocidad de desarrollo y produce el siguiente artefacto documental del Scrum, el backlog del sprint.

El backlog del sprint

Una vez que el equipo de desarrollo se compromete a un conjunto finito de requerimientos del Backlog del producto, se definen y estiman las tareas de programación necesarias para cumplir con cada uno de los requerimientos aceptados para el sprint. Esta tarea de desglose de tareas es el equivalente al WBS (Work Breakdown Schedule) de la gestión tradicional de proyectos y solo puede ser realizado por el equipo de desarrollo, particularmente por los miembros que van a trabajar esos requerimientos.

La duración de cada una de las tareas se puede estimar en horas o en las mismas unidades que se estiman los elementos del backlog del producto. Al igual que las estimaciones del backlog del producto, estas no son compromisos para terminar en ese tiempo; más bien son estimaciones honestas de parte del equipo de desarrollo que podrán ser revisadas según se descubran detalles específicos del trabajo a realizar.

Las tareas de programación deben ser tareas específicas y suficientemente atómicas para que puedan ser completadas por un miembro del equipo en un día laboral típico o menos, es decir la estimación de la duración de la tarea debe ser entre 4 y 12 horas. Si es menor de 4 horas quizás sea necesario considerar esa tarea como parte de otra, si es mayor a 12 horas la tarea debe desglosarse un poco más. El objetivo es que se desglosen tareas a las que un miembro del equipo se pueda comprometer terminar de un scrum a otro.

La suma del trabajo de las tareas de un elemento del backlog del producto debe completar el 100% del requerimiento al que pertenecen. Es necesario considerar todas las tareas necesarias para considerar que el requerimiento ha sido completado a satisfacción; el significado de completado es más amplio que lo tradicionalmente entendido, hay que considerar el tiempo de diseño, programación, pruebas, documentación técnica y de usuario entre otras cosas. La definición de completado es un artículo en sí mismo y lo atenderemos por separado.

La gráfica de burndown

La gráfica de burndown es al mismo tiempo un mecanismo de control del proyecto y de transparencia del mismo. Este gráfico permite conocer de manera ágil y visual el progreso o no

de los trabajos del proyecto. Diariamente cada miembro del equipo de desarrollo actualiza la(s) tarea(s) en que está trabajando y estima de nuevo el tiempo necesario para terminar la tarea. La suma de las estimaciones de las tareas pendientes por terminar de cada día es graficada como un punto en la gráfica; en el eje horizontal se determina un punto por cada uno de los días del sprint y de esta forma se obtiene una imagen casi en tiempo real del progreso del trabajo del equipo de desarrollo.

Con el avance del sprint se obtienen suficientes puntos como para poder calcular una línea de tendencia que indica el éxito o fracaso del sprint mucho antes de la fecha de terminación y esto permite adaptar el trabajo del sprint para asegurar que el equipo termine el trabajo y que este sea el más importante.

Puesto que las re-estimaciones de las tareas se realizan de forma diaria y estas estimaciones pueden ser tanto a la baja como a la alta, la gráfica de burndown permite fotografiar el avance de forma diaria y conocer con suficiente anticipación cualquier tendencia fuera de lo normal y poder adaptar el proceso hacia el éxito.

Valores

Scrum es una metodología muy simple en su composición, sin embargo sus fundamentos teóricos y los valores en los que se fundamentan tienen implicaciones que van más allá de la simplicidad de sus componentes. Los valores de scrum y del manifiesto ágil son la goma que une a los personajes en las ceremonias y a través de los documentos y les permite cumplir con sus compromisos día a día, sprint a sprint hasta el éxito del proyecto.

 Compromiso

Estar dispuesto para comprometerse a una meta. La metodología la da a las personas la autoridad que necesitan para cumplir con sus compromisos.

 Enfoque

Haz tu trabajo. Enfoca todos tus esfuerzos y habilidades para trabajar en lo que te comprometiste a hacer. No te preocupes por nada más. Alguien lo hara por ti.

 Apertura / honestidad

SCRUM mantiene todo acerca del proyecto visible a todos.  Respeto

Los individuos estamos formados por nuestros orígenes y nuestras experiencias. Es importante respetar las diferentes a las personas del equipo y sus formas de pensar.

 Coraje

Resumen

1. Scrum es una metodología ágil de desarrollo de software que esta centrada en entregar la funcionalidad de más valor para el cliente en el tiempo más corto posible.

2. El "framework" scrum es simple en su composición, lo podemos ver como 3 grandes bloques principales

 Las personas  Las ceremonias

 Los documentos o artefactos

3. Manteniéndose fiel a los principios del manifiesto ágil, Scrum obliga solo unas cuantas ceremonias, pero son obligatorias todas.

Las ceremonias son:

 La junta de planeación del sprint  El scrum diario

 La revisión del sprint  La retrospectiva del sprint.

4. Scrum propone y obliga solo 3 documentos fundamentales que son usados tanto para gestionar el proyecto y sus tareas como para dar seguimiento, visibilidad y transparencia al proceso:

 El backlog del producto o bitácora priorizada de requerimientos  El backlog del sprint o bitácora priorizada de tareas

 La grafica de burndown

5. Scrum es una metodología muy simple en su composición, sin embargo sus fundamentos teóricos y los valores en los que se fundamentan tienen implicaciones que van más allá de la simplicidad de sus componentes.

 Compromiso  Enfoque

 Apertura / honestidad  Respeto

 Coraje

Pueden revisar los siguientes enlaces para ampliar los conceptos vistos en esta unidad:  http://cloud-america.com/?page_id=257

 http://www.computacionennube.org/

4.6. CLOUD COMPUTING