+ All Categories
Home > Documents > 18-Agile07FinalProject1CHECKER.ppt

18-Agile07FinalProject1CHECKER.ppt

Date post: 27-Jan-2015
Category:
Upload: softwarecentral
View: 104 times
Download: 0 times
Share this document with a friend
Description:
 
Popular Tags:
44
Agile Software Development: Practices through Values C Sc 335 Rick Mercer
Transcript
Page 1: 18-Agile07FinalProject1CHECKER.ppt

Agile Software Development:Practices through Values

C Sc 335Rick Mercer

Page 2: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 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

Page 3: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 3

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

Page 4: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 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)

Page 5: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 5

Sprial

Dr Barry Boehm proposed a spiral approach

Page 6: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 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

Page 7: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 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 Programming–Embrace Change,

Addison-Wesley, 2000,

ISBN 0-201-61641-6 http://www.extremeprogramming.org/

Page 8: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 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 processeshttp://www.agilealliance.org/

Page 9: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 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

Page 10: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 10

Cost of change

Costof

change

time

Waterfall

XP

Page 11: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 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

Page 12: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 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

Page 13: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 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

Page 14: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 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

Page 15: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 15

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?"

Page 16: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 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

Page 17: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 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

Page 18: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 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

Page 19: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 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

Page 20: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 20

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, including e-Commerce and web-based systems .

Page 21: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 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

Page 22: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 22

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

Page 23: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 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

Page 24: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 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

Page 25: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 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

Page 26: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 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

Page 27: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 27

Continuous Integration

Find problems early Can see if a change breaks the system more

quickly -- while you remember the details Small increments

Page 28: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 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 people’s code Avoids code changes because of syntactic preferences

Page 29: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 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

Page 30: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 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

Page 31: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 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

Page 32: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 32

Values: Simplicity

Simplicity Choose the simplest thing that will work Choose the simplest design, technology,

algorithm, technique

Page 33: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 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)

Page 34: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 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?

Page 35: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 35

Agile ManifestoManifesto 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.

Page 36: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 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

Page 37: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 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 :-)

Page 38: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 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

Page 39: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 39

Page 40: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 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

Page 41: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 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

Page 42: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 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

Page 43: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 43

Page 44: 18-Agile07FinalProject1CHECKER.ppt

April 10, 2023 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?


Recommended