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. L'objectiu és desenvolupar i crear un producte en un període determinat on un equip format per diferents persones treballen conjuntament per arribar a un objectiu comú.

Un dels principis claus de l'èxit de Scrum és que està basat en la premissa que, durant el desenvolupament dels productes, els clients canviaran les seves opinions sobre què volen i què necessiten. Els imprevistos no han de ser una gran dificultat per al desenvolupament dels productes. En aquest cas Scrum accepta que el problema no està completament entès i definit i se centra a maximitzar la capacitat de l'equip per entregar ràpidament dins dels terminis establerts i respondre a les necessitats d'última hora.

Història

Scrum es va definir per primera vegada el 1986 per Hirotaka Takeuchi i Ikujiro Nonaka com una estratègia flexible i com una aproximació holística al desenvolupament de productes, on un equip de desenvolupadors treballen com una unitat per aconseguir un objectiu comú. Per la creació de Scrum els seus autors es van basar en casos d'estudi d'empreses d'automoció, fotocopiadores i impressió.^[1] Durant el seu estudi, Nonaka i Takeuchi van comparar la nova forma de treball amb equip amb l'avanç en formació de la melé (scrum en anglès) dels jugadors de rugbi, per aquest motiu es va escollir el terme "scrum" per referir-se a aquesta metodologia de treball.

A principis del 1990, Ken Schwaber va utilitzar el que es convertiria Scrum a la seva companyia, Mètodes Avançats de Desenvolupament, i Jeff Sutherland, amb en John Scumniotales i Jeff McKenna, van desenvolupar un enfocament similar a Easel Corporation, i van ser els primers a referir-se a ell amb la paraula Scrum. El 1995, Sutherland i Schwaber van fer la primera presentació publica de Scrum on van presentar conjuntament un document on descrivien la metodologia de treball de Scrum en el disseny d'objectes de negoci i la implementació en el marc de la programació orientada a objectes, sistemes, idiomes i aplicacions '95 (OOPSLA '95) a Austin (Texas). Durant els següents anys Sutherland i Schwaber van treballar conjuntament per fusionar els escrits anteriors, les seves experiències i millorar les pràctiques de la indústria fins a obtenir el resultat final de Scrum que és tal com el coneixem actualment.

Més tard Schwaber va fundar l'Aliança Scrum i va crear els programes Mastes Certified Scrum i els seus derivats. Schwaber va deixar l'Aliança Scrum a la tardor del 2009, llavors va fundar Scrum.org amb Alex Armstrong per tal de millorar encara més la qualitat i l'eficàcia de Scrum.

Sistema de treball

Scrum és un model de referència que defineix un conjunt de pràctiques, on cada persona participant assumeix un rol (Scrum Master, Product Owner, Equip de desenvolupament, ...), fet que permet adaptar-se a les necessitats i preferències de cada equip o organització.

El primer que es fa és 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 Product Owner 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 en un període determinat.

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 fix d'una durada definida –solen ser d'entre una i quatre setmanes– on l'equip realitza 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, l'ú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 autoorganitzats impulsant la co-localització de tots els membres de l'equip, i la comunicació verbal entre tots els membres i disciplines involucrades en el projecte.

Rols

Rols Principals

Existeixen tres rols principals en el marc de treball de Scrum:

Product Owner

El Product Owner representa els grups d'interès i 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, i les col·loca en el Product Backlog. Sempre ha d'estar a la part comercial del projecte, en cap cas pot interferir en l'equip de desenvolupament per discutir sobre aspectes tècnics. Aquesta funció és equivalent a la representació del client en alguns altres marcs àgils.

Equip de desenvolupament

L'equip de desenvolupament té la responsabilitat de lliurar les diferents parts del producte dins els períodes establerts (Sprint) i lliurar el producte final. Es recomana un equip petit entre 3 a 9 persones amb les capacitats transversals necessàries per realitzar les diferents entregues al final de cada Sprint (p.e. anàlisi, disseny, programació, proves, documentació, etc.).

Scrum Master

El Scrum és facilitat per un Scrum Master, la seva feina principal é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'autoorganitza), 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 es fa servir correctament i que es compleixin les regles tal com s'ha de fer.

Rols Auxiliars

Els rols auxiliars en els "equips Scrum" són aquells que no tenen un rol formal i que no s'involucren sovint 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 d'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.

Administradors (Managers)

Són aquells que estableixen l'equip i l'entorn en els quals es desenvolupa el projecte.

Sprint

Un Sprint (o iteració) és la unitat bàsica de desenvolupament de scrum. És altament recomanable que la durada dels Sprints sigui fixada a l'inici de cada un i determinada per l'experiència de l'equip, normalment entre 1 setmana i 1 mes. 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ó.

Els Sprints s'inicien amb una reunió de planificació (Sprint Planning Meeting) que tenen com a objectiu definir un Sprint Backlog, identificar el treball que s'ha de realitzar durant el Sprint i fer una estimació del temps necessari per entregar el producte al final del període. 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 llevat que els canvis siguin imprescindibles per a assegurar l'èxit del projecte. La constància permet augmentar la concentració i per tant la productivitat de l'equip de desenvolupament.

Reunions

Scrum Diari (Daily Scrum)

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 durada 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

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)

A l'inici del cicle Sprint (d'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ó de l'esforç disponible (hores * mida de l'equip * durada del Sprint) es selecciona quina feina es farà
Es comunica, no negocia, aquesta feina al Product Owner
Vuit hores com a límit per un Sprint d'un mes, proporcionalment menys per Sprints més curts

Quan s'acaba 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)

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)

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.

Beneficis de Scrum

Flexibilitat a canvis: Gran capacitat de reacció en cas que es produeixin canvis en els requeriments generats per les necessitats del client o l'evolució del mercat. El marc de treball està dissenyat perquè s'adapti a les noves necessitats que implica un projecte complex.
Reducció del Time to Market: El client pot començar a utilitzar les característiques més importants del projecte abans que aquest estigui completament acabat.
Millor qualitat del software: El treball metòdic i la necessitat d'obtenir una versió de treball funcional després de cada iteració ajuda a l'obtenció d'un software de gran qualitat.
Millor productivitat: S'aconsegueix, entre altres raons, gràcies a l'eliminació de la burocràcia i la motivació de l'equip proporcionada pel fet que es poden estructurar de manera autònoma.
Maximitzar el retorn de la inversió (ROI): Creació de software únicament per les prestacions que contribueixen a una millora en el valor del negoci gràcies a la priorització del retorn d'inversió.
Prediccions de temps: A través d'aquest marc de treball es coneix la velocitat mitjana de l'equip per sprint, d'aquesta manera és possible estimar de manera fàcil quan es podrà fer ús d'una determinada funcionalitat que encara està en el Backlog.
Reduccions de riscos: El fet de dur a terme les funcionalitats de més valor en primer lloc i saber la velocitat a la qual l'equip avança en el projecte, permet evitar riscos eficaçment de manera anticipada.

Documents

Product backlog

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

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 perquè 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 com es va realitzant la feina.

Aquest és un exemple d'un burn down chart per a un projecte de 21 dies. A l'exemple, el projecte ja ha acabat i es pot observar la comparativa entre la línia de treball ideal i la real, tot veient la càrrega de feina realitzada cada dia.

Sprint burn-down chart

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 acaba 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

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 totalment 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ó

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 a les eines de programari. Una de les majors avantatges de Scrum és que és molt fàcil d'aprendre, i requereix poc esforç per posar-se en marxa.

Referències

↑ 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

Bibliografia

"Scrum and XP from the Trenches" llibre gratuït sobre Scrum d'en Henrik Kniberg

Vegeu també

Enllaços externs

(PDF) Rising, L., Janoff, N.S. (2000). The Scrum Software Development Process for Small Teams Retrieved March 15, 2007
(PDF) Schwaber, K. Advanced Development Methods. SCRUM Development Process Arxivat 2015-08-14 a Wayback Machine. Retrieved July 01, 2010
(video) Jeff Sutherland in Scrum Tuning: Lessons learned from Scrum implementation at Google Retrieved 2007-12-15
(video) Ken Schwaber in Scrum et al. Retrieved 2008-01-19

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

Viccionari

[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]