Seminario de metodologías ágiles, bloque I

Metodologías Ágiles y Productividad

Autor: Juan Carlos Rubio Pineda

Creative Commons

Recursos utilizados para el curso

Este curso se realizó a partir de estos recursos: “Flexibilidad con Scrum”, Juan Palacio “Scrum Manager: Gestión de proyectos, v1.3”,

autores: Juan Palacio, Claudia Ruata “The new New product development Game”, artículo de Takeuchi & Nonaka “Kanban VS Scrum”: Henrik Kniberg & Mattias Skarin “Scrum y XP desde las trincheras”, Henrik Kniberg “The Pomodoro Technique”, Francisco Cirillo, autor de esta técnica Información de libre acceso sobre la técnica GTD (autor: David Allen): ThinkWasabi (es el blog de Berto Peña, escritor especializado en Organización,

Gestión Personal y Productividad). La información de GTD es 100% suya. Mi propia experiencia personal

lPuede contener variaciones y apreciaciones, fruto de mi propia interpretación y de mi propia experiencia (y por ello, errores, o quizás aportaciones)

Scrum: Orígenes I/II

Scrum es una metodología ágil para gestionar proyectos de software, que toma su nombre de los estudios realizados sobre nuevas prácticas de producción por Hirotaka Takeuchi e Ikujiro Nonaka a mediados de los 80 (Ikujiro & Takeuchi, 1986).

Aunque surgió como práctica en el desarrollo de productos tecnológicos, resulta válido en los entornos que trabajan con requisitos inestables, y necesitan rapidez y flexibilidad; situaciones habituales en el desarrollo de algunos sistemas de software.

Scrum: orígenes II/II

En 1993, Jeff Sutherland aplicó el modelo Scrum al desarrollo de software en Easel Corporation (Empresa que en los macro-juegos de compras y fusiones se integraría en VMARK, luego en Informix y finalmente en Ascential Software Corporation). En 1996, Jeff presentó, junto con Ken Schwaber, las prácticas que empleaba como proceso formal, para gestión del desarrollo de software en OOPSLA 96 (Schwaber & Sutherland, 1996). En 2001 formaron parte de los firmantes del Manifiesto Ágil. Las prácticas Schwaber y Sutherland están incluidas en la lista de modelos ágiles de Agile Alliance.

SOFTWARE PERSONAS Y PROCESOS

SOFTWARE PERSONAS Y PROCESOS

Formas de trabajar (madurez)A la buena de Dios (programación heroica): puede funcionar si y sólo si existe mucho talento entre los técnicos y buena auto-organización, pero sobre todo, de la motivación.

Usar una metodología orientada a procesos: organización madura.

Software personas y procesos

Ejemplo: montaje mueble IKEA. ¿Cómo sería según cada enfoque?

Software personas y procesos Factores clave de la gestión por procesos:– Repetitividad de resultados. Al conseguir que la calidad del

resultado sea consecuencia del proceso, producir aplicando el mismo proceso garantiza la homogeneidad de los resultados.

– Escalabilidad. No sólo un equipo consigue resultados homogéneos en todos los proyectos, sino que los obtienen todos los equipos de la empresa.

– Mejora continua. Aplicar medidas que mejoran de forma continua los procesos base, y por tanto de los resultados.

– Un know-how propio, consiguiendo la clave para hacer las cosas bien, con eficiencia y de forma homogénea

Relevancia del capital estructural yrelevancia del capital humano

Capital estructural: bienes que quedan en la empresa cuando las personas se van: patentes, licencias, equipos, cartera de clientes, maquinaria, etc. Capital humano: valor aportado por las personas.

Relevancia del capital estructural yrelevancia del capital humano

Las barras de color azul indican el potencial de cada activo según el sistema de producción del negocio (ej.- ¿dónde importa más el talento de un cocinero, en un restaurante francés (artesanía) o en una pizzería (p. industrial) ?

Las características del software

Puntos clave: Coste de la materia prima.• Maleabilidad del producto.• Valor aportado por las personas.• Factor de escala del producto (cómo varía los costes cuando se producen gran cantidad de unidades del producto).

Las características del software

Gris: capital estructural. Naranja: capital humano

Características del software

Coste materia prima: un ingeniero de software puede hacer un gran producto sólo con su intelecto. Ingenieros navales o arquitectos, no pueden. Maleabilidad: el software no es algo físico; lo podemos “moldear”. Valor aportado por las personas: El factor “personas” es una mezcla de “ejecución” y “talento”.

En el mundo del diseño informático, los mejores lo hacen entre 50 y 100 veces mejor que el promedio, y la cifra aumenta, conforme se incrementa la complejidad de la tecnología. Pilar Jericó: “La gestión del talento”

Factor de escala: El software tiene un factor de escala prácticamente infinito: cuesta lo mismo producir uno que mil.

Metodologías ágiles y optimización del tiempo

Scrum Management

Scrum Management

En los 80 y 90 comienza la primera base de conocimiento (metodologías “pesadas”):

Los modelos de procesos específicos: ISO9000-3 CMM’s, SPICE-ISO 15504 , Bootstrap, etc.

Aplicación del mismo patrón predictivo de gestión de proyectos, aplicado en otras ingenierías: PMI , IPMA

Primer borrador de consenso sobre el cuerpo de conocimiento de la Ingeniería del Software: SWEBOK (IEEE Computer Society, 2000).

Scrum Management

Elementos en un entorno de producción: Las personas, Los procedimentos La tecnología

CMMI: la calidad y la eficiencia de la producción se deben sobre todo a los procesos empleados. El Manifiesto Ágil, sin embargo, afirma en su primer enunciado que el protagonismo deben tenerlo las personas, y no los procesos.

Scrum Management

Los procedimientos de trabajo pueden ser: Procesos Rutinas

Scrum Management

Definiciones:

Cuando el procedimiento de trabajo contiene la mayor parte del conocimiento necesario para obtener el resultado (conocimiento explícito), se trata de un proceso.

Cuando son las personas las poseedoras del conocimiento clave para obtener el resultado (conocimiento tácito) entonces los procedimientos de trabajo son rutinas.

Scrum management

Criterios de referencia de la gestión por scrum:– Beneficio del trabajo en equipos pequeños (productividad,

comunicación directa)– Desarrollo incremental e iterativo (producción frecuente de

partes del producto que puede evaluar el cliente, integración y pruebas tempranas)

– Diseño de procesos o rutinas en función de la principal necesidad del proyecto: previsibilidad o creatividad e innovación.

– Grado de institucionalización de los procedimientos (procesos o rutinas) adecuado al tamaño y previsión de crecimiento de la organización.

– Gestión sistémica de la organización (organización como un TODO relacionado)


Scrum: Introducción a la práctica


Introducción al modelo (I / III):Scrum es una metodología ágil: Es un modo de desarrollo de carácter adaptable.

Énfasis en la capacidad de adaptación, más que en la finalización exacta según los plazos.

Orientado a las personas antes que a los procesos. Énfasis en las aportaciones, en el talento individual y de

grupo, más que en seguir ciegamente la metodología. Emplea desarrollo ágil: iterativo e incremental.

El software es un producto vivo, que no tiene valor como ente estático, sin capacidad de cambiar y adaptarse.


Introducción al modelo (II / III): El desarrollo de inicia desde la visión general del producto.

Sólo damos detalle a las funcionalidades que se van a desarrollar en primer lugar, por orden de máxima prioridad.

Sprint: iteración que produce un incremento terminado y operativo del producto (ciclo de desarrollo)

Dura entre 15-60 días (entre 2 y 8 semanas)


Introducción al modelo (III / III ): Las iteraciones o sprint’s son la base del modelo. Se revisa el trabajo realizado desde la reunión anterior y el previsto hasta la reunión siguiente. Las reuniones han de ser breves.

El protocolo de desarrollo de Software definido por Jeff S. y Ken S. define que debe haber reuniones de seguimiento de la iteración en curso DIARIAS (ver más adelante el significado del término: REUNIONES DE SEGUIMIENTO).

Scrum: Introducción a la práctica.

Control de la evolución del proyecto (I/II)Se controla con las siguientes prácticas: Revisión de las iteraciones o sprints

Tras un sprint, se convoca una revisión con todas las personas implicadas en el proyecto (responsables o representantes de cada área implicada).

Una revisión es el periodo máximo que se tarda en reconducir una desviación en el proyecto.

Desarrollo incremental: Se inspecciona y evalúa el producto operativo resultante de cada iteración. Desarrollo evolutivo: el diseño y la estructura del resultado se construyen de forma evolutiva (sigue…)


Control de la evolución del proyecto (II/II)(continuación…) ¿Para qué predecir los estados finales de la estructura, arquitectura o diseño si van a estar cambiando? Scrum toma a la inestabilidad como premisa.

Para evitar la degradación por la evolución continua, se deben incluir prácticas de refactorización periódicas en las tareas de diseño y codificación. (pEj, tras 3 iteraciones).

Ante imprevistos, la gestión predictiva confía la responsabilidad al gestor de proyectos. En Scrum los equipos son autoorganizados, con margen para tomar decisiones. Colaboración: Debe ser abierta entre todos según los conocimientos y capacidades de cada persona, y no según su rol o puesto.

Scrum: Iniciación a los componentes y conceptos

Visión general del proceso:


Los componentes y conceptos empleados en SCRUM son:

Las reuniones Los elementos Los roles o responsabilidades Las herramientas Conceptos y Métricas de control Los valores


Las reuniones: •Planificación del sprint: Jornada de trabajo previa al inicio de cada sprint en la que se determina cuál es el trabajo y los objetivos que se deben cubrir con esa iteración. Una vez cada 15 ó 60 días (al INICIO del sprint).

• Esta reunión genera la “sprint backlog” o lista de tareas que se van a realizar, y en ella también se determina el “objetivo del sprint”: lema que define la finalidad de negocio que se va a lograr.

•Seguimiento del sprint: Breve reunión diaria para dar repaso al avance de cada tarea, y al trabajo previsto para la jornada.

• Sólo interviene el equipo de desarrollo, y cada miembro responde a: • 1.- Trabajo realizado desde la reunión anterior. • 2.- Trabajo que se va a realizar hasta la próxima reunión de seguimiento. • 3.- Impedimentos que se deben solventar para que pueda realizar el trabajo, si existen.

•Revisión de sprint: Análisis y revisión del incremento generado. Esta reunión no debe tomarse como un “acontecimiento especial”, sino como la presentación normal de los resultados. Una vez cada 15 ó 60 días (al FINAL

del sprint).


Ilustración


Los elementos (I/II): Product Backlog: Es el inventario de características que el propietario final del producto desea obtener, ordenado por orden de prioridad, SEGÚN SU CRITERIO.

Es accesible a todas las personas que intervienen en el desarrollo. Todos pueden contribuir y aportar sugerencias.

El responsable del product backlog es una única persona y se le denomina: propietario del producto.

Conocedora del entorno de negocio del cliente y de la visión del producto. No es un desarrollador del equipo. Es el cliente.


Los elementos (II/II) Sprint Backlog: Lista de los trabajos que realizará el equipo durante el sprint para generar el incremento previsto.

El equipo asume el compromiso de la ejecución. Las tareas están asignadas a personas, y tienen estimados el tiempo y los recursos necesarios.

Incremento: Resultado de cada sprint. Diferencia perceptible de una versión a otra del

producto.


Los roles o responsabilidades (I / III ) Grado de funcionamiento en la organización: depende directamente de estas tres condiciones:

Características del entorno (organización y proyecto) adecuadas para desarrollo ágil.

Conocimiento de la metodología de trabajo en todas las personas de la organización y las implicadas del cliente.

Asignación de responsabilidades: Del producto. Del desarrollo. Del funcionamiento de Scrum


Los roles o responsabilidades (II / III) Propietario del producto: En el proyecto hay una persona, y sólo una, conocedora del entorno de negocio del cliente y de la visión del producto, que actúa como intermediario.

Se le denomina propietario del producto Es responsable de la financiación necesaria para el

proyecto Es el responsable del proceso de adquisición del

cliente.


Los roles o responsabilidades (III / III ) Responsabilidad del desarrollo: El equipo

Todo el equipo de desarrollo, incluido el propietario del producto conoce la metodología Scrum, y son los auténticos responsables del resultado.

Responsabilidad del funcionamiento de Scrum (scrum manager)

En el modelo de Scrum definido por Jeff Sutherland, esta responsabilidad se garantiza integrando en el equipo una persona con el rol de ScrumMaster

Scrum: Iniciación a los componentes y conceptosHerramientas (I/III)

Gráfico Burn-Up: Presenta las versiones de producto previstas, las funcionalidades de cada una, velocidad estimada, fechas probables para cada versión, margen de error previsto en las estimaciones, y avance real.


Herramientas (II/III)Gráfico Burn-Down: Representación gráfica del avance del sprint. Un sprint estaría representado por la diagonal que reduce el esfuerzo pendiente en horas de forma continua y gradual hasta terminarlo en el último día del sprint:


•Herramientas (III/III) Juegos y protocolos de decisión:

Estimación de póker: Juego para agilizar y conducir la estimación de las tareas en la reunión de inicio del sprint.

Evita las reuniones que se eternizan; se usan cartas que representan días de esfuerzo

Si es más de 10 horas, se usa la carta INFINITO. Variante: sucesión de Fibonacci (0,1,1,2,3,5,8, etc)

El juego de cartas está compuesto por números de la sucesión de Fibonacci.

La estimación no se realiza levantando varias cartas para componer la cifra exacta, sino poniendo boca arriba la carta con la cifra más aproximada a la estimación.


Conceptos y métricas (I/III) Tiempo real o tiempo de trabajo: Tiempo efectivo para

realizar un trabajo. Se suele medir en horas o días. Tiempo teórico o tiempo de tarea (también llamado

tiempo IDEAL): Tiempo que sería necesario para realizar un trabajo en “condiciones ideales”: si no se produjera ninguna interrupción, llamadas telefónicas, descansos, reuniones, etc.

Puntos de función o puntos de funcionalidad: Unidad de medida relativa para determinar la cantidad de trabajo necesaria para construir una funcionalidad o historia de usuario del product backlog. Por ejemplo, en horas ideales.


Conceptos y métricas (II/III) Estimaciones: Cálculo del esfuerzo que se prevé necesario para desarrollar una funcionalidad. Las estimaciones se pueden calcular en unidades relativas (puntos de función) o en unidades absolutas (tiempo teórico). Velocidad absoluta: Cantidad de producto construido en un sprint. Se expresa en la misma unidad en la que se realizan las estimaciones (puntos de función, horas o días reales o teóricos). Velocidad relativa: Cantidad de producto construido en una unidad de tiempo de trabajo. P. ej.: puntos de función / semana de trabajo real; ó horas teóricas / día de trabajo real…


Conceptos y métricas (III/III) Valores: Las prácticas de Scrum son una “carrocería”. La carrocería sin motor, sin los “valores” (motor del desarrollo ágil), no funciona. Estos son:

Delegación de atribuciones (empowerment) al equipo que le permita auto-organizarse y tomar las decisiones sobre el desarrollo.

Respeto entre las personas. Los miembros del equipo deben confiar entre ellos y respetar sus conocimientos y capacidades.

Responsabilidad y auto-disciplina (no disciplina impuesta). Trabajo centrado en el desarrollo de lo comprometido información, transparencia y visibilidad del desarrollo del proyecto


Scrum: los elementos


Los principales elementos de Scrum son: •Product Backlog. Lista de las funcionalidades que necesita el cliente, priorizada según lo que él (propietario del producto) determine.•Sprint Backlog: Lista de tareas que se van a realizar en un sprint. •Incremento: Parte del sistema desarrollada en un sprint.


Los requisitos en el desarrollo ágil: La ingeniería del software clásica diferencia dos áreas de requisitos Requisitos del sistema Requisitos del software


Proyectos predictivos VS proyectos ágiles: Especificación de requisitos de sistema:

En P. Predictivos los requisitos de sistema se especifican en documentos formales.

En P. Ágiles el product backlog se convierte en lista de historias de usuario (ePics).

Desarrollo de los Requisitos de sistema: En P. Predictivos, los requisitos son recogidos del cliente por

un equipo especializado en ingeniería de requisitos, directamente con el cliente.

En P. Ágiles, la visión del cliente es conocida por todo el equipo (el cliente, “forma parte del equipo”).


En SCRUM, lo que se incluye o no en el product backlog, y el orden de prioridad, son responsabilidad del cliente.


Requisitos y visión del producto Scrum para software emplea dos formatos para el registro y comunicación de los requisitos:

Product Backlog Sprint Backlog

Para que Scrum alcance niveles elevados de eficiencia cuando responde a una visión clara, conocida y compartida por todo el equipo, tanto a nivel de producto en general (visión del producto) como del sprint en que

se está trabajando (objetivo del sprint).


Product Backlog: los requisitos del cliente El product backlog es el inventario de funcionalidades,

mejoras, tecnología y corrección de errores que deben incorporarse al producto a través de las sucesivas iteraciones de desarrollo.

Representa todo aquello que esperan los clientes, usuarios, y en general los interesados en el producto. Todo lo que suponga un trabajo que debe realizar el equipo tiene que estar reflejado en el backlog.

Nunca se da por completo; está en continuo crecimiento y evolución.

[…] mientras el producto esté en el mercado, para darle valor y mantenerlo útil y competitivo.


Estos son algunos ejemplos de posibles entradas de un backlog:

Permitir a los usuarios la consulta de las obras publicadas por un determinado autor.

Reducir el tiempo de instalación del programa. Mejorar la escalabilidad del sistema. Permitir la consulta de una obra a través de un API

web.


Product Backlog:


Formato del product backlogSe recomienda formato de lista que incluya al menos la siguiente información para cada línea:

Identificador único de la funcionalidad o trabajo. Descripción de la funcionalidad. Campo o sistema de priorización. Estimación

Notas Puede tener otros campos (observaciones, persona asignada, etc.) El formato del product backlog no es cerrado. Los resultados de Scrum no dependen de la rigidez en la aplicación del

protocolo, sino de la institucionalización de sus principios


Ejemplos:


Sprint backlog Realizado de forma conjunta por todos los miembros

del equipo. Cubre todas las tareas identificadas por el equipo para

conseguir el objetivo del sprint. Sólo el equipo lo puede modificar durante el sprint. El tamaño de cada tarea está en un rango de 4 á 16

horas de trabajo. Es visible para todo el equipo. Idealmente en una

pizarra o pared en el mismo espacio físico donde trabaja el equipo.


Formato y soporte Hoja de cálculo. Pizarra o pared física. Herramienta colaborativa o de gestión de proyectos.

Esta última será nuestra opción. Usaremos nuestra versión modificada del software FLYSPRAY. Otras opciones: mantenerlo en la nube, como por ejemplo, con basecamp:http://basecamphq.com

http://basecamphq.com/?referrer=YT30B7


Criterios para elegir la herramienta: Incluye la información: lista de tareas, persona

responsable de cada una, estado en el que se encuentra y tiempo de trabajo que queda para completarla.

Sólo incluye la información estrictamente necesaria. El medio elegido es la opción que más facilita la

consulta y comunicación diaria y directa del equipo. Sirve de soporte para registrar en cada reunión diaria

del sprint, el tiempo que le queda a cada tarea.


Ejemplos: H.Cálculo VS Pizarra


El incremento Parte de producto realizada en un sprint, y potencialmente entregable: TERMINADA Y PROBADA (con documentación, con verificaciones, etc.). No se refiere a trabajos internos del tipo “diseño de la base de datos” Se produce un “incremento” en cada iteración.


Las reunionesTres reuniones que forman parte del modelo:

Planificación del sprint Monitorización del sprint Revisión del sprint

Scrum: los elementos: planificación


Planificación del Sprint Consiste en dos reuniones:

En la primera (EXPOSICIÓN), con el cliente, que puede tener una duración de una a cuatro horas, se decide qué elementos del product backlog se van a desarrollar

En la segunda (RESOLUCIÓN), en la que se puede prescindir del cliente*, se desglosan éstos para determinar las tareas necesarias, estimar el esfuerzo que necesita cada una y asignarlas a las personas del equipo.

La planificación del sprint no debe durar más de un día.


Reunión de planificación: EXPOSICIÓN (I/III)Pre-condiciones:

La organización (desarrolladora) tiene determinados los recursos posibles para llevar a cabo el sprint (personal y otros).

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

Si el propietario del producto debe haber trabajado ya previamente con el equipo, su estimación de qué cantidad de producto se puede desarrollar en el sprint será bastante ajustada => EXPERIENCIA.

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


Reunión de planificación: EXPOSICIÓN (II/III)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.


Reunión de planificación: RESOLUCIÓN (III/III)Resultados:

Backlog del sprint. Duración del sprint y fecha de la reunión de

la revisión. Objetivo del sprint.


Formato de la reunión de planificación Esta reunión marca el inicio de cada sprint. Un Scrum Manager (pEj el Scrum Master del

proyecto) es el responsable de su organización y gestión. Duración máxima: un día.

Deben asistir: el propietario del producto, el equipo y el Scrum Manager.

Pueden asistir: es una reunión abierta a todos los que puedan aportar información útil. Consta de dos partes separadas por una pausa de café o comida.


Reunión de planificación: Primera parte: EXPOSICIÓN: funciones de cada ROL

(NOTA: Duración de 1 a 4 horas. ) Propietario del producto:

Presenta las funcionalidades del backlog del producto que tienen mayor prioridad y que estima se pueden realizar en el sprint.

Equipo: El equipo realiza las preguntas y solicita las aclaraciones necesarias.

Propone sugerencias, modificaciones y soluciones alternativas. Las aportaciones del equipo pueden/deben suponer modificaciones en el backlog.

El equipo define el “objetivo del sprint” o fase que define de forma sintética cuál es el valor que se le aportará al producto.


Reunión de planificación, RESOLUCIÓN. FUNCIONES DE CADA ROL: El papel del propietario del producto en esta parte es atender a dudas. Depende del proyecto, y del cliente, que sea aconsejable o no que esté. La experiencia lo determina. El equipo:

desglosa cada funcionalidad en tareas, y estima el tiempo para cada una de ellas.

Los miembros del equipo se auto-asignan las diferentes tareas teniendo como criterios sus conocimientos, intereses y distribución homogénea del trabajo.

El scrum manager: modera la reunión, pudiendo alterar la asignación de tareas.


Funciones del rol de Scrum Manager (I/)1.- Que se realiza la reunión de planificación antes de cada sprint.2.-Que antes de la reunión, el propietario del producto disponga de un backlog3.- Que el diálogo principal de la reunión se realice entre el propietario del producto y el equipo. Otros asistentes pueden participar, pero sin toma de decisiones ni limitar el diálogo principal.

(SIGUE...)


Funciones del rol de Scrum Manager (II/)4.- Que la reunión sea un trabajo de colaboración activa entre cliente y equipo, y concluyen con el incremento de producto que van a realizar en el sprint. 5.- Que el equipo comprende la visión y necesidades de negocio del cliente. 6.- 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.

(SIGUE...).


Funciones del rol de Scrum Manager (II/)7.- Que al final de la reunión están objetivamente determinados:

Los elementos de la pila o partes del producto que se van a ejecutar.

El objetivo del sprint. La pila de sprint con todas las tareas estimadas y

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


Pizarra de trabajo Es recomendable emplear una hoja de cálculo, o el soporte de otra herramienta para guardar en formato digital la pila del producto. Se supone que hay dos pizarras, la que emplea propietario del producto y la que usa el Scrum Manager para el Sprint Backlog 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/notas removibles.

Lo más barato y útil en mi opinión, es una pizarra de corcho, donde pinchamos los post-its u octavillas (incluso de papel reciclado) y los movemos. Así da igual el adhesivo y podemos cambiarlos muchas veces de sitio. Además, se puede hacer tan grande como necesitemos, pues se venden rollos de corcho como si fuera papel de vinilo.

Para cambiar la prioridad de las tareas basta con cambiarlas de sitio.


En la pizarra, se delimita: Un área superior donde el Scrum Manager coloca:

A: al principio de la reunión la capacidad del sprint a 3, 4 y 5 semanas

D: al final, las notas con: el objetivo establecido, duración del sprint, funcionalidades de la pila del producto comprometidas, hora fijada para las reuniones diarias y fecha prevista para la reunión de revisión del sprint.

B.- Una franja para ordenar los elementos de la pila del producto de mayor a menor prioridad. C.- Una franja paralela para descomponer cada elemento de la pila del producto en las correspondientes tareas de la pila del sprint.


A


B


C


D

Scrum: los elementos: monitorización

Monitorización del Sprint (Reunión de seguimiento)Reunión diaria breve, de no más de 15 minutos en la que todos los miembros del equipo dicen las tareas en las que están trabajando, si se han encontrado o prevén encontrarse con algún impedimento y actualizan sobre el sprint backlog las tareas ya terminadas o los tiempos de trabajo que les quedan.


Monitorización del Sprint (R. Seguimiento): Pre-condiciones Disponibilidad de un lugar físico en la organización para realizar diariamente la reunión. Sprint backlog actualizado en el soporte que emplee el equipo (dibujado en pizarra, con post-it’s, sobre hoja de cálculo…)

IMPORTANTE: recordemos que PUEDEN existir dos pizarras, la que ve el cliente, y la nuestra (más técnica)

Asiste todo el equipo Asiste un responsable con rol de Scrum Manager Un miembro del equipo (team leader o Scrum Master – puede coincidir con Scrum Manager -) conduce y garantiza el protocolo, formato y tiempos de la reunión.


Monitorización del Sprint: Entradas• Sprint Backlog y gráfico Burn-down actualizados con la

información de la reunión anterior. • Información de las tareas realizadas por cada componente

del equipo Monitorización del Sprint: Resultados:

• Backlog y gráfico de avance (Burn-down) actualizados. • Identificación de necesidades e impedimentos.

• Necesidades que tiene que intentar remediar el Scrum Manager.


Monitorización del Sprint: formato de la reuniónCada miembros del equipo expone

1. Tarea en la que trabajaron ayer. 2. Tarea o tareas en las que trabajarán hoy. 3. Si van a necesitar alguna cosa especial o prevén algún

impedimento.Al final de la reunión:

1. El team leader actualiza el gráfico de avance del sprint. 2. El Scrum Manager (responsable gestión procesos / calidad)

gestiona necesidades e impedimentos.

Scrum: los elementos: Revisón

Revisión del Sprint Reunión que se realiza al final de cada sprint (de 4 horas máximo) en la que el equipo muestra el incremento construido, y se genera feedback entre todos los participantes para preparar el product backlog para el inicio del siguiente sprint.


Reunión de revisión: Pre-condiciones Se ha concluido el sprint. Asiste todo el equipo de desarrollo, el propietario del

producto, el responsable de procesos / calidad de la empresa (Scrum Manager) y todas las personas implicadas en el proyecto que lo deseen (sin voz ni voto)

Entradas Incremento terminado.


Reunión de revisión: Resultados Feedback para el propietario del producto:

Hito de seguimiento de la construcción del sistema. Información para mejorar el valor del producto.

Feedback para el responsable de procesos (Scrum Manager):

Buenas prácticas del sprint Problemas durante el sprint.

Convocatoria de la reunión del siguiente sprint.


Reunión de revisión: formato Es una reunión informal con el objetivo de ver el

incremento y trabajar en el entorno del cliente. Sin presentaciones gráficas ni “powerpoints”. El equipo no debe invertir más de una hora, y lo que se

muestra es el resultado final: terminado, probado y operando en el entorno del cliente (incremento)

El resto del tiempo (hasta cumplir las 4 horas) corresponde a resolver las cuestiones del cliente.

Scrum manager: los elementos: herramientas

Las herramientas (I/II):Gráfico Burn-Up Es una herramienta de planificación y seguimiento del propietario del producto, que muestra en un gráfico muy simple el plan general de desarrollo del producto, y la traza de su evolución.


Partimos de la estimación de esfuerzo en product backlog


Explicación: El eje Y representa el esfuerzo (en puntos de función u otra

métrica), y sobre él se marcan los hitos de versiones previstas en el backlog.

El eje X representa el tiempo de desarrollo con las fechas de los sprints previstos.

La línea que representa la velocidad de desarrollo estimada del equipo se obtiene sobre el histórico de velocidad en proyectos o sprints anteriores (la primera vez, tiempo real estimado, partido por tres; ver ejemplo).

Si las estimaciones se realizan considerando valores optimistas y pesimistas de velocidad, se pueden obtener rango de fechas probables.


Ejemplo: Para un equipo de 5 personas y sprints de 20 días laborables, el tiempo disponible es de: 5 * 20 = 100 días disponibles. Velocidad previsible (un tercio): 100/3 = 33 días laborables, por 8 horas laborables = 264 horas

Otra opción, más optimista, considerar velocidad estimada un 20% por debajo: 100*4/5 = 80 días, por 8 horas = 640 horas útiles. La diferencia entre un equipo mediocre y uno apto, es significativa.


Las herramientas (I/II):Gráfico Burn-Down Herramienta de seguimiento para el equipo, que muestra el avance del sprint día a día y revela de forma temprana posibles desviaciones. Representa en el eje X los días laborables del sprint, y en el Y la cantidad de esfuerzo estimada.


Explicación: En la reunión diaria cada miembro del equipo actualiza

en el sprint backlog si ha terminado alguna de las tareas en las que ha trabajado, o cuánto esfuerzo estima que les quedan

Al final de la reunión la columna del día del sprint backlog muestra el esfuerzo que según el equipo falta para terminar el sprint (se actualiza la gráfica en consecuencia)


• Ideal: línea punteada• Por encima: subestimación del backlog.• Por debajo: sobre estimación del backlog.


Scrum Management: RESPONSABILIDADES

Scrum management: responsabilidades

Cambio a Scrum: Algunas organizaciones abordan el cambio en la capa de las formas de trabajo: incorporan backlogs, reuniones de Scrum, gráficos de seguimiento y desarrollo en intervalos cortos.

Mejora pequeña Otras saben también necesita una cultura adecuada en la organización.

PERO: el objetivo tampoco es trabajar de forma ágil (¿y el resto? Valores, compartir conocimiento, etc)

El objetivo es trabajar de la forma más adecuada a las características de la empresa y del tipo de trabajos que desarrolla (mejorar en la organización del trabajo y cómo nos enfrentamos a él)


Scrum es un éxito si se implican tres áreas: Management o gestión de la organización Calidad o procesos Producción


Responsabilidades de Management Equilibrio sistémico de la empresa (alineación total con la visión, misión y “negocio” de la empresa). Coherencia del modelo Medios y formación para incorporar prácticas ágiles


Responsabilidades de procesosConfiguración de Scrum: se diseñan las formas y prácticas ágiles más adecuadas.

Mejora continua de la configuración de Scrum (uso de feedbacks)

Garantía de funcionamiento de Scrum: Se identifican, periódicamente:

Impedimentos en los proyectos para que el equipo pueda llevar a cabo el objetivo del sprint.

Prácticas o decisiones en la organización que impiden o dificultan la metodología Scrum.


Responsabilidades de producciónVisión del producto: el cliente impone las restricciones, funcionalidades y prioridadesAuto-organización: equipo autogestionado (“tutorizado” por team leader y scrum master, pero aportan como un miembro más en la mayoría de las ocasiones).Tecnología ágil: Aplicación de integración continua, pruebas automáticas, refactorización…


¿Responsabilidades o roles? Resulta más difícil integrar Scrum en la empresa, si el modelo prescribe roles fijos que suelen suponer modificaciones en la estructura organizativa. Para lograr trabajo de equipo es más importante pensar en las responsabilidades de toda la organización que en los roles del equipo.

Scrum: conclusiones

¿Cuáles son, entonces, las preferencias en una metodología ágil como Scrum?

Prioridad

Personas y su interaccción Procesos y herramientas

Software que funciona Documentación exhaustiva

Colaboración con el cliente Negociación contractual

Respuesta al cambio Seguimiento de un plan

Scum: conclusiones¿En qué podemos basarnos para elegir una

metodología adaptable o predictiva?ADAPTABLE PREDICTIVA

Prioridad de negocio Valor Cumplimiento

Estabilidad de requisitos Entorno inestable Entorno estable

Rigidez del producto Modificable Difícil de modificar

Coste del prototipado Bajo Alto

Criticidad del sistema Bajo Alto

Tamaño del equipo Pequeño Grande

Metodologías Ágiles y gestión del tiempo

Kanban

Kanban

<<El trabajo se expande hasta llenar el tiempo disponible para que se termine.>>

Ley de Parkinson Kanban es un sistema de señalización para

comunicar información relativa y necesaria en la ejecución o monitorización de un trabajo.

Su autor es Taichi Ohno, que lo creó a principios de los 50 en los centros de producción de Toyota en Japón.

Kanban

Kanban

Kanban no es un modelo o marco de gestión, sino una herramienta de señalización. No hay por tanto un formato cerrado de tarjetas o tableros kanban

Concepto WIP: “WIP”(Work In Process”) delimita el número máximo de tareas o de historias que pueden estar de forma simultánea en el estado “en curso”.

Los estados básicos que se suelen representar en un tablero kanban son “pendiente”, “en curso” y “terminada”.

Kanban Produce un ritmo sostenido y evita la ley de Parkinson.

Si no se puede trabjar con sprints, porque tenemos entrada contínua de tareas urgentes, es necesario un mecanismo de trabajo SOSTENIDO.

lEjemplo de uso: autogestión de equipo

Kanban

Kanban box

La organización mantiene una “pila de producción” o lista de historias de usuario (ePics), pendientes,estimadas y priorizadas.

Si la organización trabaja en un único producto, la“pila de producción” es en definitiva la pila del producto o product backlog.

Una historia se representa en una caja:

kanban

kanbanKanban Box: en cada caja se representa: Puntos totales de esfuerzo estimados

Tarjetas con las tareas

Un fondo de escala graduado con los puntos totales de esfuerzo estimados

Barra dibujada con rotulador “borrable” que representa la velocidad prevista

Barra de velocidad real

Una descripción de la historia de usuario.

kanban

¿Qué cantidad de trabajo o tareas pueden realizarse simultáneamente?

– Empezar con un WIP igual al número de miembros del equipo x 1.5, redondeando el resultado por exceso, o x2.

– En ningún caso es aconsejable trabajar con tareas de tamaño que se prevea superior a un día de trabajo, y si esto ocurre lo aconsejable es dividirlas en otras de menor tamaño.

– TAMAÑO MÁXIMO DE UNA TAREA: 1 DÍA DE TRABAJO

– Conclusión: KANBAN LIMITA EL NÚMERO DE TAREAS EN PROCESO. Con la práctica, encontraremos nuestro WIP idóneo.

Scrum VS Kanban

¿Cómo se relacionan entre sí?

Scrum vs kanban

¿Qué herramienta utilizar? Depende. A veces Scrum, a veces Kanban, a veces

la mezcla de ambas. Por ejemplo, Scrum te obliga a tener iteraciones de

duración fija y equipos interdisciplinarios, y Kanban te obliga a usar tableros visibles y a limitar el tamaño de tus colas.

Scrum prescribe el uso de iteraciones de duración fija, Kanban no.

Kanban: tamaño máximo de una tarea, 1 día (8 horas). En SCRUM, el tamaño máximo son 16h.

Scrum vs kanban

Scrum vs kanban

Scrum prescribe 3 roles: Product Owner o dueño de producto (establece la

visión del producto y las prioridades), Equipo (implementa el producto) y Scrum Manager (elimina los impedimentos y

proporciona liderazgo en el proceso).

Kanban no establece ningún rol.

Combinemos lo que nos interese. Veamos algunos ejemplos

Scrum VS Kanban

lEquipo 1: hacemos iteraciones SCRUM:

Scrum vs kanban

Equipo 2: Cada semana entregamos lo que está listo para su entrega. Cada dos semanas tenemos una reunión de planificación, actualización de nuestras prioridades y los planes de entrega. Cada cuarta semana tenemos una reunión retrospectiva o de revisión para modificar y mejorar nuestro proceso".

Scrum vs kanban

Equipo 3: por eventos.- Lanzamos una reunión de planificación cada vez que comenzamos a quedarnos sin cosas que hacer. Lanzamos una entrega siempre que hay un conjunto mínimo de características listo para entregar. Lanzamos un círculo de calidad espontáneo siempre que nos topamos con un mismo problema por segunda vez. Además hacemos una revisión más en profundidad cada cuatro semanas.

Scrum vs kanban

Cuestiones: Scrum dice que debemos tener equipos

multidisciplinares. Entonces, ¿Quién debe estar en cada equipo? No lo sé, experimenta.

Scrum dice que el equipo selecciona cuanto trabajo incluir en un sprint. Entonces, ¿Cuánto deben incluir? No lo sé, experimenta.

Kanban dice que debemos limitar en trabajo en curso. Entonces, ¿Cuál debe ser ese límite? No lo sé, experimenta.

Scrum vs kanban

Diferencia de tableros

Scrum vs kanban

Tanto SCRUM como kanban permiten el trabajo de varios “productos” a la vez. Una recomendación es con tarjetas de diferente color y diferentes filas:

Scrum vs kanban

Un ejemplo real

Scrum VS Kanban

Simple kanban

Scrum VS Kanban

lFuente del tablero:P_Q,F16,Arreglar problema Web ServiceP,F3,Eliminar duplicidad clave 01.23 en CVNPdfD_Q,F13,Chequear doctores activosD,F17,Do Comprobar introducción datos formulario siform01DE,F18,Eliminar capacidad de duplicidad de producciónDE,F7,Alta de grupos con más de 3 doctores activosDE,F10,Cambio de direcciones de correo de asistencia según provinciaDE,F39,Mejora de la velocidad de carga de las páginas: cambio en los gráficosDE,F4,Reconstruir la clase cliente del WS CVNPdfT,F1,Construir nuevo módulo validador

Seminario de metodologías ágiles, bloque I

Technology

Transcript of Seminario de metodologías ágiles, bloque I