Salta el contingut

Events de Scrum

Scrum defineix cinc events (també anomenats cerimònies). Cada event té un propòsit concret, una durada màxima (time-box) i uns participants definits. No son reunions opcionals — son la columna vertebral del procés.

flowchart LR
    subgraph Sprint["Sprint (1-4 setmanes, time-boxed)"]
        direction TB
        SPL["Sprint Planning\nMaxim 8h per sprint de 4 setmanes"]
        DS["Daily Scrum\n15 minuts, cada dia"]
        SB["Treball del\nSprint Backlog"]
        SR["Sprint Review\nMaxim 4h per sprint de 4 setmanes"]
        RET["Retrospectiva\nMaxim 3h per sprint de 4 setmanes"]

        SPL --> SB
        DS --> SB
        SB --> SR --> RET
    end

    PB["Product\nBacklog"] -->|"input"| Sprint
    RET -->|"millora"| PB
    SR -->|"feedback"| PB

    style SPL fill:#1565c0,stroke:#0d47a1,color:#fff
    style DS fill:#00695c,stroke:#004d40,color:#fff
    style SR fill:#e65100,stroke:#bf360c,color:#fff
    style RET fill:#6a1b9a,stroke:#4a148c,color:#fff

El Sprint

El Sprint és el contenidor de tots els altres events. Es una iteració de durada fixa (1, 2, 3 o 4 setmanes) durant la qual l'equip crea un increment potencialment lliurable.

Regles del Sprint

  • La durada és fixa i consistent durant tot el projecte. Si l'equip tria sprints de 2 setmanes, tots els sprints duren 2 setmanes.
  • No es canvien els objectius del sprint un cop ha començat. Si sorgeix una urgència, el PO i el SM decideixen si cal cancel·lar el sprint (molt rar) o si espera al proper sprint.
  • El Sprint comença immediatament quan acaba l'anterior. No hi ha pausa entre sprints.
  • Cada sprint ha de produir un increment que compleixi la Definition of Done.

Quina durada triar?

Durada Quan és adequat
1 setmana Projectes molt nous on els requisits canvien ràpidament. Equips experimentats.
2 setmanes El més habitual. Bon equilibri entre agilitat i profunditat.
3-4 setmanes Projectes estables, tasques de llarga durada (infraestructura complexa), equips novells.

A ASIX: comenceu amb 2 setmanes

Per a projectes de sistemes, 2 setmanes és la durada recomanada. Permet fer deploys significatius sense la pressió d'1 setmana ni l'inèrcia de 4 setmanes.

Sprint Planning

La Sprint Planning és la reunió on l'equip planifica el treball del sprint. Es fa al principi de cada sprint.

Participants: tot l'Scrum Team (PO + SM + Dev Team). Durada màxima: 8 hores per a un sprint de 4 setmanes (proporcional per a sprints més curts).

Les dues preguntes del Sprint Planning

1. Que podem lliurar al final d'aquest sprint? (Sprint Goal)

El PO presenta els items del Product Backlog més prioritaris. L'equip analitza quants poden comprometre's a completar en el sprint, tenint en compte la seva velocitat (quantitat de treball completat en sprints anteriors) i les seves disponibilitats (vacances, formacions, etc.).

El resultat és el Sprint Goal: un objectiu clar i concís que descriu el valor que lliurarà el sprint. Exemple: "Al final del sprint, el nou servidor de correu estarà configurat, provat i accessible per als usuaris pilots."

2. Com farem el treball? (Sprint Backlog)

L'equip descompon cada item del backlog en tasques concretes. Cada tasca ha de ser completable en menys d'un dia. L'equip s'auto-assigna les tasques (no ho fa el PO ni el SM).

Daily Scrum

La Daily Scrum (o Daily Stand-up) és una reunió de sincronització diària de 15 minuts. El seu propòsit és que l'equip s'alineï i identifiqui obstacles.

Participants: Development Team (el SM facilita, el PO pot assistir com a observador). Durada: exactament 15 minuts. Si s'allarga, el SM talla i continua en una reunió separada. Hora: sempre a la mateixa hora, sempre al mateix lloc (o canal virtual).

Les tres preguntes clàssiques

Cada membre respon breument:

  1. Que vaig fer ahir que ajuda l'equip a assolir el Sprint Goal?
  2. Que faré avui que ajuda l'equip a assolir el Sprint Goal?
  3. Hi ha algun impediment que bloqueja el meu progrés o el de l'equip?

La Daily no es una reunio d'estatus per al cap

La Daily Scrum és una reunió de l'equip per a l'equip. No és un informe al Scrum Master o al Product Owner. Si el cap de sistemes assisteix a la Daily i demana explicacions, está destruint la confiança i convertint la reunió en un control. El SM ha de protegir l'equip d'aquesta dinàmica.

Sprint Review

La Sprint Review és la reunió de final de sprint on l'equip demostra el treball completat al Product Owner i als stakeholders. No és una "presentació de PowerPoint" — és una demostració del sistema funcionant.

Participants: Scrum Team + stakeholders convidats pel PO. Durada màxima: 4 hores per a un sprint de 4 setmanes.

Que passa a la Sprint Review?

  1. El Development Team demostra les funcionalitats completades (les que passen la Definition of Done).
  2. Els stakeholders fan preguntes, proven el sistema i donen feedback.
  3. El PO decideix que es dona per "done" i que no.
  4. El PO actualitza el Product Backlog en funció del feedback rebut.
  5. L'equip discuteix el que ve: que podria ser el proper sprint?

Que NO demostrareu a la Sprint Review

Items que no estan completament fets (que no passen la DoD), features a mitges, o "el que hem fet fins ara". Si un item no esta complet, no es demonstra. Mostrar treball incomplet crea confusió i erosiona la confiança dels stakeholders.

Retrospectiva

La Retrospectiva és l'event més important per al creixement de l'equip. Es fa al final de cada sprint, sempre abans de la Planning del proper sprint.

Participants: Scrum Team complet. Durada màxima: 3 hores per a un sprint de 4 setmanes.

El propòsit

La Retrospectiva respon a tres preguntes sobre el procés de treball (no sobre el producte, que és tema de la Sprint Review):

  1. Que ha anat bé en aquest sprint? (Keep)
  2. Que ha anat malament o podria millorar? (Improve)
  3. Quines accions concretes prendrem al proper sprint? (Actions)

Format "Starfish"

Un format popular que afegeix matisos:

flowchart TD
    subgraph SF["Starfish Retrospective"]
        direction LR
        KM["Fer mes\n(Start doing)"]
        KK["Continuar\n(Keep doing)"]
        KL["Fer menys\n(Less of)"]
        ST["Deixar de fer\n(Stop doing)"]
        TR["Provar\n(Try)"]
    end

L'accio de millora ha de ser concreta

Una acció de millora vaga ("comunicar-nos millor") no serveix. Una acció concreta és accionable i mesurable: "A partir del proper sprint, documentarem cada configuració de servidor en el wiki del projecte el mateix dia que la fem."

Al final de la Retrospectiva, assigneu cada acció a una persona i fixeu una data de verificació.

Activitat AC-RA2-02

Simuleu un Sprint Planning per al vostre projecte de pràctiques:

  1. Partint del Product Backlog que heu creat, trieu els items per al primer sprint de 2 setmanes.
  2. Definiu el Sprint Goal en una frase clara.
  3. Descomposeu cada item en tasques de menys d'un dia.
  4. Estimeu quantes hores de feina teniu disponibles (descomptem vacances, altres assignatures, etc.).
  5. Confirmeu si el compromis és realista o cal reduir l'abast.