agile. processes waterfall traditional with prototyping sprial agile dynamic systems development...

Agile

2

Processes

• Waterfall• Traditional• With prototyping

• Sprial• Agile

• Dynamic Systems Development Method (DSDM)• Scrum• Crystal• eXtreme Programming (XP)

3

Waterfall Spiral AgileEmphasizes:

-Simplicity-Traceability

-Risk management-Exploring alternatives

-Flexibility-Immediacy

Weakness: Requirement/design mistakes can be costly

Exploring alternatives can be costly

Continual rework can be costly

Style: -Highly controlled-High ceremony

-Moderately controlled-Moderate ceremony

-Rapid & organic-Low ceremony

Some definitions-“traceability”: relationships between requirements and system elements are documented-“immediacy”: getting some sort of working system to the customer as fast as possible-“rework”: redesigning the architecture and/or refactoring the program code-“controlled”: conformance to process is highly valued, even if it slows a project down-“ceremony”: how much analysis, documentation, and planning is involved

4

When to choose what

• Waterfall: good for smaller systems where requirements can be fully understood before design and implementation

• Spiral: good for larger systems with vague requirements and many alternatives for designing and coding

• Agile: good for systems where you can rapidly create something very small but useful and then expand from there

5

Agile Manifesto

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

6

Agile Processes

Customer provides short requirements

System and acceptance tests

evaluate & control risk

Prioritizerequirements

and plan

Implement

OperationWrite/run/modify

unit tests

7

Iterations

• Purpose• Iterative gives you a few “oh drat”s instead of one OMG at the end.

• Timing• Scrum: 1 month• XP: 1-2 weeks

• Grouping• Iterations can be grouped into releases• Not ever iteration results in a new release

• Sub-dividing• Each iteration has “micro-iterations”

8

Principles of DSDM (Dynamic Systems Development Method)

• Active user involvement is imperative

• The team must be empowered to make decisions

• Fitness for business purpose is the essential criterion for accepting deliverables

• Requirements are specified at a high level

• Focus on frequent delivery of products

9

Principles of DSDM (cont..)

• Iterative and incremental development necessary to converge on a solution

• All changes during development are reversible

• Testing is integrated throughout life cycle

• Collaboration and cooperation is essential

10

Key Practices of DSDM

• Ambassador users and facilitated workshops• Users on-call and users en-masse (respectively)

• Stages of iterations:• Pre-project exploratory phase (kick around ideas)• Feasibility study (explore if ideas are doable) • Business study (explore if ideas worth doing)• Model, design, implement (a “timebox” of work)• Post-project phase (what went well and what didn’t?)

11

Principles of XP (Extreme Programming)

• Communication- It’s good to talk with customer and between developers

• Simplicity- Keep it simple and grow the system (and models) when required

• Feedback- Let users provide feedback early and often

• Courage- Speak the truth, with respect

12

Practices of XP

• Whole team• Metaphor• The planning game• Simple design• Small releases• Customer tests• Pair programming

• Test-driven development

• Design improvement• Collective code ownership• Continuous integration• Sustainable pace• Coding standards

13

Practices of XP

• Whole team- Customer is part of team

• Metaphor- Design around a coherent idea

• The planning game- Be realistic re: meeting customer needs

• Simple design- Simple models, architecture, code

14

Practices of XP

• Small releases- Meet customer needs in small increments

• Customer tests- Customer participates in testing

• Pair programming- All code written with “co-pilot”

• Test-driven development- Write tests first, then code

15

Practices of XP

• Design improvement- Refactor only as needed

• Collective code ownership- Anyone can modify any code

• Continuous integration- Regularly check if system on track

• Sustainable pace- No all-nighters, no superheroes

• Coding standards- Pick a format, use it, move on

16

Agile Processes

Customer provides short requirements

System and acceptance tests

evaluate & control risk

Prioritizerequirements

and plan

Implement

OperationWrite/run/modify

unit tests

17

Agile Processes

Customer provides short requirements

System and acceptance tests

evaluate & control risk

Prioritizerequirements

and plan

Implement

OperationWrite/run/modify

unit tests

collect user stories

18

Agile Processes

Customer provides short requirements

System and acceptance tests

evaluate & control risk

Prioritizerequirements

and plan

Implement

OperationWrite/run/modify

unit tests

divide stories into

tasks

estimate effort

19

Agile Processes

Customer provides short requirements

System and acceptance tests

evaluate & control risk

Prioritizerequirements

and plan

Implement

OperationWrite/run/modify

unit tests

customer selects stories

allocate work among team

20

Agile Processes

Customer provides short requirements

System and acceptance tests

evaluate & control risk

Prioritizerequirements

and plan

Implement

OperationWrite/run/modify

unit testswrite unit

tests

21

Agile Processes

Customer provides short requirements

System and acceptance tests

evaluate & control risk

Prioritizerequirements

and plan

Implement

OperationWrite/run/modify

unit tests

write and refactor code

22

Agile Processes

Customer provides short requirements

System and acceptance tests

evaluate & control risk

Prioritizerequirements

and plan

Implement

OperationWrite/run/modify

unit tests

customer tests system

23

Agile Processes

Customer provides short requirements

System and acceptance tests

evaluate & control risk

Prioritizerequirements

and plan

Implement

OperationWrite/run/modify

unit tests

customer uses system

24

Agile Processes

Customer provides short requirements

System and acceptance tests

evaluate & control risk

Prioritizerequirements

and plan

Implement

OperationWrite/run/modify

unit tests

collect user stories

divide stories into

tasks

estimate effort

customer selects stories

allocate work among team

write unit tests

write and refactor code

customer tests system

customer uses system

25

Concerns About XP

• Constant refactoring can be expensive

• Pair programming can take extra effort

• XP is not very standardized

• Programmers don’t always specialize

26

Lessons from DSDM and XP

• Learn from:• Users (DSDM)• Customers (XP)

• Design based on:• Business value (DSDM)• Customer direction (XP)

• Requirements should be:• High-level (DSDM)• Succinct (XP)

27

Next Steps..

• HW #4 (Design) due Friday!!

• Vision statement peer review next Tuesday!! • Bring hard copy of rough draft

• Don’t forget your midterm!! • Due 11/25