ÍNDEX

Model de treball Agile. 1

1.____ Fases model de treball <Scrum/CTTI>. 1

1.1______ Embarcament 1

1.2______ Esprint 0. 1

1.3______ Esprint N.. 1

1.4______ Producte. 1

2_____ Rols. 1

2.1______ Propietari de producte. 1

2.2______ Scrum Màster. 1

2.3______ Equip de desenvolupament 1

2.4______ Equip. 1

2.5______ Altres rols. 1

3_____ Artefactes i Compromisos Scrum... 1

3.1______ Pila de producte. 1

3.2______ Objectiu de producte. 1

3.3______ Pila d'esprint 1

3.4______ Objectiu de l'esprint 1

3.5______ Increment de producte. 1

3.6______ Definició de Llest 1

3.7______ Definició de Fet 1

4_____ Altres elements. 1

4.1______ Épica. 1

4.2______ Història d'usuari 1

4.3______ Full de ruta. 1

4.4______ Mapa d'històries. 1

5______ Cerimònies i esdeveniments. 1

5.1______ Planificació. 1

5.2______ Reunió diària. 1

5.3______ Revisió. 1

5.4______ Retrospectiva. 1

6_____ Mètriques i Reporting. 1

6.1______ Mètriques. 1

6.2______ Pràctiques de Reporting. 1

 

Model de treball Agile

En aquesta secció us presentem el model de treball <Scrum/CTTI>, on és la metodologia de desenvolupament àgil adaptada a l'entorn CTTI. Separat per seccions: Fases, Rols, Artefactes, Cerimònies... trobareu descrit cadascun dels elements que conformen el model de treball <Scrum/CTTI>, per saber-ne més de cadascun d'ells.

 

1.    Fases model de treball <Scrum/CTTI>

 

1.1         Embarcament

La fase d'embarcament comprèn des que es detecta una necessitat o es localitza una oportunitat de millorar per a la qual es pensa a desenvolupar una aplicació, fins que hi ha un proveïdor assignat i just abans que aquest comenci a treballar-hi.

·       Detecció de la necessitat

En aquesta fase, és quan es detecta una necessitat o una oportunitat de millora en qualsevol àmbit i que es vol desenvolupar. Aquesta necessitat o oportunitat, s’ha de definir molt bé per poder fer una anàlisi posteriorment.

·       Anàlisi de les possibles Solucions

Quan es tenen definides amb precisió les necessitats, és crucial procedir a una anàlisi exhaustiva de les possibles respostes i solucions disponibles. Aquesta anàlisi hauria de considerar no només les opcions internes, que provenen de dins de l'organització o l'entitat en qüestió, sinó també les opcions externes, que es podrien obtenir de fonts externes a l'organització.

·       Visió

La visió del producte, ha de ser clara, inequívoca i que respongui a una necessitat real dels usuaris. Al mateix temps tots els implicats en el desenvolupament del producte han de tenir una comprensió clara i compartida de la visió del producte. Això permet que totes les decisions de desenvolupament estiguin alineades amb aquesta visió. Una bona pràctica en aquest punt és realitzar un “Product Canvas”.

·       Assessorament Agile

Per poder valorar la idoneïtat de realitzar el projecte amb metodologies àgils, així com detectar aquells punts a reforçar o tenir en compte de cara al desenvolupament Agile, l’assessorament s’inicia amb un qüestionari d’autoavaluació, per posteriorment comentar els resultats i els diferents aspectes amb el Servei de suport a la governança d’enginyeria del software, qualitat i metodologies TIC Agile.

·       Creació de l’oferta

Cal expressar les necessitats en el marc de l’oferta, deixant especificats aquells requisits que són imprescindibles. Pot ser interessant incloure en la mateixa la creació de prototips o casos d’ús particulars.

·       Avaluació de l’oferta

En aquesta fase, és essencial realitzar una avaluació detallada i exhaustiva, atenent no només als aspectes que es poden valorar mitjançant criteris quantificables, sinó també als elements subjacents que poden ser més difícils de mesurar, però que tenen una influència substancial en la idoneïtat i l'èxit de l’opció seleccionada.

·       Preparació entorn de treball

Anticipar-se a les necessitats del proveïdor abans que aquest comenci, per tal de tenir-ho tot llest en el moment que correspon. Usuaris, adreces de correu electrònic, permisos, llicències, llocs de treball...
S’ha de tenir present tot allò que és responsabilitat de CTTI i que serà necessari per a l’inici.

 

1.1.1    Visió

La visió del producte descriu clarament quins problemes intenta resoldre i quines ambicions tenim de cara a futur.  La visió de producte és molt important per proveir motivació i propòsit a l'equip d’Scrum i l'alineament amb el negoci. Amb una visió apropiada, l'autogestió arriba a tenir sentit per orientar adequadament el focus de l'esforç compartit per lliurar valor.

Com crear una visió de producte

·       Descobrir la motivació

Les organitzacions solen crear productes amb objectius a llarg termini. La visió de producte ha de satisfer les motivacions, o el "per què" del producte.

 

·       Establir límits

Establir límits per a les funcions del producte, l'audiència a què se serveix i els factors de diferenciació. No es pot servir a tothom, per això s'ha de triar parts que interessin molt i quedar-se amb algunes d'elles.

 

·       Col·laborar i alinear-se amb els interessats

Cal treballar a tota l'organització per formar la visió de producte, això inclou qualsevol persona que exerceixi un paper en la creació i el llançament del producte.

Punts a destacar

·       Genera inspiració i motivació

A la gestió de producte la claredat de la visió del producte és crucial per inspirar i donar objectius a l'equip Scrum i per estar en consonància amb els objectius del negoci. Amb una visió ben establerta, la capacitat d'autogestió esdevé possible enfocant l'esforç conjunt cap a la generació de valor.

 

·       Millora la transparència

Definir, comunicar i difondre una visió és un treball extens abordat pel Propietari de producte (Product Owner) amb la col·laboració dels membres de l'equip Scrum i dels interessats (Stakeholders).

 

·       Relaciona el context de mercat

La visió defineix el client o mercat potencial, el problema que cal resoldre i el valor a lliurar. La visió també expressa l'avantatge competitiu i la solució potencial.

 

·       Brinda propòsit

La visió té el propòsit d'aportar valor al client perquè permeti millorar l'impacte en el negoci.

 

1.1.2    Oferta

Aquí és on tot comença formalment. Una necessitat, una oportunitat, una millora... Qualsevol d’aquestes o altres circumstàncies que desencadenen l’inici d’un nou desenvolupament, creació o actualització d’un producte, aplicació o servei.

En alguns casos són necessitats clarament identificades i conegudes, en altres casos la seva detecció es produeix de forma indirecta a conseqüència de canvis en el context o la tecnologia. És important des d’aquest mateix inici, identificar i involucrar a totes les parts interessades que puguin sumar.

Aspectes a definir

·       Descripció de la necessitat

Cal descriure la situació actual, justificació i els objectius que es persegueixen. Així com els resultats desitjats.

 

·       Enfocament de la solució

Cal descriure requisits o restriccions tècniques, consideracions, dependències i enfocament de desplegament.

 

·       Valoració quantitativa

Valoració quant a esforços, calendari i oferta econòmica.

 

·       Facturació

Definir el pla de facturació.

Punts a destacar

·       Interessats

És important a l’hora de descriure les necessitats tenir en compte els diferents punts de vista. Identificar clients, usuaris i interessats, els quals poden tenir visions i interessos contraposats.

 

·       Descripció

La descripció ha de fer referència a les necessitats i les funcionalitats necessàries. No avançar-se a la descripció de les característiques.

 

·       Estimació

L’estimació d’hores és orientativa de cara a la determinació de costos per la presentació d’ofertes per part dels proveïdors. La dedicació en hores de cada rol, no hauria de ser un criteri de valoració de les ofertes.

 

·       Coordinació

El pla de facturació ha d’anar associat al seguiment del compliment dels requeriments. Fer-ho coincidir temporalment amb les cerimònies establertes facilitarà la tasca.

 

1.1.3    Kick-off

La reunió de "Kick-off" de projecte és una trobada que es realitza al començament d'un projecte àgil per definir els objectius i les expectatives del projecte i establir la base per a una comunicació i col·laboració efectives entre els membres de l'equip, els interessats, promotors i clients.

És útil per

·       Establir una base sòlida

Assegurar una bona marxa del projecte amb governança, seguiment, acords de treball, rols i persones responsables.

 

·       Camí a seguir

Planificar amb un Roadmap que inclogui fites i lliurables per a una execució reeixida.

 

·       Definir objectius i abast

Establir objectius clars i definir amb precisió l'abast del projecte, concretant tant allò que s'hi inclourà com el que en quedarà exclòs.

 

·       Importància dels interessats

Identificar les parts interessades i definir rols i responsabilitats amb un "Stakeholders Map".

Punts a destacar

·       Acorda objectius

Permet acordar els objectius del projecte i els resultats esperats.

 

·       Defineix responsabilitats

Es defineixen els rols i les responsabilitats.

 

·       ANS i mètriques

S’estableixen els Acords de Nivell de Servei (ANS) i les mètriques per a la governança.

 

·       Full de ruta

S’acorda el full de ruta i les fites principals.

 

1.2         Esprint 0

A l’inici del projecte, l’equip haurà d’executar una primera iteració, anomenada Esprint 0. Consistirà a executar un conjunt de tasques o Històries d’Usuari (HU) definides per assegurar el correcte encaix de l’equip a l’inici del desenvolupament.

Algunes d’aquestes tasques són d’obligada realització per a tots els casos. Altres dependran de cada projecte. Les tasques a realitzar són les següents:

·       L’equip seleccionarà aquelles Històries d’Usuari que s’inclouran en el seu Esprint 0 i les posaran en ordre en un panell físic tipus Kanban. Les HU hauran de complir la corresponent DoR (Definició de Llest).

·       Els membres de l’equip s’assignen les HU al seu nom.

·       A mesura que es fa la feina, les HU canvien el seu estat, movent-se a la columna de la dreta del Kanban, fins a assolir l’estat “Fet".

                 Els passos a seguir durant la fase d’Esprint 0 són:

·       Comunicar Kick-off

·       Realització Kick-off

·       Planificació lliurables

·       Acordar DoR i DoD

·       Pla mestre de proves

·       Prototip

·       Integració amb Gicar

·       Procediments de desenvolupament

·       Document d’arquitectura

·       Hello World App

·       Revisar requisits

·       Aspectes contractuals

·       Assegurar capacitat de l’equip

·       Assegurar recursos

·       Acords d’equip

·       Mapa de “Interessats”

 

1.3         Esprint N

Un cop transcorregudes les fases d'Embarcament i l'Esprint 0, l'equip es troba en situació́ d'iniciar els esprints o iteracions ordinàries del projecte. L'esprint és el cor d’Scrum, un interval de temps de màxim un mes, que comença amb la Planificació d'esprint i finalitza amb la Retrospectiva.

Durant un esprint es desenvolupa l'increment d'un producte potencialment entregable, on l'equip de desenvolupament focalitza tots els seus esforços per aconseguir l'objectiu definit a la Planificació d'esprint.

Aspectes a tenir en compte

·       Respectar les cerimònies

Cada cerimònia de l'esprint ha de ser acuradament respectada per tot l'equip. Evitant canvis durant l’esprint que posin en perill l'Objectiu d'esprint.

 

·       Prioritzar objectius/requisits

És recomanable no treballar diversos objectius/requisits alhora, el primer que cal acabar és el més important per al client.

 

·       Cicles continus

Un esprint comença immediatament en finalitzar l'esprint anterior, no hi ha temps intermedis. Tenen un màxim d'un mes de durada, si es fessin esprints més llargs, potser les definicions del que estem fent canviïn, posant en risc l'èxit del projecte.

 

·       Limitació de temps

Els temps dels esprints no s'haurien de canviar al llarg d'un projecte, però això no és restrictiu i, si és necessari, es pot canviar. És important diferenciar que el que no hem de fer és anar canviant els temps esprint rere esprint.

             Beneficis de treballar amb esprints

·       Millora el focus

Treballar en fases permet millorar el focus. Atès que només es treballa durant un període de temps limitat en unes tasques concretes, l'equip s'enfoca i se centra en la realització d'aquestes.

 

·       Comunicació i transparència

Millora la comunicació i la transparència del projecte. El treball per fases exigeix ​​reunions periòdiques en què es posa en comú els èxits aconseguits a l'esprint anterior, aquelles tasques que no s'han finalitzat, per què no s'ha fet i com es pot millorar.

 

·       Treball en equip

Es potencia el treball en equip, enfocant tots els esforços i recursos per assolir un objectiu en comú. A més, l'equip es consciencia sobre la necessitat de millorar els seus mètodes de treball i s'esforçarà per fer-ho abans.

 

·       Major implicació del client

Augmenta la implicació del client final i de la resta de parts interessades (Stakeholders) relacionats amb el projecte. El client pot seguir el desenvolupament del seu producte sense haver d'esperar a veure un resultat final que potser no els convenç. En altres paraules: treballant amb esprints es minimitzen els riscos.

 

1.3.1    Discovery Track

A la metodologia <Scrum/CTTI> un esprint s’executa amb “Dual Track”, és a dir en dos fluxos de treball. En el track “Discovery” es treballen i s’analitzen les necessitats i requisits fins que les Històries d’Usuari (HU) estan en estat “Ready” que voldrà dir que la HU està a punt perquè l’equip de desenvolupament la realitzi.

·       El resultat són Històries d’Usuari “Ready”

La Història d’Usuari (HU) que està llesta (Ready) te el nivell de definició i claredat necessari i suficient, és a dir, l’equip ha entès perquè convé fer-la.

 

·       La Pila (Backlog) de “Discovery”

L’equip i el Propietari de producte (PO) exploren possibles solucions a implementar al producte. Són idees que passen per un procés d’experimentació i prototipatge, emprant tècniques com ara el “Design Thinking”. El cicle de vida d’aquestes idees, des que s’expressen fins que es validen, es gestiona al Kanban de Discovery, que proporciona informació a l’equip respecte del procés experimental i de descobriment. Un cop la idea està validada, l’equip dona la HU per definida si aquesta compleix la DoR (Definició de Llest).

Punts a destacar

·       Sincronitzat

L’equip que treballa en el “Discovery” és el mateix que treballa en el “Delivery”. Comparteixen cerimònies àgils: Reunió diària, Revisió, Retrospectiva.

 

·       Enfocament usuari

En contacte estret amb l’usuari, empatitzant i recuperant feedback.

 

·       Qualitat

Amb la DoR, el track de Discovery constitueix, defineix i especifica el nivell de qualitat del producte.

 

·       Centrat a Producte

Es col·labora estretament amb els Gestors de Producte, per alinear objectius i resultats.

 

1.3.2    Delivery Track

A la metodologia <Scrum/CTTI> un esprint s’executa amb “Dual Track”, és a dir, en dos fluxos de treball. En el track “Delivery” es desenvolupen les funcionalitats i requisits que estan “Ready” fins que les Històries d’Usuari estan en estat “Done”. Això vol dir que l’increment de producte està a punt per passar a producció.

·       El resultat són increments de Producte

Les Històries d’Usuari que provenen del track de “Discovery”, que es troben a la Pila de producte (Product Backlog) en estat “Ready”, s’introdueixen al flux de desenvolupament “Delivery” mitjançant la Planificació d'esprint. L’equip planifica què i com desenvoluparà el conjunt d’HU per tal de complir l’Objectiu de l’esprint (Sprint Goal). Durant l’execució de l’esprint realitza el desenvolupament fins que cada HU compleix la DoD (Definició de Fet).

 

·       Scrum, el procés de “Delivery”

El “Delivery Track” és el que la majoria de la gent coneix com a procés àgil o scrum. Aquest track pren les idees validades del “Discovery” i les aplica al producte acabat. Gràcies al Dual Track de <Scrum/CTTI> això és més senzill, les idees ja estan validades, de manera que l’equip de desenvolupament pot centrar-se en la millor manera de desenvolupar-les, a més, estan segurs que les funcionalitats que estan creant són importants per als usuaris.

Punts a destacar

·       Sincronitzat

L’equip que treballa en el “Discovery” és el mateix que treballa en el “Delivery”. Comparteixen cerimònies àgils: Reunió diària, Revisió, Retrospectiva.

 

·       Produeix valor

El “Delivery Track” materialitza el valor per l’usuari en forma d’Història d’Usuari “Done”.

 

·       Qualitat

Amb la DoD, el track de “Delivery” constitueix, defineix i especifica el nivell de qualitat del producte.

 

·       Eficient

No es perd temps desenvolupant funcionalitats que no siguin valuoses per a l’usuari.

 

1.4         Producte

Un producte és qualsevol instrument que satisfà una necessitat de negoci i, com a conseqüència, proporciona valor als usuaris.
Des d’una perspectiva TIC, són productes qualsevol combinació de programari, suport físic, dades i serveis adreçats a un públic concret i que donin resposta a les seves demandes o necessitats.

Característiques d’un producte

·       Cobreix una demanda. Un producte és aprofitable i, per tant, respon a una necessitat.

·       La seva elaboració comporta un cost. Crear un producte suposa dedicar-hi certs recursos.

·       És planificat. Un producte és el resultat d’una cosa prèviament estudiada i planificada.

·       Passa per un procés productiu. És la fase en què es desenvolupa un producte.

·       Pot ser tangible o intangible. Depenent de l’element, pot ser tocable físicament (producte) o no es pot tocar (servei).

   Cicle de vida d’un producte

·       Introducció

En aquesta fase, trobem la part del MVP (Minimum Viable Product), un descobriment, un disseny, provar a veure el que funciona. S’ha d’intentar, també, tenir una visió del que es vol o cap a on es vol anar.

 

·       Creixement

És on hi ha tota la part d'implementació, d'escalabilitat i de posada en producció de versions que ampliï l’MVP. Es treure el mínim necessari al mercat per poder testejar si realment la nostra visió té sentit, si això encaixarà amb les necessitats del mercat, dels usuaris i parts interessades.

 

·       Maduresa

Un cop el producte es troba consolidat, les accions que s'hi duen a terme són, majoritàriament, accions d'operació, manteniment i suport als nostres usuaris.

 

·       Declivi

Un cop un producte ja no aporta el valor desitjat als usuaris es procedeix a la seva retirada i desmuntatge, tant físic com de programari. Cal gestionar què cal fer amb el servei que donava, amb les dades que hi havia...

 

2      Rols

 

2.1         Propietari de producte

El Propietari de producte o Product Owner (PO) és la persona que té la responsabilitat de definir i prioritzar les funcionalitats i característiques del producte que s'està desenvolupant.

Responsabilitats

·       Comunicar la visió del producte

Comunica clarament la visió del producte a l'equip Scrum per garantir un objectiu comú.

 

·       Creació de la Pila de producte (Product Backlog)

Crea la Pila de producte, descomponent funcionalitats en increments valuosos.

 

·       Gestió de producte

Gestiona requisits amb direcció del producte (PM) i interessats. Prioritza per valor: Històries d'Usuari, Èpiques i Requisits no Funcionals (NFR).

 

·       Mesurar l’èxit

Identifica indicadors per mesurar l'èxit del producte i avaluar l'impacte i els objectius assolits.

Habilitats

·       Lideratge

Proporciona orientació, direcció i motivació a l’equip de desenvolupament, inspirant-los per aconseguir bons resultats.

 

·       Empatia

Li permet entendre i connectar amb les perspectives, reptes i motivacions dels interessats i membres de l’equip.

 

·       Flexibilitat

Ser adaptable i flexible permet als PO moure’s en un entorn dinàmic i canviant constantment. Cal estar obert a les aportacions, acollir noves idees i estar disposat a ajustar plans i prioritats.

           

·       Negociació

Les habilitats de negociació són essencials per abordar prioritats en conflicte, gestionar les expectatives dels interessats i resoldre conflictes de manera efectiva.

 

2.2         Scrum Màster

L’Scrum Màster (SM) és la persona que té la responsabilitat del compliment de les regles d’Scrum. S’assegura que aquestes són enteses per l’organització i que es treballa d’acord amb elles.

Responsabilitats

·       Maximitzar eficiència de l’equip

Fa visible l'estat actual perquè els integrants es puguin adaptar i funcionar amb més rendiment, i també pot gestionar canvis en l’equip (reemplaçar o afegir persones).

 

·       Efectivitat de l’equip

S'assegura que els membres de l'equip estiguin ben capacitats i comprenguin els valors i els principis, i els esdeveniments i artefactes de l'Scrum.

 

·       Eliminar impediments

En cas de qualsevol impediment que l'equip no pugui resoldre ràpidament per si mateix, l’Scrum Màster treballa dins l'equip, per eliminar-lo.

 

·       Ensenyar pràctiques i principis

Lidera l’organització en la implementació d’Scrum mitjançant capacitació, entrenament i assessorament. Això inclou ensenyar i defensar els valors i l’estructura d’Scrum.

Habilitats

·       Mentor

Fa servir la seva experiència per ajudar les altres persones, recolzant-les, brindant comentaris sobre el seu treball i oferint orientació mentre resolen problemes a la feina.

 

·       Lideratge

Serveix l’equip Scrum i tota l’organització. Posa sempre el seu equip en primer lloc a la llista de prioritats, empodera a l’equip i en valora a cada persona (Servant Leader).

 

·       Coach

Ofereix orientació per ajudar els altres a assolir els seus objectius professionals o personals i permet a aquells a qui serveix que aconsegueixin els seus objectius.

 

·       Manager

Responsable de gestionar els impediments, eliminar el malbaratament, gestionar el procés, els límits de l’autoorganització i la cultura.

 

2.3         Equip de desenvolupament

L’equip de desenvolupament és un equip que té un coneixement complementari. Entre tots ells han de poder abordar tot el que hi ha en la Pila del producte. Són els responsables de decidir com construir el producte de la millor forma, és a dir, la manera com assoliran l’Objectiu de l’esprint.

Responsabilitats

·       Creació de l’Increment en l’esprint

Responsables de la creació d’increments en l’esprint, i també d’adherir-se a la DoD (Definició de Fet) en crear-los.

 

·       Creació del pla de l’esprint

Un cop els elements de la Pila de producte compleixen amb la DoR (Definició de Llest), poden crear el pla per cada esprint (Pila de l’esprint).

 

·       Refinament

El refinament de les Històries d’Usuari ens permet tenir converses necessàries i afegir el detall necessari perquè compleixi la DoR i que els requisits del producte s’entenguin i siguin clars per tot l’equip.

 

·       Adaptació del pla de forma contínua

Revisen dia a dia l’avenç cap a l’Objectiu de l’esprint (Sprint Goal) i detecten desviaments i prenen les decisions necessàries per adaptar el pla, amb l’objectiu de corregir qualsevol eventualitat.

Habilitats

·       Equip multidisciplinari

Està compost per persones amb diferents competències necessàries per completar cada increment de producte.

 

·       Equip auto organitzat

Ningú no diu a l’equip com convertir la Pila de producte en increments al llarg de cada esprint. Tot l’equip ha de tenir molt clara i present la visió del producte.

 

·       Col·laboració amb altres membres de l’equip

Com a desenvolupador es treballa en estreta col·laboració amb altres membres de l’equip, per garantir que l’equip estigui alineat i treballant cap als mateixos objectius.

 

·       Flexibilitat

Ha de respondre ràpidament als canvis i ajustaments necessaris per mantenir el projecte en el camí correcte.

 

2.4         Equip

Un equip àgil es un grup de persones multidisciplinari, de fins a deu persones, que tenen totes les capacitats i coneixements necessaris per a definir, construir, desenvolupar i lliurar valor al seu client i usuaris. Està format pel Propietari de producte, l’Scrum Màster i l’Equip de desenvolupament.

Responsabilitats

·       Crear valor

Prioritzar i desenvolupar funcionalitats que aportin valor real als usuaris i a les parts interessades, amb entregues freqüents i valuoses.

 

·       Planificar el treball

Elaborar una planificació col·laborativa, transparent i efectiva en les cerimònies d'esprint per garantir l'acompliment dels objectius.

 

·       Connectar amb el client

Establir una comunicació directa amb el client/usuari, i empatitzar amb les seves necessitats per garantir la satisfacció i la realització del valor esperat.

 

·       Gestionar els rols

Assegurar que els rols clau com el Propietari de producte i l’Scrum Màster compleixen amb les seves responsabilitats per aconseguir l'èxit dels projectes àgils.

Habilitats

·       Multidisciplinari

Posseeix una varietat de coneixements i habilitats necessàries per proporcionar valor al client i usuaris de manera completa i eficaç.

 

·       Aprenentatge ràpid

Està capacitat per assimilar de manera àgil i eficient noves idees, tècniques o coneixements, amb l’objectiu de millorar processos i resultats.

 

·       Feedback continu del client/usuari

Manté una línia de comunicació constant amb els clients/usuaris per tal d’obtenir una comprensió profunda de les seves opinions, necessitats i suggeriments, afavorint la millora contínua del producte o servei.

 

·       Adaptació ràpida del producte

Té la flexibilitat i agilitat per ajustar-se als canvis, ja sigui en les necessitats del client o en el context del projecte, per assegurar la millor resposta possible.

 

2.5         Altres rols

En Scrum hi ha altres rols que són secundaris i que també intervenen durant l’execució de l’esprint. Aquests rols són: Interessats (Stakeholders), Client i Usuaris.

·       Usuaris

Un usuari és una persona que utilitza un producte o servei de manera habitual, obtenint-ne algun benefici, sense entrar a valorar-ne les característiques tècniques. Simplement, fa ús del producte o servei en qüestió.

§  Experiència d’usuari

§  Fidelitat

 

·     Client

El client és qui defineix i acorda el servei o el producte que vol implementar. Tots els requisits del producte s'han de comentar amb el Propietari del producte (PO) i donar-li indicacions necessàries per tal que els pugui prioritzar.

§  Col·laboratiu

§  Pacient

§  Ambaixador

§  Avaluador

 

·       Interessats (Stakeholders)

Un interessat (Stakeholder) és una persona externa a l'equip Scrum, amb interessos específics i coneixement o ús del producte. Són individus que es veuen afectats d'alguna manera amb el resultat del producte, ja sigui que els generi beneficis econòmics o algun tipus de millora a les seves vides.

§  Font d’informació

§  No formen part de l’equip Scrum

 

3      Artefactes i Compromisos Scrum

 

3.1         Pila de producte

La Pila de producte és una llista ordenada d'elements a implementar, com funcionalitats i requisits. És necessària per tenir presents les necessitats de l’usuari, centrar-se en allò que més valor li aporta i prioritzar les històries. El Propietari de producte (PO), en contacte amb usuaris i clients, reflecteix les necessitats a la Pila (Backlog).

És útil per

·       Priorització efectiva

Permet ordenar les funcionalitats i requisits del producte segons la seva importància i valor, garantint que l'equip de desenvolupament es centri en les tasques més rellevants.

 

·       Visibilitat clara

Proporciona una visió completa de tot el treball a realitzar, assegurant que tot l'equip tingui una comprensió compartida dels objectius del projecte.

 

·       Flexibilitat adaptativa

La Pila de producte és flexible i pot adaptar-se als canvis en les necessitats dels usuaris o clients, permetent una resposta àgil a les demandes del mercat.

 

·       Fomenta la col·laboració

Afavoreix la col·laboració entre l'equip de desenvolupament, el PO i altres interessats, promocionant la comunicació, l'aliança d'interessos i la presa de decisions consensuada mitjançant la revisió i refinament de la Pila de producte.

Punts a destacar

·       Refinament

El refinament de la Pila de producte és el procés de col·laboració entre el Propietari de producte, l'equip de desenvolupament i altres interessats per aclarir i detallar les Històries d'Usuari de la Pila de producte. Aquest procés és conegut també com a "Backlog Grooming" o "Backlog Refinement".

 

·       Pila de producte i Objectiu del producte

La Pila de producte (Product Backlog) i l’Objectiu del producte (Product Goal) estan estretament relacionats en un projecte Agile. L’Objectiu del producte és una declaració clara i concisa dels objectius a aconseguir amb el producte i guia principalment al Propietari de producte en la gestió de la Pila de producte.

 

3.2         Objectiu de producte

L'Objectiu de producte (Product Goal) es defineix com un compromís associat a la Pila de producte (Product Backlog), que descriu un estat futur del producte i que serveix a l'equip Scrum per fixar-se una meta a llarg termini per planificar. L'Objectiu de producte dona rumb a l'equip Scrum.

Consideracions a tenir en compte

·       Elements de la Pila de producte

L'equip Scrum se centrarà en un únic Objectiu de producte en un moment determinat. És important no perdre el focus introduint a la Pila altres elements relacionats amb altres objectius de producte potencials o futurs.

 

·       Equip Scrum

Abans de passar al següent Objectiu de producte, s'ha d'haver aconseguit o descartat l'anterior. És una qüestió de focus.

 

·       Propietari de producte

A la Planificació d'esprint, el PO ha d'assegurar-se que els assistents estan preparats per comentar els elements més importants de la Pila de producte i com connecten amb l'Objectiu de producte.

 

·       Revisió d'esprint

El progrés cap a la consecució de l'Objectiu de producte ha de tractar-se a la Revisió, juntament amb els interessats que hi assisteixin.

Com aconseguir un Objectiu de producte?

·       Visió de producte

És la base per descobrir els usuaris, clients i interessats als quals ens adreçarem, les seves necessitats i l’encaix de la proposta i crea el context per determinar l’Objectiu del producte.

 

·       Usuaris, clients, interessats i metes de negoci

Tenir ben identificats aquests usuaris, distingint-los, si s’escau dels clients i la resta d’interessats. S’ha de poder anar definint les nostres metes de negoci, les propostes de valor del producte i els beneficis desitjats.

 

·       Objectiu de producte

És l’estat futur del producte, els beneficis desitjats o el resultat que el producte hauria de generar.

 

·       Objectiu d'esprint

És el benefici d'un esprint.

 

3.3         Pila d’esprint

La Pila d'esprint (Sprint Backlog) és un dels tres artefactes d’Scrum i es construeix durant l’esdeveniment de la Planificació d’esprint (Sprint Planning). És un pla fet per i per als desenvolupadors de l'equip Scrum.
És un artefacte que pretén ser una imatge molt visible i en temps real de la feina que els desenvolupadors tenen planificada per realitzar durant l'esprint per assolir l'Objectiu d'esprint. D’aquesta manera es fomenta el pilar d’Scrum de la transparència.

Gestió de la Pila d'esprint

·       Compromís

El compromís de la Pila d'esprint es coneix com a Objectiu d'esprint (Sprint Goal).

 

·       Ítems de la Pila d'esprint

L'equip divideix el treball en elements i aquests poden representar tasques que l'equip ha de completar, que ajudin l'equip a comprendre com aconseguir l'Objectiu d'esprint dins de l'esprint.

 

·       Revisió d'esprint

Les tasques que l’equip de desenvolupament va determinar per aconseguir l'increment que es lliurarà al final de l'esprint i que s'inspeccionarà durant la Revisió d'esprint (Sprint Review).

 

·       Equip de desenvolupament

Té la responsabilitat de crear el pla per a cada esprint. Per aconseguir-ho, és fonamental fer estimacions del treball a fer i determinar quant d'aquest treball pot completar durant la iteració actual. A més, ha de desglossar el treball en tasques més petites i assegurar-se que hi hagi coherència en el conjunt de tasques.

Aspectes a tenir en compte

·       No hi ha un pla perfecte

La Pila d'esprint és un pla de treball incomplet a propòsit. El treball sorgirà i s'acabarà de consolidar durant l'esprint gràcies a la naturalesa empírica d’Scrum, sense perdre de vista l'Objectiu d'esprint.

 

·       No és fixa

La Pila d’esprint no és fixa, sinó que s’anirà actualitzant durant l'esprint en funció de l'aprenentatge que es vagi assolint. Si cal fer modificacions, aquestes sorgiran dels acords entre els desenvolupadors i el PO, sempre sense posar en perill l'Objectiu d'esprint.

 

3.4         Objectiu de l’esprint

L'Objectiu d'esprint (Sprint Goal) és l'objectiu més important que l'equip Scrum ha de complir durant l'esprint. Ha de ser assolible mitjançant la realització d'un conjunt coherent d'ítems de la Pila de producte (Product Backlog), i serveix de guia a l'equip de desenvolupament per saber perquè estan construint aquest Increment.

Com deixem llests la Pila de producte i l’Objectiu d'esprint?

·       Ordenat i actualitzat

Tenim un artefacte que ha d’estar ordenat i actualitzat que és la Pila de producte amb un Objectiu de producte (Product Goal).

 

·       Increment sòlid

Mirant el que tenim a la Pila de producte, identifiquem un fil conductor i seleccionem allò que en conjunt ofereixi un increment de producte sòlid i concís.

 

·       Refinament

Tot això s'acaba de polir en les sessions de refinament i es concreta aquest objectiu (Objectiu d’esprint) abans de la Planificació (Sprint Planning).

 

·       Tècniques recomanades

Hi ha diverses tècniques recomanades per a definir l’Objectiu d’esprint, com per exemple les tècniques de: “Top-Down” i “Bottom-Up”.

Punts a destacar

·       Enfocat a aconseguir resultats i objectius de negoci

Aconseguir resultats o outcomes (és un canvi mesurable en el comportament del client) que ajuden a assolir un impacte en el negoci.

 

·       Proveeix un propòsit

Fomenta l'autoorganització, la col·laboració i la creativitat. També fomenta l'ús dels valors d’Scrum.

 

·       Millora l’ús dels tres pilars d’Scrum

Facilita la transparència del progrés, millora la inspecció i l'adaptació durant l'esprint.

 

·       Es crea conjuntament per l’equip d’Scrum

No canvia durant l'esprint i brinda flexibilitat per aconseguir-ho.

 

3.5         Increment de producte

L’increment és la part de producte produïda en un esprint i que es troba en condicions de ser lliurada al client, és a dir, acabada, provada i operativa. El responsable dels increments, és tot l’equip Scrum.

És útil per

·       Avenç real

L’increment representa un avenç real, un pas cap a l’Objectiu del producte (Product Goal). L’Objectiu del producte és l’objectiu a llarg termini de l’equip Scrum, i cal complir un objectiu abans d’assumir el següent. Cada esprint hauria d’apropar el producte a l’Objectiu del producte.

 

·       Valor

L’increment representa valor pel client i per proporcionar el valor, l’increment ha de ser utilitzable. El fet de lliurar valor, ofereix la capacitat de verificar si el projecte està en el camí correcte i obtenir feedback que ajudarà a donar forma a futures iteracions.

 

·       Qualitat

L’increment és un ítem de la Pila de producte finalitzat que compleix amb la DoD (Definició de Fet). No existeix increment si no compleix amb ella. L’increment ha de complir amb les mesures de qualitat que requereix el producte.

 

·       Entregables

Durant un mateix esprint es poden crear diversos increments, ja que, en realitat, tan aviat com un element de la Pila de producte seleccionat per a l’esprint compleix la DoD neix un increment.

Punts a destacar

·       Compromís

El compromís de l’increment, és la DoD (Definició de Fet). Els responsables d’adherir-se a la DoD quan es crea el producte, són els desenvolupadors.

 

·       Revisió de l’esprint

Tanmateix tota Història d’Usuari que compleixi amb la DoD, suposa un Increment de producte i, per tant, és susceptible de pujar a producció si el Propietari de producte (PO) ho determina sense necessitat d’esperar a la Revisió (Sprint Review). L’increment es presenta a la Revisió per obtenir feedback sobre el producte i adaptar la Pila de producte si s’escau.

 

3.6         Definició de Llest

La Definició de Llest (DoR) fa referència a les condicions que una Història d'Usuari (HU) ha de complir perquè l'equip la pugui incloure en el track de Delivery d'un esprint. Una HU que està llesta ("Ready") té el nivell de definició i claredat necessari i suficient, a més, l'equip ha entès per què és convenient dur-la a terme.

És útil per

·       Ajudar a l’equip

Ajudar a l’equip a analitzar millor les necessitats i requisits, abans d’implementar-los.

 

·       Gestionar el producte

Quan diversos equips col·laboren per desenvolupar un mateix producte, la DoR permet acordar criteris i obtenir claredat de l'abast de la feina de cada equip.

 

·       Millorar la comunicació

Fomentar la col·laboració entre el Propietari de producte i l’equip de desenvolupament.

Punts a destacar

·       La DoR obre camí

Si la Història d'Usuari (HU) compleix les condicions acordades, pot seguir el seu camí cap a l'esprint.

 

·       Pot ser opcional

Si l'equip és madur per analitzar i descriure les Històries d'Usuari (HU), se'n pot prescindir.

 

·       Resultat del Discovery

En el track de "Discovery" es treballen les Històries d'Usuari (HU) fins que estan "Ready".

 

Per a més informació sobre els criteris de DoR, ho podeu consultar en la web de Qualitat.

 

3.7         Definició de Fet

La Definició de Fet (DoD) és una definició que estandarditza l'estat necessari d’una Història d'Usuari o tasca per assegurar la qualitat de treball final i del producte. Per a ser considerada “Done”, la HU ha de complir tots els criteris definits. Això millora la transparència, prevenint malentesos entre l’equip i altres interessats, i garanteix la qualitat del producte, establint les condicions essencials per a la finalització.

És útil per

·       Augmentar la transparència en el desenvolupament

Augmentar la transparència per evitar malentesos i confusions entre els membres de l'equip i altres parts interessades.

 

·       Assegurar la qualitat del producte

Assegurar la qualitat del producte establint clarament les condicions necessàries per a un producte acabat.

Punts a destacar

·       Impulsa la productivitat

Permet identificar les tasques que encara s’han de completar.

                      

·       Redueix residus

Elimina la possibilitat de fer tasques innecessàries.

 

·       Resultat de l’aprenentatge

La DoD s’actualitzarà quan l’equip identifiqui millores en la qualitat, gràcies a anar completant treballs.

Per a més informació sobre els criteris de DoD, ho podeu consultar en la web de Qualitat.

4      Altres elements

 

4.1         Èpica

L'èpica és un terme utilitzat per descriure un tipus d'element de treball o requisit d'alt nivell que és massa gran per ser completat en una sola iteració o esprint.
Una èpica és essencialment una Història d'Usuari molt gran i complexa que es divideix en diverses Històries d'Usuari més petites i manejables perquè puguin ser planificades i lliurades dins un esprint.

Característiques d’una èpica

·       Les èpiques solen impactar en diverses funcionalitats a la vegada.

·       Cada èpica està dividida en diferents Històries d’Usuari.

·       Normalment recullen moltes Històries d’Usuari.

·       Una èpica ajuda a estructurar un tema en concret que es vulgui desenvolupar o crear de forma més detallada.

·       Les èpiques donen flexibilitat i agilitat al projecte, ja que es divideixen en diferents Històries d'Usuari perquè s'entengui millor la funcionalitat a treballar.

·       El PO parla amb els clients/ usuaris/ interessats per determinar si eliminen o afegeixen històries dins de cada èpica.

·       Cada Història d’Usuari en que s’ha descompost una èpica, acabarà estant assignada a un membre de l’equip.

·       Una èpica sol estar en més d’una iteració o esprint.

És útil per

·       Descriure les funcionalitats d'alt nivell

Les èpiques s'utilitzen per descriure les funcionalitats o característiques d'alt nivell que l'equip d’Scrum ha de desenvolupar. Es divideixen en Històries d'Usuari més petites i manejables durant el procés de planificació de l'esprint, i cada Història d'Usuari es pot estimar i desenvolupar de forma independent.

 

·       Millor comprensió

La descomposició d'una èpica en Històries d'Usuari permet que l'equip d’Scrum tingui una millor comprensió dels detalls del treball i dels requisits específics, cosa que ajuda a planificar i gestionar el treball de forma més eficient.

 

4.2         Història d’usuari

Una Història d'Usuari (HU) és una breu descripció d'una funcionalitat del producte des de la perspectiva de l'usuari final. Els membres de l'equip Scrum utilitzen les "Històries d'Usuari" per comprendre les necessitats dels clients i per identificar els requisits del producte. Les Històries d'Usuari estan escrites en llenguatge natural i són fàcils de comprendre per a tothom.

Utilitzar la plantilla "Qui... / Què... / Per què.../ Com...”

Una plantilla útil per escriure una Història d’Usuari és la següent: "QUI (Tipus d’usuari), QUÈ (Objectiu), PER QUÈ (Motiu o Valor aportat), COM (Criteris d’acceptació)". Això ajuda a definir clarament qui és l'usuari, què vol fer, per què ho vol fer i com ho vol fer.

Per exemple, "Com a comprador, vull poder afegir un producte per poder-lo comprar més tard".

Criteris d’acceptació:

·       En afegir un producte vull que aparegui a la llista amb el preu i la disponibilitat.

·       El total s’ha d’actualitzar sumant l’import del producte afegit.

Utilitzar el criteri INVEST

INVEST és un acrònim que significa Independent, Negociable, Valuosa, Estimable, Petita (Small) i Testejable. Crear HU amb aquests criteris ajuda a poder gestionar millor la planificació i el desenvolupament a cada esprint. Per exemple, una Història d'Usuari que compleix aquest criteri podria ser "Com a comprador, vull veure els productes més venuts per poder triar els millors productes sense haver de cercar".

 

4.3         Full de ruta

En el context d'un projecte de desenvolupament de programari amb metodologia àgil, el full de ruta o Roadmap serveix com a eina de planificació i comunicació, per a establir les prioritats i la visió general del producte que es vol construir.
Facilita la planificació, priorització i comunicació, garantint que l'equip estigui alineat amb els objectius i la visió general del producte, mentre es manté la flexibilitat necessària per adaptar-se als canvis i oportunitats que puguin sorgir al llarg del camí.

Ha d’incloure

·       Visió del producte

Descriu el valor que el producte aportarà als usuaris i les necessitats del negoci que satisfarà. Proporciona una visió general clara i concisa del propòsit i l'objectiu del projecte.

 

·       Prioritats d'èpiques i funcionalitats i dependències

Especificació de les prioritats de les èpiques i funcionalitats, així com les interrelacions entre elles, per a una planificació eficaç i per abordar possibles restriccions.

 

·       Èpiques i funcionalitats més importants per cada entrega o versió

Identificació de les grans funcionalitats (èpiques) i les funcionalitats importants que s'inclouran en cada entrega o versió per al desenvolupament del producte.

 

·       Fites, lliurables i Releases

Presentació de les dates clau, els lliurables i les versions del producte (Releases) per a un seguiment precís del progrés i l'entrega del producte en etapes incrementals.

Punts a destacar

·       Planificació i execució eficient

Permet a l'equip planificar i executar el treball de manera eficient, establint una direcció clara i definint les èpiques i funcionalitats per a cada entrega o versió.

 

·       Revisió i actualització regular

S'ha de revisar i actualitzar regularment per assegurar-se que reflecteix les prioritats actuals i les lliçons apreses durant el desenvolupament. Això permet mantenir una visió actualitzada del producte i respondre als canvis del mercat o les necessitats del client.

 

·       Flexibilitat i adaptabilitat

Un full de ruta àgil ha de ser flexible i adaptar-se a les necessitats canviants del projecte. Això permet respondre ràpidament a les oportunitats emergents o als nous requeriments que puguin sorgir durant el desenvolupament.

 

·       Visió del progrés i contribució

Dona una idea clara a l'equip de com progressen i com el treball diari contribueix al producte en conjunt. Això fomenta la transparència i motiva els membres de l'equip al veure el resultat del seu esforç i la seva aportació al projecte.

 

4.4         Mapa d’històries

Un mapa d'Històries, anomenat "Story Mapping," és una representació visual de les Històries d'Usuari d'un producte, organitzades per experiència de l’usuari i prioritat. Ajudant a definir funcionalitats, identificar mancances i prioritzar, promou l'eficiència dels recursos i la coherència del producte. A més, fomenta la transparència cap a l'equip i parts interessades, oferint claredat sobre les tasques i el progrés.

És útil per

·       Definir les funcionalitats

En el mapa d’Històries, es defineixen amb detall les funcionalitats o característiques del producte amb la col·laboració de l'equip i els interessats.

 

·       Visualitzar mancances i oportunitats

Mitjançant el mapa d’Històries, es pot veure de manera clara les mancances funcionals i detectar oportunitats d'innovació en l'experiència de l'usuari.

 

·       Prioritzar les funcionalitats

El mapa d’Històries ajuda a prioritzar les funcionalitats, assegurant una composició coherent i abordant les més importants primer.

 

·       Donar transparència i visibilitat

Amb el mapa d’Històries, l'equip té una visió transparent de la feina a fer, evitant malentesos i facilitant la comunicació amb interessats.

Punts a destacar

·       1r pas: Ideació

Cal obtenir idees (noves o no) per tal d'exposar les funcionalitats del producte en desenvolupament.

 

·       2n pas: Categorització

Cal agrupar les funcionalitats en conjunts coherents que tinguin en compte l'experiència de l'usuari. En aquest mapa, s'exposen els temes i subtemes.

 

·       3r pas: Priorització

Prioritzem totes les característiques entre elles, dins d'una mateixa columna però també respecte a la resta de temes. És possible definir el MVP (Minimum Viable Product).

 

·       4t pas: Explotació

Un cop construït el mapa d’Històries, cal utilitzar-lo, compartir-lo i revisar-lo durant tota la vida del producte. Ha de ser l'únic pla de construcció de referència per al producte.

 

5      Cerimònies i esdeveniments

 

5.1         Planificació

L'objectiu de la planificació de l’esprint és crear un pla acordat per a l'equip de desenvolupament pel següent esprint. Això inclou establir les fites de l'esprint, seleccionar els elements prioritaris de la Pila de producte i descompondre'ls en tasques concretes que l'equip pugui implementar dins del període de temps de l'esprint. Aquesta reunió ajuda l'equip a obtenir una comprensió compartida del que s'ha de fer i com ho faran. També ha de definir l’Objectiu de l’esprint (Sprint Goal).

·       Preparar prèviament

Tant el Propietari de producte com l'equip de desenvolupament han de revisar la Pila de producte (Product Backlog) i comprendre els requisits abans de la reunió. Això permetrà un debat més productiu durant la Planificació d’esprint.

 

·       Limitar les discussions

Si sorgeixen discussions detallades sobre un tema específic, és important establir un temps límit i decidir si s'abordarà més endavant o si cal establir una reunió addicional per aprofundir-hi.

 

·       Facilitar la participació de tothom

Cal assegurar-se que tots els membres de l'equip d’Scrum tinguin l'oportunitat de compartir les seves opinions i prendre decisions conjuntes. Evitar que una sola persona domini la reunió i promoure la participació activa de tots els rols implicats.

 

·       Promoure la transparència

Compartint informació rellevant i assegurant-se que tothom tingui una comprensió clara dels objectius i dels requisits dels elements de la Pila de producte.

 

5.2         Reunió diària

La cerimònia de la Reunió diària, coneguda com a "Stand-up Meeting" o "Daily", és una pràctica essencial en els marcs de treball àgils com Scrum i Kanban. L'objectiu principal d'aquesta cerimònia és permetre que l'equip col·labori i es mantingui sincronitzat, compartint informació rellevant sobre l'estat del treball i coordinant les tasques per al dia.

·       Sincronitzar l'equip

La cerimònia de la Reunió diària permet a tot l'equip estar al mateix nivell d'informació, assegurant que tots comparteixen una comprensió comuna de l'estat del projecte i les tasques en curs.

 

·       Verificació del progres

Aquesta pràctica ofereix una oportunitat per avaluar si l'equip està avançant adequadament per aconseguir l'Objectiu de l'esprint. Es pot identificar qualsevol desviació o manca de progressió i prendre les mesures necessàries.

 

·       Identificació ràpida d'obstacles i impediments

Mitjançant les converses diàries, els membres de l'equip poden compartir els obstacles i impediments que troben. Això permet abordar aquestes qüestions immediatament i prendre accions per superar-les.

 

·       Adaptació al canvi i millora contínua

Les cerimònies de la Reunió diària fomenten l'adaptabilitat, ja que les necessitats i circumstàncies poden canviar ràpidament. Això permet als equips ajustar-se a les noves condicions i millorar constantment el seu enfocament, creant un sentiment de pertinença i compromís col·lectiu.

Punts a destacar

·       Temps limitat

És imprescindible respectar una durada màxima de 15 minuts.

 

·       Tothom parla

Es defineixen els rols i les responsabilitats.

 

·       Auto gestionat

L’equip es coordina i s’organitza per si sol, no es requereix la presència de l’Scrum Màster.

 

·       Mateixa hora

L’hora de la Reunió diària s’acorda i es respecta sempre. No es canvia encara que falti gent.

 

5.3         Revisió

L'objectiu d'una Revisió de l'esprint és avaluar el treball fet, obtenir el feedback dels interessats i adaptar la Pila de producte en funció d'aquest feedback. És una oportunitat per a l'equip de desenvolupament de mostrar els resultats del seu treball i per a l'equip Scrum de col·laborar amb els interessats per ajustar i millorar el producte. Aquesta revisió promou la transparència, la col·laboració i la millora contínua en el desenvolupament del producte.

·       Demostrar l'Increment del producte

L'equip de desenvolupament demostra als interessats el treball fet durant l'esprint. Aquesta demostració permet als interessats veure i provar les funcionalitats i característiques desenvolupades i proporciona una oportunitat per a les revisions i els canvis necessaris.

 

·       Obtenir feedback dels interessats

Durant la demostració, els interessats donen feedback sobre què s'ha desenvolupat. Aquest feedback és valuós per al Propietari de producte i l'equip de desenvolupament per comprendre les preferències dels interessats i adaptar la Pila de producte en funció d'aquesta retroalimentació.

 

·       Revisar i ajustar la Pila de producte

La Revisió de l'esprint també proporciona una oportunitat per revisar i ajustar la Pila de producte. Basant-se en el feedback dels interessats i en les discussions durant la Revisió, el PO i l'equip Scrum poden realitzar canvis en les prioritats, afegir o eliminar elements de la Pila de producte i ajustar les estratègies de desenvolupament.

 

·       Celebrar els èxits i identificar les oportunitats de millora

La Revisió de l'esprint permet a l'equip de desenvolupament celebrar els èxits i els objectius assolits durant l'esprint. Al mateix temps, s'identifiquen les oportunitats de millora i les accions correctives necessàries per a futures iteracions.

 

5.4         Retrospectiva

La reunió Retrospectiva és una sessió d'avaluació que es realitza al final de cada iteració o esprint, on l'equip Scrum reflexiona sobre l'increment desenvolupat, identifica oportunitats d'aprenentatge, resol problemes, ajusta el procés de treball i fomenta la col·laboració i la responsabilitat. L'objectiu és millorar constantment el treball en equip i el rendiment del desenvolupament del producte.

·       Avaluació de l'Increment desenvolupat

L’equip Scrum pren temps per reflexionar sobre l'últim increment del producte que ha desenvolupat durant la iteració o esprint. S’analitza què s'ha fet de manera satisfactòria i què podria millorar. Aquesta avaluació ajuda a identificar els punts forts i les àrees en què l'equip pot fer ajustos per augmentar la qualitat i l'eficiència del treball.

 

·       Aprenentatge i millora contínua

S’examinen els avenços i els èxits que s’han aconseguit durant la iteració, així com els reptes i els problemes que han sorgit. Aquesta anàlisi aprofundida permet identificar oportunitats d'aprenentatge. El focus està en com es poden aplicar les lliçons apreses per millorar contínuament. Això podria significar prendre decisions diferents, adoptar noves pràctiques o optimitzar processos existents.

 

·       Optimització de la col·laboració

L’equip se centra a millorar la manera com es col·labora i comunica entre ells. S'analitzen possibles barreres o conflictes que hagin afectat la cooperació durant la iteració. Es busquen maneres de fomentar la comprensió mútua, la confiança i la participació activa de tots els membres. Aquesta optimització de la col·laboració és clau per a un millor funcionament de l'equip i per resoldre problemes de manera més eficaç.

 

·       Resolució de problemes i ajustaments

S’identifiquen problemes específics que puguin afectar el desenvolupament del producte durant la iteració. Aquests problemes poden ser tècnics, de comunicació o de qualsevol altre tipus. L'objectiu és trobar solucions pràctiques i estratègies per superar aquests obstacles en futures iteracions. També es considera si hi ha ajustaments necessaris en el procés de treball per prevenir aquests problemes en el futur i millorar l'eficàcia general de l'equip.

 

6      Mètriques i Reporting

 

6.1         Mètriques

Les mètriques de seguiment permeten obtenir informació de l'estat del projecte i comunicar a tot l'equip en quin punt del camí es troba. Les diferents mètriques poden aportar una visió clara dels objectius actuals, els següents passos i avaluar els requisits complets.

Aspectes a mesurar

·       Èxit de l’esprint

L'èxit d'un esprint és fonamental per mesurar el progrés i l'eficiència de l'equip àgil. Representa la capacitat de l'equip per planificar, executar i lliurar increments de valor en un període curt. Un alt èxit dels esprints indica una planificació efectiva, una execució exitosa i una capacitat per adaptar-se als canvis.

 

·       Qualitat del codi

La qualitat del codi és essencial per garantir la sostenibilitat i l'escalabilitat del producte a llarg termini. Mètriques com la llegibilitat del codi, la baixa complexitat i la cobertura de proves poden ajudar a avaluar i millorar la qualitat del codi, la qual cosa contribueix a un desenvolupament més àgil i menys propens a errors.

 

·       Èxit de cada desplegament

Cada desplegament exitós implica el lliurament efectiu de noves característiques o correccions al producte. Mesurar l'èxit dels desplegaments ajuda a avaluar l'estabilitat del sistema, l'eficàcia de les pràctiques d'integració contínua/desplegament continu, i proporciona retroalimentació immediata sobre la funcionalitat recentment implementada.

 

·       Satisfacció de l’usuari

La satisfacció de l'usuari és crucial per l'èxit a llarg termini del producte. Obtenir retroalimentació directa dels usuaris permet ajustar i millorar contínuament el producte per satisfer les seves necessitats.

 

·       Negoci

La mètrica de negoci en el context de desenvolupament àgil avalua la relació entre el valor del producte entregat i els costos associats. Aquesta mètrica ajuda a garantir que les decisions preses durant el desenvolupament estiguin alineades amb els objectius del negoci. És crucial assegurar que les funcionalitats desenvolupades realment aportin valor i contribueixin als objectius empresarials.

 

·       Satisfacció de l’equip

L'entusiasme i la satisfacció de l'equip són claus per a un desenvolupament àgil eficaç. Un equip satisfet és més propens a ser productiu i creatiu. Mesurar la satisfacció de l'equip ajuda a identificar possibles problemes, millorar la col·laboració i mantenir un entorn de treball positiu, el que contribueix al rendiment sostenible de l'equip a llarg termini.

 

6.2         Pràctiques de Reporting

Per obtenir informació que mesurar a les mètriques de seguiment, podem fer servir un seguit de pràctiques i cerimònies recurrents durant l’esprint.

Bones practiques

·       Quadres de comandament

Permet tenir una visió global de les tasques i el seu estat. Els quadres de comandament poden estar acompanyats d’elements gràfics que donen un enteniment ràpid i resumit de les mètriques de seguiment.

 

·       Reunió diària (Daily)

Manté l’equip sincronitzat durant l’esprint. En les bones pràctiques de la reunió diària cada membre reporta l’estat de les tasques assignades i els impediments que existeixen, donant valor al principi de resposta al canvi. Han de ser breus i dinàmiques.

 

·       Revisió (Review)

Durant la Revisió de l’esprint es revisa el treball fet. Les bones pràctiques inclouen mesurar el valor entregat, la velocitat i tasques completades en relació amb les pendents. Permet fer un ajust de la Pila de producte.

 

·       Demostració (Demo)

Alguns productes poden incloure una demo durant la Revisió, l’equip fa una demostració de les funcionalitats a entregar per validar el comportament esperat o aplicar-hi nous canvis.

 

·       Refinament

Per preparar les Històries d'Usuari que es faran al següent esprint es fa el refinament de la Pila de producte un cop durant l'esprint. Aquesta cerimònia contribueix al Propietari del producte a entendre, actualitzar i prioritzar els elements de la Pila d'acord amb els canvis i la situació actual del producte.

 

·       Retrospectiva

La Retrospectiva es dona un cop al final de l’esprint i avalua l’increment desenvolupat i ajusta el procés de treball. És una bona pràctica la sinceritat a l’hora de parlar de què ha anat malament i com es pot millorar.