Transcript AGILE SW - This is not the page you are looking for

Software Quality and
Agile SW Development
Johan Lindvall
TY 22.4.2005
Content
•
•
•
•
•
Backround and problems
IID
Scrum
XP
Quality
Backround and Problems
• waterfall: response to ad-hoc code-and-fix 1960’s,
Winston Royce (proponent of iterative dev.)
• e.g. DoD standard 2167
• system should be clearly specified before its
design and implemention
• the clients are not sure what they want
• details will only be revealed during development
• as the product develop, clients change their minds
• external forces (competitor’s product)
-> high change rate, not predictable manufactoring
IID
• Interative and incremental development
• Agile methods are a subset of iterative and
evolutionary methods
• The key practices:
iterative development
risk-driven and client-driven
timeboxing
evolutionary development
evolutionary requirements
adaptive planning
Iterative Development
• ID is an approach to build sw of several
iterations
• each iteration a mini-project
– requirements analysis, design, programming,
test
– iteration release: a stable, integrated and tested
internal (external) partially complete system
• iteration by iteration system grows incrementally
with new features
 iterative and incremental development IID
• at least 3 iterations
• recommended lenght is 1-6 weeks per itr.
• early risk mitigation and discovery
– riskiest problems first
– a study [Johnson2002]:
•
•
•
•
•
45% of features were not used
19% rarely
16% sometimes
13% often
7% always
• final product better matches true client desires
 quality
• iterative development is lower risk and better
success, productivity, and defect rates than WF
• early and regular process improvement
– a per-iteration assessment
• confidence and satisfaction from early, repeated
success  team self-confidence  customer
confidence in the team
Risk-Driven and Client-Driven
Iterative Planning
• What to do in the first/next iteration?
• Risk-driven: the riskiest, most difficult
elements for the early iterations
• Client-driven: the choice of features comes
from client, the currently highest business
value
Timeboxing
• the practice of fixing the iteration end-date
and not allow it to change
• if short of time, reduce the scope and leave
features to the next iteration
• no adding of new tasks to iteration
Evolutionary and Apadtive Development
• requirements, plan, estimates, solution
evolve and are refined
• requires feedback from users, tests,
developers
• consept:
evolutionary ~ adaptive = iterative-timebox
Evolutionary Requirements Analysis
• requirements are not always changing (Boehm 1988 25%)
• most requirements discovery and refinement
usually occours during early iterations
• e.g. 1-2 day req. workshop/itr.
• early top-ten high-level req. (e.g. load, usability)
• a study (1995, 107 projects)
– 18% of the projects completed the reqs. in 1 iteration
– 32% in 2 iterations
– 50% in 3 or more iterations
Evolutionary and Adaptive planning
• an initial phase of high uncertainty which
drops
• cone of uncertainty (effort, cost, shedule
/time)
• apadtive planning: no detailed schedule are
created
Delivery
• partial software produced, not merely
documents
• incremental delivery: system into
production, deliveries between 3-12 months
• evolutionary delivery: attempt to capture
feedback, promoted in agile development
Agile sw development
• requiring feedback to guide direction, early testing, early
demos
• agility – rapid and flexible response to change
• motto: embrace change
• practices and principles: simplicity, lightness,
communication, self-directed teams, programming over
documents
• eg. Scrum and XP
• whiteboard (wall sketches), snapshots
• timeboxed iterative and evolutionary development,
adaptive planning, promote evolutionary delivery
• http://www.digitoday.fi/showPage.php?page_id=9&news_id=28365
The Agile Manifesto
Individuals and interactions
over process and tools
Working software
over comprehensive documentation
Customer collaboration
over contract negotiation
Responding to change
over following the plan
The Agile principles
•
•
•
•
•
•
•
•
•
•
•
•
•
early and continuous delivery of valuable sw
welcome changing requirements, even late
delivery working sw frequently
business people and developers daily together
motivated individuals
face-to-face conversation for information
working sw is the primary measure of progress
agile processes promote sustainable development
developpers, users maintain constant pace
attention to technical excellence and good design enhances agility
simplicity essentail – the art of maximizing the amount of work not done
the best architectures, requirements and desings emerges from self-organizing
teams
the team regulary reflects on how to become more effective
Scrum
• by Takeuchi and Nonaka 1986 paper of
summarizing common best practises in 10
innovatoive Japanese companies
• timebox exactly 30 days
• working in a common room
• daily meeting, at the same time and place
• self-directed teams (one team <=7, many teams)
• external demo at the end of each iter.
• Cockburn scale C, D, E, L and 1-100-…
• client-driven adaptive planning
• Lifecycle: plannig, staging,development,
release
• Planning:
– establish the vision, set expectations, funding
– write vision, budget, initial Product Backlog
• Staging:
– identify more requirements, priorotize enough
for first iteration
Development:
– implenent a system ready for release in series of 30 days
(sprints)
– Sprint planning: choose goals for the next iteration, how
to achieve the requests. Sprint Backlog: tasks (in next 416h) to meet the goals
– during iteration do not add work, uninterrupted focus
– quality assurance occurs specially in Sprint, with less
new development
Release:
– operational deployment
– or each release begins with staging
• Product Backlog
a list of all product requirements,
functionality, features, techlogy
never finished  evolves
• Sprint Backlog
daily estimate of work remaining for each task
Scrum is based on the insight that SW
development is creative and unpredictible new
product development, and therefore empairical
rather than defined methods are needed.
Scrum values
• Commitment
– the team commits to a defined goal and decide
themselves how best to meet it
• Focus
– team not distracted, chickens and pics-rule, srcum
master
• Openness
– product backlog makes visible the work and priorities
• Respect – self-organizing
• Courage – trust the team
XP
•
•
•
•
•
eXtreme Programming, Kent Beck 1980’s
truly adobted by developpers!
Cockburn scale C, D, E and 1-20
small team projects, <10 developpers
emphasizes collaboration, quick and early
sw creation
• the cost of change may not rise over time
• 4 values
– communication: pairs, daily meetings, customer
on-site
– simplicity: ’Do simpliest thing that could
possbly work’. Eg. avoid creating generalized
components.
– feedback: drives to quality and adaption
– courage: simple design & tests  rapid and
radical changes
• 1-4 weeks iterations
• story cards to summarize requirements, not
required detailed workproducts
• programming in pairs (deep skill transfer)
• common project room
• full-time participation by requirements donor (the
client, end user) for ongoing verbal explinations
• test-driven development, code reviews, frequent
integration of all code
short iterations, early feedback  quality
• tests written ahead!
• timeboxed, no working overtime
12 core practices
• The planning game
– scope, priority, composition of releases, dates of
releases
– estmates, consequences, process, detailed scheduling
• Small releases
– the most valuable business requirements
• Metaphor
– the basic elements and their relationships, naive
statement
• Simple Design
– runs all the tests, no duplicated logic, every intention
important, fewest possible classes and methods
• Testing
– unit tests, functional tests
• Refactoring
– even more simpler?
• Pair programming
– implemention vs. strategy
• Collective ownership
– need to change now, not later
• Continous Integration
– integrated and tested after few hours - a day
• 40 hour week
• On-site customer
• Coding standards
Others: Evo
•
•
•
•
1960’s, published 1976
1-2 weeks iteration
evolutionary delivery on each iteration
plans iterations by highest value-to-cost
ratio
Others: UP
• Unified Process, 1990’s
• iterative, not agile
• risk-driven development in early iterations
focusing on creation of the core architecture
and driving down the high risks
• 2-6 weeks iterations
Quality
• research show that shorter steps have lower
complexity and risk, better feedback, and
higher productivity and success rate
• early defect removal, less useless work,
concentration on essential features
• each iteration tested for acceptance
real business value for customer.
References
• Larman, Craig: Agile and Iterative Development,
Addison-Wesley, 2004
• Beck, Kent: Extreme programming explained:
embrace change, Addison-Wesley, 2000
• Scwaber Ken, Beedle Mike:Agile Software
Development with Scrum, Prentice-Hall, 2002
• http://www.digitoday.fi/showPage.php?page_id=9&news_id=28365