agile software development practices through values l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Agile Software Development: Practices through Values PowerPoint Presentation
Download Presentation
Agile Software Development: Practices through Values

Loading in 2 Seconds...

play fullscreen
1 / 44

Agile Software Development: Practices through Values - PowerPoint PPT Presentation


  • 424 Views
  • Uploaded on

Agile Software Development: Practices through Values C Sc 335 Rick Mercer 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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Agile Software Development: Practices through Values' - Olivia


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
goal and outline
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
waterfall model
Waterfall Model
  • Waterfall was described by 1970
  • Understood as
    • finish each phase
    • don’t proceed

till done

  • W. W. Royce criticized this
    • proposed an

iterative approach

became popular
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)
sprial
Sprial
  • Dr Barry Boehm proposed a spiral approach
waterfall
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

extreme programming xp
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 Programming–Embrace Change,

Addison-Wesley, 2000,

ISBN 0-201-61641-6

  • http://www.extremeprogramming.org/
extreme programming
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/

essence of xp
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
cost of change
Cost of change

Waterfall

Cost

of

change

XP

time

cost of the project
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
goal and outline12
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
practices planning game
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
practices the planning game
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
practices estimation
Practices: Estimation
  • Based on similar stories from the past (“yesterday’s 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?"
practices small releases
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
practices simple design
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
practices testing
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
testing
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
sim sqs http www simgroup com consultancy regression html
SIM/SQS http://www.simgroup.com/Consultancy/regression.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, includinge-Commerce and web-based systems .
testing21
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
can t unit test always
Can't unit test always
  • Won’t 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
practices refactoring
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

practices pair programming
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
practices collective ownership
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
practices continuous integration
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
continuous integration
Continuous Integration
  • Find problems early
  • Can see if a change breaks the system more quickly -- while you remember the details
  • Small increments
practices coding standards
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 people’s code
    • Avoids code changes because of syntactic preferences
practices on site customer
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
outline
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
values communication
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

values simplicity
Values: Simplicity
  • Simplicity
    • Choose the simplest thing that will work
    • Choose the simplest design, technology, algorithm, technique
values feedback
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)
values feedback34
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?
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 toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding 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.

Agile Manifesto
outline36
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
335 final project
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 :-)
slide38
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
a little scrum
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
today
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
deliverable due next week
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
today44
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?