Upload
daniel-de-amaral
View
852
Download
2
Tags:
Embed Size (px)
DESCRIPTION
Just another presentation about Scrum.
Citation preview
• Introduction to agile principles
• Scrum framework overview
• Further (and related) topics
19
70s - Managing the
Development of Large Software Systems by Dr. Winston W. Royce. - Evolutionary processes process introduced by Tom Gilb.
1980
s - A Spiral Model of Software Development and Enhancement by Barry Boehm. - The Mythical Man Month by Fred Brooks. - PeopleWare by DeMarco and Lister. - Scrum roots on the NNPDG article by Takeuchi and Nonaka. - RUP Objectory v1.0 - Capability Maturity Model (CMM) and Managing the Software Process book by Watts Humphrey's.
1990
s - Dynamic Systems Development Methodology (DSDM). - Crystal Methodologies by Alistair Cockburn. - First toughts and testing on Scrum for SW projects by Jeff S. And Ken S. - Origins of Extreme Programming (XP) from Kent Beck. - Feature Driven Development by Peter Coad and Jeff De Luca.
2000
s - XP was gained “momentum”. - Adaptive Software Development by Jim Highsmith. - Agile Manifesto. - Agile methodologies and practicies growing significantly in the market.
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
reference: http://agilemanifesto.org
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software
Welcome changing requirements, even late in
development. Agile processes harness change
for the customer's competitive
advantage
Deliver working software frequently,
from a couple of weeks to a couple
of months, with a preference to the shorter
timescale
Business people and developers must
work together daily throughout
the project
Build projects around motivated individuals. Give them the environment
and support they need, and trust them to get the
job done
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation
Working software is the primary measure
of progress
Agile processes promote sustainable
development. The sponsors, developers, and users should be able
to maintain a constant pace indefinitely
Continuous attention to technical
excellence and good design
enhances agility
Simplicity--the art of maximizing the amount
of work not done--is essential
The best architectures, requirements, and
designs emerge from self-
organizing teams
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly
reference: http://agilemanifesto.org
reference: adapted from schwaber, 2003
Req
uire
men
ts
Technology
Far from agreement
Close to agreement
Close to certainty
Far from certainty
Here’s where Scrum Excels
I know all details about where I should go (start with plan and all requirements)
End with all requirements completed
I know what is the product/project vision (start with goals and some priority requirements)
End with Goals met
Plan-Driven
Vision and $$ Value-Driven
Inspect and adapt
reference: adapted from schwaber, 2003
Fixed Requirements Resources Schedule
Variable Resources Schedule Requirements
Plan-Driven
Value/Vision Driven
Traditional Agile
reference: sliger & broderick, 2008
“THE PERSON WHO KNEW THAT
HER SON/DAUGHTER COULD
HAVE MARRIED BETTER, AND
WHO INTENDS TO HELP YOU BE
GOOD ENOUGH. YOU HAVE
JUST INVITED HER TO COME
LIVE WITH YOU”
– KEN SCHWABER
Ken Schwaber and Jeff Sutherland - Scrum Fathers
• Co-created by Jeff Sutherland and Ken Schwaber
• Inspirations comes from Japanese manufacturing (and the HBR article “The New New Product Development Game“ from Hirotaka Takeuchi and Ikujiro Nonaka, published in 1986)
• Grounded in empirical process control theory, employs an iterative, incremental approach to optmize predictability and control risk
• Is about
– Transparency
– Inspection
– Adaptation
• Scrum teams and associated roles
• Time-boxes
• Artifacts
• Rules
• Product Owner
• ScrumMaster
• Scrum Team Product Owner
ScrumMaster
Scrum Team
Manager
Customer User
Stakeholders...
“ROI = $$ and I like that! Nice to meet you, Im the PO”
• Define the features of the product
• Decide on release dates and contents
• Responsible for the profitability (ROI)
• Prioritize features according to market value
• Adjust priorities at every Sprint, as needed
• Accept or reject work results
• Is one person, not a committee
“The sheepdog for the team”
• Ensures that the team is fully functional and productive
• Enable close cooperation across all roles and functions
• Remove barriers
• Shield the team from external interferences
• Ensure that the process is followed
• Review and Sprint Planning meetings
Multi-skill ninja team
• Cross functional. Organizes itself and its work
• Team members must have all necessary skills to create an increment of work
• Everyone chips in, even if that requires learning new skills or remembering old ones
• 5 - 9 team members
• Has the right to do everything within the boundaries of the project guidelines to reach the Sprint goal
• Demonstrates work results to the Product Owner
• Release Planning Meeting
• Sprint
• Sprint Planning Meeting
• Daily Scrum
• Sprint Review
• Sprint Retrospective
Vision Anticipated ROI,
Releases, Milestones
Functional and nonfunctional emerging
and prioritized requirements
Requirements brake down into activities/tasks
Selected Product Backlog
New functionality is demonstrated at the enf of
Sprint
1 2 3
1 Release Planning Meeting
2 Sprint planning meeting 1
3 Sprint planning meeting 2
4 The Sprint
5 Daily Scrum
6 Sprint Review
7 Sprint Retrospective
4
5
Setting the vision and the strategic plan
• Establish a plan and goals that the Scrum Teams and the rest of the organizations can understand and communicate
• Release planning requires estimating and prioritizing the Product Backlog for the Release
• Release planning is not a commitment to precise details
• Release planning is entirely optional. If Scrum teams start work without the meeting, the absence of its artifacts will become apparent as an impediment that needs to be resolved
It’s time to run!
• A Sprint is an iteration
• Time-boxed
• All work is done in Sprints
• Consisted by the Sprint Planning, development work, Sprint Review and the Sprint Retrospective
• Sprints can be cancelled before the Sprint time box is over. Only the Product Owner has the authority to cancel the Sprint
Operational plan being defined
• Is where the Sprint is planned
• Splited in two moments:
– The PO with the ScrumTeam support selects the Product Backlog items that will compose the Sprint Backlog (needs to consider team velocity, etc. during this selection)
– With the Sprint Backlog defined, the team works together to came up with a plan to the Sprint that is beginning
– Meeting output: Sprint Backlog
“Look, our burndown is about to screw up, we need to attack more harder to change that”
• The Scrum heartbeat
• 15 minutes
• 3 questions
– What did you do yesterday?
– What will you do today?
– Are there any impediments in your way?
• The Daily Scrum is not a status meeting
• The Daily Scrum is an inspection of the progress toward the Sprint Goal that the team was committed for
“Let me show you that story operating”
• The team presents to the PO and stakeholders functionality that is done and answer questions.
• The Product Owner identifies what has been done and what hasn’t been done
• The Team discusses what went well during the Sprint and what problems it ran into, and how it solved these problems
• The entire group then collaborates about what it has seen and what this means regarding what to do next
“Definetely we need more automation in our tests, we are wasting a lot of time doing
manual qualification...”
• Time to review the good and the bads
• Inspect how the last Sprint went in regards to people, relationships, process and tools
• The meeting is from the team to the team
• PO attendance is not obrigatory
• ScrumMaster hold this meeting
• Team identify the actions to adapt and improve the ongoing process
• Product Backlog
• Sprint Backlog
• Release Burndown
• Sprint Burndow
• The PO “wish list”
• Items prioritized by the business importance/value
• The PO is the owner
• As long as a product exists, the Product Backlog also exists
img source: http://epf.eclipse.org/wikis/scrum/
Sprint
Release
Next Release
Priority
user stories
themes
epics
• Details the work, or tasks, that the team defines to turning the Product Backlog it selected for that Sprint into an increment of potentially shippable product functionality img source: http://epf.eclipse.org/wikis/scrum/
• Shows the Release progress
• How much selected Product Backlog was “burned”
• Updated at the end of each Sprint
• Normally the unit measure is Story Points (not a rule) against Sprints
img source: http://epf.eclipse.org/wikis/scrum/
• Shows the Sprint progress
• How much the team already “burned” in that Sprint
• Primary tool for the Daily Scrum meetings (with task boards or Sprint activities list)
• Normally the unit measure is Hours against time (daily basis)
img source: http://epf.eclipse.org/wikis/scrum/
• Scrum requires teams to build an increment of product functionality every Sprint
• This increment must be potentially shippable, for Product Owner may choose to immediately implement the functionality
• The detailed definition of Done should be agreed between the ScrumTeam and the PO
• Plannig Poker
• User Stories and Story Points
• Technical Debt
• Team Velocity
• Complex Adaptive Systems
• Lean manufacturing
• Constraints Theory
• Kanban
• www.scrum.org
• www.scrumalliance.org
• Books