Manual de SCRUM

7/25/2019 Manual de SCRUM

1/98

Gestin de proyectos Scrum Managerv. 2.5


2/98


3/98

Scrum Manager es marca registrada, propiedad de Iubaris Info 4 Media S.L.

Gestin de proyectos Scrum Manager(Scrum Manager I y II)

Versin 2.5Abril 2014

Diseo de cubierta: Scrum Manager.Imagen derivada de la original: The Albert Bridge 04Belfast de William Murphy (http://www.streetsofdublin.com/)

2014 Juan Palacio De la edicin: Scrum ManagerInformacin de derechos y licencia de uso:

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


4/98


5/98

2005-2014ScrumManager - http://www.scrummanager.net 5

ContenidoContenido 5

Formacin Scrum Manager 9

Servicios de formacin y asesora Scrum Manager 9

Mejora continua y control de calidad Scrum Manager 11

PRIMERA PARTE 13

Agilidad 14

El Manifiesto gil 14

Los 12 principios del manifiesto gil 16

Origen de scrum. 16

Adopciones de scrum: tcnica y pragmtica 18

Introduccin al modelo 19

Gestin de la evolucin del proyecto 19

Revisin de las Iteraciones 19

Desarrollo incremental 19

Autoorganizacin 20

Colaboracin 20

Scrum tcnico 23

Scrum tcnico 24

Artefactos 24

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

Pila del producto: los requisitos del cliente 26

Pila del Sprint 28

El Incremento 29

Eventos 29

Planificacin del sprint 30

Scrum diario 32

Revisin del sprint 33

Retrospectiva 34

Roles 34

Propietario del producto 35

Equipo de desarrollo 36

Scrum Master 36

Cultura y Valores 37

Medicin y estimacin gil 39

Por qu medir? 40


6/98

Contenido

6

Flexibilidad y sentido comn 40

Criterios para el diseo y aplicacin de mtricas 41

Cuantas menos, mejor 41

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

Velocidad, trabajo y tiempo 43

Tiempo 43

Trabajo 44

Trabajo ya realizado 44

Trabajo pendiente de realizar 44

Unidades de trabajo 46

Velocidad 46

Medicin: usos y herramientas 47

Grfico de producto. 47

Grfico de avance: monitorizacin del sprint 50

Estimacin de pquer 53

SEGUNDA PARTE 57

1.- Conocimiento en continua evolucin 58

2.- Empresa como sistema 60

3.- Flexibilidad 61

Scrum pragmtico 62

Scrum Pragmtico 63Responsabilidades 64

Metodologas 66

Mapa de metodologas. 66

Conceptos 66

Patrones de gestin del proyecto 67

Personas, Procesos y Tecnologa 68

Procesos 68

Personas 69

Gestin visual kanban para scrum 71

Gestin visual kanban para obtener incremento continuo. 72

Introduccin: De la artesana a la produccin lean 73

Lean 75

Lean Software Development 76

Kanban: Origen y definicin 78

Tableros kanban: conceptos 80

Kanban: Operativa 81Casos prcticos de tableros kanban 84


7/98

Contenido


Kanban Box 88

Muda, Mura y Muri y consejos para ajustar el flujo. 91

Bibliografa 93

Tabla de ilustraciones 95

ndice 97


8/98


9/98

Formacin Scrum Manager


Formacin Scrum ManagerEste libro cubre los niveles I y II del conocimiento troncalde formacin Scrum Manager

Los contenidos de formacin se mantienen regularmente actualizados. Puede descargar la ltima versin, oconsultarla en lnea en la direccin:http://www.scrummanager.net/bok

Este documento es un recurso educativo abierto (OER) y puede emplearsegratuitamente para consulta y autoformacin.

No est permitido su uso para actividades comerciales.

Los recursos educat ivos abiertos de Scrum Manager son po sib les gracias alsopor te de los:

Servicios de formacin y asesora Scrum Manager

Cursos en convocatorias presenciales, o a medida para empresas o grupos de estudiantes.o Puede consultar el calendario de convocatorias en diferentes ciudades en la pgina de

cursos dehttp://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 [email protected]

Exmenes p resenc iales de certi fic acin. con supervisin de la ejecucin de la prueba, e

identificacin del alumnoo Incluidos en los cursos presenciales.o Disponibles en centros de formacin autorizados.

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

Ms informacin:

http://www.scrummanager.net(preguntas frecuentes)http://www.scrummanager.net/[email protected]
http://www.scrummanager.net/bokhttp://www.scrummanager.net/bokhttp://www.scrummanager.net/bokhttp://www.scrummanager.net/http://www.scrummanager.net/http://www.scrummanager.net/http://scrummanager.net/centroshttp://scrummanager.net/centroshttp://scrummanager.net/centrosmailto:[email protected]:[email protected]:[email protected]://scrummanager.net/http://scrummanager.net/http://www.scrummanager.net/http://www.scrummanager.net/http://www.scrummanager.net/http://scrummanager.net/mailto:[email protected]://scrummanager.net/centroshttp://www.scrummanager.net/http://www.scrummanager.net/bok


10/98


11/98

Control de calidad Scrum Manager


Mejora continua y control de calidad Scrum ManagerGracias por elegir los servicios de formacin de Scrum Manager

Su valoracin es el criter io del con trol de calidad de Scrum Manager,y decide la validez o no de los

servicios de formacin, y en su caso la continuidad de los cursos, centros y profesores.Si ha participado en una actividad de formacin auditada por Scrum Manager, le rogamos y agradecemosque valore la calidad del material, profesor, temario, etc. as como tus comentarios y sugerencias.

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

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


12/98


13/98

PRIMERA PARTE

Las reglas de scrum.


14/98

Scrum

14

AgilidadEl entorno de trabajo de las empresas del conocimiento se parece muy poco al que origin la gestin deproyectos predictiva. Ahora se necesitan estrategias para el lanzamiento de productos orientadas a laentrega temprana de resultados tangibles, y a la respuesta gil y flexible, necesaria para trabajar enmercados de evolucin rpida.

Ahora se construye el producto mientras se modifican y aparecen nuevos requisitos. El cliente parte de unavisin medianamente clara, pero el nivel de innovacin que requiere, y la velocidad a la que se mueve susector de negocio, no le permiten predecir con detalle cmo ser el resultado final.

Quiz ya no hay productos finales, sino productos en continua evolucin y mejora.

La gestin de proyectos predictiva es la nica posible? Los criterios para determinar el xito son siempreel cumplimiento de fechas y costos? Puede haber proyectos cuya gestin no busque realizar un trabajopreviamente 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 quetendr el producto final, ni si este estar terminado en 12 o en 16 meses.

Hay clientes que necesitan disponer de una primera versin con funcionalidades bsicas en cuestin desemanas, y no un producto completo dentro de uno o dos aos. Clientes cuyo inters es poner en elmercado rpidamente un concepto nuevo, y desarrollar de forma continua su valor.

Hay proyectos que no necesitan gestionar el seguimiento de un plan, y que fracasan por haber empleado unmodelo de gestin inapropiado.

La mayora de los fiascos se producen por aplicar ingeniera secuencial y gestin predictiva tanto en el

proceso de adquisicin (requisitos, contratacin, seguimiento y entrega) como en la gestin del proyecto, enproductos que no necesitan tanto garantas de previsibilidad en la ejecucin, como respuesta rpida yflexibilidad para funcionar en entornos de negocio que cambian y evolucionan rpidamente.

El Manifiesto gilEn marzo de 2001, 17 crticos de los modelos de produccin basados en procesos, convocados por KentBeck, que haba publicado un par de aos antes el libro en el que explicaba la nueva metodologa ExtremeProgramming (Beck, 2000) se reunieron en Salt Lake City para discutir sobre el desarrollo de software. En lareunin se acu el trmino Mtodos giles para definir a aquellos que estaban surgiendo comoalternativa a las metodologas formales: CMM-SW, (precursor de CMMI) PMI, SPICE (proyecto inicial de

ISO 15504), a las que consideraban excesivamente pesadas y rgidas por su carcter normativo y fuertedependencia de planificaciones detalladas, previas al desarrollo.

Los integrantes de la reunin resumieron en cuatro postulados lo que ha quedado denominado comoManifiesto gil, que son los valores sobre los que se asientan estos mtodos.

Hasta 2005, entre los defensores de los modelos de procesos y los de modelos giles fueron frecuentes lasposturas radicales, ms ocupadas en descalificar al otro, que en estudiar sus mtodos y conocerlos paramejorar los propios.

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


15/98

Scrum


Valoramos ms a los individuos y su interaccin que a los procesos y lasherramientas.Este es el valor ms importante del manifiesto.

Por supuesto que los procesos ayudan al trabajo. Son una gua de operacin. Las herramientas mejoran laeficiencia, pero hay tareas que requieren talento y necesitan personas que lo aporten y trabajen con unaactitud adecuada.

La produccin basada en procesos persigue que la calidad del resultado sea consecuencia del know-howexplicitado en los procesos, ms que en el conocimiento aportado por las personas que los ejecutan.

Sin embargo en desarrollo gil los procesos son una ayuda. Un soporte para guiar el trabajo. La defensa aultranza de los procesos lleva a afirmar que con ellos se pueden conseguir resultados extraordinarios con

personas mediocres, y lo cierto es que este principio no es cierto cuando se necesita creatividad einnovacin.

Valoramos ms el software que funciona que la documentacin exhaustiva.Poder anticipar cmo ser el funcionamiento del producto final, observando prototipos previos, o partes yaelaboradas ofrece un "feedback" estimulante y enriquecedor, que genera ideas imposibles de concebir enun primer momento, y difcilmente se podran incluir al redactar un documento de requisitos detallado en elcomienzo del proyecto.

El manifiesto gil no da por intil la documentacin, slo la de la documentacin innecesaria. Losdocumentos son soporte de hechos, permiten la transferencia del conocimiento, registran informacinhistrica, y en muchas cuestiones legales o normativas son obligatorios, pero su relevancia debe ser muchomenor que el producto final.

La comunicacin a travs de documentos no ofrece la riqueza y generacin de valor que logra lacomunicacin directa entre las personas, y a travs de la interaccin con prototipos del producto.

Por eso, siempre que sea posible debe preferirse reducir al mnimo indispensable el uso de documentacin,que requiere trabajo sin aportar un valor directo al producto.

Si la organizacin y los equipos se comunican a travs de documentos, adems de ocultar la riqueza de lainteraccin con el producto, forman barreras de burocracia entre departamentos o entre personas.

Valoramos ms la colaboracin con el cliente que la negociacin contractual.Las prcticas giles estn indicadas para productos cuyo detalle resulta difcil prever al principio delproyecto; y si se detallara al comenzar, el resultado final tendra menos valor que si se mejoran y precisancon retroinformacin continua durante el.

Manifiesto gilEstamos 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 ind iv iduos y su interaccin, por encima de los procesos y las herramientas. El sof tware que funcion a, por encima de la do cum entacin exhaust iva. La colaboracin con el cl iente, por encim a de la negociacin contractu al. 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.


16/98

Scrum

16

Tambin son apropiadas cuando se prevn requisitos inestables por la velocidad de cambio en el entornode negocio del cliente.

El objetivo de un proyecto gil no es controlar la ejecucin conforme a procesos y cumplimiento de planes,sino proporcionar el mayor valor posible al producto.

Resulta por tanto ms adecuada una relacin de implicacin y colaboracin continua con el cliente, ms queuna contractual de delimitacin de responsabilidades.

Valoramos ms la respuesta al cambio que el seguimiento de un planPara desarrollar productos de requisitos inestables, que tienen como factor inherente el cambio y laevolucin rpida y continua, resulta mucho ms valiosa la capacidad de respuesta que la de seguimiento yaseguramiento de planes. 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 que evite desviaciones del plan.

Los 12 principios del manifiesto gilEl manifiesto gil, tras los postulados de estos cuatro valores en los que se fundamenta, establece estos 12principios:

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

2. Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos gilesse 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 demeses, con preferencia en los periodos breves.

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

5. Construccin de proyectos en torno a individuos motivados, dndoles la oportunidad y el respaldoque 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 dedesarrollo 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.

Origen de scrum.Scrum es un modelo de desarrollo gil caracterizado por:

Ad optar un a estrategia de desarrol lo inc remental, en lugar d e la planif icacin y ejecucincom pleta del producto.

Basar la calidad del resultado ms en el conoc imiento tcito de las person as en equipo sautoorganizados, que en la cal idad d e los p rocesos empleados.

Solapamiento de las diferentes fases del desarrol lo , en lugar de realizar un a tras otra en uncic lo s ecuencial o de cascada.

Este modelo fue identificado y definido por Ikujiro Nonaka e Hirotaka Takeuchi a principios de los 80, alanalizar cmo desarrollaban los nuevos productos las principales empresas de manufactura tecnolgica:Fuji-Xerox, Canon, Honda, Nec, Epson, Brother, 3M y Hewlett-Packard (Nonaka & Takeuchi, The New NewProduct Development Game, 1986)

En su estudio, Nonaka y Takeuchi compararon la nueva forma de trabajo en equipo, con el avance enformacin de scrum de los jugadores de Rugby, a raz de lo cual qued acuado el trmino scrum parareferirse a ella.


17/98

Scrum


Aunque esta forma de trabajo surgi en empresas de productos tecnolgicos, es apropiada para proyectoscon requisitos inestables y para los que requieren rapidez y flexibilidad, situaciones frecuentes en eldesarrollo de determinados sistemas de software.

En 1995 Ken Schwaber present Scrum Development Process en OOPSLA 95 (Object-OrientedProgramming Systems & Applications conference) (SCRUM Development Process), un marco de reglaspara desarrollo de software, basado en los principios de scrum, y que l haba empleado en el desarrollo de

Delphi, y Jeff Sutherland en su empresa Easel Corporation (compaa que en los macrojuegos de comprasy fusiones, se integrara en VMARK, y luego en Informix y finalmente en Ascential Software Corporation).


18/98

Scrum

18

Adopciones de scrum: tcnica y pragmticaScrum se puede adoptar de forma tcnica, aplicando reglas definidas, o pragmtica, adoptando los valoresoriginales scrum con reglas personalizadas. ..

Esta primera parte del temario (Scrum Manager I) ensea scrum tcnico, basado en la aplicacin de reglas

concretas en un marco de roles, eventos y artefactos definidos. El aprendizaje de scrum tcnico es el primerpaso aconsejable para familiarizarse con la agilidad.

Una vez iniciados en agilidad, y con el conocimiento que el propio equipo acumula a travs de lasretrospectivas, se pueden ir rompiendo las reglas y adoptar scrum pragmtico, personalizado y msadecuado a las propias circunstancias del propio equipo y proyecto.

Scrum tcnico

eglas

Scrum pragmtico

Valores

Marco de reglas para desarrollo de software

Autores: Ken Schwaber y Jeff SutherlandScrum Development Process OOPSLA95 1995

Concepto original Scrum

Autores: Hirotaka Takeuchi e Ikujiro NonakaThe New New Product Development Game 1986

Aplicacin de reglas definidas Aplicacin de valores giles

Roles Dueo de producto Equipo de desarrollo Scrum Master

Eventos

El Sprint Reunin de planificacin Scrum diario Revisin de sprint Retrospectiva de sprint

Artefactos

Pila de product Pila de sprint Incremento

Personas > procesos Resultado > documentacin Colaboracin > negociacin Cambio > planificacin

Para avanzar en Scrum

Incertidumbre Autoorganizacin Fases de desarrollo solapadas Multiaprendizaje Control sutil

Difusion del conocimiento

Aprender las reglas de Scrum Aprender a avanzar en Scrum sin reglas


19/98

Scrum


Introduccin al modeloEl marco tcnico de scrum, por su sencillez, resulta apropiado para equipos y organizaciones que quierencomenzar a avanzar enscrum

Est formado por un conjunto de prcticas y reglas que resultan vlidos para dar respuesta a los siguientes

principios de desarrollo gil: Gestin evolutiva del avance, en lugar de la tradicional o predictiva. Trabajar basando la calidad del resultado en el con ocim iento tcito de las p erson as, ms que en el

explcito de los procesos y la tecnologa empleada. Estrategia de desar roll o in crem ental a tr avs de iteraci on es(sprints) y revisiones. Seguir los pasos del desarrollo gil: desde el concepto o visin general de la necesidad del cliente,

construccin del producto de forma incremental a travs de iteraciones breves que comprenden fasesde especulacinexploracin y revisin. Estas iteraciones (en scrum llamadas sprints) se repiten deforma continua hasta que el cliente da por cerrada la evolucin del producto.

Se comienza con la visin general de lo que se desea obtener, y a partir de ella se especifica y da detalle alas partes de mayor prioridad, y que se desean tener cuanto antes.

Cada ciclo de desarrollo o iteracin (sprint) finaliza con la entrega de una parte operativa del producto(incremento). La duracin de cada sprint puede ser desde una, hasta seis semanas, aunque se recomiendaque no excedan de un mes.

En scrum, el equipo monitoriza la evolucin de cada sprint en reuniones breves diarias donde se revisa enconjunto el trabajo realizado por cada miembro el da anterior, y el previsto para el da en curso. Estareunin diaria es de tiempo prefijado de 5 a 15 minutos mximo, se realiza de pie junto a un tablero o pizarracon informacin de las tareas del sprint, y el trabajo pendiente en cada una. Esta reunin se denominareunion de pieo scrum diarioy si se emplea la terminologa inglesa: stand-up meeting, tambin: dailyscrum o morning rollcall.

Gestin de la evolucin del proyectoScrum maneja de forma emprica la evolucin del proyecto con las siguientes tcticas:

Revisin de las IteracionesAl finalizar cada sprint se revisa funcionalmente el resultado, con todos los implicados en el proyecto. Es portanto la duracin del sprint, el perodo de tiempo mximo para descubrir 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 ofrece al final de cada iteracin una parte de producto operativa, que se puedeusar, inspeccionar y evaluar.

Scrum resulta adecuado en proyectos con requisitos inciertos y, o inestables.

Por qu predecir la versin definitiva de algo que va a estar evolucionando de forma continua? scrumconsidera a la inestabilidad como una premisa, y adopta tcnicas de trabajo para facilitar la evolucin sindegradar la calidad de la arquitectura y permitir que tambin evolucione durante el desarrollo.

Durante la construccin se depura el diseo y la arquitectura, y no se cierran en una primera fase delproyecto. Las distintas fases que el desarrollo en cascada realiza de forma secuencial, en scrum se solapany realizan de forma continua y simultnea.


20/98

Scrum

20

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

En scrum los equipos son autoorganizados, con un margen de maniobra suficiente para tomar lasdecisiones que consideren oportunas.

ColaboracinEs un componente importante y necesario para que a travs de la autoorganizacin se pueda gestionar consolvencia 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 nosegn su rol o su puesto.


21/98

Scrum


Ilustracin 1: Marco scrum tcnico


22/98


23/98

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

Scrum tcnico


24/98

Scrum tcnico

24

Scrum tcnicoEl marco tcnico de scrum est formado por:

Roles:o El equipo scrum.

o El dueo del producto.o El Scrum Master.

Artefactos:o Pila del producto.o Pila del sprint.o incremento.o Sprint.

Eventoso Reunin de planificacin del sprint.o Scrum diario.o Revisin del sprint.o Retrospectiva del sprint.

Y la pieza clave es el spr in t.

Se denomina sprint a cada ciclo o iteracin de trabajo que produce una parte del producto terminada yfuncionalmente operativa (incremento)

Como se ver ms tarde, al abordar scrum pragmtico, las implementaciones ms flexibles de scrumpueden adoptar dos tcticas diferentes para mantener un avance continuo en el proyecto:

Incremento iterat ivo: basado en pulsos de tiempo prefijado (timeboxing) Incremento con t inuo: basado en el mantenimiento de un flujo continuo, no marcado por pulsos o

sprints.

Ilustracin 2: Incremento iterativo / continuo

Al usar scrum tcnico se trabaja con sprints, y por tanto con incremento iterativo.

Artefactos Pi la 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 sprin t: (sprint backlog) lista de los trabajos que debe realizar el equipo durante el sprint para

generar el incremento previsto. Spr int: nombre que recibe cada iteracin de desarrollo. Es el ncleo central que genera el pulso de

avance por tiempos prefijados (time boxing). Incremento: resultado de cada sprint.


25/98

Scrum tcnico


Ilustracin 3: Diagrama del ciclo iterativo scrum

Otro artefacto propio del modelo estndar de scrum es el grfico de avance o grfico burn downqueel equipo actualiza a diario para comprobar el avance. Este elemento, junto con la prctica deestimacin de pquer y el grfico de producto o burn up se encuentra incluido en el captulo deMtricas giles.

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

Requisitos del sistema Requisitos del software

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

No importa si se trata de gestin tradicional o gil. La 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.


26/98

Scrum tcnico

26

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 derequisitos a travs del proceso de obtencin (elicitacin) con el cliente. En scrum la visin del clientees conocida por todo el equipo (el cliente colabora con el equipo de desarrollo) y la pila del productose realiza y evoluciona de forma continua con los aportes de todos.

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 registra los requisitos vistos desde el punto de vista del cliente. Un enfoque similar al delos requisitos del sistema o ConOps de la ingeniera tradicional. Est formada por la lista defuncionalidades o "historias de usuario" que desea obtener el cliente, ordenadas por la prioridad que elmismo le otorga a cada una.

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

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. Est realizada y gestionada por el cliente (propietario del producto).

Pila del producto: los requisitos del clienteLa pila del producto es el inventario de funcionalidades, mejoras, tecnologa y correccin de errores quedeben 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 quesuponga 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.

La pila de requisitos del producto nunca se da por completada; est en continuo crecimiento y evolucin. Alcomenzar el proyecto incluye los requisitos inicialmente conocidos y mejor entendidos, y conforme avanzael desarrollo, y evoluciona el entorno en el que ser usado, se va desarrollando.

En definitiva su continuo dinamismo refleja aquello que el producto necesita incorporar para ser el msadecuado a las circunstancias, en todo momento.

Para comenzar el desarrollo se necesita la visin del objetivo de negocio que se quiere conseguir con elproyecto, comprendida y conocida por todo el equipo, y elementos suficientes en la pila para llevar a cabo elprimer sprint.

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

El formato de la visin no es relevante. Segn los casos, puede ser una presentacin informal delresponsable 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.

El propietario del producto mantiene la pila ordenada por la prioridad de los elementos, siendo los msprioritarios los que confieren mayor valor al producto, o por alguna razn resultan ms necesarios, y

determinan las actividades de desarrollo inmediatas.


27/98

Scrum tcnico


El detalle de los requisitos en la pila del producto debe ser proporcional a la prioridad: Los elementos demayor prioridad deben tener mayor nivel de comprensin y detalle que los del resto. De esta forma el equipode desarrollo puede descomponer un elemento de prioridad alta en tareas con la precisin suficiente paraser hecho en un sprint.

Los elementos de la pila del producto que pueden ser incorporados a un sprint se denominan preparadoso accionables y son los que pueden seleccionarse en la reunin de planificacin del sprint.

Preparacin de la pila del productoSe denomina preparacin (grooming) de la pila del producto a las actividades de priorizacin, detalle yestimacin de los elementos que la componen. Es un proceso que realizan de forma puntual, en cualquiermomento, continua y colaborativa el propietario del producto y el equipo de desarrollo. No debe consumirms del 10% de la capacidad de trabajo del equipo.

La responsabilidad de estimar el esfuerzo previsible para cada elemento, es de las personas del equipo queprevisiblemente harn el trabajo.

Formato de la pila del productoScrum 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 para cadaelemento:

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 ser aconsejablesotros 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 formatos rgidos. Los resultados de scrum no dependen de las formas, sino de lainstitucionalizacin de sus principios y la implementacin adecuada a las caractersticas de la empresa y delproyecto. 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 AltaEl operador define el flujo y textos

de un expediente60 AR

5 Alta xxx 999 CC

Ilustracin 5: Ejemplo de pila de producto


28/98

Scrum tcnico

28

Pila del SprintLa pila del sprint (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 operativadel 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 se prev que falta para terminarla.La pila del sprint descompone el trabajo en unidades de tamao adecuado para monitorizar el avance adiario, 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 la puede modificar durante el sprint. Las tareas demasiado grandes deben descomponerse en otras ms pquelas. Se deben considerar

grandes .las tareas que necesitan ms de un da para realizarse.

Es visible para todo el equipo. Idealmente en un tablero o pared en el mismo espacio fsico dondetrabaja el equipo.

Formato y soporteSon soportes habituales:

Tablero fsico o pared. Hoja de clculo. Herramienta colaborativa o de gestin de proyectos.

Y sobre el ms adecuado a las caractersticas del proyecto, oficina y equipo, lo apropiado es disear elformato ms cmodo para todos, teniendo en cuenta los siguientes criterios:

Incluir la siguiente informacin: Pila del sprint, persona responsable de cada tarea, estado en el que

se encuentra y tiempo de trabajo que queda para completarla. Incluir slo la informacin estrictamente necesaria. Debe servir de medio 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


29/98

Scrum tcnico


Durante el sprint, el equipo actualiza a diario en ella los tiempos pendientes de cada tarea. Al mismo tiempo,con estos datos traza el grfico de avance o trabajo consumido (burn-down), que se describe ms adelante,en el captulo de mtricas giles.

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

No se deben considerar como Incremento a prototipos, mdulos o sub-mdulos, ni partes pendientes depruebas o integracin.

Idealmente en scrum:

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

Se produce un incremento en cada iteracin.

Sin embargo es una excepcin frecuente el primer sprint. En el que objetivos del tipo contrastar laplataforma y el diseo pueden resultar necesarios, e implican trabajos de diseo o desarrollo de prototipospara 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 estarrealizados para considerar que el incremento est hecho.

EventosReunin de Planif icacin del sp rint: reunin de trabajo previa al inicio de cada sprint en la que sedetermina cul va a ser el objetivo del sprint y las tareas necesarias para conseguirlo.

Scrum diar io: breve reunin diaria del equipo, en la que cada miembro responde a tres cuestiones:

1.- El trabajo realizado el da anterior.

2.- El que tiene previsto realizar.

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

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

Revis in d el spr int: anlisis e inspeccin del incremento generado, y adaptacin de la pila del producto siresulta necesario.

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

Retrospect iva del sp r int: revisin de lo sucedido durante el Sprint. Reunin en la que el equipo analizaaspectos operativos de la forma de trabajo y crea un plan de mejoras para aplicar en el prximo sprint.

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


30/98

Scrum tcnico

30

Planificacin del sprintDescripcinEn esta reunin se toman como base las prioridades y necesidades de negocio del cliente, y se determinancules y cmo van a ser las funcionalidades que se incorporarn al producto en el siguiente sprint.

Se trata de una reunin conducida por el responsable del funcionamiento del marco scrum (Scrum Masteren scrum tcnico, o un miembro del equipo, en scrum pragmtico) a la que deben asistir el propietario delproducto y el equipo completo, y a la que tambin pueden asistir otros implicados en el proyecto.

La reunin puede durar una jornada de trabajo completa, cuando se trata de planificar un sprint largo (de unmes de duracin) o un tiempo proporcional para planificar un sprint ms breve.

Esta reunin debe dar respuesta a dos cuestiones:

Qu se entregar al terminar el sprint. Cul es el trabajo necesario para realizar el incremento previsto, y cmo lo llevar a cabo el equipo.

La reunin se articula en dos partes de igual duracin, para dar respuesta a una de estas cuestiones, encada una.

Precondiciones La organizacin tiene determinados los recursos disponibles para llevar a cabo el sprint. Ya estn preparados los elementos prioritarios de la pila del producto, de forma que ya tienen un

nivel de detalle suficiente y una estimacin previa del trabajo que requieren. 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 delnegocio que expone el propietario del producto.

Entradas La pila del producto. El producto desarrollado hasta la fecha en los incrementos anteriores (excepto si se trata del primer

sprint). Dato de la velocidad o rendimiento del equipo en el ltimo sprint, que se emplea como criterio paraestimar la cantidad de trabajo que es razonable suponer para el prximo 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 reuninEsta reunin marca el inicio de cada sprint.

Duracin mxima: un da.

Asistentes: Propietario del producto, equipo de desarrollo y 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: Qu se entregar al terminar el sprint.El propietario del producto presenta la pila de producto, exponiendo los requisitos de mayor prioridad quenecesita y que prev que se podrn desarrollar en el siguiente sprint. Si la pila del producto ha tenidocambios 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 suficiente para comprenderel trabajo del sprint.


31/98

Scrum tcnico


Propietario del producto:

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

La presentacin se hace con un nivel de detalle suficiente para transmitir al equipo toda lainformacin 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.

Esta reunin es un punto caliente de scrum para favorecer la fertilizacin cruzada de ideas en equipo yaadir valor a la visin del producto.

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

Exceptuando sprints dedicados exclusivamente a refactorizacin o a colecciones de tareas desordenadas(que deberan ser los menos), la elaboracin de este lema de forma conjunta en la reunin es una garantade 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: Cmo se conseguir hacer el incremento.El equipo desglosa cada funcionalidad en tareas, y estima el tiempo para cada una de ellas, componiendoas las tareas que forman la pila del sprint. En este desglose, el equipo tiene en cuenta los elementos dediseo y arquitectura que deber incorporar el sistema.

Los miembros del equipo establecen cules van a ser las tareas para los primeros das del sprint, y se lasautoasignan tomando como criterios sus conocimientos, intereses y una distribucin homognea del trabajo.

Esta segunda parte debe considerarse como una reunin del equipo, en la que deben estar todos susmiembros, y ser ellos quienes descompongan estimen y asignen 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 Scrum MasterEl Scrum Master, o el 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 preparada por el propietario delproducto.

3.- Ayudar a mantener el dilogo entre el propietario del producto y el equipo.

4.- Asegurar que se llegue a un acuerdo entre el propietario del producto y el equipo respecto de lo queincluir 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 haconsiderado 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. 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 trabajo del sprint.


32/98

Scrum tcnico

32

Ejemplo de tablero operativo para la reuninEs recomendable, que el propietario del producto emplee una hoja de clculo o alguna herramienta similarpara guardar en formato digital la pila del producto. Aunque no es aconsejable usarla como base paratrabajar sobre ella en la reunin.

En la reunin es preferible usar una pizarra o un tablero y fichas o etiquetas removibles.

El tablero facilita la comunicacin y el trabajo de la reunin.

Ilustracin 7: Ejemplo de pizarra de trabajo

Algunos soportes habituales:

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

Con cinta adhesiva removible se marcan lneas para delimitar:

Un rea superior donde el equipo anota:o (A) las unidades de trabajo que segn la velocidad media del equipo se podran realizar en

sprints de 2, 3, 4 y 5 semanas.

o (D) Duracin que finalmente tendr el sprint, as como el objetivo establecido, duracin,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.

Scrum diarioDescripcinReunin diaria breve, de no ms de 15 minutos, en la que el equipo sincroniza el trabajo y establece el planpara las 24 horas siguientes.

Entradas Pila del sprint y grfico de avance (burn-down) actualizados con la informacin de la reunin anterior. Informacin del avance de cada miembro del equipo.

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

Formato de la reuninSe recomienda realizarla de pie junto a un tablero con la pila del sprint y el grfico de avance del sprint, paraque todos puedan compartir la informacin y anotar.

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


33/98

Scrum tcnico


En esta reunin cada miembro del equipo de desarrollo explica:

Lo que ha logrado desde el anterior scrum diario. Lo que va ha hacer hasta el prximo scrum diario. Si estn teniendo algn problema, o si prev que puede encontrar algn impedimento.

Y actualiza sobre la pila del sprint el esfurezo que estima pendiente en las tareas que tiene asignadas, omarca 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 realiza las gestiones adecuadas para resolver las necesidades o impedimentos

identificados.

El equipo es el responsable de esta reunin, no el Scrum Master; y no se trata de una reunin deinspeccin o control sino de comunicacin entre el equipo para compartir el estado del trabajo, chequearel ritmo de avance y colaborar en posibles dificultades o impedimentos.

Revisin del sprintDescripcinReunin realizada al final del sprint para comprobar el incremento. .

No debe durar ms de 4 horas, en el caso de revisar sprints largos. Para sprints de una o dos semanas, conuna o dos horas de duracin debera ser suficiente.

Objetivos:

El propietario del producto comprueba el progreso del sistema. Esta reunin marca, a intervalosregulares, el ritmo de construccin, y la trayectoria que va tomando la visin del producto.

El propietario del producto identifica las funcionalidades que se pueden considerar hechas y las que

no. Al ver y probar el incremento, el propietario del producto, y el equipo en general obtienen feedback

relevante para revisar la pila del producto. Otros ingenieros y programadores de la empresa tambin pueden asistir para conocer cmo trabaja

la tecnologa empleada.

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. Convocatoria de la reunin del siguiente sprint.

Formato de la reuninEs una reunin informal. El objetivo es ver el incremento realizado. Estn prohibidas las presentacionesgrficas 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).


34/98

Scrum tcnico

34

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

Es una reunin informativa. Su misin no es la toma de decisiones ni la crtica del incremento . Con lainformacin obtenida, posteriormente el propietario del producto tratarn las posibles modificaciones sobrela visin del producto.

Protocolo recomendado:

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

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

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

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

Retrospectiva

Reunin que se realiza tras la revisin de cada sprint, y antes de la reunin de planificacin del siguiente,con una duracin recomendada de una a tres horas, segn la duracin del sprint terminado.

En ella el equipo realiza autoanlisis de su sobre su forma de trabajar, e identifica fortalezas y puntosdbiles. El objetivo es consolidar y afianzar las primeras, y planificar acciones de mejora sobre lossegundos.

El hecho de que se realice normalmente al final de cada sprint lleva a veces a considerarlas errneamentecomo reuniones de revisin de sprint, cuando es aconsejable tratarlas por separado, porque sus objetivosson diferentes.

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

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

RolesTodas las personas que intervienen, o tienen relacin directa o indirecta con el proyecto, se clasifican endos grupos: comprometidos e implicados. En crculos de scrum es frecuente llamar a los primeros (sinninguna 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 entrecompromiso e implicacin en elproyecto:

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

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

La gallina respondi: huevos con jamn.

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


35/98

Scrum tcnico


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 losclientes, usuarios y resto de implicados.

Equipo d e desarro l lo: 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 deconsiderar si es un rol comprometido o implicado. Partiendo de que la divisin entre personascomprometidas y personas implicadas es ms conceptual que relevante, pero cuando se trabaja coneste rol presente, su responsabilidad es el funcionamiento de un scrum tcnico en la organizacin.

Su responsabilidad directa, su misin, es por tanto la forma de trabajo, siendo por tanto el productoelaborado en los proyectos un objetivo de segundo nivel, o indirecto.

Por esta razn en el cuadro anterior no se considera el rol de Scrum Master, aunque que en cualquiercaso no es una cuestin especialmente relevante. Si hubiera que forzar una respuesta, desde el criteriode que no est comprometido en el proyecto (sino en la mejora de la forma de trabajo) se deberaconsiderar como un rol "implicado"

Propietario del productoEl propietario del producto (product owner)es quien toma las decisiones del cliente. Su responsabilidad esel valor del producto.

Para simplificar la comunicacin y toma de decisiones es necesario que este rol recaiga en una nicapersona.

Si el cliente es una organizacin grande, o con varios departamentos, puede adoptar la forma decomunicacin interna que consideren oportuna, pero en el equipo de desarrollo slo se integra una personaen representacin del cliente, y sta debe tener el conocimiento suficiente del producto y las atribucionesnecesarias 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 lossucesivos incrementos: qu se pone y qu se quita de la pila del producto, y cul es la prioridad delas funcionalidades.

Conoce el plan del producto, sus posibilidades y plan de inversin, as como del retorno esperado a la

inversin realizada, y se responsabiliza sobre fechas y funcionalidades de las diferentes versiones delmismo.

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

Segn las circunstancias del proyecto es posible incluso que delegue en el equipo de desarrollo, o enalguien de su confianza, pero la responsabilidad siempre es suya.

Para ejercer este rol es necesario:

Conocer per fectamente el entorno d e negocio del cl iente, las necesidades y el objetivo que sepersigue con el sistema que se est construyendo.

Tener la vis in del producto, as como las necesidades concretas del proyecto, para poder priorizar

eficientemente el trabajo.


36/98

Scrum tcnico

36

Disponer de atr ibuciones y conocimiento del plan del producto suf ic iente para tomar lasdecisiones necesarias durante el proyecto, incluidas para cubrir las expectativas previstas de retornode la Inversin del proyecto.

Recibir y analizar de forma continua ret ro inform acin del entorno de negocio (evolucin delmercado, 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.

La organizacin debe respetar sus decisiones y no modificar prioridades ni elementos de la pila delproducto.

Equipo de desarrolloLo forman el grupo de profesionales que realizan el incremento de cada sprint.

Se recomienda que un equipo scrum tenga entre 4 y 8 personas. Ms all de 8 resulta ms difcil mantenerla comunicacin directa, y se manifiestan con ms intensidad los roces habituales de la dinmica de grupos(que comienzan a aparecer a partir de 6 personas). En el cmputo del nmero de miembros del equipo dedesarrollono se consideran ni el Scrum Master ni el propietario del producto.

No se trata de un grupo de trabajo formado por un arquitecto, diseador o analista, programadores y testers.Es un equipo mult i funcional, en el que todos los miembros trabajan de forma solidaria con responsabilidadcompartida. Es posible que algunos miembros sean especialistas en reas concretas, pero laresponsabilidad es el incremento de cada sprint y recae sobre el equipo de desarrollo en conjunto.

Las principales responsabilidades, ms all de la autoorganizacin y uso de tecnologas giles, son las quese 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 unoresponde por su trabajo.

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

Un equipo scrum responde en su conjunto. Trabaja de forma cohesionada y autoorganizada. No hay ungestor para delimitar, asignar y coordinar las tareas. Son los propios miembros 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 MasterEs el responsable del cumplimiento de las reglas de un marco de scrum tcnico, asegurando que seentienden en la organizacin, y se trabaja conforme a ellas.

Propociona la asesora y formacin necesaria al propietario del producto y al equipo.

Realiza su trabajo con un modelo de liderazgo servil: al servicio y en ayuda del equipo y del propietario delproducto.

Proporciona:


37/98

Scrum tcnico


Asesora y formacin al equipo para trabajar de forma autoorganizada y con responsabilidad deequipo.

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.Al crecer la fluidez de la organizacin y evolucionar hacia un marco de scrum ms pragmtico, puedeeliminarse el rol de Scrum Master, cuando estas responsabilidades ya estn institucionalizadas en laorganizacin.

Cultura y ValoresScrum tcnico define un marco que ayuda a organizar a las personas y el flujo de trabajo. Es la carrocerao el interfaz visible, pero el motor de la agilidad son los valores giles.

Las reglas de un equipo scrum pueden ser las de este marco tcnico u otras. La agilidad no la proporciona

el cumplimiento de prcticas, sino de valores. Delegacin de atr ibucion es(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. Responsabi l idad y autodiscip l ina(no disciplina impuesta). Trabajo centrado en el valor para el cl ientey el desarrollo de lo comprometido. Informacin, t ransparenciay visibilidad del desarrollo del proyecto.


38/98


39/98

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

Medicin y estimacin gil


40/98


40

Por qu medir?La informacin es la materia prima para la toma de decisiones, y la que puede ser cuantificada proporcionacriterios objetivos de gestin y seguimiento.

Desde el nivel concreto de la programacin, hasta los ms generales de la gestin global de la

organizacin, tres son los fondos de escala o niveles 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 elsegundo, el porcentaje del plan del proyecto realizado, y en el tercero, tambin por ejemplo, el nivel desatisfaccin laboral.

Ilustracin 9: mbitos de medicin

Este texto cubre la medicin gil en el mbito proyecto, aunque las consideraciones generales de estaintroduccin son 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 quese aplicar.

No se deben implantar procesos de medicin simplemente por que s.

Tomar una lista ms o menos prestigiosa de mtricas, e incorporarla a los procedimientos de la empresapuede seducir, al ofrecer un marco de trabajo monitorizado con indicadores y mediciones, pero no dicemucho a favor de las razones por las que se han adoptado.

Medir no es un fin en s mismo

Medir es costoso


41/98



Criterios para el diseo y aplicacin de mtricas

Cuantas menos, mejor Medir es costoso.

Medir aade burocracia. El objetivo de un equipo scrum es ofrecer la mejor relacin valor / simplicidad.

Aspectos que deben cuestionarse antes de monitorizar y medir un indicador:

Por qu? Qu valor proporciona esta medicin? Qu valor se pierde si se omite?

El objetivo de scrum es producir el mayor valor posible de forma continua, y la cuestin clave para laincorporacin de indicadores en la gestin de proyectos es:

Cmo con tr ibuye el uso del ind icad o r en el val o r que el proyec to p ropo rc iona al c l ien te?

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. Si despus de analizarlo no le convence, si prefiere no incorporar un indicador, o cambiarlo:usted es el gestor.

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

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 aumentar la productividad, ha vinculado los resultados de esta mtrica a la retribucin pordesempeo de los programadores, de forma que ha logrado producir ms lneas de cdigo sin incrementarla plantilla.

Para evitar que se trate de un incremento hueco de lneas de cdigo, o aumente el nmero de errores porprogramar ms deprisa, se ha dotado de mayor rigor al sistema de mtrica, incorporando al poco tiempootras mtricas para complementar y mejorar el sistema de calidad:

Test Defects/KLOC, Compile Defects/KLOC y Total Defects/KLOC, para controlar que no crezca el nmerode errores deslizados en el cdigo.

Tambin se han incorporado indicadores appraisal time para medir tiempo y costes del diseo y laejecucin de las revisiones de cdigo.

Y por temor a que el sistema de medicin pueda resultar excesivamente costoso se incluyen indicadores decoste de calidad (COQ) que miden los tiempos de revisin y los contrastan con las mejoras en los tiemposeliminados 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 queen al desarrollo de nuevos sistemas.

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

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


42/98


42

Qu queremos conocer: la cantidad de lneas, o el valor entregado 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 cdigoNo estaremos muchas veces midiendo esto, simplemente porque es cuantificable?

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

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


43/98

Medicin: las unidades


Velocidad, trabajo y tiempoVelocidad, trabajo y tiempo son las tres magnitudes que componen la frmula de la velocidad, en gestin deproyectos gil, definndola como la 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 semanao de 80 puntos por sprint.

TiempoPara mantener un ritmo de avance continuo, el desarrollo gil emplea dos tcticas posibles: incrementoiterativo, o incremento continuo.

Ilustracin 10: Agilidad con incremento iterativo o continuo

El avance a travs de incrementos iterativos mantiene el ritmo apoyndose en pulsos de sprints . Poresta razn emplea normalmente el sprint como unidad de tiempo, y expresa la velocidad como trabajo otareas realizadas en un sprint.

Nota: scrum tcnico usa incremento iterativo, y por tanto define la velocidad como la cantidad de trabajorealizado en un sprint.

El avance a travs de un incremento continuo mantiene un flujo de avance constantesin puntosmuertos ni cuellos de botella. No hay sprints, y por tanto las unidades de tiempo son das, semanas omeses, de forma que la la velocidad se expresa en puntos (cantidad de trabajo) por semana, da, o mes


44/98


44

Tiempo real y tiempo idealUna observacin importante: la diferencia entre tiemporeal y tiempo ideal.

Tiempo real, es el tiempo de trabajo. Equivale a lajornada laboral.

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

4 * 8 * 5 = 160 horas

Ilustracin 11: Tiempo ideal y tiempo real

Tiempo ideal se refiere sin embargo al tiempo de trabajo en condiciones ideales, esto es, eliminando todo loque no es estrictamente trabajo, suponiendo que no hay ninguna pausa por interrupcin o atencin decuestiones ajenas a la tarea y que la persona se encuentra en buenas condiciones de concentracin ydisponibilidad.

El tiempo ideal se emplea normalmente en estimaciones, como unidad de trabajo o esfuerzo necesario. Ej:Esa tarea tiene un tamao de 3 horas ideales.

Es un concepto similar al que PSP1 denomina Delta Time como la parte del tiempo laboral que esrealmente tiempo efectivo de trabajo.

TrabajoMedir el trabajo puede ser necesario por dos razones: para registrar el ya hecho, o para estimaranticipadamente, el que se debe realizar.

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

Trabajo ya realizadoMedir 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 defuncin, horas trabajadas, etc.

La gestin de p royecto s gil no mid e el esfuerzo realizado para calcular el avanc e del trabajo.

Es posible que otros procesos de la organizacin necesiten registrar el esfuerzo invertido, y por lo tanto seanecesario su registro, pero no debe emplearse para calcular el avance del proyecto.

Trabajo pendiente de realizarScrum mide el trabajo pendiente para:

1Personal Software Process

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

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


45/98



Estimar esfuerzo y tiempo previsto para realizar un trabajo (tareas, historias de usuario o epics). Determinar el grado de avance del proyecto, y en especial en cada sprint.

Determinar con precisin, de forma cuantitativa y objetiva el trabajo que necesitar la construccin de unrequisito, es un empeo cuestionable.

Ilustracin 12: Medicin del trabajo pendiente

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

Y si no resulta posible estimar con precisin la cantidad de trabajo que hay en un requisito, tampoco sepuede saber cunto tiempo necesitar, porque adems de la incertidumbre del trabajo, se suman lasinherentes al tiempo:

No es realista hablar de la cantidad o de la calidad del trabajo que realiza una persona por unidad detiempo, porque son muy grandes las diferencias de unas personas a otras.

Una misma tarea, realizada por una misma personar requerir diferentes tiempos en o situacionesdistintas.

Sobre estas premisas:

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

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 del trabajo estimado.

La estr ategia empleada por l a gest in gil es : Trabajar con estimaciones aproximadas. Estimar con la tcnica juicio de expertos. Descomponer las tareas en subtareas ms pequeas, si las estimaciones superan rangos de medio,

o un da de tiempo real.


46/98


46

Unidades de trabajoUn trabajo puede dimensionarse midiendo el producto que se construye, como los tradicionales puntos defuncin de COCOMO; o el tiempo que cuesta realizarlo.

Ilustracin 13: Velocidad

En gestin gil se suelen emplear puntos como unidad de trabajo, empleando denominaciones comopuntos de historia o simplemente puntos puntos.

La unidad Story Point de eXtreme Programming se define como la cantidad de trabajo que se realiza en unda ideal.

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

Puede definir su punto

Como tamao relativo de tareas conocidas que normalmente emplea.

Ej: El equipo de un sistema de venta por internet, podra determinar que un punto representara eltamao que tiene un listado de las facturas de un usuario.

En base al tiempo ideal necesario para realizar el trabajo.

Ej: Un equipo puede determinar que un punto es el trabajo realizado en 4 horas ideales.

Es importante que la mtrica empleada, su significado y la forma de aplicacin sea consistente en todas lasmediciones de la organizacin, y conocida por todas las personas:

Que se trate de un procedimiento de trabajo inst i tucional izado.

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

Velocidad en scrum tcnico 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 en implantaciones de scrum pragmtico, que pueden realizar sprints de diferentes duraciones, ono siempre con el mismo nmero de miembros en el equipo, la velocidad se expresa indicando la unidad detiempo y en su caso tambin si se refiere a la total del equipo, o a la media por persona. As por ejemplo:La velocidad media del equipo es de 100 puntos por semana. La veloc idad media de una persona delequipo es de 5 puntos por da.


47/98

Medicin: usos y herramientas

Grfico de producto.El grfico de producto o grfico burn upes una herramienta de planificacin del propietario del producto,

que muestra 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 esfuerzoestimado para construir las diferentes historias de la pila del producto, y en el de las abscisas el tiempo,medido en sprints o en tiempo real.

Ilustracin 14: Grfico de producto

Ejemplo

Convenciones empleadas por el equipo:

Unidad para estimar el 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


48/98


48

Se traza en el grfico la lnea que representa el ritmo de avance previsto, segn la velocidad media delequipo (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. Sedibujan basndose en la velocidad obtenida en los sprints anteriores que han ido peor y mejor de loprevisto, 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:


49/98



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 cuatroprimeras historias, que tienen un esfuerzo estimado en 950 puntos (150+250+250+300).

Adems tiene tambin esbozadas las previsiones para versiones posteriores: 1.1 y 1.2 tal y como muestrala 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 esfuerzocalculado 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 yoptimista) proyectan en el eje horizontal la fecha o sprint en el que se espera completar la versin.


50/98


50

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 herramienta proyecta la previsin de la pila del producto, que es un documento vivo cuya evolucinprev la del producto.

Como herramienta gil no debe considerarse como la representacin de un plan estable, sino como laprevisin de la pila del producto.

Grfico de avance: monitorizacin del sprintTambin se suele llamar a este grfico con su nombre ingls: burn-down.

Lo actualiza el equipo en el scrum diario, para comprobar el ritmo de avance, y detectar desde el primermomento si es el previsto, o por el contrario se puede ver comprometida o adelantada la entrega prevista alfinal de sprint.

La estrategia gil para el seguimiento del proyecto se basa en:

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

Y este grfico trabaja con ambos principios:

Registra en el eje Y el trabajo pendiente. Se actualiza a diario.


51/98



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 una figura elesfuerzo pendiente.

Esto es: el primer da, en la pila de tareas figura para cada tarea el esfuerzo que se ha estimado, puestoque 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 vadesarrollando, hasta que se terminan y van queda 0 como tiempo pendiente.

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

Ilustracin 24: Pila del sprint

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


52/98


52

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 formacontinua y gradual hasta completarlo el da que termina el 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 deavance ms normal.

Ilustracin 27: Grfica de avance real

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


53/98



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 estnrequiriendo 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 pquerEs una prctica gil, para conducir las reuniones en las que se estima el esfuerzo y la duracin de tareas.

James Grenning ide este juego de planificacin para evitar discusiones dilatadas que no terminan de darconclusiones concretas.

El modelo inicial de Grenning consta de 8 cartas, con los nmeros representados en siguiente figura,

Ilustracin 30: Cartas para planificacin de pquer

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


54/98


54

Cuando se considera que ste es mayor de x horas ideales (el tamao mximo considerado por el equipo

para una historia), se levanta la carta

.

Las tareas que exceden el tamao mximo deben descomponerse en subtareas de menor tamao.

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

Variante: sucesin de FibonacciBasado en el hecho de que al aumentar el tamao de las tareas, aumenta tambin la incertidumbre y elmargen de error, se ha desarrollado esta variante que consiste en emplear slo nmeros de la sucesin deFibonacci, de forma que:

El juego de cartas est compuesto por nmeros en 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.

As, si por ejemplo una persona cree que el tamao adecuado de una tarea es 6, se ve obligado areconsiderar y, o bien aceptar que el tamao puede ser 5, o bien aceptar una estimacin ms conservadoray levantar el 8.

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

Ilustracin 31: Cartas para estimacin de pquer (Fibonacci)

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

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

Operativa 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 posiblespreguntas 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, quien asume la responsabilidad de gestionar la reunin,

con su criterio de gestin, y basndose en las caractersticas del proyecto, equipo, reunin, n deelementos pendientes de evaluar, puede optar por:

o Preguntar a las personas de las estimaciones extremas: Por qu crees que es necesariotanto tiempo?, y por qu crees que es necesario tan poco tiempo? Tras escuchar las

razones, repetir la estimacin.o Dejar a un lado la estimacin de esa tarea y retomar al final o en otro momento aquellas

que hayan quedado pendientes.


55/98



o Pedir al cliente o propietario del producto que descomponga la funcionalidad y valorar cadauna de las funcionalidades resultantes.

o Tomar la estimacin menor, mayor, o la media.

Este protocolo de moderacin, evita en la reunin los atascos de anlisis circulares en ping-pong entrediversas opciones de implementacin, hace participar a todos los asistentes, reduce el cuarto de hora o lamedia hora de tiempo de estimacin de una funcionalidad, a escasos minutos, consigue alcanzar consensos

sin discusiones, y adems resulta divertido y dinamiza la reunin.


56/98


57/98


SEGUNDA PARTE

Scrum en su concepcin original.


58/98

Scrum pragmtico

58

1.- Conocimiento en continua evolucinLos marcos de prcticas giles no llegan a los proyectos TIC como tesis de conocimiento, sino comoanttesis al que la Ingeniera del Software vena desarrollando.

Comenzaremos viendo qu significa esto, y as tomar la distancia necesaria para ver con perspectiva lasrazones por las que los proyectos TIC abrazaron la agilidad a finales del siglo pasado, y sus diferencias con

la ingeniera de procesos; no desde las prcticas concretas, sino desde los principios en los que se basan, ycon ello comprender las fortalezas y debilidades de la agilidad.

Alcanzar una visin de las razones y los principios de cada metodologa, ms all de la concrecin de unmodelo es clave para dar el salto de gestin tcnica a gestin experta. Esto es, de gestin basada en laaplicacin de prcticas a gestin basada en la aplicacin del propio conocimiento.

El patrn dialcticoAl cuestionar el conocimiento, se inicia su evolucin que sigue un patrn dialctico de: tesis, anttesis ysntesis.

De manera esquemtica el patrn dialctico puede definirse como el ritmo de avance que contrapone unaan ttes is a una concepcin previa, entendida como tesis. La anttesis muestra los problemas ycontradicciones de la tesis, y de la confrontacin surge un tercer momento llamado sntes is, una resolucino una nueva comprensin del problema.

Ilustracin 32: Patrn dialctico

De esta forma la estrategia de abordar con ingeniera de procesos los retos de los proyectos de software,supuso la primera tesis para dar respuesta a la crisis del software, y sus problemas y contradicciones hansido puestos de manifiesto por su anttesis: la agilidad.

En 1968, en la primera conferencia sobre desarrollo de software celebrada por la organizacin OTAN, seanalizaron los problemas de la programacin del software, y en ella se acu el trmino crisis del softwarepara referirse a ellos.

La conclusin de la conferencia (Bauer, Bolliet, & Helms, 1969) fue la necesidad de crear una disciplinacientfica que, como ocurra en otras reas, permitiera aplicar un enfoque sistemtico disciplinado ycuantificable al desarrollo, operacin y mantenimiento de los sistemas del software, es decir, la aplicacinde la ingeniera de procesos al software. Fue el nacimiento de la Ingeniera del Software.

La primera estrategia de la Ingeniera del software (tesis) se ha basado en dos pilares:

Ingeniera de procesos: Gestin predictiva:

El primero para aplicar el principio bsico de calidad contrastado con xito en los entornos de produccinindustrial: la calidad del resultado depende de la c

Date post:	28-Feb-2018
Category:	Documents
Upload:	jaclyn-hidalgo-lamadrid
View:	221 times
Download:	0 times

Manual de SCRUM

Documents