Scrum

De Viquipèdia
Dreceres ràpides: navegació, cerca

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 de temps 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 perquè esta pensat que durant el desenvolupament dels productes, els clients poden canviar les seves opinions sobre què volen i què necessiten. Els imprevistos no han de ser una gran dificultat per el desenvolupament dels productes, en aquest cas Scrum accepta que el problema no està completament entès i definit i es centre en maximitzar la capacitat de l'equip per entregar ràpidament dintre els terminis establerts i respondre a les necessitats d'última hora.

Història[modifica | modifica el codi]

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 inglés) dels jugadors de rugby, 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 industria 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[modifica | modifica el codi]

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 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, 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 auto-organitzats 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[modifica | modifica el codi]

Rols Principals[modifica | modifica el codi]

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

Product Owner[modifica | modifica el codi]

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[modifica | modifica el codi]

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[modifica | modifica el codi]

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'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 correctament i que es compleixin les regles tal com s'ha de fer.

Rols Auxiliars[modifica | modifica el codi]

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 d'adaptar el producte resultant a través del contingut actualitzat del Product Backlog.

Stakeholders (Clients, Proveïdors, Comercials, etc.)[modifica | modifica el codi]

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)[modifica | modifica el codi]

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

Sprint[modifica | modifica el codi]

Procés de treball amb Scrum

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 al 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 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.

Reunions[modifica | modifica el codi]

Scrum Diari (Daily Scrum)[modifica | modifica el codi]

Un scrum diari (daily scrum) a la sala de computació. Aquesta ubicació centralitzada ajuda a l'equip a iniciar a temps.

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[modifica | modifica el codi]

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 | modifica el codi]

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ó del 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 limit 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)[modifica | modifica el codi]

  • 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 | modifica el codi]

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[modifica | modifica el codi]

  • 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 de obtenir una versió de treball funcional després de cada iteració ajuda a l'obtenció de 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 per fet de què 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 de 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 de 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 què l'equip avança en el projecte, permet evitar riscos eficaçment de manera anticipada.

Documents[modifica | modifica el codi]

Product backlog[modifica | modifica el codi]

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 | modifica el codi]

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[modifica | modifica el codi]

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[modifica | modifica el codi]

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ó[modifica | modifica el codi]

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.

Notes[modifica | modifica el codi]

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

Referències[modifica | modifica el codi]

Vegeu també[modifica | modifica el codi]

Enllaços externs[modifica | modifica el codi]

A Wikimedia Commons hi ha contingut multimèdia relatiu a: Scrum Modifica l'enllaç a Wikidata

Portals temàtics i blogs[modifica | modifica el codi]

Comunitats o grups d'usuaris[modifica | modifica el codi]

  • 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 | modifica el codi]

Llibres originals o traduïts[modifica | modifica el codi]