Guia PES

Desenvolupament

Un sprint, de la planning a la retrospectiva

A PES hi ha una incepció i tres sprints d'unes tres setmanes, amb una sola release. No hi ha release backlog: només el product backlog i un sprint backlog per a cada sprint.

Les quatre cerimònies

Inici

Sprint planning

Definiu l'objectiu de l'sprint i creeu-ne el backlog. El mateix dia, planning_X.pdf al Drive.

Cada classe

Daily scrum

Com a mínim dos cops per setmana, a classe: què vaig fer, què faré, què em bloqueja. Sincronitza l'equip per a les properes hores.

Final

Sprint review

Ensenyeu el que està fet, comenteu què ha anat bé i quins problemes heu resolt, i reviseu el product backlog per al proper sprint.

Després de la review

Retrospectiva

Què ha anat bé, què es pot millorar i a què us comprometeu per al proper sprint. Revisa també la vostra manera de treballar.

Planning guiada per la velocitat

  1. Ajusteu prioritats i fixeu una velocitat objectiu (per historial, prototip o estimació).
  2. Un objectiu de l'sprint, en una sola frase.
  3. Trieu històries segons prioritat i esforç fins a la velocitat objectiu.
  4. Partiu-les en tasques, idealment d'un dia com a màxim.
  5. Estimeu les tasques en hores ideals. La suma hauria de quadrar, a grans trets, amb els punts.

Les tasques barregen enginyeria i gestió (dissenyar la UI, programar, escriure proves d'acceptació, reunions) i s'assignen dinàmicament segons habilitats i disponibilitat. Cada tasca ha d'aportar valor.

planning_X.pdf

Ull: en el pla de release no assigneu persones a històries ni hi poseu tasques d'enginyeria ni l'ordre de la feina. Tot això va al pla de cada sprint.

Juga-hi

El task board

Serveix per autoorganitzar-se i per veure què queda i què s'està fent. Moveu les tasques i mireu com baixen les hores pendents.

Definició de fet (DoD)

Una història no està feta quan "funciona al meu ordinador", sinó quan passa per tot el cicle que l'equip ha acordat. Per exemple:

especificada → implementada → provada → documentada → diagrames actualitzats

Acordeu-la a la incepció, escriviu-la a la memòria (metodologia) i reviseu-la a cada retrospectiva.

I quan apareix un bug?

  • En una història encara oberta: no té gaire efecte, s'arregla dins la mateixa història.
  • En una història ja tancada: si és poca cosa, s'arregla i prou; si és costós, es reobre la història (vigileu els punts).
  • Registreu-los sempre: la gestió de bugs és un dels aspectes metodològics avaluats.

El report de l'sprint

Plantilla sprints/1/nom_report_1.docx, en tres parts:

  1. Introducció: resum de l'sprint i del treball en equip.
  2. Cerimònies: planning, dailies, review i retrospectiva, amb els gràfics.
  3. Changelog: tots els canvis des de la iteració anterior, de manera sistemàtica.

Al costat, la memòria es manté viva (requisits, metodologia i descripció tècnica) i se'n desa una còpia en PDF a cada sprint.

Generador

Els tres gràfics del report

Taiga en genera alguns, però aquí els podeu fer amb les vostres dades i descarregar-los en PNG o SVG per al report. Les dades es queden al vostre navegador.

Burndown de l'sprint

Punts pendents al final de cada dia de l'sprint (el dia 0 és el total compromès).

Velocitat

Punts completats a cada sprint. És l'eina principal per planificar dates i abast.

Burndown del producte

Punts pendents de tot el backlog a l'inici i després de cada sprint.

Recordeu: el burndown no és per castigar ningú. Es reestima cada dia i serveix perquè l'equip s'autoorganitzi. Si la línia real no baixa, és el moment de parlar-ne a la daily.