Introducció al desenvolupament àgil: SCRUM

1. Introducció al
desenvolupament àgil
SCRUM

2. Alguna
experiència àgil?
Heu pogut implantar algun aspecte
àgil en la vostra feina?

3. Que és “agilitat”?
Les necessitats es formulen des de la
perspectiva de l’adaptació, i no de
l’anticipació (predicció)

4. Predictiu vs Adaptatiu
• Predictiva: consisteix en resoldre totes les incerteses abans
de començar el projecte, o en la fase inicial d’aquest. El
resultat d’això es una «full de ruta» (també es coneix com
contracte) que marca la construcció del producte objecte
del projecte
• Adaptativa: consisteix en proporcionar una primea versió
del producte del projecte útil tot i inacabada, i anar
perfeccionant el producte en successives iteracions, fis
arribar a un nivell de funcionalitat tal que permeti donar per
finalitzat el projecte

5. Organització "improvisació"
Les persones per sobre dels procediments i les eines
Organització "disciplinada"
Les persones es coordinen mitjançant procediments i eines
Síntesi
Els procediments evolucionen i s’especialitzen. Les persones no només "executen"
sinó que aporten i cuiden el coneixement de l’organització
Organització àgil​
S’apliquen mètodes àgils en
organitzacions amb voluntat
d’evolucionar els seus
procediments de treball
Campana de Gauss de les organitzacions àgils?
•Improvisació

6. Que és 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)

7. SCRUM
Definit per Hirotaka Takeuchi i Ikujiro
Nonaka al 1986 com a aproximació al
desenvolupament de productes de
forma general, fent èmfasi en la
rapidesa i la flexibilitat
Foment d’equips amb talent, autoorganitzats I motivats
The New New Product Development Game (1986)

8. Origen de la paraula “SCRUM”
Hirotaka Takeuchi i Ikujiro Nonaka comparen el treball en equip
en empreses de manufactura amb la formació dels jugadors de
rugby. I en el seu anàlisi proposen una tècnica que fomenta la
motivació, l’autoorganització i el talent
Que és una melè?
• Un grup de persones que
treballen en equip
• Estan autoorganitzats
• Estan enfocats
• Tenen coratge

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
Manifest per al desenvolupament àgil de programari
Estem posant al descobert millors maneres de desenvolupar programari
fent-ho i ajudant a altres a fer-ho. Mitjançant aquesta feina hem acabat valorant:
Individus i interaccions per sobre de processos i eines
Programari que funciona per sobre de documentació exhaustiva
Col·laboració amb el client per sobre de negociació de contractes
Resposta al canvi per sobre de cenyir-se a una planificació
És a dir, encara que els elements de la dreta tenen valor,
nosaltres valorem més els de l’esquerra.

10. Agile Manifesto
Individus i interaccions per sobre
de procesos i eines

11. Agile Manifesto
Individus i interaccions
per sobre de procesos i eines
Comunicació
La comunicació efectiva és mes important
que els processos, metodologies, pautes,
eines….

12. Agile Manifesto
Software que funciona per sobre
de documentació exhaustiva

13. Agile Manifesto
Software que funciona per sobre
de documentació exhaustiva
Resultats
Els resultats son el que fa que les
empreses funcionin, i no el procés, (sense
menyspreu a la seva utilitat)

14. Agile Manifesto
Col·laboració amb el client per
sobre de negociació de contractes

15. Agile Manifesto
Col·laboració amb el client per
sobre de negociació de contractes
Enteniment
Per a que un projecte arribi a bon port és mes
important una col·laboració estreta que
garanteixi resultats que un contracte

16. Agile Manifesto
Resposta al canvi per sobre de
cenyir-se a una planificació

17. Agile Manifesto
Resposta al canvi per sobre de
cenyir-se a una planificació
Adaptación
L’adaptación és la clau de la resposta
davant noves necessitats i canvis

18. Agile Manifesto
Martin Fowler
UK, 1963
Especialitat en anàlisi i disseny en POO
UML
Patrons de disseny
Metodologies àgils: XP

19. Agile Manifesto
Robert Cecil Martin
EEUU, 1952
Enginyer de programari
Molt especialitzat en tècniques àgils de
programació, UML i patrons de disseny

20. Agile Manifesto
Jim Highsmith
EEUU, 1945
Especialitat en metodologies de desenvolupament de
programari
Creador de ASD (1999): Adaptive Software Development,
(Jim Highsmith I Sam Bayer)
Creació d’un model en contraposició al procés tradicional en
cascada, basat en la col·laboració

21. Agile Manifesto
Kent Beck
EEUU, 1961
Enginyer de programari
Tarjetes CRC
Proves Unitàries jUnit
Creador de eXtreme Porgramming, (XP) i
de Test-Driven Development (TDD)

22. XP Programming
XP es una de les tècniques de programació
àgil mes conegudes i mes mal tractades de
tots els temps
En essència transmet els mateixos principis
que SCRUM:
- Simplicitat
- Comunicació
- Realimentació
- Coratge
- Respecte
SCRUM = Gestió
XP = Bones pràctiques en el
desenvolupament
Normes del XP Programming:
- Desenvolupament iteratiu i incremental
- Proves unitàries continues
- Programació en parelles
- Integració de l’equip amb el client
- Correcció de tots els errors SEMPRE
- Refactorització de codi SEMPRE
- Propietat del codi compartida
- Simplicitat en el codi

23. Agile Manifesto
Ken Shwaber i Jeff Sutherland
Ken Shwaber: EEUU, 1945
Jeff Sutherland: EEUU, ????
Desenvolupadors de programari
Adaptació de SCRUM i principis àgils
(1995) de la versió original (1986)

24. Principis de SCRUM

25. Principis de SCRUM
• Satisfacció del client
• Receptivitat davant el canvi de requeriments
• Treball enfocat al producte o servei
• Desenvolupament sostenible
• Cooperació diària i oberta entre negoci i desenvolupadors
• Comunicació directa persona a persona
• Individus motivats front individus dirigits
• Orientació a l’excel·lència
• Simplicitat
• Equips auto-organitzats
• Adaptabilitat

26. Principis de SCRUM
Satisfacció del client
L’objectiu últim és la satisfacció del client. El client ha d’obtenir el que vol i ha de
sentir que el producte que li donem és útil

27. Principis de SCRUM
Receptivitat davant el canvi de requeriments
Els projectes no son estàtics. Canvien cada dia. La nostra feina diària ha de donar
espai a assumir aquest fet

28. Principis de SCRUM
Treball enfocat al producte o servei
La finalitat és la creació d’un producte útil, per sobre del mètode emprat

29. Principis de SCRUM
Desenvolupament sostenible
Capaç de mantenir un ritme que permeti aplicar SCRUM

30. Principis de SCRUM
Cooperació diària i oberta entre negoci i
desenvolupadors
Tots els participants en la creació del producte han d’estar en contacte sense
traves. La informació ha de fluir

31. Principis de SCRUM
Comunicació directa persona a persona
La comunicació cara a cara per sobre d’altres mitjans de comunicació. La
comunicació cara a cara, si hi ha compromís per totes les parts, afavoreix
l’adopció de responsabilitats

32. Principis de SCRUM
Individus motivats front individus dirigits
Els participants en la creació del producte han de sentir-se part d’un equip, i han
de sentir-se còmodes en la seva feina

33. Principis de SCRUM
Orientació a l’excel·lència
L’objectiu no és crear producte perquè sí. L’objectiu és crear producte incremental
que millora en qualitat cada dia

34. Principis de SCRUM
Simplicitat
Fer només allò que és necessari. No reinventeu la roda. No us adalanteu a
possibles necessitats que no han estat demanades. Si es detecta una necessitat
útil no demanada cal comunicar-la abans de prendre la decisió unilateral de
construir-la

35. Principis de SCRUM
Equips auto-organitzats
L’equip és capaç de fer la feina que es demana. Les persones individualment
potser no, però la feina és de l’equip, no de les persones. L’equip s’organitza de
forma que pugui assumir tots els aspectes que comporta executar la feina

36. Principis de SCRUM
Adaptabilitat
Els projectes canvien. Cal adaptar-se a aquest canvi i fer propostes que adaptin el
projecte a la nova situació. L’adaptabilitat només és possible si l’equip és
adaptable

37. Valors de SCRUM

38. Valors de SCRUM
Compromís, (commitment): Per a treballar en equip és necessari un alt grau de
compromís. (Fàbula del porc i la gallina  Diferència entre compromís i implicació)
Enfocament, (focus): Dividir el problema en parts més petites que ens permetin
concentrar-nos en la resolució d’un únic problema assumible per a l’equip.
Organització oberta, (Openness): De forma continua expressem amb l’equip com
ens trobem i que estem fent per treballar en equip. Aprenem dels demés.
Demanem ajuda. Oferim ajuda.
Respecte: Amb el compromís i el treball en equip arribem a respectar la nostra
feina i la feina dels demés
Coratge: La feina en equip i el respecte ens dona el que necessitem per afrontar els
reptes de projectes complexos i incerts

39. Els SCRUM no ...
1. Aplicar SCRUM no és prescindir de la documentació (doc
professional, enfocada a esquema i iterativa)
2. Aplicar SCRUM no significa prescindir de definir l’abast
abans de començar el projecte
3. Aplicar SCRUM no significa prescindir de les comunicacions
formals, (segueixen sent útils actes i documentació
d’acords)
4. Adaptar-se al canvi no significa resistir-se al canvi amb
procediments o amb eines
5. Col·laborar amb el client no és “si a tot”

40. SCRUM no és una
metodologia
És un marc de treball (framework)
Per dir que fas SCRUM com ha mínim has d’acomplir:
(Transparència, Inspecció, adaptació i Millora continua) + (Daily Meeting, Time Box, Sprint)

42. Projecte

43. Projecte
complex, incert, canviant

44. Projecte
• Acotat en el temps Dates, objectius i decisions
• Controlat en recursos No només econòmics
• Definit en l’abast Objectius clars

45. SCRUM no dona una
definició de Projecte

46. SCRUM no dona una
definició de Projecte
Per sobre del “pla” està el producte

47. SCRUM està basat en la teoria del
control de processos empírics
Wikipèdia: L’empirisme és una teoria filosòfica que emfatitza el paper de l’experiència, lligada a
la percepció sensorial, en la formació del coneixement

48. En que es caracteritza el Control de
processos empírics?
3 pilars que defineixen l’empirisme:
• Transparència
• Inspecció
• Adaptació
+ concepte de Millora continua

49. La informació “ha de fluir”.
S’ha de parlar “el mateix idioma”
Transparència
3 pilars
Els aspectes significatius del procés han de ser coneguts per tothom que hi participa. Això
requereix que aquests aspectes han d'estar definits mitjançant un estàndard comú, de
forma que tothom tingui la mateixa percepció de les característiques de cada aspecte.
(per ex: definició de “acabat”)

50. (també del procés mateix)
Inspecció
3 pilars
Tot procés persegueix un objectiu. Per la consecució d'aquest objectiu és necessari que els
participants en el procés avaluïn de forma continua els seus resultats i el procés mateix,
per tal de detectar possibles desviacions de l'objectiu el mes aviat possible
Projecte Objectius
Avaluació
continua
Desviacions
Projecte = Caçar desviacions

51. Que fem quan detectem una desviació? Ens adaptem
Adaptar-se és:
1. Crear un pla per corregir la desviació
2. Canviar els objectius afectats
Adaptació
3 pilars
Quan es detecta una desviació, la resposta a aquesta desviació ha de ser l'adaptació, es a
dir, l'adopció d'accions o plans que o bé ajudin a corregir la desviació, o bé reconfigurin
l'objectiu

52. SCRUM és
Millora continua (actitud)

53. Organitzacions de SCRUM

54. Scrum.org, (https://www.scrum.org/)
Scrum Alliance, (http://www.scrumalliance.org/)
European Scrum, (http://www.europeanscrum.org/)
ScrumManager, (www.scrummanager.net)

55. Organització de SCRUM

56. Organització de SCRUM

57. Organització de SCRUM
Model tradicional, (cascada) SCRUM
- Predictiu
- Relay race, (cursa de relleus)
- Organitzat jeràrquic
- Departamental
- Objectius complets (cascada)
- Controlat en Temps, pressupost, abast i qualitat
- Adaptatiu
- Holístic . Esport d'equip
- Aproximació Matricial
- Autogestionat
- Lliuraments incrementals. Aportació continua de valor
- Controlat en temps, pressupost, abast, qualitat i
expectatives  El client col·labora

58. Rols, artefactes, activitats
• Persones
• Eines
• Flux

59. Rols, artefactes, activitats
Product Owner
Scrum Master
Stakeholders
Development Team

60. Rols de SCRUM
Presentació dels rols
Scrum Team

61. Rols, artefactes, activitats
Scrum Board GraphsLists
Product Backlog
Sprint Backlog
Incidence Backlog
Impediments Backlog
Release Burn-down
Sprint Burn-down

62. Rols, artefactes, activitats
Sprint 0 o First Sprint
Sprint
Sprint Planning, (planificació del Sprint)
Daily Scrum Meeting, (reunió diària)
Sprint Review, (Revisió del Sprint)
Sprint Retrospective, (Retrospectiva del Sprint)
Refinement / Grooming, (Refinament)

63. Artefactes de SCRUM
Presentació

64. Artefactes SCRUM
• Product Backlog
Llista de User Stories
Només un
Responsable: PO

65. Artefactes SCRUM
• Sprint Backlog
Llista de User Stories del Sprint
Es pot tocar?
Divisible en tasques?
Les tasques estimades en que?
Responsable: DT i el SM

66. Artefactes SCRUM
• Impediments, incidències i
bloquejos
Llista de problemes, que s’han de registrar i que
afecten a l’execució d’una tasca i, per tant, del
sprint

67. Artefactes SCRUM
• Impediments, incidències i bloquejos
• Impediment Backlog (procés): Llista de problemes, que serveix com a registre per
a que el Scrum Master pugui cercar solucions
• Incidence Backlog (tasques): La Incidence Backlog és una llista de problemes
detectats a nivell de tasca per a un Sprint. Qualsevol canvi no previst sobre una
tasca s’anota en aquesta llista, per a ser tractat a la reunió de Sprint Retrospective.
• Parking Backlog (aturades): El Parking Backlog és la llista de tasques que es
troben aturades en un Sprint. Una tasca pot estar aturada perquè s’ha detectat
algun problema que impedeix acabar-la, o bé perquè s’està a l’espera d’un
resultat intermedi, etc.

68. Artefactes SCRUM
• Impediments backlog
Problemes que es caracteritzen per la “sorpresa” i
requereixen adaptació. Acostumen a bloquejar la
tasca durant temps limitat
Qui informa dels problemes?
Exemples?

69. Artefactes SCRUM
• Incidence Backlog
Es caracteritzen per representar un “retard” i que pot
resoldre’s en el si de l’equip
Qui informa?
Exemples?

70. Artefactes SCRUM
• Parking Backlog
Es caracteritzen per un “bloqueig” sobre una tasca i
que ha de resoldre’s en el temps del sprint
Qui informa?
Exemples?

71. Artefactes SCRUM Scrum Board

72. Rols de SCRUM
Presentació dels rols
Scrum Team

73. Rols - Product Owner

74. On participa:
Ho veurem després
De que és responsable:
Ho veurem després
Enllaç entre el client i l'equip de desenvolupament.
Enfocat a negoci o a TIC.
• Dona suport per resoldre qualsevol qüestió funcional o impediment
• Estratègia. Coneix el “negoci”
• Defineix els objectius
• Manté el Product Backlog
• Negocia l’abast amb el client
• Defineix consensuadament els criteris d'acceptació del projecte i de cada sprint
• Manté el pressupost
Rols - Product Owner

75. Rols - Scrum Master

76. Rols - Scrum Master
El Scrum Master NO és el Project Manager.
És l'enllaç entre el DT i el PO
• És un coach/mentor per als components del Development Team, (DT)
• Proporciona suport al DT i resol els problemes
• Modera les reunions de que és responsable
• Reporta, arxiva i porta registre
• Proposa, promou i potencia millores sobre el procés i sobre el Scrum Team
On participa:
Ho veurem després
De que és responsable:
Ho veurem després

77. Rols
Development Team

78. Rols
Development Team
Entre 3 i 9 persones, sense comptar el PO ni el SM
Tots els components de l’equip haurien d’estar en
contacte directe entre ells i amb el SM
• És flexible
• Està auto-organitzat
• És multidisciplinar
On participa:
Ho veurem després
De que és responsable:
Ho veurem després
És un equip!!! No un grup de treball

79. Rols: Direccionalitat de les comunicacions
StakeHolders
Product
Owner
Scrum
Master
Development
team

80. User Stories i Planning Poker

81. User Stories
Les User Stories son fitxes que expliquen el
detall funcional de cada item del Product
Backlog
Inclouen informació descriptiva
Prioritat
Criteris d’acceptació
“Pes” en forma de Story Points

82. User Stories
Definició
Les User Stories han de ser INVEST
- Independent
- Negotiable
- Valuable
- Estimable
- Sized appropiatelly
- Testable

83. Story Points
Un Story Point és la forma de consensuar
l’esforç per a construir una funcionalitat donada

84. Planning Poker
• Per a una història d’usuari donada,
s'exposen les seves característiques i tota la
informació necessària per a poder donar una
valoració, (incloent els criteris d'acceptació).
Un cop feta l'exposició, cada membre de
l'equip la puntua. L'objectiu d’aquest mètode
de valoració és doble
1. Consens
2. Imparcialitat
• Si però... Que representa en esforç 1 Story Point?

85. Scrum Board
Al Scrum Board es mostra:
• Les User Stories del Sprint: Les User Stories es col·loquen en ordre de prioritat,
(a dalt les més prioritàries), per a que l’equip conegui amb un simple cop d’ull la
importància de cada tasca.
• Les tasques de cada User Story i la seva situació
• Les llistes de incidencies, impediments i Parking Backlog
Les tasques son Post-its que es mouen pel Scrum Board
Cada tasca, (post-it), te una estimació inicial i el nom de la persona que es
responsabilitza a cada moment. Si l’estimació varia, s’ha d’anotar al post-it, i si la
desviació es greu s’ha de registrar una incidència

86. Scrum Board - KANBAN
El Scrum Board és una variant de KANBAN
El terme KANBAN va ser emprat por Taiichi Onho (Toyota) para definir un sistema de
visualització de tasques en un escenari de cadena de muntatge
La comunitat Scrum (no Scrum oficial) l’ha adaptat per al ús en projectes TIC
L’objectiu de KANBAN és:
- Lliurar a temps
- Evitar colls d’ampolla
- Informar de l’estat
Operativa amb KANBAN
- No existeix el concepte de Sprint ni de iteració
- No hi ha rols
- Limita el WIP por estat de flux
Que és el WIP?
El WIP és una tècnica per limitar el
treball concurrent en un estat de flux
concret. D’aquesta forma es guia
l’equip de treball a resoldre els colls
d’ampolla tant bon punt es produeixen

87. Scrum Board – KANBAN – Muda/Mura i Muri
Muda / Mura i Muri son 3 variables que ens ajuden a governar el flux en un tauler KANBAN.
Muda (Malbaratament):
La muda es la minva de temps producte d’accions que no tenen a veurr directament
amb el projecte (per ex: burocràcia), o decisions que alenteixen el curs del projecte
(per ex: desenvolupaments no encarregats)
Mura (Discrepància):
Temps morts. Degut a factors com:
- Seqüència d’execució d’accions
- Alt grau d’especialització de l’equip de desenvolupament
Muri (Tensió):
Colls d’ampolla. Mitigable mitjançant l’aplicació del WIP a nivell d’estat de flux

88. Scrum Board
Columnes del tauler:
- To Do, (Pendent)
- In Process
- Acabat
Qui és responsable: El Scrum
Master controla el Scrum
Board amb la col·laboració
de tot el DT. A més, el Scrum
Master pot canviar el Scrum
Board en temps real, (fora
de les Daily Meeting), per
adaptar-se a canvis,
reassignar tasques, atendre
peticions del DT si acaba
tasques abans d’hora, etc.

89. Scrum Board

90. Ja tenim les User Stories i el Scrum Board
Com desfem les user stories en tasques?
Les tasques son “post-its” que circulen pel Scrum Board.
Son la veritable “feina”
Han d’acomplir els criteris de SMART:
- Specific: Descriuen una acció acotada
- Measurable: Es poden pesar en hores o jornades de feina
- Achievable: Son realistes. Poden executar-se de la forma descrita
- Relevant: Descriuen una acció que aporta valor
- Time-boxed: Es pot acabar en el temps compromés

91. Activitats SCRUM
En detall

92. Sprint 0
Preparatòria
Sprint 1
Sprint n
Sprint
planning
2 hores
Retrospectiva
2 hores
Revissió
1 hora 
Sprint
5 dies
Reunió diària
Reunió amb el client / Refinament
 Aprovació
Release
Activitats de SCRUM

93. Time Box
Activitat Time Box
Sprint 0 No hi ha un límit establert per aquesta fase. Dependrà del
temps disponible per llençar el projecte, o les dates per lliurar
un prototip, etc.
Sprint Planning Un màxim de 8h per a Sprints d’un mes. Sent proporcional per
a Sprints inferiors
Daily meeting Mai més de 15 minuts
Sprint Review Un màxim de 4h per a Sprints d’un mes. Sent proporcional per
a Sprints inferiors
Sprint Retrospective Un màxim de 3h per a Sprints d’un mes. Sent proporcional per
a Sprints inferiors
Grooming Es racomana un temps global de entre el 5% i 10% del Sprint.

94. Activitats de
SCRUM - Sprint Planning
Sprint
planning
RetrospectivaRevissióSprint

95. Activitats de
SCRUM - Sprint Planning
Per a que serveix?
1. Per planificar en detall el Sprint
2. Per a recollir la funcionalitat a
desenvolupar
3. Per aclarir dubtes
4. Per a crear les User Stories
5. Per determinar els criteris
d'acceptació del Sprint i de cada
User Story
6. Per separar el User Story en
tasques y determinar l'esforç de
cada tasca.
Que cal tenir en compte?
• User Stories valorades
• Es necessita un Product
Backlog prou detallat
Que passa després?
• Tasques valorades
• Daily Meeting
Sprint
planning
RetrospectivaRevissióSprint

96. Activitats de
SCRUM - Daily Meeting
Sprint
planning
RetrospectivaRevissióSprint

97. Activitats de
SCRUM - Daily Meeting
Per a que serveix?
1. Per explicar-se
2. Per fer seguiment de l’estat a
nivell de tasca
3. Per a determinar quines tasques
fa cada tècnic en aquell moment
4. Per a resoldre dubtes
Que cal tenir en compte?
• Tothom parla i participa
• Durada màxima: 15 minuts
• Sempre al mateix lloc
• Sempre a la mateixa hora
• Obligatori per al DT
• Voluntari per a SM
• El PO només si és convidat
Sprint
planning
RetrospectivaRevissióSprint

98. Activitats de
SCRUM - Sprint Review
Sprint
planning
RetrospectivaRevissióSprint

99. Activitats de
SCRUM - Sprint Review
Per a que serveix?
(Part 1)
1. Per a mostrar al PO el
resultat/situació final del
Sprint
(Part 2)
1. Per a mostrar a l’usuari/client
l’increment de producte
2. Obtenir acceptació
Que cal tenir en
compte?
• S’ha d’explicar a l’usuari els objectius
del Sprint
• Incloure algun comentari útil
• S’ha de fer Demo
Que passa després?
• Es fa Sprint Retrospective
Sprint
planning
RetrospectivaRevissióSprint

100. Activitats de
SCRUM - Sprint Retrospective
Sprint
planning
RetrospectivaRevissióSprint

101. Activitats de
SCRUM - Sprint Retrospective
Per a que serveix?
1. Per a debatre entre SM i DT sobre
el curs del Sprint
2. Revisar incidents i bloquejos
3. Per a cercar solucions
4. Per aplicar la millora continua
Que cal tenir en compte?
• És l’aplicació de la millora continua
Que passa després?
• S’intenten aplicar les millores
acordades per al Sprint següent
Sprint
planning
RetrospectivaRevissióSprint

102. Activitats de
SCRUM - Sprint Retrospective
Sprint
planning
RetrospectivaRevissióSprint

103. Relació entre
activitats i rols

104. Relació entre
esdeveniments i rols
DT SM PO Stakeholder
Sprint 0 Opcional Sí Sí Opcional
Sprint Planning Sí Sí
A la definició
de que es farà
Daily meeting Sí Opcional
Només si és
convidat
Sprint Review Recomanable Sí Sí
Només a la 2a
part de la reunió,
on es fa demo i es
demana
acceptació
Sprint Retrospective Sí Sí
Només si és
convidat
Grooming Opcional Sí Sí Opcional

105. On participa:
- Sprint 0
- Sprint Planning (definició d'objectius)
- Sprint Review
- Sprint Retrospective si és convidat
- Grooming que demani i on sigui convidat
De que és responsable:
- Del Product Backlog
- Del gràfic Release Burn-down
Recomanacions/Restriccions: El PO no pot
ser Scrum Master.
Enllaç entre el client i l'equip de desenvolupament.
Enfocat a negoci o a TIC.
• Dona suport per resoldre qualsevol qüestió funcional o impediment
• Estratègia. Coneix el “negoci”
• Defineix els objectius
• Manté el Product Backlog
• Negocia l’abast amb el client
• Defineix consensuadament els criteris d'acceptació del projecte i de cada sprint
• Manté el pressupost
Rols - Product Owner

106. Rols - Scrum Master
El Scrum Master NO és el Project Manager.
És l'enllaç entre el DT i el PO
• És un coach/mentor per als components del Development Team, (DT)
• Proporciona suport al DT i resol els problemes
• Reporta, arxiva i porta registre
• Proposa, promou i potencia millores sobre el procés i sobre el Scrum Team
On participa:
- Sprint 0
- Sprint Planning
- Opcionalment als Daily Meetings
- Sprint Review i Sprint Retrospective
- A les reunions de Grooming que demani i
a les que sigui convidat
De que és responsable:
- Del Sprint Backlog juntament amb el DT
- Del Scrum Board juntament amb el DT
- Del gràfic Sprint Burn-down
- Del Incident Backlog i del Impediment Backlog
- De coordinar la reunió de Scrum Retrospective

107. Rols
Development Team
Entre 3 i 9 persones, sense comptar el PO ni el SM
Tots els components de l’equip haurien d’estar en
contacte directe entre ells i amb el SM
• És flexible
• Està auto-organitzat
• És multidisciplinar
On participa:
- Sprint Planning
- Daily Meeting
- Opcionalment al Sprint
Review
- Sprint Retrospective
- A les reunions de grooming
on sigui convidat
De que és responsable:
- Determinar el detall de cada funcionalitat descrita al Product Backlog, i fer
la subdivisió en tasques
- Estimació del esforç, en Story Points al Product Backlog, i en hores a cada
tasca
- Gestionar el Sprint Backlog
- Proporcionar producte “acabat”. Convenientment testejat, seguint els
criteris d'acceptació marcats.
- Executar diàriament el Daily meeting i acomplir les normes d'aquest
esdeveniment

108. Els gràfics de SCRUM
En detall

109. Artefactes SCRUM Graphs

110. Artefactes 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. Artefactes 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àfic de Sprint Burn-down
mostra en tot moment la
“feina pendent”, i permet
veure la velocitat a la que es
resolen les funcionalitats
compromeses al sprint. Per a
cada dia d’iteració el SM
incorpora el total d’hores de
tasques en les diferents
columnes de treball pendent
o en curs.
Usualment el gràfic s’actualitza després de dur a terme la reunió diària

112. Altres conceptes avançats de
SCRUM

113. Themes, Epics, User Stories i Tasques
Theme
Correspon a un gran apartat funcional del projecte. Un módul, una secció amb valor per si mateixa.
Susceptible de disposar del seu propi Product Backlog (per ex: un mòdul de gestió de RRHH)
Epic
Una història d’usuari susceptible de ser dividida (una “superhistòria”). Descriu una necessitat gran que
conforma un submòdul (per ex: el corrector ortogràfic de word)
User Story
Una necessitat susceptible de ser construïda en l’àmbit d’un Sprint
Tasca
Les User Stories es subdivideixen en tasques durant el Sprint Planning. Una tasca és na acció que pot
ser executada per una o poques persones. És la unitat mínima per poder assignar treball a persones i
fer seguiment de l’execució

114. Dades bàsiques d’una User Story
Nom
Nom descriptiu i curt que defineix la User Story en una frase
Descripció
Petita descripció que complementa el nom. En la forma
Com [rol] vull [objectiu] per poder [resultat]
Story Points (estimació)
Valoració en esforç
Prioritat
Prioritat (governada pel PO)
Criteris d’acceptació
Criteris que cal examinar per donar la història per acabada

115. User Stories
Priorització
El PO és el responsable de prioritzar
Tècnica MoSCoW de priorització, que classifica les
User Stories en 4 categories:
• M - MUST HAVE (es necessari)
• S - SHOULD HAVE (es recomanable)
• C - COULD HAVE (podria implementar-se)
• W - WON'T HAVE (no ho volem... potser en un altre
moment)

116. User Stories
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
Com escriure els criteris de validació?
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

117. User Stories
Quantes històries seleccionem en un Sprint?
Team Velocity
La Team Velocity és la velocitat en la que l’equip resol
els Sprints, en forma de Story Points
El Scrum Master porta una estadística de la velocitat i
la reflecteix al gràfic de Release Burn-down
Les històries d’un nou sprint haurien de ser per valor
aproximat de l’històric de velocitat de l’equip

118. User Stories
Subdividir històries grans
Tenim una història per valor superior a la capacitat. Cal
subdividir-la. No és lícit en Scrum que una User Story abasti
més d’un Sprint
Possibles estratègies de subdivisió:
- Per regles de negoci
- Per happy/unhappy flow
- Per paràmetres o dades
etc

119. User Stories
Selecció d’històries per aportar valor
Premissa de Scrum:
Satisfacció del client
“El client ha de percebre que sempre li
proporcionem increments útils”
Hi ha tècniques per proporcionar al client increments de producte
que veritablement aportin valor. Per ex: Visual Story Mapping

120. Sprint 1
Sprint n
Sprint
planning
2 hores
Retrospectiva
2 hores
Revissió
1 hora 
Sprint
Release
La release
La Release és un conveni amb el Product Owner,
per al que és possible lliurar producte cada cert
nombre de Sprints, depenent de la funcionalitat a
construïr

121. Altres tècniques de medició
(no només de burn-down viu l’home)
- Mesurar no és una fi en si mateix
- Mesurar és costos
- Mesurar es pot confondre amb
auditar
- Tinguem sempre present “Temps
ideal” i “Temps real”

122. Estenent SCRUM
Conviure amb
altres
mètodes

123. Estenent SCRUM
A nivell de producte:
1. Un producte te UN ÚNIC Product
Backlog
2. Un producte pot tenir diversos PO.
Cada PO veu una “vista” del product
Backlog
3. Un PO pot gestionar diversos SM
4. Un SM respon només a un PO per a un
producte
5. Un SM pot tenir al seu càrrec diversos
DT, i te UN ÚNIC Sprint Backlog
6. Un DT només te UN ÚNIC SM

124. Com aplicar SCRUM?
1. [Tens 3 a 9] + 2?
2. Separar els projectes. Entendre els requeriments. Conèixer l’abast
3. Establir cicles, (sprints)
4. Establir reunions diàries
5. Fer partícip a l’equip i fomentar la comunicació
6. Fomentar la transparència, la inspecció i l’adaptació
7. Determinar rols i vies de comunicació amb l’usuari
Com se si aplico SCRUM?
www.sierra-charlie.com/download/SB023-TheNokiaTest.pdf
www.verheulconsultants.nl/ScrumButtTest.pdf
Es pot dir que fas SCRUM quan,
com a mínim fas:
(Transparència, Inspecció,
adaptació i Millora 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

126. Gracies
2017, Josep Lluis Monte Galiano
moga@moga.cat
www.moga.cat
www.slideshare.net/jlmoga/introscrumes
www.slideshare.net/jlmoga/introscrumcat
www.moga.cat/agils