scrum events time boxing
Introducció als esdeveniments Scrum:
En els nostres tutorials anteriors, vam parlar sobre Scrum i com s’estructura.
I el nostre tutorial anterior explicava tot Artefactes Scrum en detall.
Sabem qui forma l’equip Scrum i quins artefactes diferents es desenvolupen al llarg del procés. Ara hem establert un bagatge sòlid. Per tant, fem un pas endavant en Scrum i discutim els esdeveniments / cerimònies clau que constitueixen el Procés Scrum.
En aquest tutorial, intentarem entendre què significa cadascun dels esdeveniments Scrum, quines són les característiques essencials i com les organitzem en detall.
Què aprendreu:
- Visió general
- Tipus d'esdeveniments Scrum
- Què és el Time Boxing?
- El Sprint Planning
- El dia a dia
- The Sprint Review
- La retrospectiva Sprint
- Restricció de retards
- Conclusió
- Lectura recomanada
Visió general
Mentre treballava en un projecte basat en Scrum, l’equip de scrum passa per una sèrie de cerimònies Scrum.
Alguns els poden anomenar cerimònies o esdeveniments Scrum i d'altres els poden convocar per a rituals o reunions. Independentment de les diferents terminologies que s’utilitzin aquí, l’objectiu de cada esdeveniment Scrum continua sent el mateix. Cadascun dels esdeveniments Scrum, en essència, ajuda a realitzar i controlar el treball de Sprint.
Tipus d'esdeveniments Scrum
Cada cerimònia Scrum és un assumpte / reunió presencial organitzat pel Scrum Master per als grups dedicats. A part de l’equip bàsic, algunes de les reunions poden implicar grups d’interès, gestors de lliurament o fins i tot el propi client. Aquestes reunions tenen un temps limitat i, per tant, s'han de completar dins del termini estipulat.
L’objectiu de cadascuna de les reunions és reunir els participants i deixar-los debatre sobre la feina que porten a terme. L’expectativa de cada participant és mantenir-se concentrat, compromès i participatiu.
Es considera una oportunitat per conversar, examinar i recuperar els comentaris del treball realitzat. A diferència de les reunions ordinàries, els esdeveniments Scrum estan orientats als resultats, estan ajustats al temps, es basen en el públic objectiu i tenen un objectiu específic alineat amb cadascun d’ells.
Què és el Time Boxing?
El Timeboxing és una de les funcions clau associades a tots els esdeveniments Scrum. S'espera que els participants siguin conscients i respectuosos amb el temps assignat a cadascun dels esdeveniments. Els esdeveniments no es poden allargar però es poden escurçar si ja s’han assolit els objectius de la reunió.
Scrum Master, que també és un facilitador de tots els esdeveniments Scrum, s’assegura que tothom entengui la importància de la boxa del temps i també els segueix recordant que se centren en l’objectiu de la reunió per obtenir els millors resultats i els resultats temporals amb desviacions.
La caixa de temps d’un esdeveniment no s’hauria d’estendre idealment, però com sabem que Scrum no tracta de les regles, el temps es pot ampliar a una durada determinada si tots els participants hi estan d’acord.
Com decidim el quadre de temps de cada esdeveniment Scrum?
El quadre de temps per a Scrum Events és directament proporcional a la durada del Sprint. Tanmateix, l'única excepció a aquesta regla és Standup diari, que té un quadre de temps fix de 15 minuts independentment de la durada del sprint.
Hi ha marcs de temps estàndard per a cada esdeveniment en funció de la durada del Sprint. Tot i això, l’equip té la llibertat de decidir els terminis per a aquests esdeveniments en funció del seu requisit.
Entenem més d’aquests conceptes discutint detalladament cada esdeveniment Scrum.
El Sprint Planning
Com a requisit previ per a aquesta cerimònia, el propietari del producte hauria de preparar una cartera de productes estable i prioritària de les històries dels usuaris abans de venir a la reunió. Les històries dels usuaris han d’estar ben formades i prou clares perquè l’equip les entengui.
El propietari del producte pot demanar ajuda a les parts interessades, al client, al dissenyador i al Scrum Master per desenvolupar la cartera de productes.
És obligatori tenir criteris d’acceptació en una història d’usuari. L'equip està autoritzat a rebutjar una història d'usuari sense els criteris d'acceptació.
Propòsit
Sprint Planning és la cerimònia inicial mentre s’inicia un Sprint. El propòsit de la reunió de Sprint Planning és crear un objectiu Sprint, seleccionar les històries dels usuaris del Product Backlog a Sprint Backlog i discutir-les detalladament.
L'equip es reuneix en una sala de reunions juntament amb el propietari del producte i el Scrum Master, on el propietari del producte presenta les històries dels usuaris que haurien de ser seleccionades per al proper sprint.
L’equip pot fer tantes preguntes com vulgui per saber més sobre la història i és responsabilitat del propietari del producte atendre les consultes. L’equip també podria desafiar la història per la seva integritat i idoneïtat.
Si es necessita informació addicional dins de la història o té una dependència incompleta o es troba incompleta, l'equip té el poder de rebutjar aquesta història.
Al cap i a la fi, s’han esborrat els dubtes i l’equip sap la quantitat exacta del treball que cal fer per completar una història. L’equip calcula i dóna els punts de la història a cadascun dels contes de l’usuari.
De manera similar, es discuteixen i s’estimen les altres històries. Ara, l’equip selecciona les històries de la part superior de la cartera de productes prioritzats a la cartera de treballs de Sprint, que creuen que podran comprometre i completar a la caixa donada la seva velocitat passada.
La velocitat es determina pel nombre total de punts de la història completats en un esprint mitjà. La velocitat es calcula basant-se en els Sprints històrics i fent-ne una mitjana. Com més velocitats completem, més estable és la velocitat d’un equip.
Molts equips utilitzen les cartes Planning Poker per a l'estimació d'històries. La tècnica d’estimació més comuna és la història que apunta mitjançant la sèrie de Fibonacci. La sèrie de Fibonacci és una sèrie de nombres on cada número següent de la sèrie es constitueix sumant els dos números anteriors.
Sèrie Fibonacci: 1, 1, 2, 3, 5, 8, 13, etc.
Les històries d’usuaris estimades més enllà de 13 punts de la història es consideren molt grans per completar-se en un sol sprint i, per tant, es descomponen en històries d’usuaris lògiques més petites que es poden estimar individualment.
Durant una reunió de planificació de Sprint, l’equip també crearà tasques a les històries d’usuari que s’hagin seleccionat per al Sprint. No s’espera que l’equip faci tasques a totes les històries dels usuaris durant el Sprint Planning, però és suficient per iniciar-les. La resta de tasques es poden fer durant el sprint.
El resultat clau d’una reunió de Sprint Planning és l’objectiu Sprint i Sprint Backlog, que consisteix en les històries d’usuaris que l’equip s’ha compromès a completar.
A part de les User Stories, hi pot haver algun altre tipus d’elements que puguin formar part del Sprint Backlog.
- Pics
- Deutes tècnics
- Errors
Pics són les tasques d’investigació per trobar una solució, és a dir, la necessitat de la qual és la pròpia User Story. És possible que algunes de les històries no siguin senzilles o no tinguin la capacitat tècnica i, per tant, requeririen més anàlisis i investigacions al seu voltant. Per tant, es crea una espiga. També pot incloure un POC si sorgeix la necessitat.
Deutes tècnics són la refactorització del codi existent. Moltes vegades hi ha situacions en què l'equip ha de tornar a treballar el codi que es va desenvolupar anteriorment per adaptar-se als nous requisits.
Errors a Scrum solen ser els requisits nous o perduts que surten de les històries d’usuaris acceptades, però que són rellevants per als elements de treball actuals. Si no és un requisit, en realitat pot ser un error del sistema que es va desenterrar durant els sprints anteriors, però que no es va solucionar i s’ha prioritzat en aquest sprint.
Assistents
Tothom de l’equip Scrum forma part de la reunió de Sprint Planning. No hi ha ningú més que l’equip bàsic convidat a assistir a la reunió.
La reunió Sprint Planning està organitzada i facilitada pel Scrum Master, però el propietari del producte roba el programa.
Time-box
La reunió Sprint Planning pot trigar fins a mig dia durant dues setmanes Sprint. El quadre de temps per a una reunió de Sprint Planning depèn directament de la durada del Sprint. Més curt per a un Sprint curt i més llarg per a un Sprint llarg.
La reunió de Sprint Planning té un paper molt crucial en l'arquitectura general de Scrum i afecta directament el producte que s'està desenvolupant. Per tant, l’equip hauria d’invertir tot el temps que cregués necessari per debatre detalladament totes les històries dels usuaris i proposar un horari alternatiu que els convingui.
Una vegada que es decideix i s’acorda el cronometratge, és responsabilitat del Scrum Master mantenir l’equip centrat en la meta i, alhora, fer un seguiment del temps.
El dia a dia
Propòsit
Daily Standup és una reunió que ofereix una oportunitat per il·lustrar una visió general de la salut del Sprint. També és una plataforma per debatre en què estan treballant els altres membres de l’equip i si hi ha alguna cosa que s’atura per assolir l’objectiu del Sprint.
Durant una reunió stand-up diària, cada membre de l’equip comparteix l’estat del seu progrés en els elements de treball en què treballen. També comparteixen i demanen ajuda als altres membres de l’equip si hi ha obstacles que bloquegin el seu progrés.
Durant una reunió stand-up diària, tots els membres de l’equip al voltant de la taula responen les tres preguntes clau una per una:
'Què heu fet des de la darrera reunió diària?'
'Què penses fer avui?'
Administrador d'informàtica preguntes i respostes de l'entrevista
'Hi ha algun impediment per bloquejar la vostra feina?'
S’espera que els altres membres de l’equip prestin atenció quan algú comparteixi l’estat i ofereixi ajuda si sorgeix la necessitat. Tan bon punt l’últim membre de l’equip hagi respost a les tres preguntes, la reunió acaba aquí.
La reunió Standup diària proporciona una visió general sobre quin és l'estat de finalització actual i general de la iteració en què estan treballant actualment. Scrum Master juga un paper molt important a l’hora de mantenir la reunió Daily Standup concentrada i el temps ajustat. També és responsable de resoldre els impediments que impedeixen a l'equip progressar amb les seves històries d'usuaris.
Scrum Master també s'ha d'assegurar que ningú més que l'equip bàsic no faci preguntes i presenti estat. Si ho requereix, pot permetre discussions ràpides sobre les històries dels usuaris, però ha de ser conscient del temps i pot intervenir en qualsevol moment i demanar als membres de l’equip que tinguin una discussió fora de línia.
Assistents
Qualsevol persona pot assistir a una reunió diària. Tot i això, és obligatori que l’equip bàsic assisteixi a la reunió i presenti l’estat del seu treball.
Qualsevol altra persona, fins i tot de fora de l’equip, que estigui interessada en conèixer el progrés de l’Sprint pot assistir a la Reunió diària, però no se li permet presentar l’estat del seu treball ni preguntar als membres de l’equip de desenvolupament sobre el seu treball.
Només es permet als membres bàsics de l’equip compartir el seu progrés laboral i s’espera que tots els altres escoltin en silenci.
La reunió diària de Standup s’hauria de dur a terme encara que hi hagi un membre de l’equip únic.
L’equip pot dur a terme la reunió diària d’autonomia pel seu compte o bé pot demanar-li a Scrum Master que la faciliti.
Time-box
Com el seu nom indica, cada dia es fa una reunió stand-up diària i s’espera que els participants s’aturin, ja que es tracta d’una reunió curta de només 15 minuts. La idea és mantenir-se a l’agenda i no desviar el focus, per tant la reunió es manté curta. Mantenir la reunió també ajuda les persones a comprometre’s fàcilment, ja que només requereix 15 minuts.
La reunió stand-up diària també es manté a la mateixa hora i al mateix lloc diàriament per reduir la confusió entre els participants i la sobrecàrrega per reservar les sales de reunions diàriament. Durant la reunió es desaconsella l’ús d’ordinadors portàtils, ordinadors de sobretaula o telèfons mòbils.
Els equips poden decidir quan tindran lloc la reunió diària de stand-up i mantenir-s’hi. Tot i això, la tendència normal és que les reunions siguin les primeres del matí. Per als equips que treballen en diferents zones horàries, la trucada al matí pot no funcionar i, per tant, poden tenir la trucada a la tarda o el que més els convingui.
El Scrum Master també pot compartir les notícies o actualitzacions importants al final de la reunió amb l’equip si el temps ho permet, però no se li permet allargar la reunió a qualsevol preu.
The Sprint Review
Propòsit
Sprint Review Meeting consisteix en demostrar la feina feta i recopilar els comentaris i la compra. En alguns llocs, la reunió de Sprint Review també es coneix com a Sprint Demo. La reunió de revisió de Sprint se sol fer al final de l’esprint, però abans de la reunió retrospectiva de Sprint.
El (s) representant (s) escollit (s) de l'equip demostra els elements de treball actuals de l'esprint. Normalment, el desenvolupador que treballa en la història de l'usuari demostra el treball i respon a les consultes plantejades per qualsevol persona del públic.
Les històries dels usuaris que es fan basant-se en la Definició de Fet són els únics candidats a la demostració de la Sprint Review Meeting.
El propietari del producte té un paper molt important durant la reunió de revisió de Sprint. És l’encarregat d’avaluar cadascuna de les històries de l’usuari que es demostra en funció dels seus criteris d’acceptació i accepta o rebutja la història.
Les històries acceptades s’integren després amb l’increment fet, que és un lliurament potencialment enviable. Cap a on aniria una història rebutjada o incompleta és la trucada del propietari del producte. Les històries rebutjades poden formar part del proper sprint o poden passar al Product Backlog des d'on es tornaran a prioritzar.
El resultat clau de la reunió de Sprint Review és una imatge general de la data de finalització del projecte. El propietari del producte accepta / rebutja la història i, a continuació, les històries acceptades s’integren amb l’increment (creat durant els sprints anteriors) en conjunt per donar una millor imatge de la nostra posició en completar el producte sencer.
Un altre resultat clau de la reunió de Sprint Review és que els membres de l'equip aprenen alguna cosa sobre l'estimació. El nombre d’històries d’usuaris acceptades determina el nombre de punts d’història aconseguits en un sprint.
Per tant, esprint a esprint, l’equip pot desenvolupar la capacitat d’estimar correctament i prendre una decisió informada sobre els punts de la història que són factibles d’aconseguir.
Sovint s’observa que aquestes reunions aporten llum sobre els criteris d’acceptació incomplets o els nous requisits que apareixen. La millor manera d’afrontar aquesta situació és tancar les històries i marcar-les com a fetes si compleixen tots els criteris d’acceptació acordats inicialment durant la reunió de planificació de Sprint.
Qualsevol cosa que sigui superior a això s’ha de considerar com un nou requisit i el propietari del producte és responsable d’aquests requisits per al futur sprint.
Assistents
Els membres de l’equip, inclosos el Scrum Master i el propietari del producte, assisteixen a la reunió de Sprint Review Meeting. Altres participants a la reunió de revisió de Sprint són els grups d'interès, gestors de lliurament, clients / usuaris finals o qualsevol persona que estigui interessada a formar part de Sprint Review.
Time-box
En un escenari ideal per a un sprint de dues setmanes, passem aproximadament dues hores a la reunió Sprint Review. Això pot variar en funció de la longitud del Sprint. Per a un sprint més curt, Sprint Review més curt i per a un sprint més llarg, Sprint Review.
Igual que altres reunions, Scrum Master és responsable de mantenir l’impuls de la reunió i assegurar-se que les activitats (demostració de les històries, resposta a les consultes, acceptació de les històries, comentaris assenyalats, etc.) s’ajusten al termini estipulat.
La retrospectiva Sprint
Propòsit
La retrospectiva Sprint es tracta d’encarnar el que diu Agile: ‘ Reflexions periòdiques sobre com ser més efectius ’. Sprint Retrospective ofereix a tot l’equip l’oportunitat de reflexionar i contemplar com va anar l’esprint i què s’ha de fer per improvisar els processos? La retrospectiva Sprint es realitza al final de cada sprint.
Durant una reunió Sprint Retrospectiva, tot l’equip es reuneix i discuteix el Sprint que s’acaba de completar. S'espera que l'equip sigui transparent i doni opinions honestes, però no hi ha jocs de culpa.
Recordeu l’objectiu de la reunió de fer un pas endavant en l’àmbit de la improvisació i no mantenir l’equip augmentant la tensió entre els membres.
Tothom dins s'espera que l'equip respongui a les quatre preguntes bàsiques:
El Scrum Master demana als membres de l’equip que escrivin els seus punts per a cadascun dels quadrants tal com es mostra a la nota anterior. En alguns llocs, s’utilitzen eines amb el mateix propòsit.
Què ha anat bé?
com obrir un fitxer torrent Windows 10
Els membres de l'equip donen un o més punts sobre el que ha anat bé en l'últim Sprint. Aquesta secció també es pot prendre com una oportunitat per agrair i reconèixer la resta de membres de l’equip pel seu bon treball.
Què has après?
Scrum es considera com una oportunitat per aprendre alguna cosa nova en cada sprint. Aquesta àrea d’un quadrant tracta de debatre els punts clau per endur-se i els aprenentatges de l’últim Sprint.
Què no ha anat bé?
En aquesta secció, l’equip discuteix els problemes i obstacles que s’havien enfrontat durant l’últim esprint. Aquesta part de la reunió acostuma a ser la més fràgil, ja que la gent pot plantejar qüestions que poden incomodar els altres.
És responsabilitat del Scrum Master tranquil·litzar l’atmosfera si ho necessita i ensenyar a la gent a plantejar els seus problemes d’una manera constructiva en lloc de passar per les rondes d’atacs personals.
Si algun dels membres no se sent còmode a l’hora d’afrontar els problemes davant dels altres companys, pot anar més tard al Scrum Master i discutir-los.
Què es podria fer millor?
Aquesta part de la reunió dóna l'oportunitat a tots els membres de l'equip de debatre tots els problemes plantejats anteriorment i trobar les maneres de resoldre'ls. Tothom de l’equip és benvingut per proposar solucions al problema que ens ocupa. Aleshores, l’equip decideix en unitat les millors solucions adequades.
L’equip també hauria de plantejar-se adherir-se a les coses que es van discutir a la secció sobre el que va anar bé per als futurs sprints i, en el futur, aquestes coses es poden afegir com a part integral del procés.
El resultat de la reunió retrospectiva Sprint és una llista d’accions acordades pels participants per millorar el procés del proper sprint.
Assistents
Tot l’equip Scrum, inclòs Scrum Master i el propietari del producte. Però, a diferència d’una reunió stand-up diària, el Scrum Master i el Producte també participen a l’hora de proporcionar les seves aportacions i punts retrospectius.
Igual que la reunió Daily Standup, el Scrum Master també facilita la reunió retrospectiva Sprint. Scrum Master s’assegura que tothom de l’equip, inclòs ell, tingui l’oportunitat d’obrir-se i parlar tant dels aspectes positius com dels negatius.
Tingueu en compte que els participants externs a l’equip no estan convidats a Sprint Retrospective Meeting. Sprint Retrospective es considera un entorn personal i emocional poc permès que permet als membres de l’equip obrir-se sense dubtar-ho i discutir els problemes que han afrontat durant l’últim sprint.
Time-box
Es diu amb raó que totes les cerimònies Scrum tenen una caixa de temps i la seva caixa de temps depèn de la durada del Sprint. Dit això, durant un sprint de dues setmanes, és ideal tenir una reunió Sprint Retrospectiva durant 2 hores.
Tot i això, si considerem la Retrospectiva Sprint com una oportunitat per comunicar-nos, retrospectivament i comprometre’ns amb les millores, està molt justificat donar prou temps a la reunió per evitar perdre els punts de vista i punts de vista importants.
Per tant, és bo programar la reunió, però no s’hauria de fer a costa de la comunicació i la progressió. Un altre esdeveniment molt important a Scrum és el Restricció de retards. Prenem un moment ràpid per posar-hi una mica de llum.
Restricció de retards
El refinament de backlog, que també es coneix com a preparació de backlog, és una reunió per debatre les històries dels usuaris al Product Backlog que podrien formar part del proper Sprint. En una reunió de perfeccionament de treballs pendents, tot l'equip es reuneix i discuteix les històries dels usuaris proporcionant així les seves aportacions.
La idea general és preparar el Product Backlog per al proper Sprint i assegurar-se que les històries dels usuaris estiguin a punt per escollir-les. La reunió de restringiment de treballs pendents s’organitza durant el sprint ‘n-1’ per preparar-se per als articles que s’escolliran al sprint ‘n’.
Conclusió
Amb això, hem arribat al final d’aquest tutorial sobre ‘Scrum Events’, que és imprescindible per llegir-ne. Scrum Events és, amb diferència, el tema més important i significatiu de la sèrie Scrum.
En aquest tutorial, hem parlat dels cinc esdeveniments Scrum, és a dir Sprint, Sprint Planning, Daily Standup, Sprint Review i Sprint Retrospectiva . Cada esdeveniment que no sigui el standup diari té un cicle regular per sprint, és a dir, es realitza una vegada a cada sprint.
Els esdeveniments donen una idea de com es realitzen les tasques en un entorn Scrum. Tots els esdeveniments Scrum són oportunitats de millora, adaptació i inspecció.
El següent és un tutorial sobre 'Triaging de defectes', que és una reunió formal on es discuteixen i es trien tots els defectes de l'actual Sprint, és a dir, es prioritzen.
Lectura recomanada
- Artefactes Scrum: acumulació de productes, acumulació de Sprint i increments de producte
- Tutorial de JIRA Scrum Board: Manipulació de Scrum amb Jira per gestionar el Sprint
- Preguntes en línia sobre Agile Scrum: proveu els vostres coneixements sobre Agile Scrum
- Com oferir funcions de programari d’alt valor en un període curt de temps mitjançant el procés Agile Scrum
- Triaging de defectes a Scrum: com s’organitza en una configuració de Scrum
- Oportunitat de treball autònom a temps parcial per a experts en seleni
- Funcions i responsabilitats de l’equip Scrum: Scrum Master i propietari del producte
- 10 millors programes de rellotge de temps lliure per al seguiment del temps dels empleats