4. Predictivo vs Adaptativo
• Predictiva: consiste en resolver todas las incertidumbres
antes de empezar el proyecto o en la fase inicial de éste. El
resultado de esto es una «hoja de ruta» (también se conoce
como contrato) que marca la construcción del producto
objeto del proyecto
• Adaptativa: consiste en proporcionar una primea versión
del producto del proyecto útil aunque inacabada, e ir
perfeccionando el producto en sucesivas iteraciones, hasta
llegar a un nivel de funcionalidad tal que permita dar por
finalizado el proyecto
5. Organización "improvisación"
Las personas por encima de los procedimientos y las herramientas
Organización "disciplinada"
Las personas se coordinan mediante procedimientos y herramientas
Síntesis
Los procedimientos evolucionan y se especializan. Las personas no solo "ejecutan"
sinó que aportan y cuidan el conocimiento de la organización
Organización ágil
Se aplican métodos ágiles en
organizaciones con voluntad de
evolucionar sus procedimientos de
trabajo
Campana de Gauss de les organitzacions àgils?
•Improvisación
6. Que es SCRUM?
Ikujiro Nonaka e Hirotaka Takeuchi
Empresas de manufactura y equipos
The New New Product Development Game, (1986)
Ken Schwaber y Jeff Sutherland
Adaptación a necesidades de proyectos TIC (1995)
7. SCRUM
Definido por Hirotaka Takeuchi y
Ikujiro Nonaka en 1986 como
aproximación al desarrollo de
productos de forma general, haciendo
énfasis en la rapidez y la flexibilidad
Fomento de equipos con talento, autoorganitzados y motivados
The New New Product Development Game (1986)
8. Origen de la palabra “SCRUM”
Hirotaka Takeuchi y Ikujiro Nonaka comparan el trabajo en
equipo en empresas de manufactura con la formación de los
jugadores de rugby. Y en su análisis proponen una técnica que
fomenta la motivación, la autoorganización y el talento
Que es una melé?
• Un grupo de personas que
trabajan en equipo
• Están autoorganizados
• Están enfocados
• Tienen coraje
9. Agile Manifesto
Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas
Manifiesto para el desarrollo ágil de software
Estamos poniendo al descubierto mejores formas de desarrollar software
Haciendolo y ayudando a otros a hacerlo. Mediante este trabajo hemos acabado
valorando:
Individuos e interacciones per encima de procesos y herramientas
Software que funciona por encima de documentación exhaustiva
Colaboración con el cliente por encima de negociación de contratos
Respuesta al cambio por encima de ceñirse a una planificación
Es decir, aunque elementos de la derecha tienen valor,
nosotros valoramos mas los de la izquierda.
11. Agile Manifesto
Individuos e interacciones por
encima de procesos y herramientas
Comunicación
La comunicación efectiva es más
importante que los procesos,
metodologias, pautas, herramientas….
13. Agile Manifesto
Software que funciona por
encima de documentación exhaustiva
Resultados
Los resultados son lo que hace que las
empresas funcionen, y no el proceso, (sin
menosprecio a su utilidad)
15. Agile Manifesto
Colaboración con el cliente por
encima de negociación de contratos
Entendimiento
Para que un proyecto llegue a buen fin es mas
importante una colaboración estrecha que
garantice resultados que un contrato
17. Agile Manifesto
Respuesta al cambio por encima
de ceñirse a una planificación
Adaptación
La adaptación es la clave de la respuesta
ante nuevas necesidades y cambios
19. Agile Manifesto
Robert Cecil Martin
EEUU, 1952
Ingeniero de software
Muy especializado en técnicas ágiles de
programación, UML y patrones de diseño
20. Agile Manifesto
Jim Highsmith
EEUU, 1945
Especialidad en metodologías de desarrollo
de software
Creador de ASD (1999): Adaptive Software
Development, (Jim Highsmith I Sam Bayer)
Creador de un modelo en contraposición al
proceso tradicional en cascada, basado en
la colaboración
21. Agile Manifesto
Kent Beck
EEUU, 1961
Ingeniero de software
Tarjetas CRC
Pruebas Unitarias jUnit
Creador de eXtreme Porgramming, (XP) y
de Test-Driven Development (TDD)
22. XP Programming
XP es una de las técnicas de programación
ágil mas conocidas y mas maltratadas de
todos los tiempos
En esencia transmite los mismos principios
que SCRUM:
- Simplicidad
- Comunicación
- Realimentación
- Coraje
- Respeto
SCRUM = Gestión
XP = Buenas prácticas en el
desarrollo
Normas del XP Programming:
- Desarrollo iterativo e incremental
- Pruebas unitarias continuas
- Programació en parejas
- Integración del equipo con el cliente
- Corrección de todos los errores SIEMPRE
- Refactorización de código SIEMPRE
- Propiedad del código compartida
- Simplicidad del código
23. Agile Manifesto
Ken Shwaber i Jeff Sutherland
Ken Shwaber: EEUU, 1945
Jeff Sutherland: EEUU, ????
Desarrolladores de software
Adaptación de SCRUM y principios ágiles
(1995) de la versión original (1986)
25. Principios de SCRUM
• Satisfacción del cliente
• Receptividad ante el cambio de requerimientos
• Trabajo enfocado al producto o servicio
• Desarrollo sostenible
• Cooperación diaria y abierta entre negocio y desarrolladores
• Comunicación directa persona a persona
• Individuos motivados frente individuos dirigidos
• Orientación a la excelencia
• Simplicidad
• Equipos auto-organizados
• Adaptabilidad
26. Principios de SCRUM
Satisfacción del cliente
El objetivo último es la satisfacción del cliente. El cliente ha de obtener lo que
desea y ha de sentir que el producto que le proporcionamos es útil
27. Principios de SCRUM
Receptividad ante el cambio de
requerimientos
Los proyectos no son estáticos. Cambian cada día. Nuestro trabajo diario ha de
dar espacio a asumir este hecho
28. Principios de SCRUM
Trabajo enfocado al producto o servicio
La finalidad es la creación de un producte útil, por encima del método utilizado
30. Principios de SCRUM
Cooperación diaria y abierta entre negocio y
desarrolladores
Todos los participantes en la creación del producto han de estar en contacto sin
trabas. La información ha de fluir
31. Principios de SCRUM
Comunicación directa persona a persona
La comunicación cara a cara por encima de otros medios de comunicación. La
comunicación cara a cara, si hay compromiso por todas las partes, favorece la
adopción de responsabilidades
32. Principios de SCRUM
Individuos motivados frente a individuos
dirigidos
Los participantes en la creación del producto han de sentirse parte de un equipo,
y han de sentirse cómodos en su trabajo
33. Principios de SCRUM
Orientación a la excelencia
El objetivo no es crear producto “porque si”. El objetivo es crear producto
incremental que mejora en calidad cada día
34. Principios de SCRUM
Simplicidad
Hacer sólo lo que es necesario. No reinventar la rueda. No adalantarse a posibles
necesidades que no han sido solicitadas. Si se detecta una necesidad útil no
solicitada es necesario comunicarlo antes de tomar la decisión unilateral de
construirla
35. Principios de SCRUM
Equipos auto-organizados
El equipo es capaz de hacer el trabajo que se le pide. Les personas
individualmente a lo mejor no, pero el trabajo es del equipo, no de las personas.
El equipo se organiza de forma que pueda asumir todos los aspectos que
comporta ejecutar el trabajo
36. Principios de SCRUM
Adaptabilidad
Los proyectos cambian. Es necesario adaptarse a este cambio y hacer propuestas
que adapten el proyecto a la nueva situación. La adaptabilidad sólo es posible si el
equipo es adaptable
38. Valores de SCRUM
Compromiso, (commitment): Para trabajar en equipo es necesario un alto grado
de compromiso
Enfoque, (focus): Dividir el problema en partes mas pequeñas que nos permitan
concentrarnos en la resolución de un único problema asumible para el equipo.
Organización abierta, (Openness): De forma continua expresemos con el equipo
como nos encontramos y que estamos haciendo para trabajar en equipo.
Aprendemos de los demás. Pedimos ayuda. Ofrecemos ayuda.
Respeto: Con el compromiso y el trabajo en equipo llegamos a respetar nuestro
trabajo y el trabajo de los demás
Coraje: El trabajo en equipo y el respeto nos da el que necesitamos para afrontar
los retos de proyectos complejos e inciertos
39. Los SCRUM no ...
1. Aplicar SCRUM no es prescindir de la documentación (doc
profesional, enfocada a esquema, modelo e iterativa)
2. Aplicar SCRUM no significa prescindir de definir el alcance
antes de iniciar el proyecto
3. Aplicar SCRUM no significa prescindir de las
comunicaciones formales, (siguen siendo útiles actos y
documentación de acuerdos)
4. Adaptarse al cambio no significa resistirse al cambio con
procedimientos o con herramientas
5. Colaborar con el cliente no es “si a todo”
40. SCRUM no es una
metodología
Es un marco de trabajo (framework)
Para poder decir que haces SCRUM, como mínimo has de cumplir:
(Transparencia, Inspección, adaptación y Mejora continua) + (Daily Meeting, Time Box, Sprint)
44. Proyecto
• Acotado en el tiempo Datos, objetivos y decisiones
• Controlado en recursos No sólo los económicos
• Definido en el alcance Objetivos claros
46. SCRUM no da una definición
de Proyecto
Por encima del “plan” está el producto
47. SCRUM está basado en la teoría
del control de procesos empíricos
Wikipèdia: El empirismo es una teoría filosófica que enfatiza el papel de la experiencia, ligada a
la percepción sensorial, en la formación del conocimiento
48. En que se caracteriza el Control de
procesos empíricos?
3 pilares que definen el empirismo:
• Transparencia
• Inspección
• Adaptación
+ concepto de Mejora continua
49. La información “ha de fluir”.
Se ha de hablar “el mismo idioma”
Transparencia
3 pilars
Los aspectos significativos del proceso han de ser conocidos por todos los participantes.
Esto requiere que estos aspectos han de estar definidos mediante un estándar común, de
forma que todos tengan la misma percepción de las características de cada aspecto. (por
ejemplo: definición de “acabado”)
50. (también del proceso mismo)
Inspección
3 pilars
Todo proceso persigue un objetivo. Para la consecución de este objetivo es necesario que
los participantes en el proceso evalúen de forma continua sus resultados y el proceso
mismo, para detectar posibles desviaciones del objetivo lo mas pronto posible
Proyecto Objetivos
Evaluación
continua
Desviaciones
Proyecto = Cazar desviaciones
51. Que hacemos cuando detectamos una desviación? Nos adaptamos
Adaptarse es:
1. Crear un plan para corregir la desviación
2. Cambiar los objetivos afectados
Adaptación
3 pilares
Cuando se detecta una desviación, la respuesta a esta desviación ha de ser la adaptación,
es decir, la adopción de acciones o planes que, o bien ayuden a corregir la desviación, o
bien reconfiguren el objetivo
65. Artefactos SCRUM
• Sprint Backlog
Lista de User Stories del Sprint
Se puede tocar?
Divisible en tareas?
Las tareas estimadas en que?
Responsable: DT y el SM
66. Artefactos SCRUM
• Impedimentos, incidencias y
bloqueos
Lista de problemas, que se han de registrar y que
afectan a la ejecución de una tarea y, por tanto, del
sprint
67. Artefactos SCRUM
• Impedimentos, incidencias y bloqueos
• Impediment Backlog (proceso): Lista de problemas, que sirven como registro para
que el Scrum Master pueda buscar soluciones
• Incidence Backlog (tareas): La Incidence Backlog es una lista de problemas
detectados a nivel de tarea para un Sprint. Cualquier cambio no previsto sobre una
tarea se anota en esta lista, para ser tratada en la reunión de Sprint Retrospective.
• Parking Backlog (bloqueos): El Parking Backlog es la lista de tareas que se
encuentran “bloqueadas” en un Sprint. Una tarea puede estar bloqueada porqué se
ha detectado algún problema que impide acabarla, o bien porqué se está a la espera
de un resultado intermedio, etc.
68. Artefactos SCRUM
• Impediment backlog
Problemas que se caracterizan por la “sorpresa” y
requerieren adaptación
Quien informa de los problemas?
Ejemplos?
69. Artefactos SCRUM
• Incidence Backlog
Se caracterizan por representar un “retraso” y que
puede resolverse por el equipo
Quien informa?
Ejemplos?
70. Artefactos SCRUM
• Parking Backlog
Se caracterizan por un “bloqueo” sobre una tarea y
que ha de resolverse en el tiempo del sprint
Quien informa?
Ejemplos?
74. Enlace entre el cliente y el equipo de desarrollo.
Enfocado a negocio o a TIC.
• Da soporte para resolver cualquier cuestión funcional o impedimento
• Estrategia. Conoce el “negocio”
• Define los objetivos
• Mantiene el Product Backlog
• Negocia el alcance con el cliente
• Define consensuadamente los criterios de aceptación del proyecto y de cada sprint
• Mantiene el presupuesto
Roles - Product Owner
Donde participa:
Lo veremos mas tarde
De que es responsable:
Lo veremos mas tarde
76. Roles - Scrum Master
El Scrum Master NO es el Project Manager.
Es el enlace entre el DT y el PO
• Es un coach/mentor para los componentes del Development Team, (DT)
• Proporciona soporte al DT y resuelve los problemas
• Modera las reuniones de que es responsable
• Reporta, archiva y lleva registro
• Propone, promueve y potencia mejoras sobre el proceso y sobre el Scrum Team
Donde participa:
Lo veremos mas tarde
De que es responsable:
Lo veremos mas tarde
78. Roles
Development Team
Entre 3 y 9 personas, sin contar el PO ni el SM
Todos los componentes del equipo deberían estar en
contacto directo entre ellos y con el SM
• Es flexible
• Está auto-organitzado
• Es multidisciplinar
Donde participa:
Lo veremos mas tarde
De que es responsable:
Lo veremos mas tarde
És un equipo!!! No un grupo de trabajo
81. User Stories
Las User Stories son fichas que explican el
detalle funcional de cada ítem del Product
Backlog
Incluyen información descriptiva
Prioridad
Criterios de aceptación
“Peso” en forma de Story Points
82. User Stories
Definición
Las User Stories han de ser INVEST
- Independent
- Negotiable
- Valuable
- Estimable
- Sized appropiatelly
- Testable
83. Story Points
Un Story Point es la forma de consensuar el
esfuerzo para construir una funcionalidad dada
84. Planning Poker
• Para una história de usuario dada, se expomen sus
características y toda la información necesaria para
poder dar una valoración, (incluyendo los criterios de
aceptación). Una vez hecha la exposición, cada
miembro del equipo la puntúa. El objetivo de éste
método de valoración es doble
1. Consenso
2. Imparcialidad
• Si pero... Que representa en esfuerzo 1 Story Point?
85. Scrum Board
En el Scrum Board se muestra:
• Las User Stories del Sprint: Las User Stories se colocan en orden de prioridad,
(a la parte superior las mas prioritàrias), para que el equipo conozca con un simple
vistazo la importancia de cada tarea.
• Las tareas de cada User Story y su situación
• Las listas de incidencias, impedimentos y Parking Backlog
Las tareas son Post-its que se mueven en el Scrum Board
Cada tarea, (post-it), tiene una estimación inicial y el nombre de la persona que se
responsabiliza en cada momento. Si la estimación varia, se ha de anotar al post-it,yi
si la desviación es grave se ha de registrar una incidencia
86. Scrum Board - KANBAN
El Scrum Board es una variante de KANBAN
El término KANBAN fue empleado por Taiichi Onho (Toyota) para definir un sistema de
visualización de tareas en un escenario de cadena de montaje
La comunidad Scrum (no Scrum oficial) lo ha adaptado para el uso en proyectos TIC
El objetivo de KANBAN es:
- Entregar a tiempo
- Evitar cuellos de botella
- Informar del estado
Operativa con KANBAN
- No existe el concepto de Sprint ni de iteración
- No hay roles
- Limita el WIP por estado de flujo
Que es el WIP?
El WIP es una técnica para limitar el
trabajo concurrente en un estado de
flujo concreto. De esta forma se guía
al equipo de trabajo a resolver los
cuellos de botella en cuanto se
producen
87. Scrum Board – KANBAN – Muda/Mura y Muri
Muda / Mura y Muri son 3 variables que nos ayudan a governar el flujo en un tablero KANBAN.
Muda (Desperdicio):
La muda es la merma de tiempo producto de acciones que no tienen que ver
directamente con el proyecto (por ej: burocrácia), o decisiones que enlentecen el
curso del proyecto (por ej: desarrollos no encargados)
Mura (Discrepáncia):
Tiempos muertos. Debido a factores como:
- Secuencia de ejecución de acciones
- Alto grado de especialización del equipo de desarrollo
Muri (Tensión):
Cuellos de botella. Mitigable mediante la aplicación del WIP a nivel de estado de
flujo
88. Scrum Board
Columnas del tablero:
- To Do, (Pendiente)
- In Process
- Acabado
Quien es responsable: El
Scrum Master controla el
Scrum Board con la
colaboración de todo el DT.
Además, el Scrum Master
puede cambiar el Scrum
Board en tiempo real, (fuera
de las Daily Meeting), para
adaptarse a cambios,
reasignar tareas, atender
peticiones del DT si acaba
tareas antes de hora, etc.
90. Ya tenemos las User Stories y el Scrum Board
Com desacemos las user stories en tareas?
Las tareas son “post-its” que circulan por el Scrum Board.
Son el verdadero “trabajo”
Han de cumplir los criterios de SMART:
- Specific: Describen una acción acotada
- Measurable: Se pueden pesar en horas o jornadas de trabajo
- Achievable: Son realistas. Pueden ejecutarse de la forma descrita
- Relevant: Describen una acción que aporta valor
- Time-boxed: Se pueden acabar en el tiempo comprometido
92. Sprint 0
Preparatoria
Sprint 1
Sprint n
Sprint
planning
2 horas
Retrospectiva
2 horas
Revisión
1 hora
Sprint
5 dias
Reunión diaria
Reunión con el cliente / Refinamiento
Aprovación
Release
Actividades de SCRUM
93. Time Box
Actividad Time Box
Sprint 0 No hay un límite establecido para esta fase. Dependerá del tiempo
disponible para lanzar el proyecto, o las fechas para la entrega de un
prototipo, etc.
Sprint Planning Un máximo de 8h para Sprints de un mes. Siendo proporcional para
Sprints inferiores
Daily meeting En ningún caso mas de 15 minutos
Sprint Review Un máximo de 4h para Sprints de un mes. Siendo proporcional para
Sprints inferiores
Sprint Retrospective Un máximo de 3h para Sprints de un mes. Siendo proporcional para
Sprints inferiores
Grooming Se recomienda un tiempo global de entre el 5% y 10% del Sprint.
95. Actividades de
SCRUM - Sprint Planning
Para que sirve?
1. Para planificar en detalle el Sprint
2. Para recoger la funcionalidad a
desarrollar
3. Para aclarar dudas
4. Para crear las User Stories
5. Para determinar los criterios de
aceptación del Sprint y de cada User
Story
6. Para separar el User Story en tareas
y determinar el esfuerzo de cada
tarea
Que se necesita?
• User Stories valoradas
• Product Backlog detallado
suficientemente
Que pasa después?
• Tareas valoradas
• Daily Meeting
Sprint
planning
RetrospectivaRevisiónSprint
97. Actividades de
SCRUM - Daily Meeting
Para que sirve?
1. Para explicarse
2. Para hacer seguimiento del estado a
nivel de tarea
3. Para determinar que tareas hace
cada persona en ese momento
4. Para resolver dudas
Que se necesita?
• Todos los participantes hablan
• Duración máxima: 15 minutos
• Siempre en el mismo sitio
• Siempre a la misma hora
• Obligatorio para el DT
• Voluntario para el SM
• El PO sólo si se le invita
Sprint
planning
RetrospectivaRevisiónSprint
99. Actividades de
SCRUM - Sprint Review
Para que sirve?
(Parte 1)
1. Para mostrar al PO el
resultado/situación final del Sprint
(Parte 2)
1. Para mostrar al usuario/cliente el
incremento de producto
2. Obtener aceptación
Que se necesita?
• Se ha de explicar al usuario los
objetivos del Sprint
• Incluir siempre algún comentario útil
• Se ha de realizar Demo
Que pasa después?
• Sprint Retrospective
• La aceptación lanza el siguiente Sprint
Sprint
planning
RetrospectivaRevisiónSprint
100. Actividades de
SCRUM - Sprint Retrospective
Sprint
planning
RetrospectivaRevisiónSprint
101. Actividades de
SCRUM - Sprint Retrospective
Pera que sirve?
1. Para debatir entre SM y DT sobre el curso
del Sprint
2. Revisar incidentes y bloqueos
3. Para buscar soluciones
4. Para aplicar la mejora continua
Que se necesita?
• Es la aplicación de la mejora continua
Que pasa después?
• Se intentan aplicar las mejoras acordadas en
el siguiente Sprint
Sprint
planning
RetrospectivaRevisiónSprint
102. Actividades de
SCRUM - Sprint Retrospective
Sprint
planning
RetrospectivaRevisiónSprint
104. Relación entre
Actividades y roles
DT SM PO Stakeholder
Sprint 0 Opcional Sí Sí Opcional
Sprint Planning Sí Sí
En la definición de lo
que se hará
Daily meeting Sí Opcional Sólo si es invitado
Sprint Review Recomendable Sí Sí
Sólo a la 2ª parte de
la reunión, donde se
hace demo y se pide
aceptación
Sprint Retrospective Sí Sí Sólo si es invitado
Grooming Opcional Sí Sí Opcional
105. Donde participa:
- Sprint 0
- Sprint Planning (definición de los objetivos)
- Sprint Review
- Sprint Retrospective si se le invita
- Grooming que pida o donde sea invitado
De que es responsable:
- Del Product Backlog
- Del gráfico Release Burn-down
Recomendaciones/Restriccions: El PO no puede
ser a la vez el Scrum Master.
Enlace entre el cliente y el equipo de desarrollo
Enfocado a negocio o a TIC.
• Da soporte para resolver cualquier cuestión funcional o impedimento
• Estrategia. Conoce el “negocio”
• Define los objectivos
• Mantiene el Product Backlog
• Negocia el alcance con el cliente
• Define consensuadamente los criterios de aceptación del proyecto y de cada sprint
• Mantienne el presuposto
Roles - Product Owner
106. Roles - Scrum Master
El Scrum Master NO es el Project Manager.
Es el enlace entre el DT y el PO
• Es un coach/mentor para los componentes del Development Team, (DT)
• Proporciona soporte al DT y resuelve los problemas
• Reporta, archiva y lleva registro
• Propone, promueve y potencia mejoras sobre el proceso y sobre el Scrum Team
Donde participa:
- Sprint 0
- Sprint Planning
- Opcionalmente en los Daily Meetings
- Sprint Review y Sprint Retrospective
- A las reuniones de Grooming que pida y a las que
sea invitado
De que es responsable:
- Del Sprint Backlog junto con el DT
- Del Scrum Board junto con el DT
- Del gráfico Sprint Burn-down
- Del Incident Backlog y del Impediment Backlog
- De coordinar la reunión de Scrum Retrospective
107. Roles
Development Team
Entre 3 y 9 personas, sin contar el PO ni el SM
Todos los componentes del equipo deberían estar en
contacto directo entre ellos y con el SM
• Es flexible
• Està auto-organitzado
• Es multidisciplinar
Donde participa:
- Sprint Planning
- Daily Meeting
- Opcionalment al Sprint Review
- Sprint Retrospective
- A las reuniones de grooming
donde sea invitado
De que es responsable:
- Determinar el detalle de cada funcionalidad descrita al Product Backlog, y hacer la
subdivisión en tareas
- Estimación del esfuerzo, en Story Points al Product Backlog, y en horas a cada tarea
- Gestionar el Sprint Backlog
- Proporcionar producto “acabado”. Convenientemente testejado, siguiendo los criterios de
aceptación marcados.
- Ejecutar diariamente el Daily meeting y cumplir sus normas
110. Artefactos SCRUM Release Burn Down
Exemples de desviacions en el Release Burn-down a tenir en compte:
Relea se Burn-down
0
20
40
60
80
100
120
S
p
rin
t
1
S
p
rin
t
2
S
p
rin
t
3
S
p
rin
t
4
S
p
rin
t
5
S
p
rin
t
6
S
p
rin
t
7
Sprints
StoryPoints
L’equip va molt ràpid. Sobren Sprints
Release Burn-down
0
20
40
60
80
100
120
Sprint
1
Sprint
2
Sprint
3
Sprint
4
Sprint
5
Sprint
6
Sprint
7
Sprints
StoryPoints
L’equip va molt lent. Falten Sprints o a l’equio
li passa alguna cosa
111. Artefactos SCRUM Sprint Burn Down
Exemples de desviacions en el Sprint Burn-down a tenir en compte:
Sprint Burn-down
0
20
40
60
80
100
120
Dia 1 Dia 2 Dia 3 Dia 4 Dia 5
Dies
HoresLes tasques assignades al Sprint s’estan
resolent molt ràpidament. L’equip va fer una
estimació “pessimista”. Probablement no s’ha
triat el nombre suficient d’items del Product
Backlog. Caldria afegir-ne més
Sprint Burn-down
0
20
40
60
80
100
120
Dia 1 Dia 2 Dia 3 Dia 4 Dia 5
Dies
Hores
Les tasques s’estan resolent molt lentament.
L’equip va fer una estimació “optimista”. Cal
renegociar el Sprint amb el PO. Cal treure
tasques
El gráfico de Sprint Burn-
down muestra en todo
momento re “trabajo
pendiente”, y permite ver la
velocidad a la que se
resuelven las funcionalidades
comprometidas en el sprint.
Para cada día de iteración el
SM incorpora el total de
horas de tareas en las
diferentes columnas de
trabajo pendiente o en curso
Usualmente el gráfico se actualiza después de llevar a cabo la reunión diária
113. Themes, Epics, User Stories y Tareas
Theme
Corresponde a un gran apartado funcional del proyecto. Un módulo, una sección con valor por si
misma. Susceptible de disponer de su propio Product Backlog (por ej: un módulo de gestión de RRHH)
Epic
Una historia de usuario susceptible de ser dividida (una “superhistòoria”). Describe una necesidad
grande que conforma un submódulo (por ej: el corrector ortográfico de word)
User Story
Una necesidad susceptible de ser construida en el ámbito de un Sprint
Tarea
Las User Stories se subdividen en tareas durante el Sprint Planning. Una tarea es na acción que puede
ser ejecutada por una o pocas personas. Es la unidad mínima para poder asignar trabajo a personas y
hacer seguimiento de la ejecución
114. Datos básicos de una User Story
Nombre
Nombre descriptivo y corto que define la User Story en una frase
Descripción
Pequeña descripción que complementa el nombre. En la forma
Como [rol] quiero [objetivo] para poder [resultado]
Story Points (estimación)
Valoración en esfuerzo
Prioridad
Prioridad (governada por el PO)
Criterios de aceptación
Criterios que es necesario examinar para dar la història por terminada
115. User Stories
Priorización
El PO es el responsable de priorizar
Técnica MoSCoW de priorización, que clasifica las User
Stories en 4 categorias:
• M - MUST HAVE (es necesario)
• S - SHOULD HAVE (es recomendable)
• C - COULD HAVE (podría implementarse)
• W - WON'T HAVE (no lo queremos... quizá en un
futuro)
116. User Stories
Criterios de validación
Son muy importantes en SCRUM
Porqué? Porque ayuda a determinar si se ha
alcanzado el concepto de “acabado” para la
User Story
Como escribir los criterios de validación?
SCENARIO Tenemos un texto en word y queremos pasar el corrector ortográfico
GIVEN Tenemos el texto cargado en Word
AND Lo hemos escrito sin activar el corrector automático
WHEN Ejecutamos el corrector de word
THEN Debería marcar los errores ortográficos
117. User Stories
Cuantas histórias seleccionamos en un Sprint?
Team Velocity
La Team Velocity es la velocidad en la que el equip
resuelve los Sprints, en forma de Story Points
El Scrum Master lleva una estadística de la velocidad y
la refleja en el gráfico de Release Burn-down
Las histórias de un nuevo sprint deberian ser por valor
aproximado del histórico de velocidad del equipo
118. User Stories
Subdividir histórias grandes
Tenemos una história por valor superior a la capacidad. Es
necesario subdividirla. No es lícito en Scrum que una User
Story abarque mas de un Sprint
Posibles estratégias de subdivisión:
- Por reglas de negocio
- Por happy/unhappy flow
- Por parámetros o datos
etc
119. User Stories
Selección de históriea para aportar valor
Premisa de Scrum:
Satisfacción del cliente
“El cliente ha de percibir que siempre le
proporcionamos incrementos útiles”
Hay técnicas para proporcionar al cliente incrementos de producto
que verdaderamente aporten valor. Por ej: Visual Story Mapping
120. Sprint 1
Sprint n
Sprint
planning
2 horas
Retrospectiva
2 horas
Revisión
1 hora
Sprint
Release
La release
La Release es un convenio con el Product Owner,
por el que es posible entregar producto cada
cierto número de Sprints, dependiendo de la
funcionalidad a construïr
121. Otras técnicas de medición
(no sólo de burn-down vive el hombre)
- Medir no és un fin en si mismo
- Medir es costoso
- Medir se puede confundir con
auditar
- Tngamos siempre presente
“Tiempo ideal” y “Tiempo real”
123. Extendiendo SCRUM
A nivel de producto:
1. Un producto te UN ÚNICO Product
Backlog
2. Un producto puede tener diversos PO.
Cada PO ve una “vista” del product
Backlog
3. Un PO puede gestionar diversos SM
4. Un SM responde sólo a un PO para un
producto
5. Un SM puede tener a su cárgo diversos
DT, y tiene UN ÚNICO Sprint Backlog
6. Un DT tiene UN ÚNICO SM
124. Como aplicar SCRUM?
1. [Tienes 3 a 9] + 2?
2. Separar los proyectos. Entender los requerimientos. Conocer el alcance
3. Establecer ciclos, (sprints)
4. Establecer reuniones diarias
5. Hacer partícipe al equipo y fomentar la comunicación
6. Fomentar la transparencia, la inspección y la adaptación
7. Determinar roles y vías de comunicación con el usuario
Como se si aplico SCRUM?
http://scrumbutt.me/
Se puede decir que haces
SCRUM cuando, como mínimo :
(Transparencia, Inspección,
adaptación y Mejora continua)
+ (Daily Meeting, Time Box,
Sprint)
125. Bibliografia
1. SCRUM y XP desde las trincheras
http://www.proyectalis.com/wp-
content/uploads/2008/02/scrum-y-xp-desde-las-trincheras.pdf
2. SCRUM guide de Scrum.org
http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-
CAT.pdf#zoom=100
3. Kanban vs Scrum
https://www.crisp.se/file-uploads/Kanban-vs-Scrum.pdf
3. Implantar SCRUM amb èxit
Editorial UOC
CAT: http://www.editorialuoc.cat/implantar-scrum-amb-exit
ES: http://www.editorialuoc.cat/implantar-scrum-con-exito
El curs no pot ser un monòleg. Es requereix la participació
Es farà referència constant al llibre. El llibre ha de ser la referència
Alguns llibres:
Com implantar SCRUM amb èxit
SCRUM des de les trinxeres
SCRUM només és útil (funciona) si es te la voluntat de ser àgils. Sobre tot l’equip, però també l’organització
SCRUM en solitari no funciona
SCRUM només “amb certificat” no funciona
- Presentació dels alumnes
a. Quin és el seu rol actual
b. Gestió de projectes? De quin tipus?
Algun treball real que pugui utilitzar-se com a pràctica?
Un “aspecte àgil” no significa aplicar tota una metodologia
Q: Sabeu que és SCRUM?
Q: Coneixeu alguna altra tècnica àgil, (XP, TDD)
Q: Apliquen alguna metodologia predictiva? PMP? PRINCE2?
Q: Apliquen Mètrica com a base documental? O una variant pròpia?
Mostrar exemple propi
Teniu algun exemple que es pugui mostrar?
Q: Que expliquin fins a quin punt han pogut implantar alguna acció àgil, de SCRUM o una altra iniciativa?
Q: Quins problemes heu tingut?
Q: A que doneu importància en un projecte? A la comunicació externa? A la interna? A les proves? A l'acceptació?
Q: I a la documentació? O al seguiment?
Que és “Agilitat”?
(p9)
La gestión de proyectos ágil no se formula sobre la necesidad de anticipación, sino sobre la de adaptación continua.
Q: Que en penseu? Creieu que hi ha alguna altra?
La “Improvisativa”
Predictiu i Adaptatiu
• Predictiva:
Ho se tot sobre el cost, temps i abast. Decideixo llavors si el projecte tira endavant o no
En l’execució del projecte “defenso a mort” les tres variables
• Adaptativa:
No ho se tot de les tres variables. Però si se suficient per començar.
Això és especialmente cert amb l’abast
Ser “improvisat” no vol dir que es faci res. No fer res és negligencia
Vol dir que no es pot quantificar
Molt sovint el “canvi” no ve de l’organització, sinó de la capa de tècnics
Des de una organització “improvisada” s’apliquen accions per tenir “disciplina”
Q: Que és la “disciplina” en aquest escenari?
Que tothom faci les coses amb un conjunt de regles comú
El 2n pasa per “medir”. Només podem medir si proporcionem resultats en un format concret
Això és “síntesi”
En aquesta fase l’organització analitza les formes de millorar el procés
El 3r pas és l’agilitat
L’organització ja no governa el procés de millora constant, sinó que ho fan els treballadors
Q: En quin escenari creieu que es trova la vostra organització?
(p12 i p13)
Este modelo fue identificado y definido por Ikujiro Nonaka e Hirotaka Takeuchi a principios de los 80, al analizar cómo desarrollaban los nuevos productos las principales empresas de manufactura tecnológica: Fuji-Xerox, Canon, Honda, Nec, Epson, Brother, 3M y Hewlett-Packard (Nonaka & Takeuchi, The New New Product Development Game, 1986)
“de forma general” : Es a dir: No necessàriament TIC
The New New Product Development Game (1986) arriba a la conclusió que la clau per a millorar l’eficiència és el foment del:
Talent
Autoporganització
Motivació
La definició de la melé conformen els valors bàsics de Scrum que veurem més endavant
Q: Algú sap jugar al Rugby?
Agilemanifesto.org
XP Programming i TDD: Kent Beck
TDD: James Grenning
Ken Schwaber i Jeff Sutherland: SCRUM
UML i Patrons: Robert Cecil Martin i Martin Fowler
No és necessària cap metodologia quan es treballa “face to face”
Per això SCRUM no és útil per a equips molt petits
La utilitat del procés la hem vist a la campana de Gauss
Per sobre de la col·laboració, l’important és arribar a una entesa
Potser és la premissa o “llei” mes important del manifesto ADAPTACIÓ
ASD – Adaptació continua. Tolerància als canvis. Desenvolupament incremental
Cicles de Especulació Col·laboració Aprenentatge
Que li va fallar? No va aprofundir en els rols i les eines (artefactes)
Un crack!!
Si mireu les normes del XP Programming notareu que està enfocat al desenvolupament
Q: Que en penseu de XP?
Q: Creieu que es pot combinar amb SCRUM?
Evolucionen el mètode de Ikujiro Nonaka e Hirotaka Takeuchi dels anys 80, i l’adapten al mon dels projectes TIC
(p34)
Q: Que en penseu d’aquest principi?
Q: Quant de temps porteu treballant en projectes?
Q: Podríeu afirmar que els requeriments sempre canvien?
La finalitat no son les reunions de seguiment o la documentació
Ser capaços de ser constants en la construcció
Tant en temps com en recursos
SPRINTS!!!
Tenir contacte amb els “usuaris clau” és clau!!
Q: Esteu d’acord amb el gràfic?
Usuaris clau (En SCRUM és el Product Owner)
/ \
/ \
Client (direcció) Usuaris
Q: Que en penseu de l’ús de l’email?
Abús de l’email Eludir responsabilitats
Les comunicacions formals segueixen sent necessàries
La motivació mou el mon, i fa possibles les coses que semblen impossibles
La motivació de l’equip s’assoleix amb la satisfacció de l’equip. SCRUM persegueix la satisfacció de tothom, i també de l’equip
Q: Que en penseu de la motivació de l’equip?
És necessària? La promocioneu?
La Qualitat és una variable a tenir en compte
T
C Q A
Els processos de refactorització i perfeccionament (XP) haurien d’estar contemplats en els cicles de SCRUM
Q: Que en penseu de la qualitat en els vostres projectes?
Això és bàsic en XP
“Comunicar-la” Amb Grooming Adaptació al canvi
Q: Afavoriu l’auto-organització en els vostres projectes?
- Autoorganització <> Jerarquies rígides
El + important
Porcs i Gallines
(diferència entre compromís i implicació)
Un porc i una gallina passegen pel parc. La gallina li proposa fer un projecte junts, i li explica la idea de muntar un restaurant amb nom “Ous amb pernil”
El porc li diu que sentint-ho molt no pot participar amb la gallina en aquest projecte, perquè ell estaria compromès, mentre que la gallina únicament estaria implicada
(p31 i 32)
Campana de Gauss
Direcció del projecte
Posada en marxa del projecte = Definició / Bussiness case
Inici del projecte = Planificació
Gestió dels límits de la fase = Planificació de següents fases i plans d’excepció
Control de la fase = Seguiment
Gestió de lliurament de productes = Construcció
Tancament del projecte = Avaluació
-------------------------------------
Que te de bo un mètode predictiu?
Els registres
El catàleg de lliçons apreses
La documentació
Que te de dolent un mètode predictiu?
La rigidesa
La separació estànca als “3 poders”
El concepte d’encàrreg de “caixa negra”
Complicat
Iincert
Canviant
Acotat en el temps: Ha de tenir un inici i una fi. Arribats a aquesta fi s’han d’haver assolit els objectius planificats, o bé haver cancel·lat el projecte
Controlat en el cost: Determinant els recursos, tant humans, com materials i econòmics necessaris
Definit en l’abast: Amb objectius clars. Definint els aspectes fonamentals del producte o servei
Direcció del projecte
Posada en marxa del projecte = Definició / Bussiness case
Inici del projecte = Planificació
Gestió dels límits de la fase = Planificació de següents fases i plans d’excepció
Control de la fase = Seguiment
Gestió de lliurament de productes = Construcció
Tancament del projecte = Avaluació
-------------------------------------
Que te de bo un mètode predictiu?
Els registres
El catàleg de lliçons apreses
La documentació
Que te de dolent un mètode predictiu?
La rigidesa
La separació estànca als “3 poders”
El concepte d’encàrreg de “caixa negra”
Es valora més l’experiència que el “coneixement teòric”
Amb límits!!!
Per molt que sàpigues conduir un autobús, no el conduiràs si no estàs “certificat”, oi?
Això son pilars de comportament
És una actitud per enfrontar-se a la feina en u marc de treball SCRUM
Com dona SCRUM resposta a la Trasparència?
Amb totes les accions de foment de comunicació innterna en l’equip: TOT l’equip ha de conèixer TOTS els detalls del projecte
Amb l’Sprint Planning en col·laboració directa amb l’usuari
Amb l’Sprint Review per enseyar a tots els interessats que s’ha fet
Concepte de “Acabat” Tot provat? Eines de testing En PRE amb versió actual de PRO i provat en regressió
Tant important com provar que la nova funcionalitat funcioni és que tot l’anterior segueixi funcionant com s’espera
Objectius poden ser funcionalitats
Com dona SCRUM resposta a la Inspecció?
Els cicles de Sprint afavoreixen la inspecció
El Sprint Retrospective serveix per a que l’equip millori periòdicament el “qué” fa i “com” ho fa
Com dona SCRUM resposta a l’adaptació continua?
Els cicles de Sprint afavoreixen l’adaptació. Cada cicle “decidim” que fem segons un Product Backlog prioritzat
--------------------------------------------------------
Quan hi ha un canvi no ens hem de posar nerviosos
Adaptació <> “si a tot”
Adaptació és fer un pla que expliqui el canvi
Com reaccionem davant d’un canvi?
Fer un Grooming per obtenir informació del canvi i la motivació
Traslladar a l’equip la petició del canvi
Avaluar l’impacte
Re-valorar les històries d’usuari afectades
Segui amb l’sprint actual normalment
Cap canvi pot impactar sobre l’sprint actual
Cercle de Deming, o PDCA
William Edwards Deming: Estadístic i professor universitari, (1993). Principal difusor del concepte de “Qualitat Total”, que es basa en la satisfacció aplicada tant al producte com a les organitzacions que hi intervenen, de forma que no només es te en compte la creació del producte, sinó les millores en la qualitat de les condicions de treball, les relacions o la formació
Plan Planifica
Do Executa
Check Comprova
Act Adapta’t
Com s’aplica la millora continua amb SCRUM
P16 y p17
Revisión de las iteraciones
Desarrollo incremental
Autoorganización
Colaboración
---------------------------------------------------------------
(*) Resum:
Projecte: 3 variables: Temps, Abast i Cost, i un resultat: Qualitat
Origen de SCRUM:
Ikujiro Nonaka e Hirotaka Takeuchi
Empreses de manufactura i equips
The New New Product Development Game, (1986)
Ken Schwaber y Jeff Sutherland
Adaptació a necessitats de projectes TIC (1995)
Per entendre SCRUM cal entendre els principis de l’Agile Manifesto:
Individus i interaccions per sobre de processos i eines: Comunicació
Programari que funciona per sobre de documentació exhaustiva: Resultats
Col·laboració amb el client per sobre de negociació de contractes: Enteniment
Resposta al canvi per sobre de cenyir-se a una planificació: Adaptació
Pilars de SCRUM i de la Teòria del Control de processos empírics: Transparència, Inspecció i Adaptació
Una actitut: La Millora contínua
Els SCRUM NO...
Valors i principis de SCRUM
Rols + artefactes + activitats
Rols:
PO
Development Team
Scrum Master
Stakeholders
Artefactes:
Product Backlog
Sprint Backlog
Activitats:
Sprint Planning
Daily meeting
Scrum Review
Scrum Retrospective
Cursa de relleus:
- Respecte a les persones que hi treballen... No únicament sobre el procés
Organització jeràrquica:
Per ex: L’arquitecte o analista acostumen a ser figures que intervenen en les fases d’anàlisi i disseny (cascada), i posteriorment desapareixen
Departamental:
És el mateix concepte que l’organització jeràrquica, però a nivell organització empresarial. Per ex: Usuaris que intervenen en la fase de definició (generalment de forma reactiva) i en el desenvolupament desapareixen
Objectius complets:
Mètode cascada
Ojo: El Scrum Board no forma part del stàndard SCRUM, tot i que és àmpliament utilitzat per la comunitat SCRUM
Els Sprints tenen una durada en el temps (a consensuar en l’equip)
Però les activitats tenen una durada fixa que depen directament de la durada decidida per al Sprint
La durada del Sprint determina la durada de totes les activitats
TIMEBOX
(p22)
Característiques del Product Backlog:
Escrites pel client i en l’idioma del client
Detallades segons la necessitat
No substitueix al catàleg de requeriments
No és una llista tancada i inamobible
La prioritza sembre el PO
Col·labora TOT l’equip (no és una feina d’analista)
Només hi pot haver UN. Tot i que es poden crear vistes independents per TEMA
-----------------------------------------------------------
Mostra Product Backlog real
Columnes PB:
* ID
* Nom
* Descripció de la història
Notes
* Prioritat
* Criteris d’acceptació
* Cost en SP
Sprint assignat
ID pare
Ids filles
Nombre de tasques
Estimació inicial tasques
Dureda final tasques
ID bugtraking
Exemples:
la máquina de test se estropea
Ens adonem que una funcionalitat determinada seria més eficient (valuosa/útil) si afegíssim X
Q: Com ho resoldríem?
Fariem un Grooming amb l’usuari i faríem un pla de com atacar-ho
Una tarea prevista en x horas se retrasa
Para resolver una User Story requerimos de mas info del usuario, y este no nos la da
No es pot donar per acabada l’història d’usuari si no s’acaben totes les seves tasques
Després veurem exemples
Columnes bàsiques:
User stories
To Do
In progress
Completed
Altres espais:
Gràfics
*** Criteris d’acceptació del sprint
Pàrquing ??
Incidence
El equipo no se “pelea” con toda la empresa para obtener los requerimientos
(p32)
És flexible, (cada persona pot ocupar diversos rols a l'equip)
Està auto-organitzat: El propi equip defineix els seus rols i el seu mètode de treball
És multidisciplinar: L’equip disposa de les habilitats individuals i col·lectives suficients com per a fer front amb garanties l’execució del projecte
(p33)
Quina és la diferència entre “Grup de treball” i “equip”?
Un grup de treball és un conjunt de persones que realitzen un treball, amb una assignació específica de tasques i responsabilitats, i seguint un procés o pautes d’execució. Son autònoms. La seva feina no depèn de la dels seus companys. Acostuma a regir-se o governar-se mitjançant una jerarquia de responsabilitats. Els operaris d’una cadena son un grup de treball
A en equip s’afegeix la voluntat de col·laboració i la cohesió que provoca una resposta conjunta davant la feina realitzada o els problemes. La jerarquia és mes plana
Criteris de validació:
Son molt importants en SCRUM
Perquè? Perquè és el que ajuda a determinar si s’ha assolit el concepte “d’acabat” per la User Story
Es bo utilitzar un sistema mnemotècnic per a recollir els criteris de validació
(p79 i 80)
Per exemple amb GHERKIN
SCENARIO un cas de validació
GIVEN Una precondició
AND una altra
WHEN Una acció que es duu a terme
AND una altra
THEN Un resultat esperat
Per exemple:
SCENARIO Tenim un text en word i volem passar el corrector ortogràfic
GIVEN Tenim el text carregat a Word
AND L’hem escrit sense activar el corrector automàtic
WHEN Executem el corrector de word
THEN M’hauria de marcar els errors ortogràfics
Prioritzaió:
(p83)
El PO és el responsable de prioritzar
Tècnica MoSCoW de priorització, que classifica les User Stories en 4 categories:
- M - MUST HAVE (es necesario): Se debe tener la funcionalidad implementada en la solución, sino esta fallará o la solución no puede ser considerada un éxito.
S - SHOULD HAVE (es recomendable): Se debería tener la funcionalidad implementada en la solución ya que es una funcionalidad de alta prioridad. La solución es prescindible, no fallará si no existe pero debería de haber causas justificadas para no implementarla.
C - COULD HAVE (podría implementarse): Es deseable, por tanto sería conveniente tener esta funcionalidad implementada en la solución, dependerá de las posibilidades de los tiempos y el presupuesto del proyecto.
W - WON'T HAVE (no lo queremos... quizá en un futuro): Se trata de una funcionalidad de muy baja prioridad o descartada en ese momento, pero que en futuro pueda ser relevante. Posteriormente, cuando cobre mportancia, puede pasar a alguno de los estados anteriores.
(p81) (px113)
Els Story Points no estan bassats únicament en hores d’esforç:
Contempla les hores d’esforç per construir el que es vol
Contempla aspectes d’intermediació, formals i burocràcia, a dins del propi grup i a fora
Contempla altres aspectes que requereixen temps
(p47 i 48)
Perquè Fibonachi?
Una valoració bassada en una escala tancada de valors facilita el consens de les persones que participen en la valoració.
Així una persona que te en ment una valoració de 9, haurà d’escollir entre 8 o 13, tot depenent de si prefereix acceptar cert risc amb 8, o be prefereix una valoració més conservadora amb 13
(*) Pràctica del planning poker
(p60 a 70)
(p71)
(*) Fabricació del tauler
(p79) SMART
(*) Pràctica de planificació d’un projecte amb sprints de 3 setmanes de durada
(p27, 28 i 29)
Una bona pràctica és donar un “nom” al sprint que s’està planificant. I a partir d’aquell moment el sprint es coneixerà per aquell nom. El nom ha de sintetitzar l’objectiu principal d’aquell sprint
(*) Fer pràctica de la reunió de Sprint Planning
(p30)
Aquestes reunions no son una “auditoria” per als tècnics
En aquestes reunions no poden intervenir gent que no sigui del Scrum Team (i el PO o altres persones han de ser convidades)
Format de la reunió:
Cada persona explica el que ha fet des de la reunió anterior
Cada persona explica que farà a partir d’aquest moment
Si algú està tenint algun problema és el moment d’explicar-ho
(*) Fer pràctica del Daily Meeting
(p30 i 31)
Format de la reunió (en la part 2):
L’equip exposa l’objectiu del sprint, les històries d’usuari que estaven previstes en el sprint, i les que s’han aconseguit executar
Es demostra el funcionament d’allò que s’ha fet (l’increment)
S’obre un torn de preguntes i respostes per aclarir dubtes
S’acorda la data per al següent Sprint Review
(*) Fer pràctica de Sprint Review
(p31)
Important: La retrospectiva va a banda que el Sprint Review, i ha de servir exclussivament per millorar el procés
(*) Fer pràctica de Sprint Retrospective
Es que pueden haber reuniones en el ámbito de proyecto en las que el SM no sea invitado?
Pueden haberlas, siempre que este informado y sea el quien delegue en otro componente del DT
Pueden haber grooming donde se decidan aspectos del Sprint actual sin el DT y sin el SM?
No
És flexible, (cada persona pot ocupar diversos rols a l'equip)
Està auto-organitzat: El propi equip defineix els seus rols i el seu mètode de treball
És multidisciplinar: L’equip disposa de les habilitats individuals i col·lectives suficients com per a fer front amb garanties l’execució del projecte
(p75)
El Product Backlog te Epics i User Stories
(p76 i 77)
Prioritzaió:
(p83)
El PO és el responsable de prioritzar
Tècnica MoSCoW de priorització, que classifica les User Stories en 4 categories:
- M - MUST HAVE (es necesario): Se debe tener la funcionalidad implementada en la solución, sino esta fallará o la solución no puede ser considerada un éxito.
S - SHOULD HAVE (es recomendable): Se debería tener la funcionalidad implementada en la solución ya que es una funcionalidad de alta prioridad. La solución es prescindible, no fallará si no existe pero debería de haber causas justificadas para no implementarla.
C - COULD HAVE (podría implementarse): Es deseable, por tanto sería conveniente tener esta funcionalidad implementada en la solución, dependerá de las posibilidades de los tiempos y el presupuesto del proyecto.
W - WON'T HAVE (no lo queremos... quizá en un futuro): Se trata de una funcionalidad de muy baja prioridad o descartada en ese momento, pero que en futuro pueda ser relevante. Posteriormente, cuando cobre mportancia, puede pasar a alguno de los estados anteriores.
Criteris de validació:
Son molt importants en SCRUM
Perquè? Perquè és el que ajuda a determinar si s’ha assolit el concepte “d’acabat” per la User Story
Es bo utilitzar un sistema mnemotècnic per a recollir els criteris de validació
(p79 i 80)
Per exemple amb GHERKIN
SCENARIO un cas de validació
GIVEN Una precondició
AND una altra
WHEN Una acció que es duu a terme
AND una altra
THEN Un resultat esperat
Per exemple:
SCENARIO Tenim un text en word i volem passar el corrector ortogràfic
GIVEN Tenim el text carregat a Word
AND L’hem escrit sense activar el corrector automàtic
WHEN Executem el corrector de word
THEN M’hauria de marcar els errors ortogràfics
(p84, 85 i 86)
Quin és el valor que informa de la capacitat de l’equip per un Sprint?
Team Velocity
(p84)