Agile Software Development: Practices through Values

1
Agile Software DevelopmentPractices through
Values

• C Sc 335
• Rick Mercer

2
Goal and Outline

• Main Goal
• Suggest practices, values, and some process for
  completing a final project on time that is better
  than any one could do it in in four times the
  time.
• Outline
• Distinguish Waterfall (plan driven) from Agile
• 11 Practices of quality software development
• Four values of Extreme Programming (XP)
• Process considerations adapted from Scrum

3
Waterfall Model

• Waterfall was described by 1970
• Understood as
• finish each phase
• dont proceed
• till done
• W. W. Royce criticized this
• proposed an
• iterative approach

4
Became Popular

• Management liked phases to easily set deadlines
• Customers provide all requirements
• Analysts translate requirements into
  specification
• Coders implement the specification
• Reviews ensure the specification is met
• Testing is performed by others (QA)
• Maintenance means modifying as little as possible
  
• old code is good code
• Change is hard (and costly)

5
Sprial

• Dr Barry Boehm proposed a spiral approach

6
Waterfall

• It became popular
• This process is still is used a lot
• Craig Larman's book 1 provides proof that
  waterfall has proved to be a terrible way to
  develop software.
• In his study, 87 of all projects failed.
• The waterfall process was the "single largest
  contributing factor for failure, being cited in
  81 of the projects as the number one problem."
• 1 Agile and Iterative Development
• a Manager's Guide, Addison-Wesley Professional,
  2003

7
Extreme Programming (XP)

• As of 2007, about 12 years of growth
• About 25 of new project are Agile
• Set of SE practices that produce high-quality
• software with limited effort
• Many books, first by Kent Beck
• Extreme ProgrammingEmbrace Change,
• Addison-Wesley, 2000,
• ISBN 0-201-61641-6
• http//www.extremeprogramming.org/

8
Extreme Programming

• XP is
• a disciplined approach to software development
• code centric no reckless coding, test-first
• successful because it emphasizes customer
  involvement and promotes team work
• not a solution looking for a problem
• One of several "agile" (can adapt to change)
  software development processes
• http//www.agilealliance.org/

9
Essence of XP

• Four variables in software development
• Cost, Time, Quality, Scope ( features)
• Four Values
• Communication, Simplicity, Feedback, Courage
• Five Principles
• Provide feedback, assume simplicity, make
  incremental changes, embrace change, quality work
• Practices (or fewer, or more, or subject to
  change)
• Planning game, small releases, simple designs,
  automated testing, continuous integration,
  refactoring, pair programming, collective
  ownership, Continuous Integration, on-site
  customer, coding standard

10
Cost of change
Waterfall
Cost of change
XP
time
11
Cost of the Project

• Paraphrasing two companies from Agile 2007 (one
  is published)
• When we bid projects, we charge x for doing it
  Waterfall and x / 2 for doing it Agile

12
Goal and Outline

• Main Goal
• Suggest practices, values, and some process for
  completing a final project on time that is better
  than any one could do it in in four times the
  time.
• Outline
• Distinguish Waterfall (plan driven) from Agile
• 11 Practices of quality software development to
  use on your final project
• Four values of Extreme Programming (XP)
• Process considerations adapted from Scrum

13
Practices Planning Game

• The planning game involves story cards, which are
  short descriptions of a feature
• Provide value to customer
• Independent of each other
• Testable
• Customer writes story cards and prioritizes them
• Developers estimate how long a story takes

14
Practices The planning game

• Business decisions (customer)
• Scope which stories should be developed
• Priority of stories (features)
• Release dates
• Technical decisions (developers)
• Time estimates for features/stories
• Elaborate consequences of business decisions
• Team organization and process
• Scheduling

15
Practices Estimation

• Based on similar stories from the past
  (yesterdays weather)
• Team effort
• Get good at estimation simply by doing it
• Ideal Engineering Time (IET)
• could be points
• Velocity IET/Calendar Time
• we can do 20 points each week
• "Customer, which 20 points do you want next week?"

16
Practices Small Releases

• Releases should be as small as possible
• Should make sense as a whole
• Put system into production ASAP
• Fast feedback
• Deliver valuable features first
• Short cycle time
• Planning 1-2 months rather than 6-12 months
• Or in our case, 1-2 weeks rather than 6 weeks

17
Practices Simple design

• The right design
• Runs all tests
• No code duplication, No code duplication
• Fewest possible classes
• Short methods
• Fulfills all current business requirements
• Design for today not the future
• But design so the system can change

18
Practices Testing

• Software should be tested, but it is often spotty
  or overlooked
• Automatic testing (JUnit, for example) help us
  know that a feature works and it will work after
  refactoring, additional code, and other changes
• Provides confidence in the program

19
Testing

• Write tests at the same time as production code
• Unit tests ? developer
• Feature/acceptance tests ? customer
• Don't need a test for every method
• Testing can be used to drive development and
  design of code
• Allows for regression testing
• Do changes break previously working code

20
SIM/SQS http//www.simgroup.com/Consultancy/regres
sion.html

• Regression Testing
• re-testing of a previously tested program
  following modification to ensure that faults have
  not been introduced or uncovered as a result of
  changes.
• Regression tests are designed for repeatability,
  and are often used when testing a second or later
  version of the system under test.
• Regression testing can be carried out on all
  applications, including e-Commerce and web-based
  systems .

21
Testing

• Strong emphasis on regression testing
• Unit tests need to execute all the time
• Unit tests pass 100
• Acceptance tests (we haven't seen these) show
  progress on which user stories are working
• Other testing frameworks include
• JMeter, HttpUnit, JProbe, OptimizeIt, CPPUnit

22
Can't unit test always

• Wont have unit tests for
• GUIS There are testing frameworks to simulate
  and test user interaction, but not this course
• JPaint Visual inspection, few unit tests
• Randomness Some strategies might have some
  randomness, which can be hard to work with

23
Practices Refactoring

• Restructure code without changing the
  functionality
• Goal Keep design simple
• Change bad design when you find it
• Remove dead code
• Examples at Martin Fowler's Web site
• http//www.refactoring.com/ see
  online catalog

24
Practices Pair programming

• Write production code with 2 people on one
  machine
• Person 1 Implements the method
• Person 2 Thinks strategically about potential
  improvements, test cases, issues
• Pairs change all the time. Has advantages such as
• No single expert on any part of the system
• Continuous code reviews, fewer defects
• Cheaper in the long run, and more fun
• Problems
• Not all people like it
• Pairs need to be able to work together

25
Practices Collective ownership

• All code can be changed by anybody on the team
• Everybody is required to improve any portion of
  bad code s/he sees
• Everyone has responsibility for the system
• Individual code ownership tends to create experts

26
Practices Continuous integration

• Integration happens after a few hours of
  development
• Checkout build with your changes, Make sure all
  tests pass (green bar)
• In case of errors
• Do not put changes into the build
• Fix problems
• Checkin the system to the common repository
• Repeat

27
Continuous Integration

• Find problems early
• Can see if a change breaks the system more
  quickly -- while you remember the details
• Small increments

28
Practices Coding standards

• Coding Standard
• Naming conventions and style
• Least amount of work possible Code should exist
  once and only once
• Team has to adopt a coding standard
• Makes it easier to understand other peoples code
• Avoids code changes because of syntactic
  preferences

29
Practices On-site customer

• Many software projects fail because they do not
  deliver software that meets business needs
• Real customer has to be part of the team
• Defines business needs
• Answers questions and resolves issues
• Prioritizes features

30
Outline

• Main Goal
• Suggest practices, values, and some process for
  completing a final project on time that is better
  than any one could do it in in four times the
  time.
• Outline
• Distinguish Waterfall (plan driven) from Agile
• 11 Practices of quality software development to
  use on your final project
• Four values of Extreme Programming (XP)
• Process considerations adapted from Scrum

31
Values Communication

• Communication
• Customer centric (write "Stories")
• Pair programming
• Task estimation
• Iteration planning
• What to do in the next time period
• May be weekly goals
• Design sessions

The Agile Manifesto
32
Values Simplicity

• Simplicity
• Choose the simplest thing that will work
• Choose the simplest design, technology,
  algorithm, technique

33
Values Feedback

• Feedback very important
• Small Iterations
• Frequent deliveries
• Pair programming
• Constant code review
• Continuous integration (add often to the build)
• automated unit tests (JUnit, for example)

34
Values Feedback

• Compiler feedback seconds
• Pair programming feedback half minutes
• Unit test feedback few minutes
• Acceptance testing half hours
• Customers write these, no can do in 335
• Customer feedback daily (or several times/week
  in our case)
• Iteration feedback weekly
• FeedBack?

35
Agile Manifesto
Manifesto for Agile Software Development We
are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value
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.
36
Outline

• Main Goal
• Suggest practices, values, and some process for
  completing a final project on time that is better
  than any one could do it in in four times the
  time.
• Outline
• Distinguish Waterfall (plan driven) from Agile
• 11 Practices of quality software development to
  use on your final project
• Four values of Extreme Programming (XP)
• Process considerations adapted from Scrum

37
335 Final Project

• SLs and Rick are the customers
• JPaint Mike and Marc
• Risk Will and Ivan
• Networked Hearts Mark and Rick
• As customers, we reserve the right to change
  requirements -)

38
Team

• Class Meetings, every Tue until 27-Nov
• All teams (4 or 7) meet with customers to clarify
  specs, changes, tech issues
• Each week, ask these three Scrum Meeting
  Questions
• What have we done since our last meeting?
• What impeded our work?
• What will we before the next meeting?
• More meetings/coding session preferred of course

39
(No Transcript)
40
A little Scrum

• Scrum A popular Agile Method. We'll use
• Scrum meetings (mentioned on previous slide)
  today and the next four Tuesdays
• Product Backlog
• A document (a spreadsheet or table) in your
  repository that lists all functionality with
  estimates. Highest priorities on top. More later
• Review Meetings
• Each team will meet with their customer / grader
  (SLs)
• Meeting 1 by 6-Nov
• Meeting 2 by 20-Nov

41
Today

• Start the Product Backlog which is "the master
  list of all functionality desired in the product.
  When a project is initiated there is no
  comprehensive, time-consuming effort to write
  down all foreseeable tasks or requirements.
  Typically, a project writes down everything
  obvious (your team actually did that last
  week). The Product Backlog is then allowed to
  grow and change as more is learned about the
  product and its customers." Mountain Goat
  Software

42
Deliverable due next week

• Put a document into you repository that lists all
  functionality you can think of along with
  estimates in hours and who is responsible.
• See example on next slide
• Print a copy of this document to be turned in
  every Tuesday meeting.
• It may not vary much, that's okay
• This is an attempt to produce visibility

43
(No Transcript)
44
Today

• All teams meet customers/graders by Project
• Share discoveries, query the specs (we take role)
• In individual teams
• Draft the product Backlog, estimate, assign
  responsible people, schedule pair programming
  sessions and/or all team meetings/coding sessions
• Ask these three questions
• What have we done since our last meeting?
• What impeded our work?
• What will we before the next meeting?