treinamento scrum - english
Post on 15-Aug-2015
42 Views
Preview:
TRANSCRIPT
WASTE
Never Rarely Sometimes Frequently Always
Research of the Standish Group in the largest US project development firms,
revealed that 64% of features requested by customers are rarely or never used
12 AGILE PRINCIPES
01Continuous delivery and early software
with value: customer satisfaction
02Changes are welcome: competitive
advantage for the customer
03Development in short cycles: frequent
delivery of working software
04Business people and developers must
work together
05Motivated individuals, with support and
confidence
06Face to face conversation is the most effective method of communication
07Working software is the best measure of
the project progress
08Sustainable work pace, no rush and
overtime
09Technical excellence and good design
10Simplicity:
The art of maximizing the unrealized work is essential
11Self-organized teams:
empowerment!
12Continuous improvement: inspection and
adaptation
SCRUM
• Scrum is based on empirical process
• Defined processes say how they should be executed
• When processes are very complicated to define how, empirical processes are recommended
SCRUM
• Transparency
• Inspection
• Adaptation
ROLES: THE SCRUM TEAM
PRODUCT OWNER- Responsible for the backlog and the
value- Ensures the value of work being done
by the team- Ensures that the team understands the
items in the backlog
SCRUM MASTER- Teach Scrum and ensures that it is
followed- Remove impediments
- Eases management of the backlog- Helps in communication
- Facilitates Scrum events as needed
DEVELOPMENT TEAM
- Auto organized;- Multi-functional;
- Does not contain sub-teams.
SCRUM EVENTS
SPRINT• Scrum heart;
• Fixed time (one month or less);
• No changes affecting the sprint goals are performed;
• Does not put or remove people from the team during an Sprint;
• The scope can be renegotiated when more is learned;
PLANNING
• It answers two questions:
• What will be delivered on the next Sprint?
• How the work to achieve the result will be done?
DAILY SCRUM
• What has been achieved since the last meeting?
• What will be done until the next meeting?
• What are the impediments?
SPRINT REVIEW
• Inspects the result of Sprint and adapts the Product Backlog if necessary;
• It is recommended four hours to one month Sprint;
• The Product Owner finds out what was done and what was not done;
• The group collaborates on what to do next;
RETROSPECTIVE• It inspects up as was the Sprint as:
• People
• Relationships
• Processes
• Tools
• It creates a map of gaps and an improvement plan
SCRUM ARTIFACTS
PRODUCT BACKLOG
• Ordered: items are sorted according to priority implementation - in order to maximize customer ROI
• Estimable: judge and form an opinion on the size of the product backlog or a relevant part of it (eg next Sprint or Release.)
PRODUCT BACKLOG
• Emerging: incomplete and dynamic list. The environment evolves and customers and Development Team learn about the product
• Gradually refined: according to the priority
• Top items: smaller granularity, more detail
• Down items: high granularity, minor detail
DYNAMICMyths and Facts
MYTHS AND FACTS: PRODUCT OWNER1. The PO is the "proxy" or customer representative, conveying their wishes to the Development Team
2. Although it should be influenced by different people, the PO is the only one who can modify the Product Backlog
3. The PO must balance the needs and desires of different stakeholders of the project
4. The best PO's own client or someone chosen by him
5. The PO should be only one person - there should be only a decision point on the product to the Development Team
6. The PO usually can accumulate the role of ScrumMaster smoothly
7. The PO should collaborate closely with the Development Team to maximize the value delivered to the customer
8. The PO should charge the Development Team are committed to all items selected for the Sprint are developed
9. The presence of the PO is not mandatory in the Sprint Planning Meeting - simply the Development Team choose items from the top of the Product Backlog
10. The PO is responsible for defining the right product to be developed
1. Myth: The PO is the "proxy" or customer representative, conveying their wishes to the Development Team
2. Although it should be influenced by different people, the PO is the only one who can modify the Product Backlog
3. The PO must balance the needs and desires of different stakeholders of the project
4. Myth: The best PO's own client or someone chosen by him
5. The PO should be only one person - there should be only a decision point on the product to the Development Team
6. Myth: The PO usually can accumulate the role of ScrumMaster smoothly
7. The PO should collaborate closely with the Development Team to maximize the value delivered to the customer
8. Myth: The PO should charge the Development Team are committed to all items selected for the Sprint are developed
9. Myth: The presence of the PO is not mandatory in the Sprint Planning Meeting - simply the Development Team choose items from the top of the Product Backlog
10. The PO is responsible for defining the right product to be developed
MYTHS AND FACTS: PRODUCT OWNER
MYTHS AND FACTS: SCRUM MASTER1. To be effective, the ScrumMaster must have worked as a member of a Development Team
2. The ScrumMaster works for the Scrum be correctly used by teaching and reinforcing the values and rules
3. The ScrumMaster should work to remove impediments to the work of the Development Team, but only those that do not require organizational changes
4. ScrumMaster is the most important role in a project that uses Scrum
5. The ScrumMaster should have good interpersonal skills to facilitate the resolution of conflicts and promote good communication
6. The ScrumMaster must protect the Development Team from outside interference
7. The ScrumMaster must manage the work of the Development Team
8. The ScrumMaster works toward becoming increasingly necessary
9. ScrumMasters who work all hours in that role better carry out their work
10. In an opinion, impose or interfere with work decisions of the Development Team, the ScrumMaster becomes less efficient as facilitator
MYTHS AND FACTS: SCRUM MASTER1. Myth: To be effective, the ScrumMaster must have worked as a member of a Development Team
2. The ScrumMaster works for the Scrum be correctly used by teaching and reinforcing the values and rules
3. Myth: The ScrumMaster should work to remove impediments to the work of the Development Team, but only those that do not require organizational changes
4. Myth: ScrumMaster is the most important role in a project that uses Scrum
5. The ScrumMaster should have good interpersonal skills to facilitate the resolution of conflicts and promote good communication
6. The ScrumMaster must protect the Development Team from outside interference
7. Myth: The ScrumMaster must manage the work of the Development Team
8. Myth: The ScrumMaster works toward becoming increasingly necessary
9. ScrumMasters who work all hours in that role better carry out their work
10. In an opinion, impose or interfere with work decisions of the Development Team, the ScrumMaster becomes less efficient as facilitator
WHAT A USER STORY ISN'T
A MOCKUP
USE CASE
REMINDER
SIMPLE TASK GROUP
WHAT IS USER STORY
WHO?
WHAT?
WHY?
As an <ROLE>, I can/should/would
<FUNCTIONALITY> to <VALUE>
As an buyer, I can SEARCH BOOKS to CHOOSE ONE
AND BUY
ACCEPTANCE CRITERIA
• What will be the format of the alert?
• In which way the alert will be shown?
• Constantly means which frequency?
• How we can know that the order is late?
AN ALERT SHOULD BE CONSTANTLY SHOWN AS THE SOFTWARE DETECTS
AN LATE ORDER
ACCEPTANCE CRITERIA
• Defined the limits of what should be developed for each User Story;
• The Acceptance Criteria guide the team to avoid adding features without value in the functionalities, and at the same time, at the same time ensures the minimum needed to deliver value;
• Are expressed in short and simple phrases;
ACCEPTANCE CRITERIA
• The Acceptance Criterias are added to the User Stories in the refinement sessions of the Backlog;
• Should be written by the Product Owner together with the Team, to obtain a shared understanding of what must be done;
ACCEPTANCE CRITERIA
• The acceptance criteria also guide the team in the definition of Acceptance Tests;
• Acceptance Criteria are part of the Definition of Done.
top related