Software Quality and Agile SW Development

1
Software Quality and Agile SW Development

• Johan Lindvall
• TY 22.4.2005

2
Content

• Backround and problems
• IID
• Scrum
• XP
• Quality

3
Backround and Problems

• waterfall response to ad-hoc code-and-fix
  1960s, 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 (competitors product)
• -gt high change rate, not predictable
  manufactoring

4
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

5
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

6

• 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

7

• 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

8
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

9
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

10
Evolutionary and Apadtive Development

• requirements, plan, estimates, solution evolve
  and are refined
• requires feedback from users, tests, developers
• consept
• evolutionary adaptive iterative-timebox

11
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

12
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

13
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

14
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_id9new
  s_id28365

15
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

16
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

17
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 lt7, many teams)
• external demo at the end of each iter.

18

• 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

19

• 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 4-16h) 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

20

• 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.

21
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

22
XP

• eXtreme Programming, Kent Beck 1980s
• truly adobted by developpers!
• Cockburn scale C, D, E and 1-20
• small team projects, lt10 developpers
• emphasizes collaboration, quick and early sw
  creation
• the cost of change may not rise over time

23

• 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

24

• 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

25
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

26

• 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

27
Others Evo

• 1960s, published 1976
• 1-2 weeks iteration
• evolutionary delivery on each iteration
• plans iterations by highest value-to-cost ratio

28
Others UP

• Unified Process, 1990s
• 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

29
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.

30
References

• Larman, Craig Agile and Iterative Development,
  Addison-Wesley, 2004
• Beck, Kent Extreme programming explained
  embrace change, Addison-Wesley, 2000
• Scwaber Ken, Beedle MikeAgile Software
  Development with Scrum, Prentice-Hall, 2002
• http//www.digitoday.fi/showPage.php?page_id9new
  s_id28365