Software technology
2016/17
Agile software development
Manifesto
Individuals and interactions
over processes and tools
Working software
over comprehensive documentation
Customer collaboration
over contract negotiation
Responding to change
over following a plan
February 13, 2001
02/08/2016
© Z. László
2
Agile methodologies
SCRUM
Extreme Programming
Dynamic Systems Development Method
Adaptive Software Development
Crystal
Feature-Driven Development
Pragmatic Programming
….
02/08/2016
© Z. László
3
02/08/2016
© Z. László
4
Agile principles
Customer satisfaction by rapid delivery of useful software
Welcome changing requirements, even late in development
Working software is delivered frequently
Working software is the principal measure of progress
Sustainable development, able to maintain a constant pace
Close, daily cooperation between business people and developers
Face-to-face conversation is the best form of communication
Projects are built around motivated individuals, who should be
trusted
Continuous attention to technical excellence and good design
Simplicity
Self-organizing teams
Regular adaptation to changing circumstances
02/08/2016
© Z. László
5
Scrum / Overview
A framework within which people can address
complex adaptive problems, while productively
and creatively delivering products of the
highest possible value.
Lightweight
Simple to understand
Extremely difficult to master
http://www.scrum.org/
http://www.agilealliance.hu/
02/08/2016
© Z. László
6
Scrum / Overview
Pillars
Transparency
Inspection
Scrum users must frequently inspect artifacts and
progress toward a goal to detect undesirable variances
Adaptation
02/08/2016
observers share a common understanding
“things” be defined by a common standard
If the process deviate outside acceptable limits, or the
resulting product will be unacceptable, an adjustment
must be made asap to minimize further deviation.
© Z. László
7
Scrum / Overview
02/08/2016
© Z. László
8
Scrum / Overview
Sprint
02/08/2016
The heart of Scrum
Scrum projects make progress in a series of sprints
A time-box for producing a releasable product
Typical duration is 2–4 weeks or a month at most
Product is designed, coded, and tested during the
sprint
No changes during a sprint
would be cancelled if the goal becomes obsolete
Is a container for all other events
© Z. László
9
Scrum / Framework
Roles (core, pigs)
Events
Product owner
ScrumMaster
Team
Sprint planning
Sprint review
Sprint retrospective
Daily scrum meeting
Artifacts
02/08/2016
Product backlog
Sprint backlog
Burndown charts
© Z. László
10
Scrum / Roles
Product owner
02/08/2016
Represents the “voice of the customer”
Responsible for managing the Product Backlog
Define the features of the product
Decide on release date and content
Responsible for the profitability of the product
Prioritize features according to market value
Adjust features and priority every iteration
Accept or reject work results
has the authority to cancel the Sprint
© Z. László
11
Scrum / Roles
ScrumMaster
02/08/2016
Represents management to the project
Responsible for enacting Scrum values and
practices
Removes impediments
Ensure that the team is fully functional and
productive
Enable close cooperation across all roles and
functions
Buffer between the team and any distracting
influences
Shield the team from external interferences
© Z. László
12
Scrum / Roles
Team
02/08/2016
Responsible for delivering the product
Typically 5-9 people
Cross-functional:
analyse, design, develop, test, technical
communication, document, etc.
Be self-organizing and self-led
Members should be full-time
Membership should change only between sprints
© Z. László
13
Scrum / Roles
Ancillary roles (chickens)
Stakeholders (customers, vendors)
Managers (including Project Managers)
02/08/2016
These are the people who enable the project and for
whom the project will produce the agreed-upon benefit[s],
which justify its production. They are only directly involved
in the process during the sprint reviews.
People who will set up the environment for product
development.
© Z. László
14
Scrum / Events
Sprint planning
Team
capacity
Product
backlog
Business
conditions
Current
product
Sprint
prioritization
Sprint
planning
Goal
Sprint
backlog
Technology
02/08/2016
© Z. László
15
Scrum / Roles
Sprint planning
Sprint prioritization
Sprint planning
02/08/2016
Analyze and evaluate product backlog
Select sprint goal
Team selects items from the product backlog they can
commit to completing
Decide how to achieve sprint goal (design)
High-level design is considered
Create sprint backlog (tasks) from product backlog items
(user stories / features)
Estimate sprint backlog in hours
Collaboratively, not done alone by the ScrumMaster
© Z. László
16
Scrum / Roles
Daily scrum
15-minute time-boxed event to
Stand-up
Each Team member explains
02/08/2016
synchronize activities
create a plan for the next 24 hours
What has been accomplished since the last meeting?
What will be done before the next meeting?
What obstacles are in the way?
Not for problem solving
Whole world is invited
Only Team members, ScrumMaster, Product owner
can talk
© Z. László
17
Scrum / Roles
Sprint review
held at the end of the Sprint to
02/08/2016
inspect the Increment and
adapt the Product Backlog if needed.
four-hour time-boxed meeting for one-month
Sprints. Proportionately less time is allocated for
shorter Sprint.
2-hour prep time rule, no slides, informal
Result: revised Product Backlog
© Z. László
18
Scrum / Roles
Sprint review
includes the following elements:
02/08/2016
The Product Owner identifies what has been “Done” and
what has not been “Done”;
The Team discusses what went well, what problems it ran
into, and how those problems were solved;
The Team demonstrates the work that it has “Done” and
answers questions about the Increment;
The Product Owner discusses the Product Backlog as it
stands.
The entire group collaborates on what to do next.
© Z. László
19
Scrum / Roles
Sprint retrospective
occurs between the Sprint Review and the next
Sprint Planning Meeting.
is an opportunity for the Team to inspect itself and
create a plan for improvements to be enacted
during the next Sprint.
02/08/2016
Inspect how the last Sprint went with regards to people,
relationships, process, and tools;
Identify and order the major items that went well and
potential improvements;
Create a plan for implementing improvements to the way
the Team does its work.
three-hour time-boxed meeting for one-month
Sprints.
© Z. László
20
Scrum / Artifacts
Product backlog (PB)
02/08/2016
ordered list of everything that might be needed in
the product, and is the single source of
requirements
The Product Owner is responsible for the PB.
PB items have the attributes of a description, order,
and estimate.
Grooming is the act of adding detail, estimates, and
order to items.
How and when grooming is done is decided by the
Core Team.
The Team is responsible for all estimates.
© Z. László
21
Scrum / Artifacts
Sprint backlog
set of PB items selected for the Sprint + a plan for
delivering the product Increment
forecast about what will be in the next Increment
and the work needed to deliver that functionality.
plan with enough detail (4-16 hours) that changes
in progress can be understood in the Daily Scrum.
Task
Code user interface
Test user interface
Code model class
Test model class
Write help
02/08/2016
M
T
4
3
W
4
1
2
4
Th
4
5
F
2
3
2
4
12
© Z. László
22
Scrum / Artifacts
Burndown chart
At any point in time, the total work remaining in the
Sprint Backlog items can be summed.
The Core Team tracks this total work remaining at
least for every Daily Scrum.
60
50
40
30
20
10
0
M
02/08/2016
T
W
© Z. László
Th
F
23
Scrum / Conclusions
Applicability and effectiveness
in small-scale and relatively simple projects
mission-critical and large-scale projects ???
questionable
Problems:
02/08/2016
team composition
ScrumMaster
allocate enough time for planning and design
© Z. László
24
XP / Introduction
Extreme Programming (XP)
Why X and why P ?
lightweight process model for OO software
development
code is in the centre of the process
practices are applied extremely
What is new in XP?
none of the ideas or practices are new
the combination of practices and their extreme
application is new
XP is based on a set of values, principles, and
practices
25
© Z. László
02/08/2016
XP / Introduction
http://www.extremeprogramming.org/
02/08/2016
© Z. László
26
XP / Introduction
XP values
Communication
Simplicity
enables developers to feel comfortable with refactoring
their code when necessary
Respect
02/08/2016
test results are the best concrete feedback.
Courage
what is the simplest thing that could possibly work?
Feedback
within the team, and with customers
developers respect their own work by always striving for
high quality
© Z. László
27
XP / Introduction
XP principles
Rapid feedback
Assume simplicity
Solve problems with a series of small changes
Embracing change
02/08/2016
Treat every problem as simple
Incremental change
Minutes, rather than days or weeks
not working against changes but embracing them
© Z. László
28
XP / Introduction
Planning/feedback loops
02/08/2016
© Z. László
29
XP / Introduction
XP project
02/08/2016
© Z. László
30
XP / Introduction
An XP day
02/08/2016
© Z. László
31
XP / Rules
XP key practices (rules)
02/08/2016
Planning game
Frequent releases
System metaphor
Simple design
Tests
Refactoring
Pair programming
Collective code ownership
Continuous Integration
Forty-hour week
On-site customer
Coding standards
© Z. László
32
XP / Rules
Planning game
Business people need to decide about:
Technical people decide about:
02/08/2016
Scope
Priority
Composition of releases
Dates of releases
Estimates
Technical consequences
Process
Detailed schedule
© Z. László
33
XP / Rules
Planning game
Release planning
Iteration planning
02/08/2016
Goal: determining what requirements are included in
which near-term releases, and when they should be
delivered.
each Release is typically 1 - 6 months
This plans the activities and tasks of the developers.
typically 1 - 3 weeks
© Z. László
34
XP / Rules
Planning game / Release planning
Exploration phase
Commitment phase
determination of costs, benefits, and schedule impact
value, risk, velocity, scope
Steering phase
02/08/2016
gathering requirements and estimating the work impact of
each of those requirements.
write a story - user story card
estimate a story - how long it will take to implement
split a story - complex stories must be split into smaller
ones
revisit the plan. Changes, adjust
© Z. László
35
XP / Rules
Planning game / Iteration planning
Exploration phase
Commitment phase
programmers are assigned tasks
programmer estimates the task
load balancing
Steering phase
02/08/2016
is about creating tasks and estimating their impl. time
combine/split task
estimate task
implementation of the tasks
design, write, test, refactor
© Z. László
36
XP / Rules
Frequent Releases
02/08/2016
The development process is highly iterative
A release cycle is usually up to 3-6 months
Every release should be small as possible,
containing the most valuable business
requirements
Small and frequent releases provide frequent
feedback from the customer
The release must make sense as a whole
A release cycle consists of iterations up to 3 weeks
Each user story is split in programming tasks of 1-3
days
© Z. László
37
XP / Rules
System Metaphore
02/08/2016
Common concepts of what the system is like
Defines the overall theme to which developers and
clients can relate
The system is built around one (or more) system
metaphor from which classes, methods, variables
and basic responsibilities are derived
© Z. László
38
XP / Rules
Simple Design
Keep things as simple as possible as long as
possible by never adding functionality before it is
scheduled!
What is simple ?
02/08/2016
Testable
Understandable
Browsable
Explainable
Once and only once
© Z. László
39
XP / Rules
Tests
Create tests first, before the code !
Unit test
Acceptance test
02/08/2016
Code without tests may not be released.
Use test tools !
Unit tests enable refactoring.
are created from user stories.
are black box system tests.
as regression tests prior to a production release.
Customers are responsible for verifying the correctness of
the acceptance tests and reviewing test scores.
© Z. László
40
XP / Rules
Refactoring
Changing a software system in a way that does not
alter the external behavior of the code, while
improving its internal structure.
The code may be changed at any time to provide:
•
•
•
02/08/2016
Simplification
Flexibility
Reduced redundancy
© Z. László
41
XP / Rules
Pair programming
All programming is done with two coders at the
same machine.
What pair programming is:
One partner typing, One partner the other thinking at a
strategic level.
A chance for communication.
What pair programming is not:
02/08/2016
The programmers must share one mouse, keyboard,
screen, etc.
One writing and one watching.
A tutorial session.
© Z. László
42
XP / Rules
Pair programming
Is a social skill that takes time to learn.
Pairs change continuously (few times in a day)
02/08/2016
every programmer knows all the aspects of the system
a programmer can be easily replaced in the middle of the
project
Costs more (10-15%)
Code is simpler (fewer LOC) with less defects
(15%)
Continuous code inspection
© Z. László
43
XP / Rules
Collective code ownership
The code does not belong to any programmer but
to the team
Any programmer can (actually should) change any
of the code at any time in order to
Encourages the entire team to work more closely
together
Everybody tries to produce a high-quality system
02/08/2016
make it simpler
make it better
code gets cleaner
system gets better all the time
everybody is familiar with most of the system
© Z. László
44
XP / Rules
Continuous integration
02/08/2016
Commiting code into the code repository every few
hours, when ever possible (no more than a day).
The whole system is built (integrated) every couple
of hours.
Everyone needs to work with the latest version.
A working tested system is always available.
Avoids diverging or fragmented development
efforts.
© Z. László
45
XP / Rules
Forty-hour week
02/08/2016
Developers should not work more than 40 hour
weeks.
Consecutive weeks of overtime is not allowed.
If more is needed then something is wrong.
A key enabler to achieve sustainable pace is
frequent code-merge and always executable & test
covered high quality code.
© Z. László
46
XP / Rules
On-site customer
At least one customer is always present (part of the
team).
User stories are not detailed, so there are always
questions to ask the customer
The customer must always be available
02/08/2016
to resolve ambiguities
set priorities
provide test cases
© Z. László
47
XP / Rules
Coding standards
The standard specifies a consistent style and
format for
02/08/2016
source code
various programming constructs (common naming,
packing)
patterns
Coding standards make pair programming and
collective code ownership easier.
© Z. László
48
XP / Conclusions
XP is successful because...
02/08/2016
XP can handle changing customer requirements,
even late in the life cycle
XP stresses customer satisfaction; it delivers
what the customer needs
when the customer needs it
XP emphasises team work
© Z. László
49
XP / Conclusions
XP Controversy
Detailed specifications are not created or
preserved.
Not all developers expect to be asked to pair work.
Most of the design activity takes place on the fly
and incrementally
02/08/2016
starting with "the simplest thing that could possibly work"
adding complexity only when it's required by failing tests.
More re-design effort.
Underestimation.
Uncooperative customers.
© Z. László
50