Preparando el escenario: Agiles y Scrum #scrum

Como mucha gente, nos entusiasma la adopción de Metodologías Agiles cuando trabajamos con proyectos de desarrollo de software, en particular la adopción de Scrum.

Para quienes hemos participado como Gerente de Proyectos con metodologías tradicionales para aplicar lineamientos de seguimiento y control, podremos observar que Scrum hace que el equipo de desarrollo de software alcance mejores rendimientos y niveles de productividad, debido Scrum nos enseña cómo dar unos pasos atrás para reflexionar sobre lo que hacemos y aprender a mejorar nuestras técnicas y procesos con nuevas ideas y conceptos.

Scrum nos ayuda a superar obstaculos, en forma ágil a traves del aprendizaje, todo cambio es dificil si no se gestiona adecuadamente, pero un buen manejo de las dificultades puede convertirse en oportunidades para mejora del proyecto.

¿Qué es la Fundación de Software Ágil Desarrollo y Gestión de Proyectos?

En 2001, un grupo de expertos en software se reunieron en la localidad de Utah, Snowbird para redactar lo que se conoce como el Manifiesto Ágil (www.agilemanifesto.org):

” Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:

a. Individuos e interacciones sobre procesos y herramientas
b. Software funcionando sobre documentación extensiva
c. Colaboración con el cliente sobre negociación contractual
d. Respuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.”

Los doce Principios del Manifiesto Ágil:

1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.

2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.

4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.

5. 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.

6. 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.

7. El software funcionando es la medida principal de progreso.

8. Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.

9. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.

10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

11. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.

12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

Aunque el Manifiesto Ágil se redactó en 2001, pocos años después de Scrum, es un hecho bien conocido entre los expertos que el manifesto tiene una gran influencia en Scrum.

Esta influencia fue evidente en el segundo libro de Ken Schwaber, Gestión ágil de proyectos con Scrum, siendo Scrum una de las metodologías ágiles con los valores y principios que se mencionan en el Manifiesto Ágil.

Es importante destacar en este momento la declaración de interdependencia realizada en el 2005 para Proyectos Agiles (http://pmdoi.org/index.html):

Los principios de esta declaración, que todo equipo de desarollo ágil debería asumir sin problemas, son:

“Nosotros…

1. Incrementamos el retorno de la inversión enfocándonos en lograr un contínuo flujo de valor.
2. Proporcionamos resultados fiables involucrando frecuentemente al cliente y compartiendo con el la propiedad del proyecto.
3. Esperamos incertidumbre y la manejamos mediante iteraciones, anticipación y adaptación.
4. Liberamos creatividad y motivación reconociendo a los individuos como la fuente última de valor y creando un entorno donde ellos puedan marcar la diferencia.
5. Impulsamos el rendimiento mediante la responsabilidad compartida en los resultados y efectividad del equipo.
6. Mejoramos la efectividad y la confianza mediante procesos, prácticas y estratégias especificas para cada situación.”

¿Como funciona Scrum?

Los Miembros del Equipo es uno de los Roles De Scrum. El equipo del proyecto es un grupo multi-funcional de personas con todas las habilidades diferentes que son necesarias para convertir los requerimientos en algo que es un incremento de una funcionalidad potencialmente productiva. Por lo tanto, usualmente consiste en:

  • analistas
  • diseñadores
  • encargados de Calidad (QA)
  • desarrolladores
  • documentadores
  • otras habilidades necesarias para realizar el trabajo

Este es el equipo que se compromete con el Dueño Del Producto en las tareas a realizar en cada iteración, y luego las hace. Al final de la iteración le muestran al Dueño Del Producto el resultado, de manera que pueda elegir cómo seguir.

Muchas organizacionse suelen tener un grupo de personas especializadas en distintos temas, como ser usabilidad, administradores de bases de datos, expertos en seguridad y arquitectos de sistemas. Cuando se necesita la participación de alguno de ellos, deberían pasar a formar parte del equipo. Es decir, no son parte de un grupo “externo” de expertos que dan consejos, sino que se convierten en miembros del equipo para aquellas iteraciones en las que es necesario construir una arquitectura, infraestructura o trabajar en la base de datos. Pueden estar trabajando o guiando, monitoreando a los miembros del equipo que hacen el trabajo.  Se comprometen al comienzo de la iteración junto al resto del equipo, y siguen con ellos hasta el fin de la iteración. Por lo tanto se convierten en cerdos por un período corto de tiempo.
Características

  • Multi-funcional.
  • Tamaño del equipo de entre 5 y 9 miembros.
  • Auto-Administrado, gestionado por los mismos miembros del equipo.
  • Responsabilidades

Las principales responsabilidades, más allá de la auto-organización y uso de tecnologías ágiles, son las que se derivan de la diferencia entre “grupo de trabajo” y “equipo”.

Un grupo de trabajo es un conjunto de personas que realizan un trabajo con una asignación específica de tareas, responsabilidades y siguiendo un proceso o pautas de ejecución. Los operarios de una cadena, forman un grupo de trabajo: aunque tienen un jefe común, y trabajan en la misma organización, cada uno responde de su trabajo.

El equipo tiene espíritu de colaboración, y un propósito común: conseguir el mayor valor posible para la visión del cliente.

Un equipo Scrum responde en su conjunto. Trabajan de forma cohesionada y auto-organizada. No hay un gestor que delimita, asigna y coordina las tareas. Son los propios miembros del equipo los que realizan estas funciones.

En el equipo:

  • Todos los miembros conocen comprenden la visión del propietario del producto.
  • Aportan y colaboran con el propietario del producto en el desarrollo de la pila de producto.
  • Comparten de forma conjunta el objetivo de cada sprint y la responsabilidad del logro.
  • Todos los miembros participan en las decisiones.
  • Se respetan las opiniones y aportaciones de todos
  • Todos conocen el modelo de trabajo con Scrum.

Entonces las responsabilidades son:

  • Selecciona el objetivo de la iteración y determina los resultados del trabajo
  • Tiene el derecho para hacer todo lo necesario (dentro de los límites de las guías del proyecto) para alcanzar el objetivo de la iteración
  • Se organiza a si mismo y a su trabajo
  • Realiza demostraciones del resultado del trabajo ante el Dueño Del Producto y los stakeholders.

 

Planificación Del Sprint

El propósito de un Sprint es convertir un set de items del Backlog Del Producto en un incremento de funcionalidad potencialmente productiva. El Dueño Del Producto, el Scrum Master y los Miembros Del Equipo De Scrum se reunen antes de cada Sprint para determinar en qué funcionalidad del producto se seguirá trabajando. El Dueño Del Producto presenta el Backlog Del Producto y el equipo selecciona lo que cree puede ser construido durante el Sprint.

La reunión de Planificación del Sprint consiste de dos partes, cada una de las cuales puede durar hasta cuatro horas.

1. Selección del backlog (Exposición): el Dueño Del Producto presenta el backlog de mayor prioridad al equipo de desarrollo. Juntos colaboran para acordar cuántos de estos items pueden convertirse en un Incremento Del Producto potencialmente productivo durante el próximo Sprint. El equipo realiza la Estimacion Del Sprint y selecciona todo lo que crea pueda realizar.

2. Planificación de trabajo del Sprint (Resolución): el equipo define la arquitectura y el diseño de la funcionalidad que fue seleccionada, y luego define el trabajo, o tareas que conformarán el Backlog Del Sprint, para construir dicha funcionalidad durante el próximo Sprint.

El tiempo que dura la Planificación del Sprint debería estar en correspondencia con la duración misma del Sprint (donde, por ejemplo, en un sprint de 2 semanas no se deberían usar más de 4 horas en total para la planificación).

Pre-condiciones

La organización tiene determinados los recursos posibles para llevar a cabo el sprint.

El propietario del producto tiene preparado el backlog del producto: con su criterio de prioridad para el negocio, y un nº suficiente de elementos para desarrollar en el sprint.

Siempre que sea posible el propietario del producto debe haber trabajado ya previamente con el equipo. De esta forma su estimación previa de qué cantidad de backlog de producto se puede desarrollar en el sprint será bastante ajustada.

El equipo tiene un conocimiento de las tecnologías empleadas, y del negocio del producto suficiente para realizar estimaciones basadas en “juicio de expertos”, y para comprender los conceptos del negocio que expone el propietario del producto.

Entradas

  • El backlog del producto
  • El producto desarrollado hasta la fecha a través de los sucesivos incrementos (excepto si se trata del primer sprint)
  • Circunstancias de las condiciones de negocio del cliente y del escenario tecnológico empleado.

Resultados

  • Backlog del sprint.
  • Duración del sprint y fecha de la reunión de revisión.
  • Objetivo del sprint.
  • Funciones del rol de Scrum Manager

El Scrum Manager es responsable y garante de:

  • Se realiza esta reunión antes de cada sprint.
  • Que antes de la reunión que el propietario del producto disponga de un backlog adecuado y suficiente para realizar el sprint.
  • Que el diálogo principal de la reunión se realice entre el propietario del producto y el equipo. Otros asistentes pueden participar, pero su colaboración no puede implicar toma de decisiones ni limitar el diálogo principal.
  • Que la reunión sea un trabajo de colaboración activa entre los dos protagonistas: cliente y equipo, y concluyen con un acuerdo sobre el incremento de producto que van a realizar en el sprint.
  • Que el equipo comprende la visión y necesidades de negocio del cliente.
  • Que el equipo ha realizado una descomposición y estimación del trabajo realistas y ha considerado las posibles tareas necesarias de análisis, investigación o apoyo.
  • Que al final de la reunión están objetivamente determinados:
  • Los elementos del backlog del producto que se van a ejecutar.

El objetivo del sprint.

  • El backlog del sprint con todas las tareas estimadas.
  • La duración del sprint y la fecha de la reunión de revisión.
  • El Scrum Manager modera la reunión para que no dure más de un día. Debe evitar que el equipo comience a profundizar en trabajos de análisis o arquitectura que son propios del sprint.

Creación de historias

El Dueño del Producto presenta las historias de usuario, las cuales se escriben con títulos que el equipo comprenda en los post-it amarillos grandes. Estos post-it se pegan en la mesa para que todos los vean. Cada post-it contiene 3 datos:
1. Nombre de la historia
2. Importancia
3. Estimación

Validación

El nombre de la historia es una muy breve frase o título que describe a la historia (por ejemplo, “exportación de saldos”, “alta de usuario”, “modificación de dirección de facturación”, etc.).

La importancia es un número positivo; mientras más grande el número más importante la historia (y deberá terminarse antes que historias de menor importancia). La importancia la indica el Dueño del Producto.

La estimación en principio se deja en blanco, ya que será completada más adelante (pero dentro de la misma reunión).

La validación será la forma que el Dueño del Producto dará por aceptada la historia en la reunión de Revisión (Demo del Producto).

Así, luego de la exposición del Dueño del Producto, se tiene cierto número de historias pegadas sobre la mesa, ordenadas por importancia.

El Equipo además puede agregar historias propias, generalmente técnicas, que considera necesarias para la ejecución del proyecto (por ejemplo, la creación de un repositorio de código).

Pizarra de Trabajo

Es recomendable, que el propietario del producto emplee una hoja de cálculo, alguna herramienta similar, o el soporte de una intranet, para guardar en formato digital la pila del producto. Pero no es aconsejable emplearla como base para trabajar sobre ella en la reunión proyectándola sobre la pantalla de la sala. Es mucho mejor trabajar y manipular elementos físicos; y usar una pizarra y fichas removibles (adhesivas, con chinchetas o magnéticas).

Un ejemplo de pizarra.

La pizarra es una herramienta para facilitar la comunicación y el trabajo de la reunión. Al final de la reunión el propietario del producto registrará en la hoja de cálculo, o en la herramienta que emplee, el estado y las modificaciones en el backlog del producto. El equipo hará lo mismo con backlog del sprint. Según la distribución y espacio de la oficina de trabajo quizá se reutilice la pizarra o las notas para el seguimiento del sprint; o quizá no. Este es un ejemplo, pero la pizarra, y el resto de las formas, son técnicas que ayudan a trabajar de forma ágil; no reglas estrictas. En cada caso se pueden ajustar o modificar según las características de la organización. Algunos soportes que se suelen emplear:

  • Pizarra blanca y fichas adhesivas tipo “Post-it”
  • Pizarra de corcho laminado y chinchetas para sujetar las fichas.
  • Pizarra de acero vitrificado y soportes magnéticos para sujetar las fichas.
  • Se puede conseguir una solución práctica y económica empleando fichas adhesivas (“Post-it”) y usando como pizarra cartón pluma blanco de 5mm. fijado con puntas directamente sobre la pared. El cartón pluma es un material ligero, de acabado satinado que puede adquirirse en tiendas de materiales para bellas artes y manualidades.
  • Ejemplo De Backlog Del Sprint

Daily Scrum

Cada día de un sprint, se realiza la reunión sobre el estado de un proyecto. Esto se llama “daily standup”. El scrum tiene unas guías específicas:

La reunión comienza puntualmente a su hora. A menudo hay castigos -acordados por el equipo- para quien llegue tarde (por ejemplo: dinero, flexiones, llevar colgando una gallina de plástico del cuello, etc)

Todos son bienvenidos, pero sólo los “cerdos” pueden hablar.

La reunión tiene una duración fija de 15 minutos, de forma independiente del tamaño del equipo.

Todos los asistentes deben mantenerse de pie (esto ayuda a mantener la reunión corta)

La reunión debe ocurrir en la misma ubicación y a la misma hora todos los días.

Durante la reunión, cada miembro del equipo contesta a tres preguntas:

  • ¿Qué has hecho desde ayer?
  • ¿Qué es lo que estás planeando hacer hoy?
  • ¿Has tenido algún problema que te haya impedido alcanzar tu objetivo? (Es el papel del ScrumMaster recordar estos impedimentos).

 

 

 

Autor: arevalomaria

Ingeniero de Sistemas, Magister en Gerencia y Tecnologia de la Informacion, Certificaciones: ITIL V3, CCNA, Microsoft Certified Professional.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s