Rols de Scrum

Scrum defineix exactament tres rols. No més, no menys. Cada rol té responsabilitats clares i no superposades. La confusió de rols és una de les causes més freqüents de fracàs en la implementació de Scrum.

flowchart TD
    subgraph ST["Scrum Team (3-9 persones)"]
        PO["Product Owner\n— Que hem de construir?\n— Prioritza el backlog\n— Representa el client"]
        SM["Scrum Master\n— Com treballem millor?\n— Elimina obstacles\n— Guia el proces"]
        DT["Development Team\n— Com ho construim?\n— Autogestionat\n— Multidisciplinar\n3-9 persones"]
    end

    CL["Client / Stakeholders\n(externs a l'equip)"]
    CL <-->|"feedback i prioritats"| PO

    style PO fill:#1565c0,stroke:#0d47a1,color:#fff
    style SM fill:#00695c,stroke:#004d40,color:#fff
    style DT fill:#6a1b9a,stroke:#4a148c,color:#fff
    style CL fill:#37474f,stroke:#263238,color:#cfd8dc

---

Product Owner (PO)

El Product Owner és la persona responsable de maximitzar el valor del producte. Representa els interessos del client i dels stakeholders davant l'equip tècnic.

Responsabilitats

• Gestionar el Product Backlog: crear, refinar i prioritzar les històries d'usuari. El backlog reflecteix en tot moment la millor visió possible del que cal construir.
• Definir la visió del producte: comunicar a l'equip per que estem construint el que estem construint. Sense visió, l'equip pren decisions tècniques sense criteri de valor.
• Acceptar o rebutjar increments: al final de cada sprint, el PO decideix si el que s'ha construït compleix els criteris d'acceptació.
• Estar disponible per a l'equip: resoldre dubtes sobre requisits durant el sprint. Un PO inaccessible és un dels principals obstacles en Scrum.

Qui és el PO a ASIX?

En un projecte de sistemes, el PO acostuma a ser el responsable TIC del client (el cap de sistemes de l'empresa, el CTO), o un tècnic designat que coneix les necessitats del negoci. No és el gestor de projecte waterfall — no planifica ni controla. Prioritza.

El PO no és el gerent del equip

El Product Owner decideix que es fa i en quin ordre. No decideix com es fa ni qui fa cada tasca. Si el PO comença a dir "tu fes el servidor de correu i tu fes el firewall", s'ha convertit en un micro-gestor waterfall amb nom diferent.

---

Scrum Master (SM)

El Scrum Master és el garant que Scrum s'aplica correctament. No és un gestor de projecte, ni un líder tècnic, ni un secretari de reunions. És un servant leader: el seu treball és que l'equip pugui treballar al màxim de la seva capacitat.

Responsabilitats

• Eliminar impediments: qualsevol obstacle que bloqueja l'equip (un servidor caigut, una decisió pendent, una dependència externa) és responsabilitat del SM resoldre o escalar.
• Guiar el procés Scrum: assegurar que les cerimònies es fan correctament, que els artefactes s'actualitzen i que l'equip entén el marc.
• Protegir l'equip: durant el sprint, l'equip no ha de ser interromput amb noves tasques urgents. El SM gestiona les peticions externes.
• Facilitar la millora contínua: liderar les retrospectives i assegurar que les accions de millora s'implementen.
• Fer coaching àgil: ajudar el PO a refinar el backlog, ajudar l'equip a estimar millor, ajudar l'organització a entendre Scrum.

Qui és el SM a ASIX?

En equips petits (3-5 persones), el rol de Scrum Master es pot combinar amb un rol tècnic, tot i que no és l'ideal. El SM dedica entre el 20% i el 50% del seu temps al rol, depenent de la maduresa de l'equip.

El SM no resol problemes tècnics

El Scrum Master no és el tècnic que resol problemes per l'equip. Si el servidor de bases de dades cau, el SM no el repara — però sí que s'assegura que la persona adequada el repara ràpidament i que l'impediment queda documentat per evitar-lo en el futur.

---

Development Team (Dev Team)

El Development Team és l'equip que construeix l'increment. A ASIX, això inclou configurar, desplegar, automatitzar, programar, documentar — qualsevol cosa necessària per lliurar el treball.

Característiques clau

Autogestionat: l'equip decideix com organitza la feina del sprint. Ninguú de fora (ni el PO, ni el SM, ni el cap) li diu qui fa cada tasca o com ho ha de fer.

Multidisciplinar: l'equip té totes les competències necessàries per completar el treball sense dependre d'altres equips. En un equip de sistemes, aixo pot significar tenir competències en xarxa, servidors, seguretat, scripting i documentació dins del mateix equip.

Mida: entre 3 i 9 persones. Menys de 3 és massa petit per a la diversitat necessària. Més de 9 genera massa coordinació.

No hi ha sub-rols: a Scrum no hi ha "l'encarregat de la xarxa" o "l'administrador de sistemes". Tots els membres de l'equip son desenvolupadors (en el sentit àgil: qui construeix l'increment). Poden tenir especialitzacions, però qualsevol membre pot agafar qualsevol tasca del backlog.

La matriu de competències

En equips madurs, es fa servir una matriu de competències per identificar àrees on l'equip és fort i àrees de risc (on tot recau en una sola persona):

Competència	Anna	Bernat	Carla	David
Linux / servidors	Expert	Mig	Mig	Baix
Xarxa / firewall	Mig	Expert	Baix	Mig
Scripting / automatitzacio	Mig	Baix	Expert	Mig
Seguretat	Baix	Mig	Mig	Expert
Documentació	Mig	Mig	Alt	Mig

L'objectiu és que cap columna tingui un únic "Expert" en una àrea crítica (single point of failure humà). La millora transversal de competències és un objectiu de llarg termini de l'equip.

Activitat AC-RA2-01

Per al projecte de migració d'infraestructura a núvol del vostre cas pràctic:

1. Definiu qui seria el Product Owner, el Scrum Master i els membres del Development Team.
2. Quines competències necessita l'equip? Construïu una matriu de competències amb els membres del vostre equip de classe.
3. Identifiqueu dos possibles conflictes de rol (per exemple, el cap de sistemes com a PO que vol ser Scrum Master alhora) i expliqueu per que son problemàtics.