Scrum

Scrum és un marc de treball per a la gestió de projectes. Inicialment força estès entre els desenvolupadors i mantenidors de programari o d'aplicacions, amb el temps Scrum també s'ha fet popular per a la gestió de programes i de múltiples equips de desenvolupament.

Història [modifica]

El 1986 Hirotaka Takeuchi i Ikujiro Nonaka van descriure una nova aproximació holística al desenvolupament de productes que incrementava la seva rapidesa i la flexibilitat, basant-se en casos d'estudi de empreses d'automoció, fotocopiadores i impressió.^[1]

Sistema de treball [modifica]

Scrum és un model de referència que defineix un conjunt de pràctiques, on cada persona participant assumeix un rol (ScrumMaster, ProducOwner i equip de desenvolupament), fet que permet adaptar-se a les necessitats i preferències de cada equip o organització. Els rols principals de Scrum són:

Organització [modifica]

El primer que es fa es definir els objectius del projecte, separar-los per tasques a realitzar i assignar-los un temps necessari per realitzar aquestes tasques.

Un cop estan definides les tasques a fer, el ProductOwner les ordena per ordre d'importància i preferències, tot creant el que es coneix com a Product Backlog, que és, en resum, el conjunt de requeriments a alt nivell prioritzats que defineixen la feina a fer.

El conjunt de tasques que forma part de cada sprint es defineix i es documenta al Product Backlog, que és, en resum, el conjunt de requeriments a alt nivell prioritzats que defineixen la feina a fer.

Un cop es té el Product Backlog redactat, l'equip fa una reunió per a planejar i prioritzar tasques. És en aquest moment que es fa la planificació de sprints. Els sprints són períodes de temps fix d'una durada definida -solen ser d'entre una i quatre setmanes- on l'equip realtiza les tasques que tenia assignades al Produckt Blacklog. Durant aquest període l'equip ha de realitzar les tasques encomanades per tal d'assolir la fita dins del període marcat. El procés de planificació previ es coneix com a Sprint Planning.^[2]

Durant el temps que dura l'Sprint, la única part que pot canviar del Backlog és l'equip de desenvolupament, si veu que aquest no pot completar-les tasques dins del període establert.

El sistema Scrum permet la creació d'equips auto-organitzats impulsant la co-localització de tots els membres de l'equip, i la comunicació verbal entre tots els membres i disciplines involucrats en el projecte.

Rols [modifica]

El ScrumMaster: És qui prova de fer seguir les pràctiques de Scrum tant a dins de l'equip com envers l'organització.
El ProductOwner: És qui representa els interessats en el projecte
L'Equip de desenvolupament: Inclou tots els participants en la construcció del programari.

Rols Principals [modifica]

Aquest són els rols principals:

Product Owner: El Product Owner representa la veu del client. S'assegura que el resultat del treball de l'equip de Scrum s'adequa des de la perspectiva del negoci. El Product Owner escriu històries d'usuari, les prioritza, y les col·loca en el Product Backlog.

ScrumMaster: El Scrum és facilitat per un Scrum Master, la feina principal del qual és eliminar els obstacles que impedeixen que l'equip arribi a l'objectiu de cada Sprint. El Scrum Master no és el líder de l'equip (ja que aquest s'auto-organitza), sinó que actua com una protecció entre l'equip i qualsevol influència que el distregui. El ScrumMaster s'assegura que el procès Scrum s'utilitza com cal. El ScrumMaster fa que es compleixin les regles de Scrum.

Equip de desenvolupament: L'equip té la responsabilitat de lliurar el producte amb el resultat dels Sprints. Scrum recomana un equip petit (de 6 més/menys 3 membres) amb les capacitats transversals necessàries per realitzar l'increment lliurable del producte (p.e. anàlisi, disseny, programació, proves, documentació, etc.).

Rols Auxiliars [modifica]

Els rols auxiliars en els "equips Scrum" són aquells que no tenen un rol formal i que no s'involucren freqüentment en el "procés Scrum", i que tot i això, se'ls ha de considerar. Un aspecte crític de qualsevol aproximació àgil és la pràctica d'involucrar en el procés als usuaris, experts del negoci i d'altres interessats (stakeholders). És vital que aquestes figures participin i comuniquin la seva opinió (feedback) respecte a la sortida dels Sprints, per tal de adaptar el producte resultant a través del contingut actualitzat del Product Backlog.

Stakeholders (Clients, Proveïdors, Comercials, etc): Són aquells que fan possible que el projecte es realitzi i els que obtindran el seu benefici acordat que justifica el projecte. Només participen directament durant les revisions del Sprint.

Directors (Managers): Són aquells que estableixen l'equip i l'entorn en els que es desenvolupa el projecte.

Reunions [modifica]

Scrum Diari (Daily Scrum) [modifica]

Cada dia del Sprint es realitza una reunió sobre l'estat del projecte, típicament al començament de la jornada. També se li anomena daily standup i té unes regles concretes:

La reunió comença puntualment a la seva hora. Poden acodar-se càstigs simbòlics -acordats per l'equip- per qui no respecti la puntualitat.
Tothom és benvingut, tot i que només els membres de l'equip de desenvolupament poden parlar.
La reunió té una durara fixa de 15 minuts, independentment de la mida de l'equip i de la durada del Sprint.
Tots els assistents han d'estar dempeus (això ajuda a mantenir la reunió curta)
La reunió ha de fer-se al mateix lloc i hora durant tot el Sprint.

Durant la reunió, cada membre de l'equip contesta a tres preguntes:

Que has fet des d'ahir?
Què faràs avui?
Quins problemes t'impedeixen arribar als teus objectius del Sprint?

Scrum de Scrums [modifica]

Cada dia normalment desprès del “Daily Scrum”

Aquestes reunions permeten a grups d'equips treballant en un mateix projecte discutir el seu treball, especialment els solapaments i integracions
Cada equip designa a una persona per aquesta reunió

L'agenda serà la mateixa que la del Scrum diari però fent les següents quatre preguntes:

Què ha fet el teu equip des de la darrera reunió?
Què farà l'equip abans que ens tornem a trobar?
Hi ha quelcom que endarrereix o destorba el teu equip?
Estàs a punt de posar quelcom en el camí d'un altre equip?

Reunió de Planificació del Sprint (Sprint Planning Meeting) [modifica]

A l'inici del cicle Sprint (de 1 a 4 setmanes), una “Reunió de Planificació del Sprint” on es decideix:

Es prioritza la feina assignada al Sprint actual amb el Product Owner
L'equip de desenvolupament estima l'esforç necessari per realitzar cada element assignat al Sprint
En funció del esforç disponible (hores * mida de l'equip * durada del Sprint) es sel·lecciona quina feina es farà
Es comunica, no negocia, aquesta feina al Product Owner
Vuit hores com a limit per un Sprint d'un mes, proporcionalment menys per Sprints més curts

Quan s'acava el cicle de Sprint, es realitzen dues reunions: “Reunió de revisió del Sprint” i “Retrospectiva del Sprint”

Reunió de revisió del Sprint (Sprint Review Meeting) [modifica]

Revisar la feina que es va poder completar i que no
Presentar el resultat de l'increment del producte als interessats, normalment amb una demostració
Quatre hores com a límit

Retrospectiva del Sprint (Sprint Retrospective) [modifica]

Després de cada Sprint, es realitza una retrospectiva del Sprint, on tot l'equip de desenvolupament opina sobre com ha funcionat l'equip durant el Sprint. L'objectiu de la reunió és identificar els aspectes positius i els que s'han de millorar per optimitzar el rendiment de l'equip. Aquesta reunió té un temps fix de quatre hores.

Sprint [modifica]

El Sprint és el periode en el que es realitza l'increment del producte. És altament recomanable que la durada dels Sprints sigui fixa i determinada per l'experiència de l'equip. La durada fixa té com a objectiu mantenir un ritme constant i facilitar que l'abast dels requeriments associats al Sprint es respecti per part del client durant la seva execució. Al final de cada Sprint, l'equip de desenvolupament haurà de presentar l'increment aconseguit sobre el producte, que ha de ser potencialment lliurable al client. Tanmateix es recomana no canviar els objectius del Sprint a no ser que els canvis siguin imprescindibles per asegurar l'èxit del projecte. La constància permet augmentar la concentració i per tant la productivitat de l'equip de desenvolupament.

Documents [modifica]

Product backlog [modifica]

El product backlog és un document d'alt nivell per tot el projecte. Conté descripcions genèriques dels requeriments, funcionalitats dessitjables, errors existents a solucionar, etc. prioritzats segons el criteri del Product Owner. És allò que es construirà durant el Sprint. És public i tothom pot fer aportacions, però és el Product Owner qui té l'autoritat per modificar-lo. Conté estimacions d'alt nivell, tant del valor pel negoci de cada element com de l'esforç per realitzar-los. Aquesta estimació ajuda al Product Owner a anar reajustant les prioritats i les assignacions als Sprints (Product Roadmap).

Sprint backlog [modifica]

El sprint backlog és un document detallat on es defineixen les tasques necessàries per realitzar els requeriments assignats al Sprint actual. Les tasques es detallen suficientment per a que la seva durada sigui petita (p.e. menor de 2 dies). D'aquest refinament dels requeriments del Sprint pot observar-se que l'esforç del Sprint pot variar i per tant, l'abast assignat pot crèixer o minvar. Les tasques del Sprint Backlog no s'assignen sinó que els propis membres de l'equip les van prenent del Sprint Backlog tal i com es va realitzant la feina.

Burn down [modifica]

La burn down chart és una gràfica mostrada públicament que mesura la quantitat de requeriments del Product Backlog assignats al Sprint actual que estan pendents de finalitzar. S'obté dibuixant en un quadrant (Hores x Dies) una "recta ideal" que comença a (#Hores Sprint i Zero) i acava a (Zero, #Dies Sprint). Cada dia del Sprint es revisa la feina aconseguida i es van pintant els "punts reals" de la (#Hores Pendents, #Dia Actual). Aquesta "recta real" s'obté unint aquests "punts reals", i permet anticipar diàriament quina quantitat de la feina planificada pel Sprint es podrà assolir realment.

Scrum aplicat al desenvolupament de programari [modifica]

Tot i que Scrum va sorgir com a model de desenvolupament de productes tecnològics, també es fa servir en entorns on es treballa amb requeriments inestables i que requereixen ser desenvolupats amb rapidesa i flexibilitat; situacions freqüents en el desenvolupament de sistemes formats total o parcialment per programari.

Jeff Sutherland va aplicar el model Scrum al desenvolupament de software el 1993 a l'Easel Corporation, que va acabar sent integrada successivament en VMARK, Informix, Ascential i finalment a IBM. Aquest model va ser presentat el 1995 com a procés formal pel desenvolupament de programari, conjuntament amb Ken Schwaber, al congrés OOPSLA 95. Més tard, el 2001, tots dos formarien part del grup que va promulgar el Manifest Àgil.

Implementació [modifica]

Existeixen diferents implementacions de sistemes per gestionar el procés de Scrum, que van des de les notes grogues "post-it" i les pissarres fins les eines de programari. Una de les majors aventatges de Scrum es que és molt fàcil d'aprendre, i requereix poc esforç per posar-se en marxa.

Notes [modifica]

↑ Takeuchi and Nonaka: The New New Product Development Game (Harvard Business Review, Jan-Feb 1986)
↑ Agile Project Management with Scrum, Ken Schwaber, Microsoft Press, January 2004, 163pp, ISBN 0-7356-1993-X

Referències [modifica]

Vegeu també [modifica]

Enllaços externs [modifica]

A Wikimedia Commons hi ha contingut multimèdia relatiu a: Scrum

Portals temàtics i blogs [modifica]

Comunitats o grups d'usuaris [modifica]

Scrum.org : Organització dedicada a la difusió i certificació de Scrum liderada per Ken Schwaber.
ScrumAlliance : Organització professional sense ànim de lucre dedicada a la difusió de Scrum.
Scrum.cat : Portal en desenvolupament dedicat als usuaris catalans de Scrum.

Articles i guies [modifica]

La guia de Scrum en 1 pàgina

Llibres originals o traduïts [modifica]

[1] Takeuchi and Nonaka: The New New Product Development Game (Harvard Business Review, Jan-Feb 1986)

[schwaber-2] Agile Project Management with Scrum, Ken Schwaber, Microsoft Press, January 2004, 163pp, ISBN 0-7356-1993-X

[1]

[2]