Scrum Method

Introduzione (idea principale)

In breve: essence card 🟩-

Giallo = Prodotto.

Metafora staffetta-rugby 🟩

Con altri metodi si fanno produzioni stile staffetta, ossia un membro sta fermo, finché non ha il testimone e poi si uccide correndo… Il metodo più utile ispirato a scrum è rugby, che tutti si muovo insieme collaborando. Un po’ di tutto è fatto durante lo sprint

Cicli di base (3) 🟩

1. Planning: in cui vengono scelti i task da eseguire durante questo sprint, solitamente questo viene preso da un subset dei task descritti dal product owner.
2. Execution: questo è abbastanza chiaro, si sviluppa.
3. Retrospective and review: in cui vengono identificati i problemi che sono stati incontrati durante lo sviluppo, e modi possibili per risolverli.

Lo sprint (3) 🟩-

Una cosa molto importante che aiuterà di gran lunga lo sviluppo è la costanza che Si scelgono

• Task READY che vengono fatte
• Queste vengono spostate in done quando sono fatte
• E poi vengono testate, questo per tutto il prodotto.

Questo lo guarderemo in una sezione successiva.

Ruoli

Introduzione in generale ai ruoli (3) 🟩

• Product owner: deve rappresentare il cliente e scrivere le features più interessanti per il team, sempre secondo ciò che deve essere utile per il cliente..
• Scrum Master deve cercare di eliminare gli ostacoli.
  • Esempio: persone che litigano internamente al team
  • Persone lavorano meno e non portano risultati, e si isola.
• Developer chi sviluppa.

All’esterno ci sono gli stakeholders che sono in pratica i clienti, vuole cercare di capire esattamente cosa debba essere fatto.

In breve:

Dinamiche del team 🟨

• Auto-organizzazione, ossia il team stesso dovrebbe definire i suoi ruoli TODO: definire questa parte meglio, in che sensi si dovrà auto-organizzare il team?

Scrum pillars

Scrum team

A Scrum team is a group of individuals who work collaboratively to deliver high-quality product increments. The team is typically composed of a Scrum Master, a Product Owner, and Developers. The Scrum Team is cross-functional, self-organizing, and responsible for all product-related activities, including stakeholder collaboration, verification, maintenance, operation, experimentation, research, and development. The team is structured and empowered by the organization to manage their own work, and they work in Sprints at a sustainable pace to improve focus and consistency. The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically consisting of 10 or fewer people. The team is focused on achieving the Product Goal and shares the same Product Backlog and Product Owner. The Scrum Team embodies the principles of transparency, inspection, and adaptation, and is essential for the successful implementation of the Scrum framework in delivering valuable products https://www.visual-paradigm.com/scrum/what-is-scrum-team/

Product Owner

È il membro del team che si relaziona con gli stakeholders esterni. rappresenta il punto di vista del cliente e deve essere in grado di descrivere il prodotto al team. Dato che è il cliente che stabilisce le priorità, dovrebbe gestire le priorità (massimizza il valore dei rilasci). Dato che è la figura che va con i clienti, deve anche essere in grado di recepire i cambiamenti di mercato e comunicarlo per bene al team. Deve sapere cosa prioritizzare per avere prodotto migliore nelle prossime iterazioni seguendo i dati che vengono raccolti durante lo scrum.

Responsabilità

• Product Goal.

Triangolo di Ferro (3)

• Scope
• Cost
• Time Si tratta di migliorare la qualità del software restando dentro a questi limiti. È anche una cosa che dovrebbe essere per Project Management, ossia quello che il manager deve considerare per fare stime dei progetti e consegnare più qualità.

In waterfall è lo scopo la dimensione costante, cambiano le altre due.

Eventi scrum

Riassunti eventi scrum (!!) (4) 🟩

• Planning, in cui si scelgono le cose da fare
• Review, in cui si analizza quanto bene si è fatto
• Retrospective, in cui si guarda come si potrebbe migliorare
• Daily Standup, feedback su quanto siamo messi.

Sprint planning (2) 🟩

Si tengono in conto vari fattori (vedi immagine), e a seconda di questi vogliamo avere due output

• GOAL, l’obiettivo del nostro sprint
• Planning
  • Chi fa cosa
  • Il backlog presente

Planning Poker 🟩

È un gioco per stimare il tempo dei task https://planningpokeronline.com/ che è molto divertente. Solve il problema di stimare il tempo necessario per fare qualcosa.

Velocità sprint 🟩

Si può intendere come il numero di story point completati, che solitamente è dipendente da qualcosa di passato. Questo serve per stimare quanto si riuscirà a fare negli sprint successivi.

Sprint review 🟩

In cui è presente una demo del prodotto, con anche magari gli stakeholders Una specie di presentazione e più gente forse :). Quindi si ha un feedback su quanto fatto per il prodotto durante lo sprint.

Sprint retrospective (3) 🟩

Si parla di ciò che

1. Start doing (che magari potrebbe aiutare, che prima non si faceva)
2. Stop Doing che magari è una cosa tossica da fare, non aiuta, e prende tempo
3. Continue doing se va ancora bene È sempre all’interno di scrum un modo per vedere se si può migliorare il modo di lavorare.

Artefatti

Product backlog 🟩

Qui trattiamo l’insieme degli aspetti utili a gestire tutti i task che dovranno essere fatti

Gestione del backlog 🟩

• La scelta dei singoli task è fatta in maniera volontaria da parte di chi lavora.
• Il lavoro-board deve essere aggiornato volta volta in cui si continua a starci sopra.

User story mapping 🟩

L’idea è già dividere task per task, nei sprint corretti.

Esempi di mapping possibili

Burndown chart 🟩

In pratica il numero totale di ore che sarà una stima di quanto fatto.

Caso ideale: lineare. Sono quindi dei grafici per valutare qualità del lavoro

Conclusioni

Meta-scrum

Cause effetti negativi

NOTA: questa alla fine non è scienza, si fa fatica a fare uno studio comparativo che cerchi di identificare se funziona o meno questo metodo, è solamente

Definizioni di fatto o finito

The DoR outlines the criteria that a specific user story must meet before being considered for estimation or inclusion into a sprint. It describes the characteristics of an effective user story and ensures that the team has a shared understanding of what’s needed for a user story to be brought into a sprint. The DoR is optional and is particularly useful when aspects of user stories are impeding progress, leading to stories being rolled into the next sprint. It is focused on user story level characteristics and is changeable based on the team’s needs

The DoD is a shared understanding among team members of what it means for a product backlog item (PBI) to be considered complete. It applies to all work in the backlog and represents the acceptance criteria for a sprint or release. The DoD outlines the quality standards that a piece of work needs to reach to be releasable. It is essential for ensuring consistent delivery of quality and is often standardized across the company. The DoD is changeable and may need to be adjusted based on the team’s needs

Mancanze di supporto

• Scrum master che non fa il lavoro
• Cattiva comunicazione di PO
• Cattiva comunicazione dei desiderata da parte degli stakeholders.