Este documento presenta una introducción a las metodologías ágiles y a SCRUM. Explica los principios del Manifiesto Ágil y describe los roles, artefactos y reuniones clave de SCRUM, incluyendo Sprints, Backlogs y reuniones diarias. El objetivo es proveer una guía básica sobre este enfoque ágil para el desarrollo de proyectos.
How to use Redis with MuleSoft. A quick start presentation.
Agile Software development
1. ESCUELA DE INGENIERÍA INFORMÁTICAUniversidad de Oviedo
DIRECCION Y GESTIÓN
DE PROYECTOS WEB
00. Metodologías Ágiles
Máster y Doctorado
en Ingeniería Web
Curso 2010-2011
6. Manifiesto Ágil
1. Valorar a los
individuos y su
interacción, …
2. Valorar el software
que funciona,…
3. Valorar la
colaboración con el
cliente, …
4. Valorar la respuesta
al cambio, …
…sobre los procesos y
las herramientas.
…sobre la
documentación
exhaustiva.
sobre la negociación
contractual.
…sobre el seguimiento
de un plan.
13. Características
Proceso iterativo e incremental
Mitigación del riesgo (mediante iteraciones
fijas)
Mejora continua
Calidad desde el primer día
Priorización de requerimientos (según
valor)
Equipos dedicados y auto-gestionados
Colaboración continua con el cliente
Incorporar el cambio
Prácticas de desarrollo modernas
21. Origen
En 1986 Hirotaka Takeuchi e Ikujiro Nonaka describieron una nueva aproximación holística
que incrementa la rapidez y la flexibilidad en el desarrollo de nuevos productos
comerciales.1 Takeuchi y Nonaka comparan esta nueva aproximación holística, en la cual las
fases se traslapan de manera intensa y el proceso completo es realizado por
un equipo con funciones transversales, como en el rugby, donde el
equipo entero «actúa como un solo hombre para intentar llegar
al otro lado del campo, pasando el balón de uno a otro». Los casos
de estudio provienen de las industrias automovilísticas, así como de fabricación de máquinas
fotográficas, computadoras e impresoras.
En 1991 Peter DeGrace y Leslie Stahl en su libro Wicked Problems, Righteous
Solutions (A problemas malvados, soluciones virtuosas),2 se refirieron a esta aproximación
como scrum (melé en inglés), un término propio del rugby mencionado en el artículo por
Takeuchi y Nonaka.
A principios de los años 1990 Ken Schwaber empleó una aproximación que lo llevó a poner en
práctica el scrum en su compañía, Advanced Development Methods. Por aquel
tiempo Jeff Sutherland desarrolló una aproximación similar en Easel Corporation y fue el
primero en denominarla scrum.3 En 1995 Sutherland y Schwaber, durante el OOPSLA '95
desarrollado en Austin, presentaron en paralelo una serie de artículos describiendo scrum,
siendo ésta la primera aparición pública de la metodología. Durante los años siguientes,
Schwaber y Sutherland, colaboraron para consolidar los artículos antes mencionados, así
como sus experiencias y el conjunto de mejores prácticas de la industria que conforman a lo
que ahora se le conoce como scrum. En 2001, Schwaber y Mike Beedle describieron la
metodología en el libro Agile Software Development with Scrum.
22. Roles (I)
El Pollo mira al cerdo y le dice "Hey, por qué
no abrímos juntos un restaurante?". El cerdo
mira al pollo y dice: "Buena idea, ¿cómo
podría llamarse?". El pollo entonces piensa al
respecto y finalmente dice: "¿Por qué no lo
llamamos 'Jamón y Huevos'?". "Mmmmm,
no me parece justo. ", dice el cerdo, "Yo
estaría totalmente comprometido,
mientras que vos sólo estarías algo
involucrado"
23. Roles (II)
Los cerdos
Miembros del Equipo
Scrum Máster
Dueño de Producto
Los pollos
Stakeholders (clientes, vendedores, etc.)
Usuarios (quienes utilizarán el software)
Gerentes (los administradores de la org.)
Otras personas
Objetivo
•Involucrar a
usuarios, negocio
y stakeholders
Objetivo
•Involucrar a
usuarios, negocio
y stakeholders
24. Roles:
Dueño del Producto
La voz del cliente
Responsabilidades
Retorno de inversión (ROI)
Fijar características, fechas y
contenidos
Ofrecer visión única de los “pollos”
Priorizar las características
Aceptar o rechazar el resultado del
trabajo
25. Roles:
Scrum Master
El padre, el facilitador de Scrum
Responsabilidades
Asegurar las reglas
Mejorar vida y productividad de los
miembros
Asegurar la cooperación de todos los roles
Proteger al equipo de interferencias
externas
Invitar a personas a las reuniones
Seguir la lista de impedimentos
Asesorar al cliente cómo maximizar su ROI
26. Roles:
Miembros del Equipo
Los creadores
Grupo de Trabajo vs. Equipo
Perfiles (analistas, diseñadores, …)
Responsabilidades
Colaborar
Seleccionar el objetivo de la iteración
Hacer todo lo necesario para tener éxito
Se organiza a si mismo y a su trabajo
Demos. ante dueño producto y
stakeholders.
28. Sprints (I)
Iteración acotada en el tiempo [2s-
4s]
Meta del Sprint
…Sprint de Release…
Calidad
[1] ó [4, )[1] ó [4, )
semanassemanas
[3,4] semanas[3,4] semanas
2 semanas2 semanas
32. Sprints (V)
Reglas:
El Equipo puede buscar ayuda externa.
Nadie del exterior debe proveer al
Equipo con directivas.
Nadie fuera del Equipo puede cambiar los
items del Backlog del Sprint.
El Scrum Master o el Dueño del Producto
pueden cancelar el Sprint.
33. Sprints (VI)
Reglas:
Ante adelantos/retrasos…
… el Equipo puede consultar al Dueño del
Producto qué items agregar/quitar. El Scrum
Master podría decidir cancelarlo.
Gestionar desvíos en las planificaciones.
Asistencia al Scrum diario y actualizar el
Backlog del Sprint (que puede crecer).
El Equipo tiene que adherir a los
estándares.
34. Backlog del Producto (I)
Artefacto más importante de Scrum
Lista priorizada de:
Requerimientos funcionales
Mejoras
Tecnología
Corrección de errores
Típicamente formado por historias de
usuario
Nunca se da por completo (a diferencia
de un documento de requisitos del
sistema)
35. Backlog del Producto (II)
Formato: hoja cálculo, pizarra, herramienta
colaborativa
Incluye: identificador, descripción, prioridad,
estimación
Opcional: observaciones, criterios validación
Gestionado por el Dueño del Producto
36. Backlog del Sprint (I)
Contiene tareas para convertir un
Backlog del Producto en funcionalidad.
Las tareas del Backlog del sprint están
respaldadas por un Backlog del Producto.
Las tareas se estiman en horas [1-16]
Las de más de 16 horas se descomponen
Los miembros del equipo eligen las
tareas
Sólo los miembros del Equipo pueden
alterar las tareas del backlog del sprint
Actualizar la estimación de trabajo
restante
37. Backlog del Sprint (II)
Formato: hoja cálculo, pizarra, herramienta
colaborativa
Incluye: lista tareas, responsables, estado,
tiempo restante
No incluye: información innecesaria
Es ágil y soporta el Scrum diario
39. La Velocidad
Factor de foco/dedicación
Mide cuan fiables son nuestras estimaciones
Tiene en cuenta los imprevistos (< 100%)
Inicialmente 70%
Sprint 2 y sucesivos: ffi = (ff(i-1) + ff(i-2))/2
Velocidad del equipo
4 desarrolladores
15 días ideales
Factor de foco = 0,7
15 * 4 *0,7= 42 puntos
Alternativas
•Estimación a OjO
•Tiempo que hizo ayer
Alternativas
•Estimación a OjO
•Tiempo que hizo ayer
40. Reuniones (I)
Reunión de Planificación
Exposición
Resolución
Scrum Diario
Demostración o Revisión del Sprint
Retrospectiva del Sprint
42. Reunión
Planificación(I)
Fase 1: Exposición (de historias)
Horario
Durante la mañana
Asistentes
Equipo + Scrum Master + Dueño del Producto
Outputs:
Priorización
Estimación
Hasta superar la Velocidad
≤ 20 puntos
Historias del Backlog del Sprint
•Lidera esta reunión
•Evita divagaciones
43. Reunión
Planificación(II)
Fase 1: Exposición (de historias)
Outputs:
Objetivo del
Sprint
Gestión de maestros
Scrum Diario De 9:30 a 9:45 en la Sala de
Reuniones
Duración del
Sprint
3 semanas
Revisión del
Sprint
22 de Junio de 2010 en la Sala
de Reuniones
Gráfico
Burndown
Avance ideal
44. Reunión
Planificación (III)
Fase 2: Resolución
Horario
Durante la tarde
Asistentes
Equipo + Scrum Master
Outputs
Tareas del Backlog del Sprint
Tarea < 4 días ideales
51. Scrum Diario (I)
Scrum Diario
Horario
Todos los días a las 10:00 h (a lo sumo 15’)
Asistentes
Equipo + Scrum Master
Objetivos
Repasar (rápidamente) la situación y el tiempo
restante para finalizar el sprint.
Identificación temprana de impedimentos, confianza y
motivación, mejora comunicaciones y productividad (presión
inconsciente!!!)
Sincronizar actividades
Outputs
Backlog del Sprint y Gráfico Burndown actualizados
Identificación de necesidades e impedimentos
•Lidera esta reunión
•Evita divagaciones
52. Scrum Diario (II)
Reglas
Todos los días en el mismo sitio y hora
Asisten todos los miembros
Puntualidad o multa (para cafés…)
Todos hablan en sentido agujas reloj (sin
interrupciones)
Se responde al grupo (NO al Scrum
Master):
¿Qué hiciste?¿Qué harás?¿Qué problemas has
tenido?
Pollos invitados pero NO participan
53. Revisión Sprint (I)
Revisión (demostración) del Sprint
Horario
La preparación no debe superar las 2h, sino algo
falla con el concepto de “Terminado”.
Duración [1h- 2h]
Asistentes
Equipo + Scrum Master + Dueño Producto
Opcionalmente otros interesados
Objetivos
Obvio… …demostrar funcionalidad!!!
Visualización temprana!!
¿Qué?
54. Revisión Sprint (II)
Revisión (demostración) del Sprint
Reglas
Demostración en vivo (sin transparencias,
papeles…). Se puede utilizar un PC de desarrollo
Primero se describe previsión (objetivo +
historias) y luego ejecución (¿OK?¿KO?¿Por
qué?)
Se debe demostrar conforme a pruebas de
aceptación
Debate y cambios (sólo el Dueño del Producto
puede aceptarlos)
56. Retrospectiva Sprint (II)
Retrospectiva del Sprint
Dinámica
Cada miembro expone su visión y rellena dos
primera columnas
Luego el grupo propone acciones correctoras
3 votos en papel x Miembro Scrum Master
recuenta y propone hacer foco en 2-3 de ellas
Bueno A Mejorar Acción
correctora
58. Técnicas:
Historias de Usuario (I)
El cliente entra en una pantalla donde se
le pregunta el código de identificación y
entonces se le muestra los datos de
Apellido y Domicilio del mismo
• El cliente visualiza su plan actual, y de
una lista ordenada por importe elige el
nuevo plan al cual desea acceder,
constando la misma de la descripción del
plan y del importe.
Se verifica si el cliente está en condiciones de
tomar este plan.
Se confirma la operación por parte del sistema
59. Técnicas:
Historias de Usuario (II)
• ¿Cómo sería la
identificación del cliente
(login)?
- Usuario y contraseña
• ¿El pedido de cambio de plan
se resuelve Online o no?
- Online
• ¿Se puede modificar un
pedido grabado?
- Sí
• ¿Se puede cancelar un
pedido?
- Sí
•Surgen nuevas historias•Surgen nuevas historias
60. Técnicas:
Historias de Usuario (III)
Nombre
Breve
Conciso
Importancia
≡ Prioridad
A es más importante
que B si A > B
Estimación
Inicialmente vacía
Se valora durante la
reunión de planificación
Validación
A efectos de aceptación
Nombre Historia
Importancia
Estimación
Validación
63. Técnicas:
Actualización Estimaciones
Gestión Maestros
100
4
Es posible crear, buscar, borrar
y actualizar maestros
Gestión Maestros
100
Julio
4
Es posible crear, buscar, borrar
y actualizar maestros
Gestión Maestros
100
4
Es posible crear, buscar, borrar
y actualizar maestros
X 2 Gestión Maestros
100
4
Es posible crear, buscar, borrar
y actualizar maestros
X 2X
64. Técnicas:
Control de impedimentos
Sistema
legado KO!
Sistema
legado KO!
I
Sistema
legado KO!
II
Servicio
Web Down!
Servicio
Web Down!
I
Gestionados por
Scrum Master
Gestionados por
Scrum Master
67. Sprint 0: Preparación (I)
Definición Backlog de Producto
Estimaciones imprecisas (en días)
No es problema, en las primeras iteraciones se verá si
el proyecto es o no viable
Presentación de los roles
Visión de Proyecto
Cualquier integrante conoce el propósito del proyecto
Definición de Terminado
Cumple requerimientos, funciona en desarrollo, diseño
completo, desarrollo TDD, Tests OK, probado IE6 y
Firefox, documentación, 0% CS, 0% PMD…
Definición inicial de entregables
68. Sprint 0: Preparación (II)
Reunión kick-off
Alcance
Revisión backlog
Enfoques técnicos
Acuerdos varios (horas de las reuniones…)
Logística
Ubicación (ej.: reserva de salas de
reuniones)
Material (equipos, red, pizarra, entorno
desarrollo…)
69. Sprint 1: Comienzo
Día 1
Velocidad inicial
Factor de foco (inicialmente 70%)
Reunión de Planificación del Sprint
Exposición + Resolución
Día 2
Los desarrolladores eligen tareas
Scrum diario
Día 15
Reunión de Revisión
Reunión de Retrospectiva
70. Sprint 2: + Velocidad
Día 1
Recalcular Factor de Foco
Reunión de Planificación del Sprint
Día 10: hemos terminado las tareas!!!
Se recupera del Backlog del Producto un
nuevo item…
Día 15
Reunión de Revisión
Reunión de Retrospectiva
71. Sprint 3: Impedimentos
Día 1
Aumenta el Factor de Foco
Reunión de Planificación de Sprint
Día 3
Surge un impedimento
Registro en la Lista de Impedimentos
Día 8
Surge un imprevisto (bajas)
Registro en la lista de imprevistos
Día 9
Se comunica al Dueño del Producto que se prevé retraso.
¡Lo intentaremos de todas formas!
Día 15
Reunión de Revisión
Reunión de Retrospectiva
74. 74
Contactos y Página web
http://www.ceb2b2000.com
j.arguello@b2b2000.com
info@ceb2b2000.com
Julio A. Argüello Fernández
Responsable de Arquitectura y Desarrollo
Grupo B2B 2000
75. 75
Bibliografía
Do It Yourself Agile Damon B. Poole. Septiembre
2009.
Scrum y XP desde las Trincheras Henrik Kniberg.
2007.
Agile Estimating and Planning, Prentice Hall, Mike
Cohn, 2005
Blogs
http://www.dosideas.com
http://blog.crisp.se/henrikkniberg
Webs
http://agilemanifesto.org/
http://www.navegapolis.net/
http://www.agile-spain.com/
http://www.proyectosagiles.org/
http://www.scrumalliance.org/
76. ESCUELA DE INGENIERÍA INFORMÁTICAUniversidad de Oviedo
DIRECCION Y GESTIÓN
DE PROYECTOS WEB
FIN
Hinweis der Redaktion
Valorar más a los individuos y su interacción que a los procesos y las herramientas
Este es posiblemente el principio más importante del manifiesto. Por supuesto que los procesos ayudan al trabajo. Son una guía de operación. Las herramientas mejoran la eficiencia, pero sin personas con conocimiento técnico y actitud adecuada, no producen resultados.
Las empresas suelen predicar muy alto que sus empleados son lo más importante, pero la realidad es que en los años 90 la teoría de producción basada en procesos, la re-ingeniería de procesos ha dado a éstos más relevancia de la que pueden tener en tareas que deben gran parte de su valor al conocimiento y al talento de las personas que las realizan.
Los procesos deben ser una ayuda y un soporte para guiar el trabajo. Deben adaptarse a la organización, a los equipos y a las personas; y no al revés. 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 innovación.
Acaso alguien hace los huevos estrellados como Lucio sólo con la receta??? (Se admite replica… )
Valorar más el software que funciona que la documentación exhaustiva
Poder ver anticipadamente como se comportan las funcionalidades que se esperan sobre prototipos o sobre partes ya elaboradas del sistema final ofrece un &quot;feedback&quot; muy estimulante y enriquecedor que genera ideas y posibilidades imposibles de concebir en un primer momento, y difícilmente se podrían incluir al redactar un documento de requisitos detallados antes de comenzar el proyecto.
El manifiesto no afirma que no hagan falta. Los documentos son soporte de documentación, permiten la transferencia del conocimiento, registran información histórica, 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 generación de valor que se logra con la comunicación directa entre las personas y a través de la interacción con los prototipos. Por eso, siempre que sea posible debe preferirse, y reducir al mínimo indispensable el uso de documentación, que genera trabajo que no aporta un valor directo al producto.
Si la organización y los equipos se comunican a través de documentos, además de perder la riqueza que da la interacción con el producto, se acaba derivando a emplear a los documentos como barricadas entre departamentos o entre personas.
Valorar más la colaboración con el cliente que la negociación contractual
Las prácticas ágiles están especialmente indicadas para productos difíciles de definir con detalle en el principio, o que si se definieran así tendrían al final menos valor que si se van enriqueciendo con retro-información continua durante el desarrollo. También para los casos en los que los requisitos van a ser muy inestables por la velocidad del entorno de negocio.
Para el desarrollo ágil el valor del resultado no es consecuencia de haber controlado una ejecución conforme a procesos, sino de haber sido implementado directamente sobre el producto. Un contrato no aporta valor al producto. Es una formalidad que establece líneas divisorias entre responsabilidades, que fija los referentes para posibles disputas contractuales entre cliente y proveedor.
En el desarrollo ágil el cliente es un miembro más del equipo, que se integra y colabora en el grupo de trabajo. Los modelos de contrato por obra no encajan.
Riqueza de la comunicación
Valorar más la respuesta al cambio que el seguimiento de un plan
Para un modelo de desarrollo que surge de entornos inestables, que tienen como factor inherente al cambio y la evolución rápida y continua, resulta mucho más valiosa la capacidad de respuesta que la de seguimiento y aseguramiento de planes pre-establecidos. Los principales valores de la gestión ágil son la anticipación y la adaptación; diferentes a los de la gestión de proyectos ortodoxa: planificación y control para evitar desviaciones sobre el plan.
Diferenciar entre iterativo e incremental haciendo hincapié en qué significa incremento.
Juguemos a las adivinanzas ¿Qué tienen en común un balón de rugby, una pila…?
Presentar video de un scrum, ¿qué tal las all blacks? Posteriormente se afianzará el simil (colaboración, objetivos…)
¿Qué valores destacaríais del video?
- Juego en equipo
Todos los integrantes son importantes
Hacer software no es sencillo, y no sólo lo digo yo...
…además supongo que todo el mundo se habrá dado cuenta de ello.
Pues si hacer software es complejo, no lo hagamos aún más!!!!!!!!...
El principio en que debemos sustentarnos es en KISS (Keep It Simple Stupid, las cosas ya son bastante complicadas como para encima complicarlas más):
Huir de florituras.
Ser funcionales.
Ser prácticos.
Soluciones dirigidas a las reutilización…
Reducir la labor administrativa
No se trata de leer esto (nos dormiríamos…). Es la definición de la wikipedia, entre la que se destacan varios puntos.
Cerdos vs Pollos (gallinas)
Empresa
El grado de éxito de Scrum en una empresa no depende sólo de los roles y las responsabilidades directamente relacionadas con el desarrollo de los proyectos (cliente y equipo). Las organizaciones son realidades inter-relacionadas, y aunque aquí veremos los roles relacionados con la ejecución directa del proyecto, el área directiva o de management de la organización, así como la de procesos tienen también responsabilidades que deben gestionar de forma coordinada y alineada en una estrategia que genere el mejor ecosistema para la implantación y evolución de trabajos en “campos de Scrum”.
Scrum Master
El Scrum Master es uno de los Roles De Scrum. Anteriormente solía ser el project manager, ahora es la persona responsable para asegurarse que el proceso de Scrum es utilizado correctamente. Hay distintas maneras de pensar sobre el rol del Scrum Master. Podría ser, por ejemplo, como un padre, ya que cuando se crea un equipo de Scrum, al principio no saben como auto-administrarse, no saben como trabajar entre todos, no saben cómo trabajar con el Dueño Del Producto, o cómo trabajar dentro de timeboxes. Entonces, al igual que un padre, el Scrum Master es el responsable de enseñarles cómo hacer todo esto hasta que aprendan, llevándolos en el proceso de convertirse en un equipo auto-administrado. Además, el Scrum Master es como un coach, responsable de alentar a todo el equipo, ser su líder y guía. El Scrum Master es también un referee que asegura que se sigan las reglas.
El Scrum Master por sobre todas las coasas tiene que asegurar las reglas. Muchos de los procesos que utilizan las organizaciones crean impedimentos para el progreso del trabajo del equipo. A veces puede parecer más simple el abandonar y aceptar que el proceso organizacional no puede cambiar, y así comprometer la eficiencia del equipo. Por lo tanto es vital que, para mantener la alta productividad de Scrum, se sigan las reglas y las mismas se mantengan sin importar el entorno. Haciendo esto, se hace evidente las cosas de la organización que son disfuncionales y se interponen en el proceso de creación de software.
El trabajo del Scrum Master es quitar cualquier impedimento, interno o externo al equipo que le impida alcanzar el objetivo de construir el software que comprometieron al inicio del Sprint.
[editar]Responsabilidades
Un Scrum Master es entonces un Lider y Facilitador, y es el responsable de:
Mejorar la vida y productividad de los miembros del equipo, facilitándole la creatividad de cualquier manera posible.
Asegurar la cooperación de todos los roles, y quitar cualquier barrera que lo impida.
Proteger al equipo de interferencias externas, y quitar impedimentos.
Asegurar que se siga el proceso
Invitar a personas al Scrum diario, y a reuniones de revisión del sprint y planificación
Seguir la Lista De Impedimentos, quitando las barreras entre el desarrollo y el cliente, de manera que el cliente maneje directamente la funcionalidad desarrollada.
Enseñarle al cliente cómo maximizar su retorno de inversión y cumplir sus objetivos con Scrum
Mejorar las prácticas y herramientas usadas, de manera que cada incremento de funcionalidad sea potencialmente productivo.
Miembros Del Equipo De Scrum
Los Miembros del Equipo es uno de los Roles De Scrum. El equipo del proyecto es un grupo multi-funcional de personas con todas las habilidades diferentes que son necesarias para convertir los requerimientos en algo que es un incremento de una funcionalidad potencialmente productiva. Por lo tanto, usualmente consiste en:
analistas
diseñadores
encargados de Calidad (QA)
desarrolladores
documentadores
otras habilidades necesarias para realizar el trabajo
Este es el equipo que se compromete con el Dueño Del Producto en las tareas a realizar en cada iteración, y luego las hace. Al final de la iteración le muestran al Dueño Del Producto el resultado, de manera que pueda elegir cómo seguir.
Muchas organizacionse suelen tener un grupo de personas especializadas en distintos temas, como ser usabilidad, administradores de bases de datos, expertos en seguridad y arquitectos de sistemas. Cuando se necesita la participación de alguno de ellos, deberían pasar a formar parte del equipo. Es decir, no son parte de un grupo &quot;externo&quot; de expertos que dan consejos, sino que se convierten en miembros del equipo para aquellas iteraciones en las que es necesario construir una arquitectura, infraestructura o trabajar en la base de datos. Pueden estar trabajando o guiando, monitoreando a los miembros del equipo que hacen el trabajo. La diferencia fundamental es que no son más pollos. Se comprometen al comienzo de la iteración junto al resto del equipo, y siguen con ellos hasta el fin de la iteración. Por lo tanto se convierten en cerdos por un período corto de tiempo.
[editar]Características
Multi-funcional.
Tamaño del equipo de entre 5 y 9 miembros.
Auto-Administrado, gestionado por los mismos miembros del equipo.
[editar]Responsabilidades
Las principales responsabilidades, más allá de la auto-organización y uso de tecnologías ágiles, son las que se derivan de la diferencia entre “grupo de trabajo” y “equipo”.
Un grupo de trabajo es un conjunto de personas que realizan un trabajo con una asignación específica de tareas, responsabilidades y siguiendo un proceso o pautas de ejecución. Los operarios de una cadena, forman un grupo de trabajo: aunque tienen un jefe común, y trabajan en la misma organización, cada uno responde de su trabajo.
El equipo tiene espíritu de colaboración, y un propósito común: conseguir el mayor valor posible para la visión del cliente.
Un equipo Scrum responde en su conjunto. Trabajan de forma cohesionada y auto-organizada. No hay un gestor que delimita, asigna y coordina las tareas. Son los propios miembros del equipo los que realizan estas funciones.
En el equipo:
Todos los miembros conocen comprenden la visión del propietario del producto.
Aportan y colaboran con el propietario del producto en el desarrollo de la pila de producto.
Comparten de forma conjunta el objetivo de cada sprint y la responsabilidad del logro.
Todos los miembros participan en las decisiones.
Se respetan las opiniones y aportaciones de todos
Todos conocen el modelo de trabajo con Scrum.
Entonces las responsabilidades son:
Selecciona el objetivo de la iteración y determina los resultados del trabajo
Tiene el derecho para hacer todo lo necesario (dentro de los límites de las guías del proyecto) para alcanzar el objetivo de la iteración
Se organiza a si mismo y a su trabajo
Realiza demostraciones del resultado del trabajo ante el Dueño Del Producto y los stakeholders.
Con letra del “Equipo A”, para que sea más rotundo!!!!
¿Quién quiere sprints cortos y quien los quiere largos?
Cortos: dueños de producto
Largos: el equipo
Meta del sprint:
¿Por qué hacemos este Sprint en vez de irnos todos de vacaciones?”.
Sprint
Un Sprint en Scrum es el término que denomina a una iteración que está acotada en el tiempo, usualmente entre 2 y 4 semanas, durante la cual el Equipo trabaja para convertir items del Backlog Del Producto en un Incremento Del Producto potencialmente productivo.
La duración del Sprint debería ser lo suficientemente larga para crear algo de valor y con la suficiente calidad como para ser demostrado frente al DueñoDelProducto y los stakeholders. Con un plazo superior a 4 semanas el Equipo pierde agilidad, ya que tendrá más artefactos y documentación por la cual preocuparse.
Un Sprint de 2 semanas es la duración ideal, y se conviertió en un estandard defacto por los siguientes motivos:
Fuerza al equipo a operar de una manera ágil, en vez de hacer &quot;mini cascadas&quot;
Brinda un feedback más frecuente en lo que se está construyendo
Reduce el riesgo de &quot;construir la cosa equivocada&quot;
Incrementa la respuesta del equipo ante cambios en el negocio
Le brinda al equipo más oportunidades de analizar y adaptarse a la forma que trabajan
Los objetivos y actividades del Sprint se planifican al comienzo de cada Sprint en la reunión de PlanificacionDelSprint. Al finalizar el Sprint el equipo demuestra lo que construyeron en la Revision Del Sprint, y analizan su propia performance y deciden qué mejorar en la Retrospectiva Del Sprint.
La duración de las reuniones del Sprint (Planificación, Revisión y Retrospectiva) se escalan de acuerdo a la duración del Sprint.
El progreso del Sprint se sigue con el Backlog Del Sprint y un gráfico Burndown.
Contenido
[ocultar]
1 Reglas
2 Meta del Sprint
3 Cancelación del Sprint
4 Ver también
[editar]Reglas
El Equipo puede buscar ayuda externa (consejos, recomendaciones, información y soporte) durante el Sprint.
Nadie del exterior debe proveer al Equipo con instrucciones, comentarios o direcciones durante el Sprint. El Equipo es el único responsable de sí mismo: se auto-administra completamente, y cada miembro del equipo es responsable por la gestión del mismo.
El Equipo se compromete a resolver items del Backlog Del Producto durante la reunión de Planificacion Del Sprint. Nadie fuera del Equipo debe cambiar los items del Backlog Del Producto que el equipo ya comprometió.
Si el Sprint se torna no viable, el Scrum Master puede terminar anormalmente el Sprint y organizar una nueva reunión dePlanificacion Del Sprint para iniciar un Sprint nuevo. El Scrum Master puede realizar este cambio a su criterio, o a pedido del Dueño Del Producto o del Equipo. El Sprint podría ser no viable si la tecnología no funciona, las condiciones del negocio cambian, o si alguien exterior interfiere con el Equipo.
Si el Equipo siente que no podrá completar todos los items del Backlog del Producto comprometidos en el Sprint, puede consultar al Dueño Del Producto sobre qué items quitar. Si son demasiados los items a quitar, y el Sprint pierde así sentido, el Scrum Master puede terminar anormalmente el Sprint.
Si el Sprint requiere un 20% más de trabajo que el planificado luego de dos días después de la Planificacion Del Sprint, se necesita planificar mejor. Esto es algo para tratar en la Retrospectiva Del Sprint.
Si el Equipo determina que puede resolver más items del Backlog del Producto de los que seleccionó durante la Planificacion del Sprint, el Equipo le puede consultar al Dueño Del Producto sobre otros items para agregar al mismoSprint.
Los Miembros Del Equipo De Scrum tienen dos responsabilidades administrativas durante el Sprint: tienen que asistir a la Reunion Diaria De Scrum, y tienen que mantener actualizado el estado de los items del Backlog Del Sprint (por ejemplo, estimado en horas restantes). Se pueden agregar nuevas tareas al Backlog Del Sprint a medida que vayan surgiendo.
Si los miembros del Equipo informan el mismo item el mismo día, tienen que planificar mejor y descomponer las tareas con un mayor nivel de granularidad.
El Equipo tiene que adherir a los estándares y convenciones existentes para el desarrollo, prácticas y arquitectura.
[editar]Meta del Sprint
Así como la Visión del Proyecto comunica el objetivo global y el espíritu del proyecto, es también útil contar con una visión para cada Sprint que encapsule todas las tareas en una &quot;Meta&quot;. Por ejemplo, en vez de que el &quot;Sprint 6&quot; sea un Sprint más donde se construyen cosas, se podría convertir en el &quot;Sprint del sistema de pagos&quot;. Una meta del Sprint puede ser algo como:
&quot;En este Sprint lograremos que los usuarios puedan ingresar al sitio, recuperar un password olvidado, y administrar su pérfil&quot;
La Meta del Sprint se acuerda durante la reunión de PlanificacionDelSprint al comienzo del Sprint.
[editar]Cancelación del Sprint
Un sprint puede ser cancelado antes de tiempo cuando:
El equipo cancela un sprint si sienten que no pueden completar la Meta del Sprint
La gerencia puede cancelar el Sprint si circunstancias externas anulan el valor de la Meta del Sprint
Cuando un Sprint se termina anormalmente, el próximo paso es realizar una nueva reunión de PlanificacionDelSprint, en donde se revisa la razón de terminación.
Sprint De Release
En Scrum, cuando el Dueño Del Producto y los Stakeholders identifican que existe suficiente funcionalidad en el sistema para brindar valor inmediato al negocio, pueden elegir poner esta funcionalidad en producción. Usualmente se realiza un &quot;Sprint de Release&quot; que contiene todos las tareas en el Backlog Del Sprint para poner el sistema en producción. Estas tareas no deberían contener funcionalidad adicional, a menos que incluyan:
Instalar el código en el entorno productivo
Población de datos productivos
Configurar la administración, sistemas de operaciones y procesos
Entrenamiento y capacitación al staff de soporte
Planificación de contingencia y vuelta atrás
Un Sprint de Release no debería ser más largo que un Sprint normal, sin importar cuántos Sprints estén agrupados en el release. Es una buena práctica asegurarse seguido que el sistema esté en un estado tal que un sólo Sprint alcance para ponerlo en producción. Si la respuesta es negativa, entonces el equipo debería mejorar la calidad del código existente y verificar que su concepto de &quot;Terminado&quot; es lo suficientemente completo como para calidad productiva.
Variables a tener en cuenta durante la reunión de planificación del sprint, para cada item del backlog se ha de conocer su alcance, estimación e importancia… …la calidad no es negociable!!!
¿Qué tipos de calidad creéis que existen?
Calidad Interna Innegociable
Calidad Externa Postergable pero también innegociable
Un Kit-Kat (hagamos un paréntesis…)…
La mejor forma de medir la calidad del código es…
Reglas
El Equipo puede buscar ayuda externa (consejos, recomendaciones, información y soporte) durante el Sprint.
Nadie del exterior debe proveer al Equipo con instrucciones, comentarios o direcciones durante el Sprint. El Equipo es el único responsable de sí mismo: se auto-administra completamente, y cada miembro del equipo es responsable por la gestión del mismo.
El Equipo se compromete a resolver items del Backlog Del Producto durante la reunión de Planificacion Del Sprint. Nadie fuera del Equipo debe cambiar los items del Backlog Del Producto que el equipo ya comprometió.
Si el Sprint se torna no viable, el Scrum Master puede terminar anormalmente el Sprint y organizar una nueva reunión dePlanificacion Del Sprint para iniciar un Sprint nuevo. El Scrum Master puede realizar este cambio a su criterio, o a pedido del Dueño Del Producto o del Equipo. El Sprint podría ser no viable si la tecnología no funciona, las condiciones del negocio cambian, o si alguien exterior interfiere con el Equipo.
Si el Equipo siente que no podrá completar todos los items del Backlog del Producto comprometidos en el Sprint, puede consultar al Dueño Del Producto sobre qué items quitar. Si son demasiados los items a quitar, y el Sprint pierde así sentido, el Scrum Master puede terminar anormalmente el Sprint.
Si el Sprint requiere un 20% más de trabajo que el planificado luego de dos días después de la Planificacion Del Sprint, se necesita planificar mejor. Esto es algo para tratar en la Retrospectiva Del Sprint.
Si el Equipo determina que puede resolver más items del Backlog del Producto de los que seleccionó durante la Planificacion del Sprint, el Equipo le puede consultar al Dueño Del Producto sobre otros items para agregar al mismoSprint.
Los Miembros Del Equipo De Scrum tienen dos responsabilidades administrativas durante el Sprint: tienen que asistir a la Reunion Diaria De Scrum, y tienen que mantener actualizado el estado de los items del Backlog Del Sprint (por ejemplo, estimado en horas restantes). Se pueden agregar nuevas tareas al Backlog Del Sprint a medida que vayan surgiendo.
Si los miembros del Equipo informan el mismo item el mismo día, tienen que planificar mejor y descomponer las tareas con un mayor nivel de granularidad.
El Equipo tiene que adherir a los estándares y convenciones existentes para el desarrollo, prácticas y arquitectura.
Backlog Del Producto
El backlog del producto en Scrum es el artefacto más importante de Scrum, ya que dirige la construcción. Hasta el equipo más efectivo y eficiente fallará si construye lo que no es necesario.
El backlog es un inventario o una lista priorizada de requerimientos funcionales, mejoras, tecnología y corrección de errores que deben incorporarse al producto a través de las sucesivas iteraciones. Representa todo aquello que esperan los clientes, usuarios, y en general los interesados en el producto. Todo lo que suponga un trabajo que debe realizar el equipo tiene que estar reflejado en el backlog.
Estos son algunos ejemplos de posibles entradas de un backlog:
Permitir a los usuarios la consulta de las obras publicadas por un determinado autor.
Reducir el tiempo de instalación del programa.
Mejorar la escalabilidad del sistema.
Permitir la consulta de una obra a través de un API web.
A diferencia de un documento de requisitos del sistema, el product backlog nunca se da por completo; está en continuo crecimiento y evolución. Habitualmente se comienza a elaborar con el resultado de una reunión de &quot;fertilización cruzada&quot; o brainstorming; o un proceso de “Exploración” (Extreme Programming), o en el Sprint 0 (preparación) donde colabora todo el equipo partiendo de la visión del propietario del producto. El formato de la visión no es relevante. Según los casos, puede ser una presentación informal del responsable del producto, un informe de requisitos del departamento de marketing, etc. Sí que es importante sin embargo disponer de una visión real, comprendida y compartida por todo el equipo.
El product backlog evolucionará de forma continua mientras el producto esté en el mercado, para darle valor de forma continua, y mantenerlo útil y competitivo.
[editar]Formato
El desarrollo ágil prefiere la comunicación directa, antes que a través de documentos. El product backlog no es un documento de requisitos, sino una herramienta de referencia para el equipo. Es recomendable el formato de lista que incluya al menos la siguiente información para cada línea:
Identificador único de la funcionalidad o trabajo.
Descripción de la funcionalidad.
Campo o sistema de priorización.
Estimación
Dependiendo del tipo de proyecto, funcionamiento del equipo y la organización, pueden resultar aconsejables otros campos:
Observaciones
Criterio de validación
Ejemplo De Product Backlog
Cada ítem del backlog del producto debe tener una estimación de alto nivel del esfuerzo para convertir cada item en un elemento completo del sistema. El Dueño Del Producto es el responsable de mantener el contenido del backlog del producto, y asegurar que están continuamente priorizados para alinearse a las necesidades del negocio. La prioridad debería ser asignada en base a la importancia de cada item para el negocio, o aquellos que ofrezcan un más rápido retorno de la inversión. Esta lista debería evolucionar, cambiando a medida que varian las condiciones del negocio o cambia la tecnología.
Importancia: Tarea A (2), Tarea B (100).
¿Cuál es más importante?
¿Es una 50 veces más importante que la otra?
Excel compartida
¿Se os ocurren más campos?
“Creación de índices en la base de datos”, ¿es verdaderamente un item del producto backlog?
Empleo de tarjetas, ¿por qué?
Todo el mundo se siente implicado
¿Cómo combinar esto con proyectos cerrados?
Todos los elementos con importancia &gt;=100 deben estar incluidos en la versión 1.0, o seremos penalizados hasta la muerte.
Todos los elementos de importancia 50-99 deberían estar incluidos en la versión 1.0, pero podríamos pasar sin ellos si los incluyésemos en otra entrega poco después.
Los elementos con importancias 25-49 son requisitos, pero podemos incluirlos en una versión 1.1.
Los elementos con importancia &lt;25 son puramente especulativos y puede que ni siquiera hagan falta.
Backlog Del Producto
El backlog del producto en Scrum es el artefacto más importante de Scrum, ya que dirige la construcción. Hasta el equipo más efectivo y eficiente fallará si construye lo que no es necesario.
El backlog es un inventario o una lista priorizada de requerimientos funcionales, mejoras, tecnología y corrección de errores que deben incorporarse al producto a través de las sucesivas iteraciones. Representa todo aquello que esperan los clientes, usuarios, y en general los interesados en el producto. Todo lo que suponga un trabajo que debe realizar el equipo tiene que estar reflejado en el backlog.
Estos son algunos ejemplos de posibles entradas de un backlog:
Permitir a los usuarios la consulta de las obras publicadas por un determinado autor.
Reducir el tiempo de instalación del programa.
Mejorar la escalabilidad del sistema.
Permitir la consulta de una obra a través de un API web.
A diferencia de un documento de requisitos del sistema, el product backlog nunca se da por completo; está en continuo crecimiento y evolución. Habitualmente se comienza a elaborar con el resultado de una reunión de &quot;fertilización cruzada&quot; o brainstorming; o un proceso de “Exploración” (Extreme Programming), o en el Sprint 0 (preparación) donde colabora todo el equipo partiendo de la visión del propietario del producto. El formato de la visión no es relevante. Según los casos, puede ser una presentación informal del responsable del producto, un informe de requisitos del departamento de marketing, etc. Sí que es importante sin embargo disponer de una visión real, comprendida y compartida por todo el equipo.
El product backlog evolucionará de forma continua mientras el producto esté en el mercado, para darle valor de forma continua, y mantenerlo útil y competitivo.
[editar]Formato
El desarrollo ágil prefiere la comunicación directa, antes que a través de documentos. El product backlog no es un documento de requisitos, sino una herramienta de referencia para el equipo. Es recomendable el formato de lista que incluya al menos la siguiente información para cada línea:
Identificador único de la funcionalidad o trabajo.
Descripción de la funcionalidad.
Campo o sistema de priorización.
Estimación
Dependiendo del tipo de proyecto, funcionamiento del equipo y la organización, pueden resultar aconsejables otros campos:
Observaciones
Criterio de validación
Ejemplo De Product Backlog
Cada ítem del backlog del producto debe tener una estimación de alto nivel del esfuerzo para convertir cada item en un elemento completo del sistema. El Dueño Del Producto es el responsable de mantener el contenido del backlog del producto, y asegurar que están continuamente priorizados para alinearse a las necesidades del negocio. La prioridad debería ser asignada en base a la importancia de cada item para el negocio, o aquellos que ofrezcan un más rápido retorno de la inversión. Esta lista debería evolucionar, cambiando a medida que varian las condiciones del negocio o cambia la tecnología.
¿Qué significa estar por encima?¿Y por debajo?
OJO de buen cubero??
Equipos pequeños y sprints cortos
Tiempo que hizo ayer??
Requiere ya haber ejecutado algún sprint
Reuniones time-boxed, duran X tiempo y transcurrido el mismo se terminan. Si no ha dado tiempo para la próxima ya se mejorará!!
Precondiciones, ¿qué necesito como mínimo? El product back log y el dueño del producto
¿Qué pasa si están hechos los items de abajo y no los de arriba?
¿Qué pasa si hay mucho no planificado?
¿Qué pasa si hay mucha pendiente?
¿Qué pasa si hay poca pendiente?
Entradas
Backlog del sprint y gráfico de avance (burn-down) actualizados con la información de la reunión anterior. Información de las tareas realizadas por cada componente del equipo
[editar]Resultados
Backlog del sprint y gráfico de avance (Burn-down) actualizados. Identificación de necesidades e impedimentos.
[editar]Beneficios
Esta reunión es de suma utilidad y tiene los siguientes beneficios:
Los impedimentos se identifican prontamente, para poder mantener el ritmo de desarrollo.
Se disminuye la duplicación de esfuerzo.
Mejor comprensión de la interdependencia entre los Miembros Del Equipo De Scrum.
Se comparten objetivos y una dirección clara en el equipo.
Se contruye confianza y motivación durante el Sprint.
Se mejora la productividad, al tener una presión inconsciente por el hecho de tener que pararse frente al resto del equipo y contar en lo que se estuvo trabajando.
Mejora la comunicación del equipo y sus relaciones.
[editar]Reglas
Tener la Reunión Diaria de Scrum en el mismo lugar, a la misma hora todos los días. Lo ideal es que la reunión sea lo primero del día, de manera que los miembros del equipo puedan recordar lo que hicieron el día anterior, y planear el día que comienza.
Se requiere de todos los miembros del equipo en la reunión. Si por cualquier motivo algún miembro no puede asistir, se necesitaría que el ausente participe por teléfono, o que otro miembro reporte el status del ausente.
Los miembros deben ser puntuales. El Scrum Master comienza la reunión a la hora indicada, sin importar quién esté presente. Cualqueir miembro que llegue tarde paga una multa que es donada para caridad!
El Scrum Master comienza la reunión con la persona que esté a su izquierda y sigue en sentido horario hasta que todos hayan hablado.
Cada miembro del equipo debe responder a estos preguntas:
¿Qué hiciste desde el último Scrum Diario respecto al proyecto?
¿Qué harás desde ahora y hasta el próximo Scrum Diario?
¿Qué te está impidiendo hacer tu trabajo lo mejor posible?
Cada miembro informa la cantidad de tiempo que le falta para terminar la tarea que tiene asignada, registrando dicho valor en su tarea. Así, el Scrum Master podrá luego realizar el Seguimiento Del Sprint.
Los miembros del equipo no deben divagar fuera de estas preguntas, saltando por ejemplo a temas como diseño, discusiones de problemas, rumores, etc. El Scrum Master es responsable de mantener el orden y pasar de persona a persona lo más rapidamente posible.
Los miembros del Equipo deben dirigirse al Equipo al hablar. La reunión no se trata de &quot;Informarle al Scrum Master&quot;.
Durante la reunión sólo una persona habla al mismo tiempo. El resto escucha sin hablar entre ellos.
Cuando algún miembro del Equipo informa algo de interés para otros miembros del Equipo, o necesita ayuda de otros, cualquier miembro del Equipo puede organizar inmediatamente para juntarse luego de terminado el Scrum Diario.
Los Pollos (personas fuera del Equipo) son bienvenidos de participar en el Scrum Diario, pero no se les permite hablar, realizar observaciones, hacer gestos o interferir con la reunión de cualquier otra manera.
Los Pollos se mantiene alejados en la perisferia del Equipo, de manera de no interferir.
Si muchos Pollos quieren asisten a la reunión, el Scrum Master puede limitar la asistencia de los mismos para mantener el orden.
Los Pollos o Cerdos que no sigan las reglas pueden ser excluidos de la reunión (en el caso de los Pollos) o quitados del Equipo (Cerdos).
[editar]Al final de la reunión
Con las estimaciones de tiempos actualizadas por el equipo, el Scrum Master actualiza el gráfico de avance del sprint.
El responsable de la gestión de procesos de la organización (Scrum Manager o Scrum Master) comienza a gestionar las posibles necesidades e impedimentos identificados.
Si alguien no coge ninguna tarea:
Vergüenza: “Bueno, si no tenéis idea de cómo podéis ayudar al equipo os sugiero que os vayáis a casa
Vieja escuela: Simplemente asígnales una tarea.
Presión de los compañeros: Di “sentiros libres de tomaros el tiempo que haga falta
Servidumbre: Di algo como “Bueno, podéis ayudar al equipo indirectamente siendo sus mayordomos hoy.
Entradas
Backlog del sprint y gráfico de avance (burn-down) actualizados con la información de la reunión anterior. Información de las tareas realizadas por cada componente del equipo
[editar]Resultados
Backlog del sprint y gráfico de avance (Burn-down) actualizados. Identificación de necesidades e impedimentos.
[editar]Beneficios
Esta reunión es de suma utilidad y tiene los siguientes beneficios:
Los impedimentos se identifican prontamente, para poder mantener el ritmo de desarrollo.
Se disminuye la duplicación de esfuerzo.
Mejor comprensión de la interdependencia entre los Miembros Del Equipo De Scrum.
Se comparten objetivos y una dirección clara en el equipo.
Se contruye confianza y motivación durante el Sprint.
Se mejora la productividad, al tener una presión inconsciente por el hecho de tener que pararse frente al resto del equipo y contar en lo que se estuvo trabajando.
Mejora la comunicación del equipo y sus relaciones.
[editar]Reglas
Tener la Reunión Diaria de Scrum en el mismo lugar, a la misma hora todos los días. Lo ideal es que la reunión sea lo primero del día, de manera que los miembros del equipo puedan recordar lo que hicieron el día anterior, y planear el día que comienza.
Se requiere de todos los miembros del equipo en la reunión. Si por cualquier motivo algún miembro no puede asistir, se necesitaría que el ausente participe por teléfono, o que otro miembro reporte el status del ausente.
Los miembros deben ser puntuales. El Scrum Master comienza la reunión a la hora indicada, sin importar quién esté presente. Cualqueir miembro que llegue tarde paga una multa que es donada para caridad!
El Scrum Master comienza la reunión con la persona que esté a su izquierda y sigue en sentido horario hasta que todos hayan hablado.
Cada miembro del equipo debe responder a estos preguntas:
¿Qué hiciste desde el último Scrum Diario respecto al proyecto?
¿Qué harás desde ahora y hasta el próximo Scrum Diario?
¿Qué te está impidiendo hacer tu trabajo lo mejor posible?
Cada miembro informa la cantidad de tiempo que le falta para terminar la tarea que tiene asignada, registrando dicho valor en su tarea. Así, el Scrum Master podrá luego realizar el Seguimiento Del Sprint.
Los miembros del equipo no deben divagar fuera de estas preguntas, saltando por ejemplo a temas como diseño, discusiones de problemas, rumores, etc. El Scrum Master es responsable de mantener el orden y pasar de persona a persona lo más rapidamente posible.
Los miembros del Equipo deben dirigirse al Equipo al hablar. La reunión no se trata de &quot;Informarle al Scrum Master&quot;.
Durante la reunión sólo una persona habla al mismo tiempo. El resto escucha sin hablar entre ellos.
Cuando algún miembro del Equipo informa algo de interés para otros miembros del Equipo, o necesita ayuda de otros, cualquier miembro del Equipo puede organizar inmediatamente para juntarse luego de terminado el Scrum Diario.
Los Pollos (personas fuera del Equipo) son bienvenidos de participar en el Scrum Diario, pero no se les permite hablar, realizar observaciones, hacer gestos o interferir con la reunión de cualquier otra manera.
Los Pollos se mantiene alejados en la perisferia del Equipo, de manera de no interferir.
Si muchos Pollos quieren asisten a la reunión, el Scrum Master puede limitar la asistencia de los mismos para mantener el orden.
Los Pollos o Cerdos que no sigan las reglas pueden ser excluidos de la reunión (en el caso de los Pollos) o quitados del Equipo (Cerdos).
[editar]Al final de la reunión
Con las estimaciones de tiempos actualizadas por el equipo, el Scrum Master actualiza el gráfico de avance del sprint.
El responsable de la gestión de procesos de la organización (Scrum Manager o Scrum Master) comienza a gestionar las posibles necesidades e impedimentos identificados.
Vergüenza torera
Afán de superación
Ejemplos:
“Deberíamos haber pasado más tiempo dividiendo historias en subhistorias y tareas”
“Demasiadas distracciones”
“Nos sobre-comprometimos y sólo hicimos la mitad”
“Nuestro entorno de oficina es demasiado ruidoso y desordenado”
Historías técnicas (ej.: implantar un servidor de integración continua)
¿Qué hará el Dueño del producto con ellas?
Trucos para subsanar este problema:
Renombrarlas, meterlas dentro de otras, separar historias técnicas
¿Por qué no hay un 7 o un 17, 19?
Para no ofrecer una falsa sensación de exactitud
El proceso
El Planning Poker es muy sencillo, se presentan los requisitos a estimar uno por uno haciendo una descripción de los mismos. Luego se procede a discutir aquellos detalles más relevantes o que no hayan quedado claros. Tras este periodo de discusión cada uno de las personas implicadas en el proceso de estimación elije de su mazo de cartas (que estan numeradas según la serie de Fibonacci) la carta que representa su estimación del trabajo que implica implementar el requisito que se está discutiendo.
Las estimaciones son privadas hasta que todo el mundo cuenta con una estimación. En ese momento, todas las estimaciones se hacen públicas (esto es así para evitar que las estimaciones de unas personas sesgen las de otras). Si la dispersión entre las estimaciones se vuelve al discutir el requisito y se vuelve a realizar el proceso de estimación.
Generalmente la dispersión en las estimaciones es sintoma de que la información que manejan parte de los involucrados en el proceso de estimación no es completa o exacta. La segunda ronda de discusión permite aclarar aquellos puntos oscuros, diferencias de criterio y desvelar información que pueda no ser obvia sobre el requisito, de tal manera que en la siguiente ronda de estimación, la dispersión de las estimaciones será mucho menor y se podrá llegar facilmente a un consenso.
De esta manera es facil estimar los requisitos de una manera democrática, agil y rápida y que nos lleva a estimaciones respaldadas por todos los involucrados y basadas en consensos, en definitiva estimaciones que todo el mundo puede asumir como suyas y que todo el mundo respetará.
Uno de los problemas que tiene el Planning Poker es que requiere que todos los implicados en la estimación se encuentren en una misma sala. Esto no siempre es posible cuando los equipos de desarrollo están distribuidos geográficamente.
[editar]Las cartas
Este método se basa en un juego de cartas que tiene cada persona que estima. El modelo inicial de James Grening consta de 8 cartas con los números representados mas abajo, porque James lo ideó para las estimaciones de versión en Extreme Programming, con equipos que emplean como unidad de esfuerzo: días de trabajo de cada par de programadores y trabajan con tareas de tamaño máximo de 10 días.
½, 1, 2, 3, 5, 6, 7, 8, infinito
El funcionamiento es muy simple: cada participante dispone de un juego de cartas, y en la estimación de cada tarea, todos vuelven boca arriba la combinación que suma el esfuerzo estimado.
Cuando se considera que éste es mayor de 10 horas (o del tamaño máximo considerado por el equipo para una tarea), se levanta la carta “infinito”
Cada equipo u organización puede utilizar un juego de cartas con las numeraciones adecuadas a la unidad de esfuerzo con la que trabajan, y el tamaño máximo de tarea que se va a estimar.
Lo relevante no es el número de cartas, la unidad de medida empleada, o si el tamaño máximo de tarea debe ser 5, 7 ó 10 días, sino trabajar con el modelo más apropiado al equipo, respetando los principios siguientes:
No definir tareas demasiado grandes, porque dificulta la precisión de las estimaciones y la identificación de riesgos. Un criterio válido, si el equipo no dispone de experiencia previa, es descomponer en otras menores las que tengan una duración mayor de 7 días ideales de trabajo.
No definir tareas con duraciones inferiores a medio día ideal de trabajo.
Utilizar al misma unidad de medida (story points, días, horas…) en todos los gráficos y backlogs.
[editar]Variante: sucesión de Fibonacci
Basado en el hecho de que al aumentar el tamaño de las tareas, aumenta también el margen de error, se ha desarrollado una variante que consiste en emplear sólo números de la sucesión de Fibonacci para realizar las estimaciones, de forma que:
El juego de cartas está compuesto por números de la sucesión de Fibonacci.
La estimación no se realiza levantando varias cartas para componer la cifra exacta, sino poniendo boca arriba la carta con la cifra más aproximada a la estimación.
Para estimar tareas puede ser válido un juego de cartas como éste:
0, ½, 1, 2, 3, 5, 8, 13, 20, infinito
Si se quiere emplear la planificación de póker para estimar requisitos a nivel de producto o de versión (funcionalidades, temas…) además de usarlo al nivel de tareas de sprint, se pueden añadir cartas al juego para permitir estimaciones de mayor tamaño (34, 55, 89, 144…)
Es frecuente emplear una carta con un símbolo de duda o interrogación para indicar que, por las razones que sean, no se puede precisar una estimación. También es posible incluir otra carta con alguna imagen alusiva, para indicar que se necesita un descanso.
[editar]Funcionamiento
Cada participante de la reunión tiene un juego de cartas.
Para cada tarea (historia de usuario o funcionalidad, según sea el nivel de requisitos que se va a estimar) el cliente, moderador o propietario del producto expone la descripción empleando un tiempo máximo.
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 estimación y las separa del resto, boca a bajo.
Cuando todos han hecho su selección, se muestran boca arriba.
Si la estimación resulta “infinito”, por sobrepasar el límite máximo establecido para estimar, la tarea debe dividirse en sub-tareas de menor tamaño.
Si las estimaciones resultan muy dispares, el moderador, con su criterio de gestión, y basándose en las características del proyecto, equipo, reunión, nº de elementos pendientes de evaluar… puede optar por:
Preguntar a las personas de las estimaciones extremas: ¿Por qué crees que es necesario tanto tiempo?, y ¿por qué crees que es necesario tan poco tiempo?. Tras escuchar las razones, repetir la estimación.
Dejar a un lado la estimación de esa tarea y retomar al final o en otro momento aquellas que hayan quedado pendientes.
Pedir al cliente o propietario del producto que descomponga la funcionalidad y valorar cada una de las funcionalidades resultantes.
Tomar la estimación menor, mayor, o la media.
Este protocolo de reunión evita los largos atascos de análisis circulares en ping-pong entre diversas opciones de implementación, hace participar a todos los asistentes, reduce el cuarto de hora o la media hora de tiempo de estimación de una funcionalidad, a escasos minutos, consigue alcanzar consensos sin discusiones, y además... resulta divertido y dinamiza la reunión.
[editar]La unidad de estimación: el día ideal
Los números que se muestran en las cartas pueden representar distintas unidades. Uno de los enfoques más utilizados es el de &quot;día ideal de trabajo&quot;. Esto es, la unidad representa un día ideal y perfecto de trabajo, sin interrupciones, interferencias o distracciones de ningún tipo.
Dicho de otra manera: &quot;si estuviera yo solo encerrado en una habitación, con alimento ilimitado y trabajando 6 horas perfectas, inspirado y totalmente concentrado, ¿cuánto tardaria en desarrollar la funcionalidad X de forma completa y con calidad productiva?&quot;.
Por ejemplo, la carta &quot;5&quot; representa que quien estimó podría completar la funcionalidad estimada en 5 días &quot;ideales&quot; de trabajo.
Existen diferentes formas de gestionarlos
Reducir el factor de dedicación
Tratarlos como historias
Día 4: surge un impedimento
Durante el desarrollo el equipo irá detectando situaciones que, de no ser resueltas, impedierán que puedan seguir avanzando con el sprint. Estos problemas se los conoce por el nombre de Impedimentos.
El Scrum Master lleva una Lista de Impedimentos con notas adhesivas en el afiche del Sprint.
Así, el día 4 del desarollo durante el Scrum Diario un desarrollador informa que para resolver la tarea que planeaba hacer necesita tener disponible un servicio remoto de morosidad de clientes que no está funcionando. El desarrollador entonces deja pendiente la tarea y sigue avanzando con otra.
El Scrum Master registra este Impedimento y lo asienta en la Lista de Impedimentos.
El Scrum Master será el encargado de resolver cuanto antes este problema para que el equipo pueda completar la historia.
El resto del equipo debe continuar con el desarrollo de las demás historias; es responsabilidad del Scrum Master el gestionar los impedimentos que surgen y liberar al equipo de cualquier traba o problema que les impida desarrollar software.Seguimiento del impedimento
Durante cada Scrum Diario el Scrum Master informará el estado del impedimento y de no haber sido resuelto irá asentando el paso de los días en el registro del impedimento.
Una vez resuelto, el Scrum Master podrá tachar el impedimento de la lista. El Impedimento seguirá pegado en el afiche, y servirá para analizar al finalizar el Sprint.
Un impedimento que tarda mucho en resolverse seguramente producirá un impacto negativo en los tiempos de una historia. Lo mismo ocurrirá si un Sprint sufre un número excesivo de impedimentos.
En ambos casos es problable que el equipo no logre cumplir con el compromiso asumido, y contará con un detalle visible de las dificultades que tuvieron.
Preparacion De Un Proyecto Scrum
La cantidad de trabajo que se requiere para iniciar un proyecto cambia de organización a organización, y de proyecto a proyecto. Scrum es un framework para crear proyectos, y su objetivo es invertir la menor cantidad de tiempo posible para lograr llegar a una posición donde se pueda comenzar con el ciclo iterativo de Scrum.
La fase de &quot;Preparación&quot; contiene algunas tareas que son candidatas a realizar durante la etapa de iniciación de un proyecto. Esta fase de iniciar un proyecto Scrum se conoce a veces como Sprint 0.
Contenido
[ocultar]
1 El caso de negocio
2 La visión del proyecto
3 Definición de Terminado
4 Backlog inicial del proyecto
5 Plan inicial para los entregables
6 Constitución del equipo
7 Logística
8 Ver también
[editar]El caso de negocio
Todo proyecto debería tener un caso de negocio sin importar la forma en la que se llevará a cabo. Se necesita una clara compresión del valor que el proyecto le va a a agregar a la organización para luego poder tomar decisiones relativas a la prioridad de las características que serán entregadas.
Por lo tanto, es importante comprender y aceptar que las estimaciones realizadas durante esta etapa son de muy alto nivel y, por lo tanto, imprecisas. Es por eso que el Backlog Del Producto es estimado en días: estimar en cualquier otra unidad de tiempo más chica daría una falsa sensación de exactitud. Por otro lado, lo mismo es cierto sobre la estimación del valor que el proyecto le dará a la empresa, el cual será sin dudas también inexacto. Es decir, no vale la pena invertir mucho tiempo en lograr estimaciones exactas de esfuerzo, a menos que se esté preparado para invertir el mismo tiempo en lograr estimaciones igual de exactas para los beneficios. Todo este tiempo está mejor invertido en crear el producto en si mismo, en lugar de agonizar y discutir sobre la exactitud de las estimaciones.
Por otro lado, debido a la naturaleza iterativa de Scrum, la inexactitud de las estimaciones se hacen evidente muy rápidamente, ni bien comienza a aparecer datos reales sobre qué tan rápido el equipo de desarrollo puede entregar software que funcione. Esto significa que los proyectos Scrum son mucho más efectivos mitigando el riesgo de estimaciones inexactas y, por lo tanto, no necesiten perder tiempo intentando bajar el riesgo de la estimación al principio.
Una de las ventajas más importantes de Scrum, muchas veces ignorada, es que permite ver muy fácilmente si un proyecto es viable. Si un requerimiento de negocio es muy demandante para el equipo y tecnología disponibles, debería resultar evidente tras el primer Sprint que el equipo no podrá entregar la funcionalidad requerida. Esto le permitirá a la empresa cancelar el proyecto luego de unas pocas semanas, en lugar de descubrir esta información tras 6, 12 o 18 meses de arduo trabajo. Scrum permite que el negocio tenga el control del proyecto realmente.
[editar]La visión del proyecto
Scrum, como otras metodologías ágiles, no fomentan la documentación innecesaria. Sin embargo, es importante que el equipo completo comprenda la esencia del proyecto o producto que están intentando crear. Aquí es donde la Visión del Proyecto entra en juego. Debería ser lo más corta y accesible posible, comunicando la esencia y espíritu del emprendimiento. Comunicar la visión es tan importante cómo tenerla. Un buen ejemplo de éxito sería poder preguntarle a cualquier integrante del equipo que explique correctamente el propósito del proyecto.
La Visión del Proyecto debería ser descompuesta en un set levemente más detallado de Visiones de Entregable, una por entregable. Un pequeño set de slides en una presentación deberían funcionar bien para esto.
[editar]Definición de Terminado
El equipo debe acordar una Definicion De Terminado, es decir, cuándo podrá considerar que cada una de las historias y tareas se encuentran terminadas.
[editar]Backlog inicial del proyecto
A medida que el equipo entra en el primer Sprint, debería tener disponible suficientes ítems en el Backlog Del Productoenumerados y priorizados para permitirles comenzar a trabajar. Estos items del backlog pueden haber surgido durante el trabajo de crear el caso de negocio, transformados de un documento de requerimientos, o creados directamente por elDueño Del Producto.
[editar]Plan inicial para los entregables
El Backlog Del Producto contiene toda la funcionalidad que el producto debería tener. Si toda esta funcionalidad se construye antes de un entregable productivo, se pierde la oportunidad que Scrum brinda de poder ser por adelantado el valor del producto, y obtener feedback de manera temprana. Por estos motivos es una práctica común dividir el backlog en &quot;Entregables&quot; o colección de características útiles del sistema, que tienen sentido ponerlas en producción.
Es importante recordar que lo que al principio puede parecer un set coherente de entregables, puede cambiar con el paso del tiempo, de forma que es necesaria cierta flexibilidad. Algunas razones para cambiar un plan de entregas son:
cambio en las oportunidades del negocio.
durante una Revision Del Sprint el grupo de usuarios puede encontrar que la funcionalidad mostrada podría entregar valor al negocio si fuera puesta en producción.
demasiadas características para un entregable en el tiempo dado, de forma que se requiera más tiempo o menos características para el entregable.
Cuando se crea un plan de entregas:
el negocio determina cuando se necesita un entregable, la funcionalidad que debe contener, el nivel de aceptación de la calidad y el costo.
el equipo de desarrollo determina cuánto se tardara en construir ese entregable
el equipo de desarrollo crea las estimaciones preliminares
el equipo de desarrollo refina las estimaciones a medida que se incrementan las prioridades
el equipo selecciona el backlog del producto a desarrollar, cada Sprint (backlog del Sprint)
el negocio se centra en el valor entregado por cada entregable
[editar]Constitución del equipo
Una vez que todos los roles del equipo están identificados, el equipo debería juntarse para una reunión de kick off, en la cual se deberían tratar:
el alcance del proyecto
una revisión rápida del backlog
cualquier discusión técnica
acuerdos iniciales sobre cómo el equipo trabajará junto (por ejemplo, a qué hora son las reuniones diarias)
[editar]Logística
Hay ciertas tareas de organización y logística que deben completarse al iniciar un proyecto ágil:
tener un área o lugar disponible para el equipo
tener las reuniones de kick off con el equipo
planificar las reuniones con el usuario por adelantado, y agregarlas a las agendas de las personas
crear una &quot;pizarra de trabajo&quot; en el área del equipo
llenar las parades libres en el área del equipo con pizarras
asegurarse que el equipo tiene lo necesario para comenzar el desarrollo del primer Sprint: notebooks / PCs, un sistema de Control De Versiones, conectividad de red e Internet, entornos de desarrollo y test, etc...
comprar café y snacks!
Día 1: Planificación del Sprint
Tal como ya vimos, el primer Sprint va del lunes 1-septiembre-2008 al viernes 19-septiembre-2008.
Así, el día lunes 1-septiembre el equipo se junta oficialmente por primera vez para comenzar con la planificación del proyecto.
El primer día del Sprint se utiliza básicamente para la planificación del Sprint. Este día ocurren 2 reuniones que ya fueron organizadas durante el Sprint #0: son la reunión de Planificación del Sprint, en sus dos partes (Exposición y Resolución).
Velocidad inicial del equipo
Antes de asistir a la reunión de Planificación, el equipo tiene que conocer su velocidad inicial y factor de foco. Como el equipo no tiene historia, utiliza un factor de foco de 70%.
En resumen, se tiene un equipo de 4 desarrolladores, cada uno de los cuales trabajará 15 días ideales. En total suman 60 días ideales. Se reduce este número con el factor de foco: 60 x 0.70 = 42.
Finalmente, la velocidad estimada del equipo para el Sprint que inicia será de 42 puntos.
Leer más: Velocidad del Equipo
Planificación: Exposición de las historias
En la reunión de la mañana el Equipo, el Scrum Master y el Dueño del Producto se juntan para estimar las historias y decidir cuales podrán realizarse durante el Sprint. Esta primera parte de la reunión de planificación se conoce con el nombre de &quot;Exposición&quot;.
Es importante destacar que la reunión es llevada adelante por el Scrum Master, el cual tiene que asegurarse que la reunión no divague en temas que no afectan al Sprint y tiene que poder cerrar la reunión con las historias priorizadas y estimadas. Además, sólo se planifica el Sprint que está iniciando.
Creación de historias
El Dueño del Producto presenta las historias de usuario, las cuales se escriben con títulos que el equipo comprenda en los post-it amarillos grandes. Estos post-it se pegan en la mesa para que todos los vean. Cada post-it contiene 3 datos:
Nombre de la historia
Importancia
Estimación
Validación
El nombre de la historia es una muy breve frase o título que describe a la historia (por ejemplo, &quot;exportación de saldos&quot;, &quot;alta de usuario&quot;, &quot;modificación de dirección de facturación&quot;, etc.).
La importancia es un número positivo; mientras más grande el número más importante la historia (y deberá terminarse antes que historias de menor importancia). La importancia la indica el Dueño del Producto.
La estimación en principio se deja en blanco, ya que será completada más adelante (pero dentro de la misma reunión).
La validación será la forma que el Dueño del Producto dará por aceptada la historia en la reunión de Revisión (Demo del Producto).
Así, luego de la exposición del Dueño del Producto, se tiene cierto número de historias pegadas sobre la mesa, ordenadas por importancia.
El Equipo además puede agregar historias propias, generalmente técnicas, que considera necesarias para la ejecución del proyecto (por ejemplo, la creación de un repositorio de código).
Leer más: Exposición de Historias
Estimación de las historias
El Equipo y el Scrum Master son quienes estiman las historias. El Dueño del Producto está presente durante la estimación, para responder cualquier duda que pueda surgir, pero no estima ni opina sobre la estimación.
La estimación se realiza utilizando Planificación de Poker, y es guiada por el Scrum Master. Para la estimación, cada miembro estima en días ideales de trabajo.
El equipo sigue estimando tareas hasta un número mayor al de su capacidad (que es de 42 puntos). De esta manera, si durante el Sprint llega a terminar antes puede seguir tomando historias, y al estar estimadas luego se pueden tener en cuenta para el Factor de Foco del próximo Sprint.
Leer más: Estimación de Historias
Historias para el Sprint: el compromiso
Teniendo las historias estimadas, el equipo seleccionará por orden de importancia una cantidad de historias cuya estimación no supere los 42 puntos.
Estas historias seleccionadas serán las que conformarán el Backlog del Sprint, y es el compromiso que asume el Equipo frente al Dueño del Producto. Estas historias se completarán durante el Sprint, y serán las demostradas el último día durante la Revisión del Sprint.
Leer más: Compromiso
Para finalizar con esta reunión, se define:
Objetivo del Sprint
Reunión Diaria, horario y lugar
Reunión de Revisión, hora y lugar
Gráfico Burndown
Leer más: Fin de la Reunión de Planificación (Exposición)Planificación: Resolución de las tareas
En la reunión de la tarde el Equipo y el Scrum Master se vuelven a juntar para crear las tareas de las historias, y estimarlas. Esta segunda parte de la reunión de planificación se conoce con el nombre de &quot;Resolución&quot;.
En esta reunión el equipo toma cada una de las historias del Backlog del Sprint (las comprometidas) y crea las tareas que son necesario resolver para terminar con la historia. Cada tarea luego es estimada en días ideales con Planificación de Póker; cada tarea no puede tener más de 4 días ideales (de ser mayor, debe ser dividida).
Creación del tablero del Sprint
Finalizada esta reunión el equipo cuenta con toda la información necesaria para armar su tablero para el Sprint. En un afiche grande se vuelcan todas las historias y sus respectivas tareas, información general del Sprint y el gráfico de Burndown.
Este gráfico se actualiza diariamente durante la reunión diaria de Scrum, que empezará desde el día 2.
Día 2: el primer Scrum
Al comenzar el día, los desarrolladores eligen las tareas que van a realizar, tomandolas libremente, por orden de importancia, del grupo de tareas Pendientes. Cada desarrollador elige la tarea, nadie se la asigna.
Al tomar una tarea del afiche del Sprint, el desarrollador escribe su nombre en la nota adhesiva, la pasa a la columna de &quot;Asignada&quot; y comienza el trabajo en la misma.
Todos los días a las 10hs el equipo se junta frente al afiche con la información del Sprint para realizar la Reunión Diaria de Scrum.
Esta reunión ocurrirá todos los días hasta terminar el Sprint; aquí el equipo rápidamente hará un repaso de su situación y del esfuerzo restante para finalizar el Sprint. Cada integrante cuenta cuántos días le falta para finalizar la tarea que tiene asignada: tacha el valor anterior en la estimación de la tarea, y escribe la nueva estimación.
El Scrum Master lidera la reunión, y debe asegurarse que no divague en otros temas; de hecho, la reunión de Scrum diario no debe durar más de 15 minutos. Durante el Scrum Diario no se resuelven problemas, tan sólo es un punto de encuentro para que todo el equipo informe su estado al resto y puedan sincronizar sus actividades.
Finalizada la reunión, el Scrum Master puede actualizar el gráfico Burndown. Para esto debe contar la cantidad de esfuerzo restante: la suma de todas las estimaciones de tareas pendientes y asignadas.
Día 4: surge un impedimento
Durante el desarrollo el equipo irá detectando situaciones que, de no ser resueltas, impedierán que puedan seguir avanzando con el sprint. Estos problemas se los conoce por el nombre de Impedimentos.
El Scrum Master lleva una Lista de Impedimentos con notas adhesivas en el afiche del Sprint.
Así, el día 4 del desarollo durante el Scrum Diario un desarrollador informa que para resolver la tarea que planeaba hacer necesita tener disponible un servicio remoto de morosidad de clientes que no está funcionando. El desarrollador entonces deja pendiente la tarea y sigue avanzando con otra.
El Scrum Master registra este Impedimento y lo asienta en la Lista de Impedimentos.
El Scrum Master será el encargado de resolver cuanto antes este problema para que el equipo pueda completar la historia.
El resto del equipo debe continuar con el desarrollo de las demás historias; es responsabilidad del Scrum Master el gestionar los impedimentos que surgen y liberar al equipo de cualquier traba o problema que les impida desarrollar software.Seguimiento del impedimento
Durante cada Scrum Diario el Scrum Master informará el estado del impedimento y de no haber sido resuelto irá asentando el paso de los días en el registro del impedimento.
Una vez resuelto, el Scrum Master podrá tachar el impedimento de la lista. El Impedimento seguirá pegado en el afiche, y servirá para analizar al finalizar el Sprint.
Un impedimento que tarda mucho en resolverse seguramente producirá un impacto negativo en los tiempos de una historia. Lo mismo ocurrirá si un Sprint sufre un número excesivo de impedimentos.
En ambos casos es problable que el equipo no logre cumplir con el compromiso asumido, y contará con un detalle visible de las dificultades que tuvieron.
2 días y sigue el impedimento sin resolverse
5 días sin resolución
Luego de 7 días el impedimento quedó solucionado
No es una conclusión en sí misma, pero es algo que se ha de tener muy en cuenta!!!