You are on page 1of 4

SCRUM

Individuals and Interactions x over Processes and Tools

Working software x over Comprehensive documentation

Customer collaboration x over Contract negotiation

Responding to change x over Following a plan

Em cada sprint todas as fases de desenvolvimento de software estão presentes (Planning


(analysis), Design, Code (implementation), Integration, Testing, Deploy).

Casa sprint tem um resultado que o cliente pode testar, pois ele só descobre o que realmente
quer quando ele tem algo que ele possa usar.

Time-Boxed: duração fixa, data de início e fim fixas.

Scrum is Hard to Practive

It takes courage and commitment

Approaches: abordagens

Scrum provided roles, meetings and artifacts.

ROLES
Product owner:
-Responsible for returno n investment (ROI)
-Final arbiter of requirements questions
-Focused more on the what on the how

Scrum development team (Small time 4 a 9/ Room time):


-Cross functional group
-Attempts to build a “potentially shippable product increment” every Sprint.
-Collaborates
-Self organizing

Scrum Master
-Has no management authority
-Doesn’t have a Project manager role
-Facilitator
-Protege o time de distrações e interrupções
-Facilita o processo
-Ensina as pessoas como usar o SCRUM
-Promove a melhoria das melhores práticas de engenharia
-Força a realização dentro do tempo
-E faz tudo isso sem poder de gerente, apenas com influência.

Backlog Refinement Meeting/ Backlog Grooming/ Backlog Estimation/ Story Time

(2 horas em um Sprint de 2 semanas)


Product Backlog Item (PBI): INVEST (Independent, Negotiable, Valuable, Estimable, Small,
Testable).

http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/

INVEST in good Stories, and SMART tasks

SMART (Specifc, Measurable, Achievable, Relevant, Time-Boxed).

Estimation Cards (effort to get a PBI into potentially shippable form): S (Small), M (Medium), L
(Large) and XL (Extra Large).

Stories/ Split to identify Who, What and Why in a Product Backlog.

Propósitos/ Purpose:
-Estimative of effort
-Clarification of requirements
-Decomposition of large PBIs into smaller ones (e.g. epics to user stories).

Sprint Planning Meeting

4 hours to plan a 2-week sprint/ 30 days Sprint uses a 1 day timebox

Product Owner and Development time will agree to Sprint goals (metas) and negotiable which
items from Product Backlog.

Only 60% of the tasks are likely to be identified during the Sprint Planning Meeting.

Part 1: Committing to Product Backlog Items (PBIs). Item que seram feitos no Sprint.

Part 2: Coming up with tasks.

Time Sprint: 30 days, or one calendar month, but one or two weeks is recommended.

Definition od done: properly tested, refactored, potentially shippable (não é fixo).

Definir todas as tarefas que precisaram ser realizadas para a criação de um incremento
utilizável.

Conseguimos fazer todas essas tarefas dentro do prazo estipulado para o Sprint? Todos devem
estar de acordo.

Principle behind Scrum is Limit Work in Progress (WIP). Humans don´t multitask efficiently. Too
much work in progress actually slows things down.

Sprint forecast

A task should be no bigger than one day of work.

Some Scrum teams who have learned how to define small enough PBIs no longer find tasks
necessary.

A PBI is more about the what than the how. A task is more about the how.

Daily Scrum Meeting


Same time, same place, each day, standing up for 15 minutes.

Report to the three questions:


-What did I do yesterday?
-What will I do today?
-What impedes me?

Pair Programming: duas pessoas dividindo uma estação de trabalho, enquanto um programa,
a outra acompanha verificando o código e depois o processo ao inverso.

SideBar: Itens para serem discutidos depois, sem ser no daily scrum.

Refactoring: Improving internal structure only, removing duplicate code.

The Sprint execution is completed when the timebox expires.

Sprint Review Meeting

Pode participar qualquer stakeholder interessado.

1 - Product demonstration

2 – Product owner declare what’s done.

3 – Optional: Measure velocity (Story Points)

4 – Stakeholder feedback

Items that are not done or almost done will be moved in their entirety back to the product
backlog.

The Sprint review meeting is a key inspect and adapt mechanisms in Scrum so we want to
avoid things could interfere with transparency (like applause or praise).

Se o product owner solicitar novas funcionalidades ou qualquer coisa a mais, como um novo
design o scrum master vai adicionar ao product backlog para avaliação futura.

Discordâncias sobre as prioridades ou o que já deveria estar pronto, deve ser resolvido fora da
reunião com o product owner e os outros stakeholders envolvidos.

Feedback from outside stakeholders: the end, after the demonstration and measurement of
which goals were achieved.

Sprint Retrospective Meeting

1 - Safety check (http://stevenmsmith.com/ar-safety-check/)

2 - Classic Scrum retrospective


What went well? What could be improved?
What did we learn? What still puzzles us?
Actions

3 – Focused conversation principles


ORID
Objective questions (What happened?)
Reflective questions (How do we feel about it?)
Interpretive questions (What does it mean?)
Decision questions (What are we going to do about it?)

4 – Silent Writing

5 – Timeline retrospective

6 – Decisions

7 Obstacles to Enterprise Agility


http://scrumreferencecard.com/7-obstacles-to-enterprise-agility/

1 – Naïve Resource Management


2 – Teams organized by functional specialization
3 – Teams organized by architectural components
4 – Distraction
5 – Reluctance to continuously refine, reprioritize and rescope.
6 – Rampant technical debt (Dívida técnica desenfreada).
7 – Lack (falta) of commitment to transformation

Test Driven Development (TDD)

http://wiki.c2.com/?TestDrivenDevelopment

The surprising truth about what motivates us


https://www.youtube.com/watch?v=u6XAPnuFjJc

You might also like