Scrum_I

Scrum I Gestin tcnica de proyectos

Rev. 2.2.1

Scrum Manager es marca registrada propiedad de Iubaris Info 4 Media S.L. El marco y plataforma de formacin abierta ScrumManager es propiedad de Iubaris info 4 Media S.L.

Scrum I Gestin tcnica de proyectos con Scrum

Rev. 2.2,1 Agosto 2013

Diseo de cubierta: Scrum Manager. Imagen derivada de la original: The Albert Bridge 04 Belfast de William Murphy (http://www.streetsofdublin.com/) 2013 Juan Palacio De la edicin: Scrum Manager Informacin de derechos y licencia de uso:

http://www.safecreative.org/work/1308205616538

2005-2013 ScrumManager - http://www.scrummanager.net

Contenido

Contenido 4

Formacin Scrum Manager 7

Servicios de formacin y asesora presencial Scrum Manager 7

Evaluacin para mejora continua y control de calidad de Scrum Manager 9

SCRUM PARA PROYECTOS DE SOFTWARE 11

Introduccin: La agilidad 12

El Manifiesto gil 12

Manifiesto gil 13

Los 12 principios del manifiesto gil 14

Origen del uso de los principios de Scrum en proyectos de software 15

Introduccin al modelo 15

Gestin de la evolucin del proyecto 16

Revisin de las Iteraciones 16

Desarrollo incremental 16

Desarrollo incremental 16

Autoorganizacin 16

Colaboracin 16

Marco estndar de Scrum 19

Elementos del marco estndar de Scrum: 20

Pila del producto y pila del sprint: los requisitos en desarrollo gil. 21

Pila del producto: los requisitos del cliente 22

Pila del Sprint 23

El Incremento 24

Reuniones del marco estndar de Scrum 25

Planificacin del sprint 25

Seguimiento del sprint 28

Revisin del sprint 29

Retrospectiva 30

Roles en el marco estndar de Scrum 30

Valores 31

El propietario del producto 31

El equipo 32

Scrum Master 32

Medicin y estimacin gil 33

Por qu medir? 34

Flexibilidad y sentido comn 34

Contenido

2005-2013 Scrum Manager - http://www.scrummanager.net

Criterios para el diseo y aplicacin de mtricas 35

Cuantas menos, mejor 35

El indicador es apropiado para el fin que se debe conseguir? 35

Velocidad, trabajo y tiempo 37

Tiempo 37

Trabajo 38

Trabajo ya realizado 38

Trabajo pendiente de realizar 39

Unidades de trabajo 40

Velocidad 40

Medicin: usos y herramientas 41

Grfico de producto. 41

Grfico de avance: monitorizacin del sprint 44

Estimacin de pquer 47

Tabla de ilustraciones 51

ndice 52

Sobre la formacin de Scrum Manager

2005-2013 ScrumManager - http://www.scrummanager.net 7

Formacin Scrum Manager

Este es el material de formacin del curso de Scrum desarrollado e impartido por Scrum Manager

Los contenidos de formacin de Scrum Manager se mantienen regularmente actualizados. Puede descargar la ltima versin de este libro de apuntes, o consultar on-line la ltima revisin de sus contenidos en la direccin: http://www.scrummanager.net/bok

La formacin de Scrum Manager es un recurso educativo abierto (OER):

Materiales: Los materiales son de acceso y uso gratuito para consulta y autoformacin de carcter personal

1.

Cursos: Los cursos de Scrum Manager se ofrecen gratuitamente en la plataforma de e-learning: http://www.scrummanger.net/oks

Acreditacin acadmica: Incluida en los cursos OER de la plataforma de e-learning, para los alumnos que desean realizar el examen de evaluacin correspondiente.

La formacin libre de Scrum Manager es posible gracias a la subvencin y soporte de los:

Servicios de formacin y asesora presencial Scrum Manager

Cursos en convocatorias presenciales, o contratados a medida para empresas o a grupos de estudiantes.

o Puede consultar el calendario de convocatorias en diferentes ciudades en la pgina de cursos de http://www.scrummanager.net:

o Para informacin de cursos a medida: contacte con un Centro Oficial de Formacin Scrum Manager (http://scrummanager.net/centros) o en la direccin [email protected]

Exmenes de certificacin (nivel de certificacin, que incluye la supervisin presencial de la prueba e identificacin del alumno): Los cursos presenciales incluyen examen de certificacin. Tambin se pueden realizar los exmenes de certificacin en los Centros Oficiales de Formacin Scrum Manager: http://scrummanager.net/centros

Puede localizar profesionales y empresas certificadas para servicios profesionales de formacin y asesora en la implantacin y mejora de Scrum Management, en el directorio de centros de formacin autorizados Scrum Manager http://scrummanager.net/ o solicitar informacin en la direccin [email protected]

Ms informacin:

http://www.scrummanager.net http://www.scrummanager.net/oks [email protected]

1 Para impartir cursos de Scrum Manager: puedes consultar cmo hacerlo en Preguntas Frecuentes de scrummanager.net o

contactando en [email protected]

Evaluacin para control de calidad y mejora de Scrum Manager


Evaluacin para mejora continua y control de calidad de Scrum Manager

Gracias por haber elegido los servicios de formacin de Scrum Manager

La valoracin de los alumnos es el criterio de control de calidad empleado por Scrum Manager para decidir la validez o no de los servicios de formacin, y en su caso la continuidad de los cursos, profesores y partners. Su valoracin es importante, porque hace posible la garanta de calidad de Scrum Manager.

Si ha participado en una actividad de formacin auditada por Scrum Manager, le rogamos y agradecemos que valore la calidad del material, profesor, temario, etc. as como tus comentarios y sugerencias.

Scrum Manager anonimiza la informacin, de forma que comparte con los profesores, partners y centros autorizados las valoraciones y aspectos de mejora, pero en ningn caso los nombres de los alumnos que las han realizado.

Puede realizar la valoracin en la pgina de acceso restringido a miembros de Scrum Manager: http://scrummanager.net/qa.


SCRUM PARA PROYECTOS DE SOFTWARE

12 Scrum para proyectos de software

12 2005-2009 Navegapolis - http://www.navegapolis.net

Introduccin: La agilidad

El escenario actual se parece muy poco al que dio origen a la gestin de proyectos predictiva: se necesitan estrategias diferentes para el lanzamiento de productos, estrategias orientadas a la entrega temprana de resultados tangibles y a la respuesta gil y flexible necesaria para trabajar en entornos inestables.

Ahora se va construyendo el producto al mismo tiempo que se modifican y aparecen nuevos requisitos; nuevos modelos de gestin van naciendo. El cliente conoce la visin de su producto pero, por el valor de innovacin que necesita y la velocidad a la que se mueve el escenario tecnolgico y de negocio durante el desarrollo, no puede detallar cmo ser el producto final.

Quiz ya no hay productos finales, sino productos en evolucin, mejora o incremento continuo, desde la primera versin beta.

El modelo predictivo es el nico posible? Los criterios para determinar el xito slo pueden ser el cumplimiento de fechas y costos? Puede haber proyectos que no tengan como finalidad realizar un trabajo previamente planificado, con un presupuesto y en un tiempo previamente calculado?

Hoy hay directores de producto que no necesitan conocer cules van a ser las 200 funcionalidades que tendr el producto final, y si este estar terminado en 12 en 16 meses.

Hay clientes que necesitan disponer de una primera versin con funcionalidades bsicas en 2 meses, y no un producto completo en 2 aos. Clientes cuyo inters es poner en el mercado cuanto antes un producto valioso para los clientes, y estar continuamente desarrollando su valor y funcionalidad?

Quiz en algunos proyectos de software el empeo en aplicar prcticas de estimacin, planificacin, ingeniera de requisitos sea vano. Es ms que probable que la causa de los problemas no sea tanto por una mala aplicacin de las prcticas, sino por la aplicacin de prcticas inapropiadas.

La mayora de los fiascos se producen por aplicar ingeniera de procesos secuencial y gestin predictiva tanto en la adquisicin con el cliente (requisitos, contratacin, seguimiento y entrega) como en la gestin del proyecto, cuando se trata de proyectos que no necesitan tanto garantas de previsibilidad en la ejecucin, como respuesta rpida y flexibilidad para trabajar en escenarios de negocio cambiantes.

El Manifiesto gil

En marzo de 2001, 17 crticos de los modelos de mejora basados en procesos, convocados por Kent Beck, que haba publicado un par de aos antes el libro "Extreme Programming Explained" en el que expona una nueva metodologa denominada Extreme Programming, se reunieron en Salt Lake City para discutir sobre el desarrollo de software. En la reunin se acu el trmino Mtodos giles para definir a los que estaban surgiendo como alternativa a las metodologas formales: CMM-SW, precursor del CMMI, PMI, SPICE (proyecto inicial de ISO 15504), a las que consideraban excesivamente pesadas y rgidas por su carcter normativo y fuerte dependencia de planificaciones detalladas, previas al desarrollo.

Los integrantes de la reunin resumieron en cuatro postulados lo que ha quedado denominado como Manifiesto gil, que son las bases sobre las que se asientan estos mtodos. Hasta 2005, entre los defensores de los modelos de procesos y los de modelos giles han sido frecuentes las posturas radicales, quiz ms ocupadas en descalificar al otro, que en estudiar sus mtodos y conocerlos para mejorar los propios.

La gestin de proyectos gil no se formula sobre la necesidad de anticipacin, sino sobre la de adaptacin continua.

Scrum para proyectos de software 13


Manifiesto gil Estamos poniendo al descubierto mejores mtodos para desarrollar software, hacindolo y ayudando a otros a que lo hagan.

Con este trabajo hemos llegado a valorar:

A los individuos y su interaccin, por encima de los procesos y las herramientas. El software que funciona, por encima de la documentacin exhaustiva. La colaboracin con el cliente, por encima de la negociacin contractual. La respuesta al cambio, por encima del seguimiento de un plan.

Aunque hay valor en los elementos de la derecha, valoramos ms los de la izquierda.

Valoramos ms a los individuos y su interaccin que a los procesos y las herramientas.

Este es el valor ms importante del manifiesto.

Por supuesto que los procesos ayudan al trabajo. Son una gua de operacin. Las herramientas mejoran la eficiencia, pero en trabajos que requieren conocimiento tcito, sin personas con conocimiento tcnico y actitud adecuada no se logran resultados valiosos. Las empresas suelen afirmar que las personas son lo ms importante, pero la produccin basada en procesos se desarrolla para lograr que la calidad y homogeneidad de los productos sea consecuencia del know-how de los procesos ms que de las personas, de forma que sean un factor menos crtico y ms fcilmente reemplazable.

Sin embargo en la agilidad los procesos son una ayuda. Un soporte para guiar el trabajo. Se adaptan a la organizacin, a los equipos y a las personas; y no al revs. La defensa a ultranza de los procesos lleva a postular que con ellos se pueden conseguir resultados extraordinarios con personas mediocres, y lo cierto es que este principio es peligroso cuando los trabajos necesitan creatividad e innovacin.

Valoramos ms el software que funciona que la documentacin exhaustiva.

Poder anticipar cmo se comportarn las funcionalidades del producto final sobre prototipos previos, o sobre partes ya elaboradas ofrece un "feedback" estimulante y enriquecedor, que genera ideas y posibilidades imposibles de concebir en un primer momento, y difcilmente se podran incluir al redactar un documento de requisitos detallados antes de comenzar el proyecto.

El manifiesto no afirma la inutilidad de la documentacin, slo la de la documentacin innecesaria. Los documentos son soporte de hechos, permiten la transferencia del conocimiento, registran informacin histrica, y en muchas cuestiones legales o normativas son obligatorios, pero se resalta que son menos importantes que los productos que funcionan. Menos trascendentales para aportar valor al producto.

Los documentos no pueden sustituir, ni pueden ofrecer la riqueza y generacin de valor que se logra con la comunicacin directa entre las personas y a travs de la interaccin con los prototipos.

Por eso, siempre que sea posible debe preferirse reducir al mnimo indispensable el uso de documentacin, que genera trabajo que no aporta un valor directo al producto.

Si la organizacin y los equipos se comunican a travs de documentos, adems de perder la riqueza que da la interaccin con el producto, se acaba derivando en la utilizacin de los documentos como barricadas entre departamentos o entre personas.

Valoramos ms la colaboracin con el cliente que la negociacin contractual.

Las prcticas giles estn especialmente indicadas para productos difciles de definir con detalle al principio del proyecto, o que si se definieran as tendran al final menos valor que si se van enriqueciendo con retroinformacin continua durante el desarrollo. Tambin para los casos en los que los requisitos van a ser muy inestables por la velocidad del entorno de negocio del cliente.

Para el desarrollo gil el valor del resultado no es consecuencia de haber controlado una ejecucin conforme a procesos, sino de haber sido implementado directamente sobre el producto.

Un contrato no aporta valor al producto. Es una formalidad que establece lneas divisorias de responsabilidades, que fija los referentes para posibles disputas contractuales entre cliente y proveedor.



En el desarrollo gil el cliente es un miembro ms del equipo, que se integra y colabora en el grupo de trabajo. Los modelos de contrato por obra no encajan.

Valoramos ms la respuesta al cambio que el seguimiento de un plan

Para desarrollar productos de requisitos inestables, que tienen como factor inherente el cambio y la evolucin rpida y continua, resulta mucho ms valiosa la capacidad de respuesta que la de seguimiento y aseguramiento de planes pre establecidos. Los principales valores de la gestin gil son la anticipacin y la adaptacin; diferentes a los de la gestin de proyectos ortodoxa: planificacin y control para evitar desviaciones del mismo.

Los 12 principios del manifiesto gil El manifiesto gil, tras los cuatro postulados anteriores, en los que se fundamenta, desarrolla 12 principios, que definen la agilidad en proyectos de software, con independencia de la metodologa o prcticas giles que se empleen.

Ellos son:

1. Nuestra principal prioridad es satisfacer al cliente a travs de la entrega temprana y continua de software de valor.

2. Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos giles se doblegan al cambio como ventaja competitiva para el cliente.

3. Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta un par de meses, con preferencia en los periodos breves.

4. Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a travs del proyecto.

5. Construccin de proyectos en torno a individuos motivados, dndoles la oportunidad y el respaldo que necesitan y procurndoles confianza para que realicen la tarea.

6. La forma ms eficiente y efectiva de comunicar informacin de ida y vuelta dentro de un equipo de desarrollo es mediante la conversacin cara a cara.

7. El software que funciona es la principal medida del progreso. 8. Los procesos giles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores y

usuarios deben mantener un ritmo constante de forma indefinida. 9. La atencin continua a la excelencia tcnica enaltece la agilidad. 10. La simplicidad como arte de maximizar la cantidad de trabajo que se hace, es esencial. 11. Las mejores arquitecturas, requisitos y diseos emergen de equipos que se autoorganizan. 12. En intervalos regulares, el equipo reflexiona sobre la forma de ser ms efectivo y ajusta su conducta

en consecuencia.

Scrum para proyectos de software 15


Origen del uso de los principios de Scrum en proyectos de software

Scrum es un modelo de desarrollo gil caracterizado por:

Adoptar una estrategia de desarrollo incremental en lugar de tradicional de planificacin y ejecucin completa del producto.

Confiar la calidad del resultado ms al conocimiento tcito de las personas que trabajan en equipo, que a la calidad de los procesos empleados.

Solapamiento de las diferentes fases del desarrollo, en lugar de realizar una tras otra en un ciclo secuencial o de cascada.

Este modelo de desarrollo fue identificado y definido por Ikujiro Nonaka e Hirotaka Takeuchi a principios de los 80, al analizar la forma en la que desarrollaban los nuevos productos las principales empresas de manufactura tecnolgica: Fuji-Xerox, Canon, Honda, Nec, Epson, Brother, 3M y Hewlett-Packard. Los autores del estudio expusieron este modelo de desarrollo en el artculo que dio origen al trmino y concepto Scrum: New New Product Development Game.

Aunque las prcticas observadas por Nonaka y Takeuchi surgieron en empresas de productos tecnolgicos, en general son apropiadas para entornos que trabajan con requisitos inestables y que requieren rapidez y flexibilidad, situaciones frecuentes en el desarrollo de determinados sistemas de software.

En 1995 Ken Schwaber present en OOPSLA 95 (Object-Oriented Programming Systems & Applications conference) (SCRUM Development Process), la implementacin de Scrum para software que l empleaba en el desarrollo de Delphi, y Jeff Sutherland en su empresa Easel Corporation (compaa que en los macrojuegos de compras y fusiones, se integrara en VMARK, y luego en Informix y finalmente en Ascential Software Corporation).

Las implementaciones de Scrum para desarrollo de software se vienen enriqueciendo desde entonces, y poco tienen que ver las actuales con la original de Ken (Schwaber, 1995). Ahora es muy raro que alguien configure un campo de Scrum con los controles originales (paquetes, cambios, riesgos, soluciones), el Backlog nico ha evolucionado a Backlog de producto y Backlog de Sprint. Tambin es habitual usar un Backlog estratgico o Epics de producto. La evolucin aadi a la reunin de revisin de sprint, otra de inicio; y ms tarde otra de retrospectiva. Tampoco se suele usar la fase de cierre.

Por otro lado las prcticas se han enriquecido. En 2001 apareci el grfico de avance (burn-down) ms tarde empez a ser habitual el uso de estimacin de pquer, y luego los tableros de control visual kanban.

En este captulo se aborda el marco de Scrum estndar o acadmico empleado como modelo para el aprendizaje en la introduccin a las implantaciones de agilidad en organizaciones TIC, y basado en prcticas concretas que se deben realizar en un marco definido de artefactos, roles y reuniones, y que genera un avance basado en iteraciones (sprints).

Introduccin al modelo

La metodologa que define el marco estndar de Scrum es muy simple, pero no fcil de implantar, porque no se basa en ejecucin de procesos y seguimiento de un plan, sino en la adaptacin continua a las circunstancias de la evolucin del proyecto.

Como mtodo gil:

Establece un modelo de gestin evolutivo, antes que predictivo. Basa la calidad del resultado en el conocimiento de las personas, ms que en el aportado por los

procesos y la tecnologa. Emplea una estrategia de desarrollo incremental a travs de iteraciones (sprints) y revisiones. Comparte los principios estructurales del desarrollo gil: a partir del concepto o visin de la necesidad

del cliente, construye el producto de forma incremental a travs de iteraciones breves que comprenden fases de especulacin exploracin y revisin. Estas iteraciones (en Scrum llamadas sprints) se repiten de forma continua hasta que el cliente da por cerrado el producto.



Se comienza con la visin general del producto, y a partir de ella se va especificando y dando detalle a las funcionalidades o partes que tienen mayor prioridad de negocio, y que pueden llevarse a cabo en un perodo de tiempo breve.

Cada ciclo de desarrollo o iteracin finaliza con la entrega de una parte operativa (incremento) del producto, y su duracin puede ser desde una semana hasta dos meses, aunque es preferible que no duren ms de un mes.

Scrum gestiona la evolucin de los sprints con reuniones breves diarias donde todo el equipo revisa el trabajo realizado el da anterior y el previsto para el siguiente. Esta reunin diaria es de tiempo prefijado de 5 a 15 minutos mximo, se realiza de pie junto a un tablero o pizarra con informacin de las tareas del sprint y el trabajo pendiente de cada una. Esta reunin se denomina reunion de pie o si se emplea la terminologa inglesa: stand-up meeting, tambin: daily scrum o morning rollcall.

Gestin de la evolucin del proyecto

Scrum maneja de forma emprica la evolucin del proyecto a con las siguientes tcticas:

Revisin de las Iteraciones Al finalizar cada iteracin (sprint) se lleva a cabo una revisin funcional de resultado, con todos los implicados en el proyecto. Es por tanto la duracin del sprint, el perodo de tiempo mximo para advertir planteamientos errneos, mejorables o malinterpretaciones en las funcionalidades del producto

Desarrollo incremental No se trabaja con diseos o abstracciones durante toda la construccin del producto.

El desarrollo incremental implica que al final de cada iteracin se dispone de una parte de producto operativa, que se puede usar, inspeccionar y evaluar.

Desarrollo incremental Scrum resulta adecuado en proyectos con requisitos inciertos y, o inestables. Intentar predecir en las fases iniciales cmo ser el resultado final, y sobre dicha prediccin desarrollar el diseo y la arquitectura del producto no es realista, porque las circunstancias obligarn a remodelarlo muchas veces.

Por qu predecir la arquitectura o diseo definitivo, si su concepto va a estar evolucionando de forma continua? Scrum considera a la inestabilidad como una premisa, y adopta tcnicas de trabajo para facilitar la evolucin sin degradar la calidad de la arquitectura y permitir que tambin evolucione durante el desarrollo.

Durante la construccin se depura el diseo y la arquitectura; no se considera la primera fase del proyecto. Las distintas fases que el desarrollo en cascada realiza de forma secuencial, en scrum se solapan y realizan de forma continua y simultnea.

Autoorganizacin Son muchos los factores impredecibles en un proyecto. La gestin predictiva asigna al rol de gestor del proyecto la responsabilidad de su gestin y resolucin.

En Scrum los equipos son autoorganizados, con un margen de maniobra suficiente para tomar las decisiones que consideren oportunas.

Colaboracin Es un componente importante y necesario para que a travs de la autoorganizacin se pueda gestionar con solvencia la labor que de otra forma realizara un gestor de proyectos.

Todos los miembros del equipo colaboran de forma abierta con los dems, segn sus capacidades y no segn su rol o su puesto.

Marco estndar de Scrum para proyectos de software


Modelo de implementacin acadmica de Scrum en empresas TIC

MODELO ACADMICO DE SCRUM

Rev. 0.6

PPPP E

SMPP E

PPSM E I

Presentacin del incremento,

sugerencias, anuncio prximo sprint

Exposicin de prioridades

Resolucin de dudas

Estimacin del esfuerzo para

cada requisito

Objetivo del Sprint

Reunin diaria SM E( )

IPP

Revisin del trabajo;

resolucin de trabas

CICLO ITERATIVO DE DESARROLLO

PP

PROPIETARIO DEL PRODUCTO

Determina las prioridades.

Una sola persona.

E

I

ROLES COMPONENTES

PILA DEL PRODUCTO

Relacin de requisitos del producto, no es necesario

excesivo detalle. Priorizados. Lista en evolucin y abierta

a todos los roles. El propietario del producto es su

responsable y quien decide.

PILA DEL SPRINT

Requisitos comprometidos por el equipo para el sprint con

nivel de detalle suficiente para su ejecucin.

INCREMENTO

Parte del producto desarrollada en un sprint, en

condiciones de ser usada (pruebas, codificacin limpia y

documentada).

REUNIONES

PLANIFICACIN DEL SPRINT

1 jornada de trabajo. El propietario del producto explica

las prioridades y dudas del equipo. El equipo estima el

esfuerzo de los requisitos prioritarios y se elabora el

sprint backlog. Todo el equipo define en una frase el

objetivo del sprint.

REUNIN DIARIA

Duracin mxima 15 minutos. el equipo revisa las tareas

informando cada uno: Qu hice ayer?, Cul es el trabajo

para hoy?, Qu necesito?. Se actualizan los tiempos en el

sprint backlog y el grfico Burn Down.

REVISIN DEL SPRINT

Informativa, aprox. 4 horas, presentacin del incremento,

planteamiento de sugerencias y anuncio del prximo

sprint.

VALORES

- Empowerment y compromiso de las personas

- Foco en desarrollar lo comprometido

- Transparencia y visibilidad del proyecto

- Respeto entre las personas

- Coraje y responsabilidad

SPRINT

Ciclo de desarrollo bsico de

SCRUM, de duracin breve (2 - 8

semanas) en el que se desarrolla

un incremento del producto.

Modelo de implementacin acadmica de Scrum en empresas TIC

EQUIPO

Construye el producto.

INTERESADOS

Asesoran y observan.

SM

SCRUM MASTER / COACH / MANAGER

Formacin - Moderacin reuniones -

Facilitador - Mtricas y mejora proceso...

http://www.scrummanager.net

Ilustracin 1: Marco Scrum estndar


Marco estndar de Scrum


20 2005 - 2013 ScrumManager Project http://www.scrummanager.net

Una implantacin estndar de Scrum incluye:

Elementos: pila del producto, pila del sprint e incremento. Reuniones: de inicio del sprint, revisin diaria, revisin del sprint y retrospectiva. Roles: propietario del producto, equipo, scrum master y resto de implicados.

Y la pieza clave del modelo estndar de Scrum es el sprint. Se denomina sprint a cada ciclo o iteracin de trabajo que produce una parte del producto terminada y funcionalmente operativa (incremento)

Como se ve en el curso de Scrum Avanzado, las implementaciones ms flexibles de Scrum pueden adoptar dos tcticas diferentes para mantener un avance continuo en el proyecto:

Incremento iterativo: basado en pulsos de tiempo prefijado (timpeboxing) Incremento continuo: basado en el mantenimiento de un flujo continuo, no marcado por pulsos o

sprints.

Ilustracin 2: Incremento iterativo / continuo

Las implementaciones estndar de Scrum trabajan con ciclos de sprints, y por tanto con incremento iterativo.

Elementos del marco estndar de Scrum:

Pila del producto: (product backlog) lista de requisitos de usuario que a partir de la visin inicial del producto crece y evoluciona durante el desarrollo.

Pila del sprint: (sprint backlog) lista de los trabajos que debe realizar el equipo durante el sprint para generar el incremento previsto.

Sprint: nombre que recibe cada iteracin de desarrollo. Es el ncleo central que genera el pulso por tiempos prefijados (time boxing).

Incremento: resultado de cada sprint.

Ilustracin 3: Diagrama del ciclo iterativo Scrum



Otro elemento propio del modelo estndar de Scrum es el grfico de avance o grfico burn down que el equipo actualiza a diario para comprobar el avance. Este elemento, junto con la prctica de estimacin de pquer y el grfico de producto o burn up se encuentra incluido en el captulo de Mtricas giles.

Pila del producto y pila del sprint: los requisitos en desarrollo gil. La ingeniera del software clsica diferencia dos reas de requisitos:

Requisitos del sistema Requisitos del software

Los requisitos del sistema forman parte del proceso de adquisicin (ISO 12207), y por tanto es responsabilidad del cliente la definicin del problema y de las funcionalidades que debe aportar la solucin.

No importa si se trata de gestin tradicional o gil. La descripcin del sistema (pila del producto) es responsabilidad del cliente, aunque se aborda de forma diferente en cada caso.

Ilustracin 4: Requisitos completos / evolutivos

En los proyectos predictivos, los requisitos del sistema suelen especificarse en documentos formales; mientras que en los proyectos giles toman la forma de pila del producto o lista de historias de usuario.

Los requisitos del sistema formales se especifican de forma completa y cerrada al inicio del proyecto; sin embargo una pila del producto es un documento vivo, que evoluciona durante el desarrollo.

Los requisitos del sistema los desarrolla una persona o equipo especializado en ingeniera de requisitos a travs del proceso de obtencin (elicitacin) con el cliente. En Scrum la visin del cliente es conocida por todo el equipo (el cliente forma parte del equipo) y la pila del producto se realiza y evoluciona de forma continua con los aportes de todo el equipo.

Scrum, aplicado al software, emplea dos formatos para registrar los requisitos:

Pila del producto (Product Backlog) Pila del sprint (Sprint Backlog)

La pila del producto refleja los requisitos vistos desde el punto de vista del cliente. Un enfoque similar al de los requisitos del sistema de la ingeniera tradicional. Est formada por la lista de funcionalidades o "historias de usuario" que desea obtener el cliente, ordenadas por al prioridad que el mismo le otorga a cada una.



La pila del sprint refleja los requisitos vistos desde el punto de vista del equipo de trabajo. Est formada por la lista de tareas en las que se descomponen las historias de usuario que se van a llevar a cabo en el sprint.

En el desarrollo y mantenimiento de la pila del producto lo relevante no es tanto el formato, sino que:

Las funcionalidades que incluye den forma a una visin del producto definida y conocida por todo el equipo.

Las funcionalidades estn individualmente definidas, priorizadas y pre-estimadas. Estn realizados y gestionados por el cliente (propietario del producto).

Pila del producto: los requisitos del cliente La pila del producto es el inventario de funcionalidades, mejoras, tecnologa y correccin de errores que deben incorporarse al producto a travs de los sucesivos sprints.

Representa todo aquello que esperan el cliente, los usuarios, y en general los interesados. Todo lo que suponga un trabajo que debe realizar el equipo debe estar reflejado en esta pila.

Estos son algunos ejemplos de posibles entradas a una pila de producto:

Permitir a los usuarios la consulta de las obras publicadas por un determinado autor. Reducir el tiempo de instalacin del programa. Mejorar la escalabilidad del sistema. Permitir la consulta de una obra a travs de un API web.

A diferencia de un documento de requisitos del sistema, la pila del producto nunca se da por completada; est en continuo crecimiento y evolucin.

Habitualmente se comienza a elaborar con el resultado de una reunin de tormenta de ideas, o "fertilizacin cruzada", o un proceso de Exploracin (eXtreme Programming) donde colabora todo el equipo partiendo de la visin del propietario del producto.

El formato de la visin no es relevante. Segn los casos, puede ser una presentacin informal del responsable del producto, un informe de requisitos del departamento de marketing, u otros.

Sin embargo, s es importante disponer de una visin real, comprendida y compartida por todo el equipo.

La pila evoluciona de forma continua mientras el producto est en el mercado, incrementando su valor de forma permanente, mantenindolo til y competitivo.

Para dar comienzo al desarrollo se necesita una visin de los objetivos de negocio que se quieren conseguir con el proyecto, comprendida y conocida por todo el equipo, y elementos suficientes en la pila para llevar a cabo el primer sprint.

Formato de la pila del producto

El desarrollo gil prefiere la comunicacin verbal o de visualizacin directa, a la escrita.

La pila del producto no es un documento de requisitos, sino una herramienta de referencia para el equipo.

Si se emplea formato de lista, es recomendable que al menos incluya la siguiente informacin en cada lnea:

Identificador nico de la funcionalidad o trabajo. Descripcin de la funcionalidad/requisito, denominado historia de usuario. Campo o sistema de priorizacin. Estimacin del esfuerzo necesario.

Dependiendo del tipo de proyecto, funcionamiento del equipo y la organizacin, pueden resultar aconsejables otros campos:

Observaciones. Criterio de validacin. Persona asignada. N de Sprint en el que se realiza. Mdulo del sistema al que pertenece. Entre otros.



Es preferible no adoptar ningn protocolo de trabajo de forma rgida. Los resultados de Scrum no dependen de la rigidez en la aplicacin del protocolo, sino de la institucionalizacin de sus principios y la implementacin en un formato adecuado a las caractersticas de la empresa y del proyecto. He aqu un sencillo ejemplo de pila de producto:

Id Prioridad Descripcin Est. Por

1 Muy alta Plataforma tecnolgica 30 AR

2 Muy Alta Interfaz de usuario 40 LM

3 Muy Alta Un usuario se registra en el sistema 40 LM

4 Alta El operador define el flujo y textos

de un expediente 60 AR

5 Alta xxx 999 CC

Ilustracin 5: Ejemplo de pila de producto

Pila del Sprint La pila del sprint (o sprint Backlog) es la lista que descompone las funcionalidades de la pila del producto (historias de usuario) en las tareas necesarias para construir un incremento: una parte completa y operativa del producto.

La realiza el equipo durante la reunin de planificacin del sprint, autoasignando cada tarea a un miembro del equipo, e indicando en la misma lista cunto tiempo o esfuerzo falta para terminarla. Es til porque descompone el proyecto en unidades de tamao adecuado para monitorizar el avance a diario, e identificar riesgos y problemas sin necesidad de procesos de gestin complejos.

Es tambin una herramienta para la comunicacin visual directa del equipo.

Condiciones

Realizada de forma conjunta por todos los miembros del equipo. Cubre todas las tareas identificadas por el equipo para conseguir el objetivo del sprint. Slo el equipo lo puede modificar durante el sprint. El tamao de las tareas debe ser tal que se puedan realizar en un da. Es visible para todo el equipo. Idealmente en una pizarra o pared en el mismo espacio fsico donde

trabaja el equipo.

Formato y soporte

Las opciones habituales son:

Hoja de clculo. Pizarra fsica o pared. Herramienta colaborativa o de gestin de proyectos.

Y sobre la que mejor se adecue a las caractersticas del proyecto, oficina y equipo, lo apropiado es disear el formato ms cmodo para todos, teniendo en cuenta los siguientes criterios:

Incluir la siguiente informacin: Pila del sprint, persona responsable de cada una, estado en el que se encuentra y tiempo de trabajo que queda para completarla.

Incluir slo la informacin estrictamente necesaria. Debe servir de soporte para registrar en cada reunin diaria del sprint, el tiempo que le queda a cada

tarea. Facilitar la consulta y la comunicacin diaria y directa del equipo.



Ejemplo:

Ilustracin 6: Ejemplo de pila de sprint con hoja de clculo

Durante el sprint, el equipo actualiza sobre la pila del sprint, a diario, los tiempos pendientes de cada tarea. Al mismo tiempo, con estos datos traza el grfico de avance o burn-down, que se describe en el captulo de mtricas giles.

El Incremento El incremento es la parte de producto producida en un sprint, y tiene como caracterstica el estar completamente terminada y operativa, en condiciones de ser entregada al cliente final.

No se deben considerar como Incremento a prototipos, mdulos o submdulos pendientes de prueba o integracin.

Idealmente en Scrum:

Cada elemento de la pila del producto se refiere a funcionalidades entregables, no a trabajos internos del tipo diseo de la base de datos.

Se produce un incremento en cada iteracin.

Sin embargo suele ser una excepcin habitual el primer sprint. En el que objetivos del tipo contrastar la plataforma y el diseo pueden resultar necesarios, e implican trabajos de diseo o desarrollo de prototipos para contrastar las expectativas de la plataforma o tecnologa que se va a emplear. Teniendo en cuenta esta excepcin habitual:

Si el proyecto o el sistema requiere documentacin, o procesos de validacin y verificacin documentados, o con niveles de independencia que implican procesos con terceros, stos tambin tienen que estar realizados para considerar que el producto est terminado.

Incremento es la parte de producto realizada en un sprint potencialmente entregable: terminada y probada..



Reuniones del marco estndar de Scrum

Planificacin del sprint: jornada de trabajo previa al inicio de cada sprint en la que se determina cul va a ser el trabajo y los objetivos que se deben conseguir en la iteracin.

Revisin diaria: breve revisin diaria, en la que cada miembro describe tres cuestiones:

1.- El trabajo que realiz el da anterior.

2.- El que tiene previsto realizar.

3.- Cosas que puede necesitar o impedimentos que deben suprimirse para realizar el trabajo.

Cada persona actualiza en la pila del sprint el tiempo o esfuerzo pendiente de sus tareas, y con esta informacin se actualiza a su vez el grfico con el que el equipo monitoriza el avance del sprint (burn-down)

Revisin del sprint: anlisis y revisin del incremento generado.

Una cuarta reunin se incorpor al marco estndar de Scrum en la primera dcada de 2.000:

Retrospectiva del sprint: revisin de lo sucedido durante el Sprint.

Planificacin del sprint

Descripcin

En esta reunin se toman como base las prioridades y necesidades de negocio del cliente, y se determinan cules y cmo van a ser las funcionalidades que incorporar el producto tras el siguiente sprint.

Se trata de una reunin conducida por el responsable del funcionamiento de Scrum (Scrum Master o un miembro del equipo, en equipos ya expertos en trabajo con Scrum) a la que deben asistir el propietario del producto y el equipo completo, y a la que tambin pueden asistir otros implicados en el proyecto.

La reunin comienza cuando el propietario del producto presenta la pila de producto, en la que exponen los requisitos que necesita, por orden de prioridad; especialmente los que prev, se podrn desarrollar en el siguiente sprint. Si la pila del producto ha tenido cambios significativos desde la anterior reunin, explica las causas que los han ocasionado.

El objetivo es que todo el equipo conozca las razones y los detalles con el nivel necesario para estimar el trabajo necesario.

Precondiciones

La organizacin tiene determinados los recursos disponibles para llevar a cabo el sprint. El propietario del producto tiene preparada la pila 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 antes con el equipo. De

esta forma su estimacin previa del trabajo que se puede realizar en el sprint ser bastante ajustada. El equipo tiene un conocimiento de las tecnologas 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

La pila del producto. El producto desarrollado hasta la fecha a travs de los sucesivos incrementos (excepto si se trata del

primer sprint). Circunstancias de las condiciones de negocio del cliente y del escenario tecnolgico empleado.



Resultados

Pila del sprint. Duracin del sprint y fecha de la reunin de revisin. Objetivo del sprint.

Formato de la reunin

Esta reunin marca el inicio de cada sprint.

Duracin mxima: un da.

Deben asistir: el propietario del producto, el equipo y el Scrum Master

Pueden asistir: todos aquellos que aporten informacin til, ya que es una reunin abierta.

Consta de dos partes separadas por una pausa de caf o comida, segn la duracin.

Primera parte:

Duracin de 1 a 4 horas.

Propietario del producto:

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

La presentacin se hace con un nivel de detalle suficiente para transmitir al equipo toda la informacin necesaria para construir el incremento.

El equipo

Realiza las preguntas y solicita las aclaraciones necesarias. Propone sugerencias, modificaciones y soluciones alternativas.

Los aportes del equipo pueden suponer modificaciones en la pila. De hecho no es que puedan es que deben suponerlas.

Esta reunin es un punto caliente del protocolo de Scrum para favorecer la fertilizacin cruzada de ideas en equipo y aadir valor a la visin del producto.

Tras reordenar y replantear las funcionalidades de la pila del producto, el equipo define el objetivo del sprint o frase que sintetiza cul es el valor que se le va a entregar al cliente.

Exceptuando sprints dedicados exclusivamente a re-factorizacin o a colecciones de tareas desordenadas (que deberan ser los menos), la elaboracin de este lema de forma conjunta en la reunin es una garanta de que todo el equipo comprende y comparte la finalidad del trabajo; y durante el sprint sirve de criterio de referencia en las decisiones que autogestiona el equipo.

Segunda parte:

El equipo desglosa cada funcionalidad en tareas, y estima el tiempo para cada una de ellas, determinando de esta forma las tareas de la pila del sprint. En este desglose, el equipo tiene en cuenta los elementos de diseo y arquitectura que deber incorporar el sistema.

Los miembros del equipo se autoasignan las diferentes tareas tomando como criterios sus conocimientos, intereses y distribucin homognea del trabajo.

Esta segunda parte debe considerarse como una reunin del equipo, en la que deben estar todos sus miembros y ser ellos quienes descomponen, estiman y asignan el trabajo.

El papel del propietario del producto es atender a dudas y comprobar que el equipo comprende y comparte su objetivo.El Scrum Master acta de moderador de la reunin.



Funciones del rol de Scrum Master2

El Scrum Master o moderador de la reunin es responsable y garante de:

1.- Realizar esta reunin antes de cada sprint.

2.- Asegurar que se cuenta con una pila de producto adecuadamente desarrollada por el propietario de producto.

3.- Ayudar a mantener el dilogo entre el propietario de producto y el equipo, teniendo en cuenta que su colaboracin no puede implicar toma de decisiones ni limitar el dilogo principal.

4.- Asegurar que se llegue a un acuerdo entre el propietario del producto y el equipo respecto de lo que incluir el incremento.

5.- Ayudar al equipo a comprender la visin y necesidades de negocio del cliente.

6.- Asegurar que el equipo ha realizado una descomposicin y estimacin del trabajo realistas, y ha considerado las posibles tareas necesarias de anlisis, investigacin o apoyo.

7.- Asegurar que al final de la reunin estn objetivamente determinados:

Los elementos de la pila del producto que se van a ejecutar. El objetivo del sprint. La pila del sprint con todas las tareas estimadas y asignadas. La duracin del sprint y la fecha de la reunin de revisin.

El Scrum Master modera la reunin para que no dure ms de un da. Debe evitar que el equipo comience a profundizar en trabajos de anlisis o arquitectura que son propios del sprint.

Ejemplo de pizarra de trabajo

Es recomendable, que el propietario del producto emplee una hoja de clculo, alguna herramienta similar, o el soporte de una herramienta digital (ej.:intranet, sistema de gestin), para guardar en formato digital la pila del producto. Aunque no es aconsejable emplearla como base para trabajar sobre ella en la reunin.

Es mucho mejor trabajar y manipular elementos fsicos; por ejemplo usar una pizarra y fichas removibles (adhesivas, chinchetas, magnticas).

La pizarra facilita la comunicacin y el trabajo de la reunin.

Ilustracin 7: Ejemplo de pizarra de trabajo

Algunos soportes que suelen emplearse:

Pizarra blanca y notas adhesivas tipo Post-it. Pizarra de corcho laminado y chinchetas para sujetar las fichas. Pizarra de acero vitrificado y soportes magnticos para sujetar las fichas

.

2 En organizaciones en fase de implementacin de Scrum, en organizaciones con experiencia y madurez en gestin gil, en las que ya

no hay un rol especfico para garantizar el funcionamiento de Scrum, se refiere al puesto que haya asumido el rol (calidad, procesos, team leader...)



Con cinta adhesiva removible se marcan lneas para delimitar:

Un rea superior donde el Scrum Master coloca al principio de la reunin la capacidad real del sprint a 3, 4 y 5 semanas (A); y al final (D), las notas con: el objetivo establecido, duracin del sprint, funcionalidades de la pila del producto comprometidas, hora fijada para las reuniones diarias y fecha prevista para la reunin de revisin 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.

Seguimiento del sprint

Descripcin

Reunin diaria breve, de no ms de 15 minutos, en la que cada miembro del equipo informa al resto sobre las tareas en las que est trabajando, si se ha encontrado o prev encontrarse con algn impedimento, y actualiza sobre la pila del sprint las ya terminadas, o los tiempos de trabajo que les quedan.

Precondiciones

Los miembros del equipo han desarrollado las tareas definidas. Se han identificado inconvenientes (o no).

Entradas

Pila del sprint y grfico de avance (burn-down) actualizados con la informacin de la reunin anterior. Informacin de las tareas realizadas por cada componente del equipo.

Resultados

Pila del sprint y grfico de avance (burn-down) actualizados. Identificacin de necesidades e impedimentos.


Se recomienda realizarla de pie y emplear un formato de pila de tareas en una pizarra, junto con el grfico de avance del sprint, para que todo el equipo pueda ver y anotar.

En la reunin est presente todo el equipo, y pueden asistir tambin otras personas relacionadas con el proyecto o la organizacin, pero stas no pueden intervenir.

Cada miembro del equipo expone estas tres cuestiones:

1.- Tarea en la que trabaj ayer.

2.- Tarea o tareas en las que trabajar hoy.

3.- Si ha tenido algn inconveniente , o va a necesitar alguna cosa especial o prev algn impedimento para realizar su trabajo.

Y actualiza sobre la pila del sprint el tiempo de trabajo que queda pendiente en las tareas que tiene asignadas, o marca como finalizadas las ya completadas.

Al final de la reunin:

El equipo refresca el grfico de avance del sprint, con las estimaciones actualizadas, El Scrum Master comienza la gestin de necesidades e impedimentos identificados.



Revisin del sprint

Descripcin

Reunin realizada al final del sprint en la que, con una duracin mxima de 4 horas, el equipo presenta al propietario del producto, clientes, usuarios, gestores, y otros el incremento construido en el sprint.

Objetivos:

El propietario del producto obtiene informacin objetiva del progreso del sistema. Esta reunin marca, a intervalos regulares, el ritmo de construccin del sistema y la trayectoria que va tomando la visin del producto.

Al ver y probar el incremento, el propietario del producto, y el equipo en general obtienen feedback clave para definir la evolucin y dar ms valor a la pila del producto.

Otros ingenieros y programadores de la empresa tambin pueden asistir para conocer cmo trabaja la tecnologa empleada.

El Scrum Master o el responsable de procedimientos de la organizacin obtiene retroinformacin sobre buenas prcticas y problemas durante el sprint, necesaria para las prcticas de ingeniera de procesos y mejora continua de la implementacin.

Precondiciones

Se ha concluido el sprint. Asiste todo el equipo de desarrollo, el propietario del producto, el Scrum Master y todas las personas

implicadas en el proyecto que lo deseen.

Entradas

Incremento terminado.

Resultados

Feedback para el propietario del producto: hito de seguimiento de la construccin del sistema, e informacin para mejorar el valor de la visin del producto.

Feedback para el Scrum Master: buenas prcticas y problemas durante el sprint. Convocatoria de la reunin del siguiente sprint.


Es una reunin informal. El objetivo es ver el incremento y trabajar en el entorno del cliente. Estn prohibidas las presentaciones grficas y powerpoints.

El equipo no debe invertir ms de una hora en desarrollar la reunin, y lo que se muestra es el resultado final: terminado, probado y operando en el entorno del cliente (incremento).

Segn las caractersticas del proyecto puede incluir tambin documentacin de usuario, o tcnica.

Se trata de una reunin informativa. NO TIENE UNA MISIN ORIENTADA A TOMAR DECISIONES, NI A CRITICAR EL INCREMENTO. Con la informacin generada en la preparacin del siguiente sprint se expondrn y tratarn las posibles modificaciones sobre la visin del producto.

Un protocolo recomendado es el siguiente:

1.- El equipo expone el objetivo del sprint, la lista de funcionalidades que se incluan y las que se han desarrollado.

2.- El equipo hace una introduccin general del sprint y demuestra el funcionamiento de las partes construidas.

3.- Se abre un turno de preguntas y sugerencias sobre lo visto. Esta parte genera informacin muy valiosa para que el propietario del producto, y el equipo en general, puedan mejorar el valor de la visin del producto.



4.- El Scrum Master, de acuerdo con las agendas del propietario del producto y el equipo cierra la fecha para la reunin de preparacin del siguiente sprint.

Retrospectiva Desde la premisa de flexibilidad de Scrum Manager, se puede considerar tambin la realizacin de reuniones retrospectivas al final de cada sprint, o de cada versin de producto o cada cierto periodo de tiempo. Al igual que los modelos de procesos incorporan prcticas de ingeniera de procesos para conseguir una mejora continua de su capacidad, en agilidad tambin van surgiendo prcticas para lo que es el equivalente de mejora continua de la agilidad de la organizacin.

El hecho de que se realicen normalmente al final de cada sprint lleva a veces a confusin y a tomarlas como reuniones de revisin de sprint, cuando suele ser aconsejable considerarlas como diferentes, porque sus objetivos son diferentes.

El objetivo de la revisin del sprint es analizar QU se est construyendo, mientras que una reunin retrospectiva se centra en CMO lo estamos construyendo: CMO estamos trabajando, con el objetivo de analizar problemas y aspectos mejorables.

Las reuniones "retrospectivas" realizadas de forma peridica por el equipo para revisar y mejorar la forma de trabajo, se consideran cada vez ms un componente del marco estndar de Scrum, si bien no es una reunin para seguimiento de la evolucin del producto, sino para mejora del marco de trabajo.

Roles en el marco estndar de Scrum

Todas las personas que intervienen, o tienen relacin directa o indirecta con el proyecto, se clasifican en dos grupos: comprometidos e implicados. En crculos de Scrum es frecuente llamar a los primeros (sin la menor connotacin peyorativa) cerdos y a los segundos gallinas.

El origen de estos nombres est en la siguiente metfora que ilustra de forma grfica la diferencia entre compromiso e implicacin con el proyecto:

Una gallina y un cerdo paseaban por la carretera. La gallina pregunt al cerdo: Quieres abrir un restaurante conmigo?.

El cerdo consider la propuesta y respondi: S, me gustara. Y cmo lo llamaramos?.

La gallina respondi: Jamn con huevos.

El cerdo se detuvo, hizo una pausa y contest: Pensndolo mejor, creo que no voy a abrir un restaurante contigo. Yo estara realmente comprometido, mientras que tu estaras slo implicada.

COMPROMETIDOS (CERDOS) IMPLICADOS (GALLINAS)

Propietario del producto Otros interesados (direccin, gerencias, comerciales,

marketing, etc.) Miembros del equipo

Ilustracin 8: Roles estndar de Scrum

Propietario del producto: es la persona responsable de lograr el mayor valor de producto para los clientes, usuarios y resto de implicados.

Equipo de desarrollo: grupo o grupos de trabajo que desarrollan el producto.

Una observacin en este punto, sobre el rol de scrum Master, por ser en ocasiones frecuente la duda de considerar si es un rol comprometido o implicado. Partiendo de que la divisin entre personas comprometidas y personas implicadas es ms conceptual que relevante, lo cierto es que en las



organizaciones en las que se emplea, el rol de Scrum Master, tiene su responsabilidad directa en el funcionamiento del marco Scrum en la organizacin. Su objetivo de responsabilidad directa es la mejora de la organizacin y la mejora o resultado de los proyectos es por tanto un objetivo o resultado indirecto a travs de la mejora de la organizacin.

Por esta razn en el cuadro anterior no se considera el rol de Scrum Master, considerando, que en cualquier caso no es una cuestin especialmente relevante. Si hubiera que forzar una respuesta, desde el criterio de que no est comprometido en el proyecto (sino en la mejora de la organizacin) se debera considerar como un rol "implicado"

Valores El marco estndar de Scrum es la carrocera de un vehculo que se asienta y tiene su motor en los principios giles. Es una ayuda para organizar a las personas y el flujo de trabajo, como lo pueden ser otras propuestas de formas de trabajo gil: Crystal, DSDM, otros.

La carrocera sin motor, sin los valores que dan sentido al desarrollo gil no funciona, y stos son:

Delegacin de atribuciones (empowerment) al equipo para que pueda autoorganizarse 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 autodisciplina (no disciplina impuesta). Trabajo centrado en el valor para el cliente y el desarrollo de lo comprometido. Informacin, transparencia y visibilidad del desarrollo del proyecto.

El propietario del producto El propietario del producto o product owner es quien toma las decisiones del cliente.

Para simplificar la comunicacin y toma de decisiones es necesario que las responsabilidades de gestin del producto las asuma una nica persona.

Si el cliente es una organizacin grande, o con varios departamentos, puede adoptar la forma de comunicacin interna que consideren oportuna, pero en el equipo de desarrollo slo se integra una persona en representacin del cliente, y sta debe tener el conocimiento suficiente del producto y las atribuciones necesarias para tomar las decisiones que le corresponden.

En resumen, el propietario de producto es quien:

Decide en ltima instancia cmo ser el resultado final, y el orden en el que se van construyendo los sucesivos incrementos: qu se pone y qu se quita de la pila del producto, y cul es la prioridad de las funcionalidades.

Se responsabiliza de la financiacin del proyecto, y las decisiones sobre fechas y funcionalidades de las diferentes versiones del producto, y conoce las posibilidades y plan de inversin, as como el retorno esperado de la inversin del proyecto.

En los desarrollos internos para la propia empresa, suele asumir este rol el product manager o el responsable de marketing. En desarrollos para clientes externos: el responsable del proceso de adquisicin del cliente.

Para ejercer este rol es necesario:

Conocer perfectamente el entorno de negocio del cliente, las necesidades y el objetivo que se persigue con el sistema que se est construyendo.

Tener la visin del producto, as como las necesidades concretas del proyecto, para poder priorizar eficientemente el trabajo.

Disponer de atribuciones suficientes para tomar las decisiones necesarias durante el proyecto, incluidas para cubrir las expectativas previstas de retorno de la Inversin del proyecto.

Recibir y analizar de forma continua retroinformacin del entorno de negocio (evolucin del mercado, competencia, alternativas) y del proyecto (sugerencias del equipo, alternativas tcnicas, pruebas y evaluacin de cada incremento).



Es adems recomendable que el propietario de producto:

Conozca Scrum para realizar con solvencia las tareas que le corresponden: o Desarrollo y administracin de la pila del producto. o Exposicin de la visin e historias de usuario, y participacin en la reunin de planificacin

de cada sprint. Conozca y haya trabajado previamente con el mismo equipo.

El equipo Se recomienda que los equipos que trabajan con Scrum tengan entre 4 y 8 personas. Ms all de 8 resulta ms difcil mantener la agilidad en la comunicacin directa, y se manifiestan con ms intensidad las rigideces habituales de la dinmica de grupos (que comienzan a aparecer a partir de 6 personas).

No se trata de un grupo de trabajo formado por un arquitecto, diseador o analista, programadores y testers. Es un equipo multidisciplinario, en el que todos los componentes trabajan de forma solidaria con responsabilidad compartida

Las principales responsabilidades, ms all de la autoorganizacin y uso de tecnologas giles, son las que se marcan la diferencia entre grupo de trabajo y equipo.

Un grupo de trabajo es un conjunto de personas que realizan un trabajo, con una asignacin especfica de tareas, responsabilidades y siguiendo un proceso o pautas de ejecucin. Los operarios de una cadena, forman un grupo de trabajo: aunque tienen un jefe comn, y trabajan en la misma organizacin, cada uno responde por su trabajo.

El equipo tiene espritu de colaboracin, y un propsito comn: conseguir el mayor valor posible para la visin del cliente.

Un equipo Scrum responde en su conjunto. Trabajan de forma cohesionada y autoorganizada. No hay un gestor para delimitar, asignar y coordinar las tareas. Son los propios miembros del equipo los que lo realizan.

En el equipo:

Todos conocen y comprenden la visin del propietario del producto. Aportan y colaboran con el propietario del producto en el desarrollo de la pila del 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 aportes de todos. Todos conocen el modelo de trabajo con Scrum.

Scrum Master Es el responsable del funcionamiento de Scrum en el proyecto, cubriendo los aspectos que la organizacin necesite segn el conocimiento y experiencia con el modelo: Asesora y formacin al propietario del producto.

Asesora y formacin al equipo. Revisin y validacin de la pila del producto. Moderacin de las reuniones. Resolucin de impedimentos que en el sprint pueden entorpecer la ejecucin de las tareas. Gestin de las dinmicas de grupo en el equipo. Configuracin, diseo y mejora continua de las prcticas de Scrum en la organizacin. Respeto de la

organizacin y los implicados, con las pautas de tiempos y formas de Scrum.

En implementaciones no estndar o acadmicas, basadas en responsabilidades (no en roles) es habitual no contar con un rol especfico de Scrum Master, y la garanta de funcionamiento de Scrum las funciones propias del scrum Master las suele asumir un puesto especfico para contar con esta garanta (Team Leader o Gestor gil).


Medicin y estimacin gil



Por qu medir?

La informacin es la materia prima para la toma de decisiones, y la que puede ser objetivamente cuantificada proporciona criterios objetivos de gestin y seguimiento.

Desde los niveles concretos de la programacin, hasta los ms generales de la gestin global de la compaa, Scrum Management considera tres fondos de escala, o de zoom con los que se puede medir el trabajo

Desarrollo y gestin de la solucin tcnica. Gestin de proyecto. Gestin de la organizacin.

En el primero se puede medir, por ejemplo, la proporcin de polimorfismo del cdigo de un programa, en el segundo, el porcentaje de trabajo realizado, y en el tercero, tambin por ejemplo, el nivel de satisfaccin laboral.

Ilustracin 9: mbirtos de medicin

Este curso cubre el rea de gestin de proyectos, desde una perspectiva gil; pero en esta introduccin se exponen consideraciones generales, comunes a los tres.

Flexibilidad y sentido comn

Antes de incorporar un procedimiento de medicin, se debe cuestionar su conveniencia, y la forma en la que se aplicar.

No se deben implantar procesos de medicin tan slo porque s.

Tomar una lista ms o menos prestigiosa de mtricas e incorporarla a los procedimientos de la empresa, puede tentar por la imagen de profesionalidad que transmitir un escenario de trabajo monitorizado con indicadores y complejas mediciones, pero no dice mucho a favor de cmo se han analizado y adaptado esas mtricas a la realidad de los proyectos y la empresa.

Medir no es un fin en s mismo

Medir es costoso

Medicin y estimacin gil


Criterios para el diseo y aplicacin de mtricas

Cuantas menos, mejor Medir es costoso Medir aade burocracia El objetivo de Scrum Management es trabajar con la mejor relacin valor / simplicidad.

Aspectos que deben cuestionarse antes de implantar la medicin y registro de un indicador:

Por qu se va a usar? Cul es el valor por incorporarlo? Cul por omitirlo? Se pueden tomar decisiones de gestin sin esa informacin?

El objetivo de la gestin Scrum es el valor, y la cuestin clave para la incorporacin de indicadores en la gestin de proyectos es:

Cmo contribuye el uso de este indicador en el valor que el proyecto va a aportar al cliente?

El indicador es apropiado para el fin que se debe conseguir? Medir no es, o no debera ser, un fin en s mismo.

Cul es el fin?

Cumplir agendas, mejorar la eficiencia del equipo, las previsiones?

Sea crtico. Decir que eso lo miden casi todos, no es una razn. Si despus de analizarlo no le convence, si prefiere no incorporar esa mtrica, o modificarla: usted es el gestor.

Determinar qu medir es la parte ms difcil. En el mejor de los casos, las decisiones errneas slo supondrn un coste de gestin evitable; pero muchas veces empeorarn lo que se intentaba mejorar.

Un ejemplo: Medicin de la eficiencia de los trabajos de programacin

La organizacin XYZ ha adoptado mtricas estndar de eficiencia de Ingeniera del Software:

LOC/Hour: Nmero total de lneas de cdigo nuevas o modificadas en cada hora.

Adems para motivar la productividad, ha vinculado los resultados de esta mtrica a la retribucin por desempeo de los programadores. El resultado ha sido producir ms lneas de cdigo sin incrementar la plantilla.

Para evitar que se trate de un incremento hueco de lneas de cdigo, o que conlleve un aumento de los errores por programar ms deprisa, se ha dotado de mayor rigor al sistema de mtrica, incorporando al poco tiempo otras mtricas para complementar y mejorar el sistema de calidad:

Test Defects/KLOC, Compile Defects/KLOC y Total Defects/KLOC, para controlar que no aumenten el nmero de errores deslizados en el cdigo.

Tambin se incorporaron indicadores appraisal time para medir tiempo y costes del diseo y la ejecucin de las revisiones de cdigo.

Y por el temor a que el sistema de medicin pueda resultar excesivamente costoso se incorporan tambin indicadores de coste de calidad (COQ) que miden los tiempos de revisin y los contrastan con las mejoras en los tiempos eliminados por reduccin de fallos.

Lo que vamos a medir es un indicador vlido de lo que queremos conocer?

Hay tareas de programacin relativamente mecnicas, orientadas ms a la integracin y configuracin que en al desarrollo de nuevos sistemas.

Para aquellas puede resultar medianamente acertado considerar la eficiencia como volumen de trabajo realizado por unidad de tiempo.



Para las segundas sin embargo, es ms apropiado pensar en la cantidad de valor integrado por unidad de desarrollo; expresadas stas en horas, iteraciones o puntos de funcin.

Qu queremos conocer: la cantidad de lneas de programa, o el valor que entregamos al cliente?

Est relacionado lo uno con lo otro?

Se puede medir objetivamente el valor entregado al cliente?

En nuestro trabajo son muchos los parmetros que se pueden medir con criterios objetivos y cuantificables: el tiempo de tarea, los tiempos delta, y los de las interrupciones, el n de puntos de funcin, la inestabilidad de los requisitos, la proporcin de acoplamiento, el n de errores por lnea de cdigo

No estaremos muchas veces midiendo esto, simplemente porque es cuantificable?

No estaremos midiendo el n de lneas que desarrollan las personas cuando en realidad queremos saber el valor de su trabajo?

No nos estar pasando lo mismo cuando pretendemos medir: la facilidad de uso, la facilidad de mantenimiento, la flexibilidad, la transportabillidad, la complejidad, etc.?

Un ejemplo: Medicin de la eficiencia en la empresa

La organizacin XYZ, dedicada al desarrollo de software, est integrando un sistema de calidad y mejora integral para toda la empresa, que incluye mtricas para conocer el grado de eficiencia en cada departamento.

Para el de RR.HH. se ha diseado e implantado un indicador habitual para estos casos, que determina la eficiencia en los procesos de seleccin de personal.

Mide el coste de cada proceso de seleccin (anuncios, seleccin de currculos, entrevistas) y lo divide por el nmero de puestos cubiertos.

Como no slo es importante la eficiencia, sino tambin la satisfaccin del cliente (interno en este caso, que ser el departamento que solicita personal) esta mtrica se combina con otra para determinarlo: tiempo de respuesta.

Cunto tiempo se tarda en cubrir las vacantes.

La implantacin del indicador ha dado buenos resultados: desde su puesta en marcha, el departamento de RR.HH. ha comenzado a ser ms eficiente y conseguir mayor satisfaccin de su cliente:

1.- Va reduciendo los costes que suponen la incorporacin de nuevas personas a la empresa.

2.- Va reduciendo los tiempos de respuesta a los departamentos que solicitan nuevo personal.

Se podra considerar una buena mtrica?

Medicin: Las unidades


Velocidad, trabajo y tiempo

Velocidad, trabajo y tiempo son las tres magnitudes que mide la gestin de proyectos gil, y componen la frmula de la velocidad, definindola como: cantidad de trabajo realizada por unidad de tiempo.

Velocidad = Trabajo / Tiempo

As por ejemplo, se puede decir que la velocidad de un equipo de 4 miembros es de 20 puntos por semana o de 80 puntos por sprint.

Tiempo Para mantener un ritmo de avance continuo, el desarrollo gil emplea dos tcticas posibles: incremento iterativo, o incremento continuo.

Ilustracin 10: Agilidad con incremento iterativo o continuo

El avance a travs de incrementos iterativos mantiene un ritmo continuo basado en pulsos de sprints. Por esta razn emplea normalmente el sprint como unidad de tiempo, expresando la velocidad como trabajo o tareas realizadas en un sprint.

Nota En Scrum acadmico esta es la definicin de velocidad, porque el marco acadmico de scrum emplea nicamente incremento iterativo (sprints).

El avance a travs de un incremento continuo ajusta un flujo regular de trabajo evitando puntos muertos y cuellos de botella. En este caso, para medir el tiempo se emplean das, semanas o meses, de forma que para expresar la velocidad se habla de trabajo (tareas, puntos) por semana (o por da, mes)



Tiempo real y tiempo ideal

Antes de continuar, una observacin: la diferencia que se hace en la gestin gil al hablar de tiempo, entre tiempo real y tiempo ideal.

Tiempo real, es el efectivo de trabajo. Equivale a la jornada laboral.

Para un equipo de cuatro personas con jornada laboral de ocho horas el tiempo real en una semana (cinco das laborables) es:

4 * 8 * 5 = 160 horas

Ilustracin 11: Tiempo ideal y tiempo real

Sin embargo el trmino tiempo ideal no se emplea para medir tiempo, sino trabajo o esfuerzo necesario, y normalmente en estimaciones, porque se refiere al tiempo que en condiciones ideales hara falta para completar una tarea, considerando condiciones ideales: sin ninguna pausa por distraccin interrupcin o atencin a tareas ajenas al trabajo.

As para determinar el trabajo que se estima, necesario para realizar una tarea se puede hablar de x horas ideales.

Es un concepto similar al que PSP3 denomina Delta Time como la parte del tiempo laboral que es

realmente tiempo efectivo de trabajo.

Trabajo Medir el trabajo puede ser necesario por dos razones: para registrar el ya hecho, o para estimar anticipadamente, el que hay que realizar.

En ambos casos se necesita una unidad, y un criterio objetivo de cuantificacin.

Trabajo ya realizado Medir el trabajo ya realizado no entraa especial dificultad.

Se puede hacer con unidades relativas al producto (p. ej. lneas de cdigo) o a los recursos empleados (coste, tiempo de trabajo)

Para medirlo basta contabilizar lo ya realizado con la unidad empleada: lneas de cdigo, puntos de funcin, horas trabajadas, etc.

Medir el trabajo realizado para estimar el porcentaje de trabajo realizado NO es una mtrica gil.

Es posible que otros procesos de la organizacin necesiten registrarlo y medirlo, y por lo tanto sea necesario su registro, pero no debe emplearse para calcular el avance del proyecto.

3 Personal Software Process

La gestin gil no determina el grado de avance del proyecto por el trabajo realizado, sino por el pendiente de realizar.

Tiempo ideal no es una unidad de tiempo, sino de trabajo o esfuerzo necesario.



Trabajo pendiente de realizar Scrum mide el trabajo pendiente para:

Estimar el esfuerzo y la duracin prevista para completar el trabajo (tareas, historias de usuario o epics).

Determinar el avance del proyecto, y en especial en cada sprint.

Para Scrum Management, estimar con precisin, de forma cuantitativa y objetiva el trabajo que necesitar la construccin de un requisito, es un empeo ms que cuestionable.

Ilustracin 12: Medicin del trabajo pendiente

El trabajo necesario para realizar de un requisito o una historia de usuario no se puede predecir de forma absoluta, porque las funcionalidades no son realidades de solucin nica, y en el caso de que se pudiera, la complejidad de la medicin hara que la mtrica resultante fuera demasiado pesada para la gestin gil.

Y si no resulta posible estimar con precisin la cantidad de trabajo que hay en un requisito, tampoco se puede saber cunto tiempo costar llevarlo a cabo, porque adems de la incertidumbre del trabajo, se suman las inherentes al tiempo:

No es realista hablar de la cantidad o de la calidad del trabajo que realiza una persona por da, o por hora, porque hay diferencias muy grandes de estos resultados, segn las personas.

Una misma tarea, realizada por las mismas personas consumir diferentes tiempos reales en entornos o situaciones de trabajo diferentes.

Sobre estas premisas:

No es posible estimar con precisin, ni el trabajo de un requisito, ni el tiempo necesario para desarrollarlo.

La complejidad de las tcnicas de estimacin crece exponencialmente en la medida que:

o Intentan incrementar la fiabilidad y precisin de los resultados.

o Aumenta el tamao de la tarea estimada.

La estrategia empleada por la gestin gil es:

No empearse en estimaciones precisas. Estimar con la tcnica juicio de expertos

Descomponer las tareas de los sprints en subtareas ms pequeas, si las estimaciones superan los rangos de un da de trabajo efectivo.



Unidades de trabajo Las unidades para medir el trabajo pueden estar relacionadas directamente con el producto, como los tradicionales puntos de funcin de COCOMO; o indirectamente, a travs del tiempo necesario para realizarlo.

Ilustracin 13: Velocidad

La gestin gil suele llamar a las unidades que emplea para medir el trabajo puntos, puntos de funcionalidad puntos de historia

As por ejemplo la unidad de medida Story Point de eXtreme Programming define: la cantidad de trabajo que se realiza en un da de trabajo ideal.

Cada organizacin, segn sus circunstancias y su criterio institucionaliza su mtrica de trabajo definiendo el nombre y las unidades.

Puede basarse en

Estimacin del tamao relativo y emplear puntos Estimacin del tiempo ideal estimado como necesario para realizar la tarea que se mide.

Lo importante es que la mtrica empleada, su significado y la forma de aplicacin sea consistente en todas las mediciones, en todos los proyectos de la organizacin y conocida por todas las personas:

Que se trate de un procedimiento de trabajo institucionalizado.

Velocidad Velocidad es la magnitud determinada por la cantidad de trabajo realizada en un periodo de tiempo

Velocidad en un marco acadmico de Scrum es la cantidad de trabajo realizada por el equipo en un sprint. As por ejemplo una velocidad de 150 puntos indica que el equipo realiza 150 puntos de trabajo en cada sprint.

Al trabajar con incremento continuo o en implantaciones flexibles de scrum, que pueden tener sprints de diferentes duraciones o no siempre con el mismo nmero de miembros en el equipo, la velocidad se expresa indicando la unidad de tiempo y en su caso tambin si se refiere a la total del equipo, o media por persona. As por ejemplo: La velocidad media del equipo es de 100 puntos por semana. La velocidad media de una persona del equipo es de 5 puntos por da.

Medicin: usos y herramientas

Grfico de producto. El grfico de producto o grfico burn up es una herramienta de planificacin propia del propietario del producto, que presenta visualmente la evolucin previsible del producto. Proyecta en el tiempo su construccin, en base a la velocidad del equipo.

La proyeccin se realiza sobre un diagrama cartesiano que representa en el eje de ordenadas el esfuerzo estimado para construir las diferentes historias de la pila del producto, y en el de las abscisas el tiempo medido en sprints.

Ilustracin 14: Grfico de producto

Ejemplo

Convenciones empleadas por el equipo:

Unidad para medicin de trabajo: puntos de scrum. Est previsto trabajar con sprints de duracin fija: mensual (20 das laborables) El equipo est formado por 4 personas, y desarrolla una velocidad media de 400 puntos por sprint.

Ilustracin 15: Grfico de producto como plan de producto


42 2005-2013 ScrumManager - http://www.scrummanager.net

Se traza en el grfico la lnea que representa el ritmo de avance previsto, segn la velocidad media del equipo (en este ejemplo 400 puntos por sprint).

Ilustracin 16: Grfico de producto: velocidad prevista

Es recomendable trazar tambin los ritmos de avance con una previsin pesimista y otra optimista. Se dibujan basndose en informacin de los proyectos anteriores que han ido peor y mejor de lo previsto, o en su defecto estableciendo un margen segn el criterio del equipo (ej. +- 20%).

Ilustracin 17: Grfico de producto: velocidad optimista y pesimista

A continuacin se toma la pila del producto. La figura siguiente representa la empleada en este ejemplo:


2005 - 2013 ScrumManager Project http://www.scrummanager.net

43

Ilustracin 18: Ejemplo de pila del producto

En este caso, el propietario del producto tiene previsto lanzar la versin 1.0 cuando disponga de las cuatro primeras historias, que tienen un esfuerzo estimado de 950 puntos (150+250+250+300).

Adems tiene tambin esbozadas las previsiones para versiones posteriores: 1.1 y 1.2 tal y como muestra la figura siguiente:

Ilustracin 19: Versiones del producto previstas

Para trazar la previsin, se sita cada versin en el eje vertical en la posicin correspondiente al esfuerzo estimado para construir todas las historias que incluye.

Siguiendo con el ejemplo, la posicin de la versin 1.0 se situara sobre el valor 950 del eje de ordenadas:

Ilustracin 20: Representacin de la versin 1 sobre el grfico de producto



Los puntos de corte que marca esta posicin con las lneas de velocidad del equipo (pesimista, realista y optimista) proyectan en el eje horizontal la fecha o sprint en el que se completar la versin.

Ilustracin 21: Previsin de fechas sobre el grfico de producto

De igual forma se pueden proyectar las estimaciones tempranas de las futuras versiones previstas.

Ilustracin 22: previsin de lanzamiento de versiones sobre grfico de producto

Esta es una herramienta para desarrollo gil.

Proyecta la previsin de la pila del producto, que es un documento vivo cuya evolucin preestablece la del producto.

Como herramienta gil no debe considerarse para representar planes estables, sino las previsiones tras cada evolucin de la pila del producto. .

Grfico de avance: monitorizacin del sprint Tambin se suele emplear la denominacin inglesa: grfico burn-down.

Es el grfico que actualiza el equipo en las reuniones de seguimiento del sprint, para comprobar el ritmo de avance, y detectar desde el primer momento si es el previsto, o por el contrario se puede ver comprometida la entrega prevista al final de sprint.

La estrategia gil para el seguimiento de los proyectos se basa en:



45

Medir el esfuerzo que falta, no el realizado. Seguimiento cercano del avance (diario de ser posible).

Y en este grfico toman forma los dos principios:

En el eje Y se registra el trabajo que an falta por realizar. Se actualiza a diario.

Ilustracin 23: Grfico de avance

El equipo dispone en la pila del sprint, de la lista de tareas que va a realizar, y en cada uno figura el esfuerzo pendiente.

Esto es: el primer da, en la pila de tareas figura para cada tarea el esfuerzo que se ha estimado, puesto que an no se ha trabajado en ninguna de ellas.

Da a da, cada miembro del equipo actualiza en la pila del sprint el tiempo que le queda a las tareas que va desarrollando, hasta que se terminan y van quedando en 0 los tiempos pendientes.

La figura siguiente muestra un ejemplo de pila en el sexto da del sprint: las tareas terminadas ya no tienen esfuerzo pendiente, y del esfuerzo total previsto para el sprint: 276 puntos (A), en el momento actual quedan 110 (B).

Ilustracin 24: Pila del sprint

Con esta informacin de la pila del sprint se actualiza el grfico poniendo cada da el esfuerzo pendiente total de todas las tareas que an no se han terminado.



Ilustracin 25: De la pila del sprint al grfico de avance

El avance ideal de un sprint estara representado por la diagonal que reduce el esfuerzo pendiente de forma continua y gradual hasta terminarlo en el ltimo da del sprint:

Ilustracin 26: Grfica de avance previsto

Las grficas de diagonal perfecta no son lo habitual, y la siguiente imagen es un ejemplo de un patrn de avance ms normal.

Ilustracin 27: Grfica de avance real

El siguiente sera el aspecto de la grfica en un sprint subestimado



47

Ilustracin 28: Grfica de avance de un sprint subestimado

La estimacin que realiz el equipo en la reunin de inicio del sprint es inferior al esfuerzo real que estn requiriendo las tareas.

Y el siguiente sera el patrn de grfica de un sprint sobreestimado .

Ilustracin 29: Grfica de avance de un sprint sobreestimado

Estimacin de pquer Es una prctica gil, til para conducir las reuniones en las que se estima el esfuerzo y la duracin de tareas.

Para evitar en estos casos las discusiones dilatadas que no terminan de dar conclusiones concretas, James Grening ide este juego de planificacin como ayuda para conducir la reunin.

El modelo inicial de Grening consta de 8 cartas, con los nmeros representados en siguiente figura, porque James lo ide para las estimaciones de versin en eXtreme Programming, con equipos que emplean como unidad de esfuerzo: das de trabajo de cada par de programadores

4 y trabajan con historias de usuario de

tamao mximo de 10 das.5

4 eXtreme Programming trabaja con programacin por parejas.

5 Las tareas de mayor tamao se descomponen en sub-tareas hasta que stas tienen estimaciones mximas de 10 das.



Ilustracin 30: Cartas para planificacin de pquer

El funcionamiento es muy simple: cada participante dispone de un juego de cartas, y en la estimacin de cada tarea, todos vuelven boca arriba la combinacin que suma el esfuerzo estimado.

Cuando se considera que ste es mayor de 10 horas (o del tamao mximo considerado por el equipo para

una historia), se levanta la carta

Cada equipo u organizacin puede utilizar un juego de cartas con las numeraciones adecuadas a la unidad de esfuerzo con la que trabajan, y el tamao mximo de tarea o historia que se va a estimar.

Lo relevante no es el nmero de cartas, la unidad de medida empleada, o si el tamao mximo debe ser 5, 7 10 das, sino trabajar con el modelo que el equipo considera ms apropiado, respetando los principios siguientes:

No estimar trabajos demasiado grandes, porque entorpece la precisin de las estimaciones y la identificacin de riesgos.

No definir tareas cuya duracin (en puntos o tiempo) resulte inferior a medio da ideal de trabajo. Utilizar al misma unidad de medida (story points, das, horas) en todos los grficos y pilas.

Variante: sucesin de Fibonacci

Basado en el hecho de que al aumentar el tamao de las tareas, aumenta tambin el margen de error, se ha desarrollado una variante que consiste en emplear slo nmeros de la sucesin de Fibonacci para realizar las estimaciones, de forma que:

El juego de cartas est compuesto por nmeros de la sucesin de Fibonacci. La estimacin no se realiza levantando varias cartas para componer la cifra exacta, sino poniendo

boca arriba la carta con la cifra ms aproximada a la estimacin.

Para estimar tareas puede ser vlido un juego de cartas como ste:

Ilustracin 31: Cartas para estimacin de pquer (Fibonacci)



49

Es frecuente emplear una carta con un smbolo de duda o interrogacin para indicar que, por las razones que sean, no se puede precisar una estimacin.

Tambin es posible incluir otra carta con alguna imagen alusiva, para indicar que se necesita un descanso.

Funcionamiento

Cada participante de la reunin tiene un juego de cartas. Para cada tarea (historia de usuario o funcionalidad, segn sea el nivel de requisitos que se va a

estimar) el cliente, moderador o propietario del producto expone la descripcin empleando un tiempo mximo.

Hay establecido otro tiempo para que el cliente o propietario del producto atienda a las posibles preguntas del equipo.

Cada participarte selecciona la carta, o cartas que representan su estimacin, y las separa del resto, boca abajo.

Cuando todos han hecho su seleccin, se muestran boca arriba. Si la estimacin resulta infinito, por sobrepasar el lmite mximo establecido, la tarea debe dividirse

en sub-tareas de menor tamao. Si las estimaciones resultan muy dispares,

Documents

Scrum_I