scrum artifacts product backlog
Introducció als artefactes Scrum:
En els articles anteriors d’aquesta sèrie, ens van presentar àgil i les diferents metodologies àgils . També vam conèixer com les diferents metodologies són diferents a la seva manera.
En el nostre darrer tutorial, vam entrar en els detalls de Scrum on vam discutir el Rols Scrum com el propietari de producte, Scrum Master i l’equip de scrum i van veure quines eren les seves responsabilitats individuals.
En aquest tutorial, continuem amb Scrum i aprofundim en els detalls sobre els diferents artefactes de scrum.
Què aprendreu:
- Diferents artefactes Scrum
- Registre de productes
- Sprint Backlog
- Increments del producte
- Conclusió
- Lectura recomanada
Diferents artefactes Scrum
Entre els tres tipus d’artefactes escrum s’inclouen:
- Retard de producte
- Sprint backlog i
- Increments de producte
Ara veurem què volen dir aquests termes i com crear aquests artefactes.
Registre de productes
Per dir-ho en termes senzills, un retard de producte és una llista de totes les coses que es requereixen al producte. És el document final que l’equip de scrum fa referència a qualsevol cosa relacionada amb el producte. És una llista ordenada d’elements propietat del propietari del producte (OP).
L’OP és responsable de crear, mantenir i prioritzar aquesta llista. Les OP fan servir aquest retard de producte per explicar als equips de scrum els requisits principals que cal fer durant el sprint.
Els elements d’aquesta llista poden estar o no en un llenguatge tècnic. Fins i tot pot ser un llenguatge profà, però ha de contenir tots els requisits del producte i els canvis que s’hi acompanyen. A més, tenir un retard de producte no significa que l'equip de scrum només tingui aquest artefacte a seguir.
Poden crear els seus propis artefactes detallats, però no contradiuen ni substituiran la cartera de productes. Més aviat estaran alineats amb els requisits de retard de producte.
A continuació es mostra un exemple de com pot ser un producte tardà típic:
Història | Estimació | Prioritat |
---|---|---|
Vull iniciar la sessió | 4 | 1 |
Vull tancar la sessió | 2 | 2 |
Vull canviar la contrasenya | 1 | 3 |
Vull actualitzar l'adreça | 3 | 4 |
Vull afegir un nou número de telèfon de casa | 1 | 5 |
Això ens porta a la pregunta, Com es pot crear un bon retard de productes?
L’endarreriment de productes hauria de seguir idealment les regles següents:
(i) S'hauria de prioritzar - Els articles a la cartera de productes s’han d’ordenar segons la seva prioritat. Aquesta prioritat la poden decidir junts l’OP i l’equip de scrum. Els factors de priorització poden ser qualsevol benefici com el punt de la història, l'esforç que suposa la creació, la complexitat, la prioritat del client, etc.
Ajuda l’equip a entendre el que s’ha de lliurar primer.
(ii) S’hauria d’estimar - Les històries sempre s’han d’estimar segons la definició acordada, sigui quina sigui. Això també es pot utilitzar per a la priorització.
(iii) Hauria de ser d’alt nivell - Les històries de la cartera de productes estan pensades per ser d’alt nivell i no haurien d’entrar en els detalls. La creació d’històries d’usuaris detallades segons el requisit correspon a l’equip scrum i no al PO.
(iv) Ha de ser dinàmic - El registre de producte no és un document estàtic final. S’ha de revisar a mesura que l’OP rebi aportacions de l’equip de scrum i els requisits del client siguin cada cop més clars. Per tant, els requisits del document no es congelen al principi, ja que hi ha addicions / supressions / modificacions previstes a mesura que avança el projecte.
L’últim punt és el més rellevant. El propòsit d'un retard de producte és ser una font activa de requisits. No s'ha de crear al principi i després mantenir-lo en un lloc d'emmagatzematge.
En lloc d'això, s'ha de compartir una i altra vegada a mesura que els canvis continuen apareixent. És possible que apareguin nous requisits a mesura que es faci el progrés i això també pot canviar la prioritat dels elements pendents. Hi haurà situacions en què un nou requisit depèn d’un altre element del registre, de manera que és possible que s’hagi de canviar la prioritat de l’element.
O pot ser que hi hagi una història crítica de l’usuari que s’hagi d’implementar primer perquè el client vol veure-ho abans que els altres, tot i que pot ser que no tingui prioritat segons els factors decidits per l’OP i l’equip de scrum.
Així, la cartera de productes és una llista ordenada de requisits empresarials propietat de l’OP i que es visita puntualment una vegada i una altra a mesura que avança el projecte.
Sprint Backlog
Recordeu que els equips de scrum treballen en breus iteracions de 2 a 4 setmanes anomenades sprint. Durant aquests sprints, l'equip de scrum identifica els elements del backlog de producte creat per l'OP, que tenen previst lliurar com a part de la següent iteració. Els ítems que l'equip de selecció selecciona per treballar passaran a formar part del backlog de sprint.
Així, decideixen quines funcionalitats hi haurà en la següent iteració del producte. L’equip de scrum és qui decideix què entrarà en el backlog de sprint, ja que són els que hi treballaran.
Per tant, són ells els que haurien d’estimar l’esforç que suposa implementar aquestes històries i decidir quant poden aportar.
L’equip no només selecciona els articles de la cartera de productes per treballar, sinó que també calcula el temps que trigaran a desenvolupar aquesta funcionalitat. També s’afegeixen a les històries d’usuaris d’alt nivell creant tasques detallades necessàries per assolir l’objectiu sprint.
Preguntes i respostes de l'entrevista del servidor sq ms
L’equip de scrum també pot continuar actualitzant el backlog de sprint quan i quan sigui necessari durant el sprint, però només l’equip de scrum pot fer canvis al backlog de sprint.
Un Sprint Backlog típic es veurà com es mostra a continuació.
L’equip pot actualitzar-lo idealment un cop al dia i el mestre de scrum pot utilitzar aquesta informació per crear un gràfic d’explicació de velocitat. Aquest gràfic d’informació ajudarà l’equip a veure quanta feina encara li queda per al sprint i l’equip pot planificar el seu treball en conseqüència. Fins i tot poden afegir o eliminar tasques si és necessari.
Algunes pràctiques recomanades mentre es crea un backlog de sprint poden ser:
# 1) Pren decisions de grup: No hauria de ser el mestre de scrum ni cap altre membre de l’equip de scrum qui decideixi el retard. Més aviat, hauria de ser tot l’equip qui decidís conjuntament sobre quins elements s’inclourien a la cartera d’esprint i com planificar-los.
Tots els membres d’aquest equip multifuncional aporten les seves pròpies habilitats i és essencial que utilitzem la seva experiència per crear el millor retard possible.
# 2) No assigneu tasques: Com s'ha repetit diverses vegades a la literatura àgil, no assigneu mai tasques als membres de l'equip. Se suposa que un equip de scrum és autosuficient i ha de saber organitzar el seu treball pel seu compte.
Per tant, en lloc d’assignar feina, hauríem de deixar que l’equip escollís la feina per si mateixos i decidís entre ells com volia procedir.
# 3) Definició de fet - No només haurien de ser acordats pels grups d'interès, sinó que també haurien de ser visibles per l'equip en tots els punts sempre que hagin de prendre alguna decisió sobre els objectius del sprint. Això us servirà per recordar el que cal fer exactament abans que puguin lliurar un producte que es pugui enviar.
# 4) Seguiu actualitzant el retard - És imprescindible que a mesura que el sprint evolucioni, l’equip adquirirà una comprensió més gran i, per tant, haurà d’actualitzar el backlog del sprint per reflectir també aquesta comprensió més gran. No hauria de convertir-se en cap document estàtic.
# 5) Afegiu qualsevol tasca - La tasca no només ha d’estar relacionada amb la codificació, sinó que pot ser essencial lliurar un producte que es pugui enviar. Per tant, mencioneu aquestes tasques també a l'endarreriment.
Increments del producte
Això ens porta a l’últim artefacte de scrum, que són els increments del producte. Tal com es defineix a la guia scrum, un increment és la suma de tots els fitxers Articles de retard de producte completat durant un Sprint i el valor dels increments de tots els Sprints anteriors. Com ja sabem bé, Scrum és un procés iteratiu.
El resultat de cada iteració és aquest increment de producte i cada increment d’aquest producte ajuda l’equip a fer un pas més cap a l’entrega del producte final.
El que això significa és que qualsevol que hagi estat el resultat del sprint és un increment. Viouslybviament, perquè el resultat es consideri un increment, primer hauria de complir la definició predefinida de fet, és a dir, el resultat final hauria de ser un producte útil que sigui capaç d’enviar-se.
Es pot comprovar, utilitzar i provar per assegurar-se que realment es fa 'segons' la definició i, si el propietari del producte ho desitja, es pot alliberar per publicar-lo també.
El més important per oferir aquest increment de producte és tenir una comprensió compartida de la 'definició de fet' que tots entenen.
L’equip de scrum mai no hauria de tenir cap dubte de si s’acceptarà o no el que fa. Si hi ha dubtes, la definició de fet hauria de ser prou completa com per guiar-los sobre com seguir endavant. Basant-se només en aquesta definició, l'equip de scrum decideix quants articles de retard de producte triar per al sprint.
Aquest és el mínim que s’espera fora del sprint.
Conclusió
A partir d’aquest tutorial, hem entès quins són els 3 artefactes scrum, qui els posseeix juntament amb algunes de les millors pràctiques que ens ajudarien a crear artefactes de millor qualitat. En els nostres propers tutorials d'aquesta sèrie, parlarem dels esdeveniments Scrum i veurem com executar-los.
Al nostre proper tutorial sobre ‘Scrum Esdeveniments , 'Discutirem detalladament cadascun dels esdeveniments Scrum!
Lectura recomanada
- Esdeveniments Scrum: Time Boxing, Sprint Planning, Stand-up diari i restringiment de retards
- Funcions i responsabilitats de l’equip Scrum: Scrum Master i propietari del 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
- El paper dels analistes de negocis a SCRUM i per què és millor un control de qualitat per a aquest paper?
- Triaging de defectes a Scrum: com s’organitza en una configuració de Scrum
- Exemples d'informes d'errors per a aplicacions web i de productes
- Els 9 millors programes PLM del 2021 per gestionar el cicle de vida del vostre producte