evolution of software development lifecycles - … · evolution of software development lifecycles:...

1ASPIN JAN 2008©2008.

Evolution of Software

Development Lifecycles:

Waterfallacies and Agile Methods

Jorge Boria

2ASPIN JAN 2008©2008.

A Claim

I am concerned, not with an unattainable

objectivity, but with an attainable honesty.

John Dominic Crossan

The Historical Jesus, 1992

3ASPIN JAN 2008©2008.

A Second Claim

I am going to describe my personal views

about managing large software

developments.

Dr. Winston W. Royce

Managing the Development of Large

Software Systems

August 1970

4ASPIN JAN 2008©2008.

Our Purpose Tonight

Answer the questions:

Where does Agile come from?

What Lifecycle will work for me?

Do we give up on lifecycles before

we should?

Are we stuck on searching for a silver

bullet?

5ASPIN JAN 2008©2008.

Agenda

�Ancestors

�Royce’s waterfall

�Spiral

�JAD

�RUP

�RAD and RAP

�Examples

�eXtreme Programming

�TDD

�Scrum (and CMMI)

6ASPIN JAN 2008©2008.

Remember the 60’s?

“methodology” � =

methods + processes

+ semantic modeling

languages

Centrally, Hierarchical

decomposition

�HIPO, Structured

Design, Jackson,

Nassi-Shneiderman

7ASPIN JAN 2008©2008.

The Meaning of Life (Cycles)

Arriving at an operational state, on-time,

and within costs, using what others have

done before

How can I come

up with my own

lifecycle to

accommodate

my issues?

Which is the label

that I need to buy

into and impose

on the company?

8ASPIN JAN 2008©2008.

The Underlying Premise

The quality of a system is preeminently

influenced by the quality of the processes

used to develop, acquire, and maintain it.

PROCESS

PEOPLE

TECHNOLOGY

you should already have the best

available

you should already have the best

available

9ASPIN JAN 2008©2008.

The Infamous Waterfall

Royce, ibid

10ASPIN JAN 2008©2008.

And Royce’s Comment On It…

I believe in this concept, but the

implementation described above is

�risky and invites failure. […]

�in effect the development process has

returned to the origin

�one can expect up to a 100-percent

overrun in schedule and/or costs.

Royce, ibid

11ASPIN JAN 2008©2008.

Royce’s Real Waterfall

Royce, ibidem

12ASPIN JAN 2008©2008.

Initial Solutions – Spiral Model (Boehm)

Scaled down

prototypes built to

preliminary design

Risk guides iterations

Customer can abort

Partial waterfall in

every step

Complete waterfall at

the end, if needed

13ASPIN JAN 2008©2008.

Initial Solutions - JAD (Silver and Wood)

One of the first successful application of

time-boxing:

�JAD’s were restricted to a week,

development to a few months

Based on some “modern” premises:

�those who do the job have the

understanding

�software products affect the business as a

wholehttp://www.utexas.edu/ecs/trecs/hris/pub/jad.php

14ASPIN JAN 2008©2008.

The Problem Changes

Accommodating faster and faster

business cycles

15ASPIN JAN 2008©2008.

A Transition Moment

The Rational Unified Process (Jacobson,

Booch, Rumbaugh et al)1. Develop software iteratively (sashimi*)

2. Manage requirements

3. Use component-based architectures

4. Visually model software

5. Verify software quality

6. Control changes to software

*Takeuchi and Nonaka

16ASPIN JAN 2008©2008.

The RUP Lifecycle

Implementation of the spiral model.

First break of waterfall sequence

Organizes tasks into phases and iterations.

Four phases:� Inception

�Elaboration

�Construction

�Transition

17ASPIN JAN 2008©2008.

Initial Solutions - RAD (Martin)

�Prototyping using tools and environments

(RAD Tools)

�Increasingly Functional Iterative

Development

�Time Boxing

�Small Teams

�Active and Involved Management Approach

18ASPIN JAN 2008©2008.

The Problem Accelerates

Accommodating faster and faster

business cycles: Internet Time!!!!

19ASPIN JAN 2008©2008.

Agile Life Cycle Models - 1

�Shared characteristics

�software development process is inherently

chaotic

�engineers can thrive in the chaos

�embrace change, not manage change

�short iterations between product deliveries

�less than two months

�goal of four weeks

�YAGNI: don’t code it until the customer

requests it

http://www.agilemanifesto.org/

20ASPIN JAN 2008©2008.


�Shared characteristics (continued)

�small teams

�strong supporting environment

�product manager role setting firm priorities for

each iteration

�developers define tests prior to coding

�small effort on planning, large effort on control

�daily builds of the software

21ASPIN JAN 2008©2008.


�Agile Alliance (source) �Kent Beck (XP, TDD)

�Mike Beedle, Scrum Alliance (Scrum, Xbreed)

�Alistair Cockburn (Crystal)

�Ken Schwaber (Scrum)

�Peter Coad (FDD) …

�How the models differ

�degree of up-front design of the product, before

coding

�size of project for which they are useful

�team size that works best

22ASPIN JAN 2008©2008.

Agenda

�Ancestors

�Royce’s waterfall

�Spiral

�JAD

�RUP

�RAD and RAP

�Examples

�eXtreme Programming

�TDD

�Scrum (and CMMI)

23ASPIN JAN 2008©2008.

The X in XP

If code reviews are good…

If testing is good…

If design is good…

If architecture is good…

If integration testing is good…

If short iterations are good…

24ASPIN JAN 2008©2008.

eXtreme Programming - 1

�Exploration phase

�developers establish tools and technologies

�customers develop stories (scenarios,

requirements)

�Planning

�developers estimate effort, balance load

�commitments established with customer

�during development:

�record progress

�rearrange work as needed

Source: Beck, eXtreme Programming Explained

25ASPIN JAN 2008©2008.


Iterations to First Release

�1-4 week cycles of building and verifying

�first iteration establishes architecture

Productionizing

�shorter iterations, certifying the software

�may tune performance

Source: Beck, eXtreme Programming Explained

26ASPIN JAN 2008©2008.


Maintenance

�normal state of an XP project

�simultaneous addition of functionality and

supporting system

�each release has exploration, planning,

iterations to release

Death

�when no further features are needed

� if system doesn’t deliver as neededSource: Beck, eXtreme Programming Explained

27ASPIN JAN 2008©2008.


ProductionizingProductionizingIterations(each 1-4 weeks)

Iterations(each 1-4 weeks)PlanningPlanningExplorationExploration

Verify

Stories

(Requirements

Scenarios)

Estimates;

Commitments

Test Cases;

Building,

Verifying,

Software;

Certifying;

Tune Performance

Build

Source: adapted from Beck, eXtreme Programming Explained

28ASPIN JAN 2008©2008.

XP Practices - 1

�The Planning Game –

�quickly determine the scope of the next release by

combining business priorities and technical

estimates. As reality overtakes the plan, update the

plan.

�Small Releases –

�Put a simple system into production quickly, then

release new versions on a very short cycle.

�Metaphor –

�Guide all development with a simple shared story of

how the whole system works.

29ASPIN JAN 2008©2008.

XP Practices - 2�Simple Design –

�The system should be designed as simple as

possible at any given moment. Extra complexity is

removed as soon as it is discovered.

�Testing –

�programmers continually write unit tests, which must

run flawlessly for development to continue.

Customers write tests demonstrating that features

are finished.

30ASPIN JAN 2008©2008.

XP Practices - 3�Refactoring –

�Programmers restructure the system without

changing its behavior to remove duplication, improve

communication, simplify, or add flexibility. (“Smells”)

�Pair Programming - All production code is

written with two programmers at one machine.

�Collective Ownership - Anyone can change any

code anywhere in the system at any time.

31ASPIN JAN 2008©2008.

XP Practices - 4

�Continuous integration –

�Integrate and build the system many times a

day, every time a test is completed.

�40-hour Week –

�Work no more that 40 hours a week as a rule.

Never work overtime a second week in a row.

�On-site Customer –

�Include a real, live user on the team, available

full-time to answer questions. (CRACK)

32ASPIN JAN 2008©2008.

XP Practices - 5

�Coding Standards - Programmers write all

code in accordance with rules emphasizing

communication through the code.

33ASPIN JAN 2008©2008.

XP Practices

What you are not allowed to do:PICK AND CHOOSEamong the practices.

XP IS ALL OF THEM

34ASPIN JAN 2008©2008.

Refactoring

Disciplined technique for restructuring

existing body of code,

�altering its internal structure

�no change to external behavior

�use small “behavior preserving

transformations”

�keep system fully working all the time

http://www.refactoring.com/

35ASPIN JAN 2008©2008.

Test Driven Development

Also known as “Son of XP” ☺ (Beck, 2000)

Two simple Rules:�write new business code only when an automated test has failed

� eliminate any duplication that you find.

Consequences (Beck):� design organically, running code provides feedback

�write your own tests (no time to wait for someone else to write them for you)

� development environment must provide rapid response � fast compiler, regression test suite

� highly cohesive, loosely coupled components

36ASPIN JAN 2008©2008.

Four Interpretations of TDD

� 1) Test Driven Development:

� the idea of writing new code in a test first manner.

� 2) Test Oriented Development:

�write unit tests or integration tests for your code either

before or immediately after you write the code.

� 3) Test Driven Design(the eXtreme Programming

way):

�drive full design from little to no design whatsoever. You

design as you go. Tests guide your design process

� 4) Test Driven Development and Design:

�evolve your design from tests.

http://weblogs.asp.net/rosherove/archive/2007/10/08/the-various-meanings-of-tdd.aspx

37ASPIN JAN 2008©2008.

Test First Design (TFD)

add a test, � just enough code to fail.

run tests� often the complete test suite

� sometimes only a subset

� ensure that the new test does in fact fail.

update your functional code to make it pass

run your tests again.� if they fail update your functional code and retest.

Once the tests pass start over or refactor your design and then start over.

38ASPIN JAN 2008©2008.

TDD = TFD + Refactoring

Requires great discipline: it is easy to “slip” and

write functional code without first writing a new

test.

�write your test code before your functional code

� do so in very small steps

�one test and a small bit of corresponding functional code

�no new function without a test that fails because that

function isn’t present

�no code until a test exists for it

�ensure that the test suite now passes

� refactor it to ensure high quality.

Use pair programming to help stay on track.

39ASPIN JAN 2008©2008.

Implications for Developers

Developers need to learn how to write effective

unit tests.

Good unit tests:

�Run fast (have short setups, run times, and break

downs).

�Run in isolation (can be reordered).

�Use data that makes them easy to read and to

understand.

�Use real data (e.g. copies of production data)

when they need to.

�Represent one step towards your overall goal.

40ASPIN JAN 2008©2008.

Shortcomings

Equating “goodness” with passing a test

Test suites are also code

�more code to maintain

�could be buggy itself

�might mean longer and longer runtimes for

testing

41ASPIN JAN 2008©2008.

Scrum (Schwaber and Beedle)

�Scrum is a framework within which the

game of product development is played.

�Your team plays and how good or not-good

it is becomes highly visible.

�Your team gets to continuously improve

itself.

used under perm

ission of the Scrum Alliance

42ASPIN JAN 2008©2008.

Companies Using Scrum

Bottom Up

�Microsoft, Sun, Sammy Studios, Siemens, CNA,

State Farm, State Street Bank, Philips, BBC, IBM,

SAIC, LMCO, APL, Ariba, Federal Reserve Bank,

HP, Medtronics, Motorola, TransUnion

Top Down

� IDX, Siemens Medical, Gestalt, Wildcard Systems,

Primavera, Yahoo, Conchango, BMC, Lexis-Nexis,

Bentley Systems, Bose, CapitalOne, Federal

Reserve Bank, ClearChannel, Xerox, Nokia,

Motorola

43ASPIN JAN 2008©2008.

Scrum Characteristics

�Self-organizing teams

�Product progresses in a series of month-

long “sprints”

�Requirements are captured as items in a

list of “product backlog”

�No specific engineering practices

prescribed

�Uses generative rules to create an agile

environment for delivering projects

used under perm


44

ASPIN J

AN 2008

©2008.

Scrum M

odel

used under permission of the Scrum Alliance

45ASPIN JAN 2008©2008.

Sprints

Scrum projects make progress in a series

of “sprints”

�Analogous to XP iterations

Target duration is one month

�+/- a week or two

�But, a constant duration leads to a better

rhythm

Product is designed, coded, and tested

during the sprint

used under perm


No changes during the sprint

46ASPIN JAN 2008©2008.

Product Backlog

A list of all desired

work on the project

� combination of

�story-based work

� task-based work

List is prioritized by the

Product Owner

�Typically a Product

Manager, Marketing,

Internal Customer,

etc.

used under perm


47ASPIN JAN 2008©2008.

Sprint Planning Meeting

Sprint Planning

Meeting

Product Backlog

Team Capabilities

Business Conditions

Technology

Current Product

Sprint Backlog

Product Owner

Scrum

Team

Managem

ent

Customers

Sprint Goal

used under perm


48ASPIN JAN 2008©2008.

Sprint Backlog during the Sprint

Changes

�Team adds new tasks whenever they need

to in order to meet the Sprint Goal

�Team can remove unnecessary tasks

�But: Sprint Backlog can only be updated by

the team

Estimates are updated whenever there’s

new information

used under perm


49ASPIN JAN 2008©2008.

Sprint Burndown Chart

Progress

752 762

664619

304264

180104

200

100

200

300

400

500

600

700

800

900

5/3/

2002

5/5/

2002

5/7/

2002

5/9/

2002

5/11

/200

25/

13/2

002

5/15

/200

25/

17/2

002

5/19

/200

25/

21/2

002

5/23

/200

25/

25/2

002

5/27

/200

25/

29/2

002

5/31

/200

2

Date

Remaining E

ffort in H

ours

used under perm


50ASPIN JAN 2008©2008.

� Parameters� Daily

� 15-minutes

� Stand-up

� Not for problem solving

� Three questions:1. What did you do yesterday

2. What will you do today?

3. What obstacles are in your way?

� Chickens and pigs are invited� Help avoid other unnecessary meetings

� Only pigs can talk

Daily Scrum meetingsused under perm


51ASPIN JAN 2008©2008.

Sprint Review Meeting

Team presents what it accomplished during the sprint

Typically takes the form of a demo of new features or underlying architecture

Informal� 2-hour prep time rule

Participants�Customers

�Management

�Product Owner

�Other engineers

used under perm


52ASPIN JAN 2008©2008.

The Origin of Religious Wars

One faith, one law, one king

French royalists, circa 1562

even some people who call God God

worship God in a way that's odd

We have to kill them, it's a shame

Austin Lounge Lizards,

"One True God", The Drugs I Need

53ASPIN JAN 2008©2008.

Agility vs. Discipline

If one has strong discipline without agility,

the result is bureaucracy and stagnation.

Agility without discipline is the

unencumbered enthusiasm of a startup

company before it has to turn a profit

54ASPIN JAN 2008©2008.

Requirements for Success - 1

Waterfall-based projects need:

�management support

�organizational infrastructure

�engineers that understand, value and follow

processes

�process assets

�customer representatives that are

collaborative, representative, authorized,

committed and knowledgeable

55ASPIN JAN 2008©2008.


Agile projects need:




processes

� leads that can break the rules and make

new ones as needed

�full-time customer representatives that are



56ASPIN JAN 2008©2008.

Why Go Agile

Right reasons

�we have CRACK

customers

� our projects are small

to medium

� criticality is low to

medium

�we have experienced

people that have

succeeded with it

Wrong reasons

�we don’t have the

time for process


time to document the

system

� our engineers are

young and

inexperienced

57ASPIN JAN 2008©2008.

When Not to Go Agile

Product is mission-critical

�requirements of traceability very strict

No CRACK users

�customer is reluctant to commit a valuable

player to the team

Architectural concerns are high

�non functional aspects are dominant

�YAGNI does not apply

Project demands large team

58ASPIN JAN 2008©2008.

So, Maybe…

There is no silver bullet

There is no one-size-fits-all

It is better to build your method up than to

pare it down

Potential silver bullets are elsewhere

�people

�values

�communication

�expectation management

59ASPIN JAN 2008©2008.

Final Conclusion

�Follow the six key principles for business-driven development:�Adapt the process

�Balance stakeholder priorities

�Collaborate across teams

�Demonstrate value iteratively

�Elevate the level of abstraction

�Focus continuously on quality

�In short -> [ABCDEF] ☺

�Steal with pride but do not lie to yourself:

A Monkey In A Silk Suit Is Still A Monkey !

60

Any Questions?

thank you for your time

[email protected]

www.liveware.com

61ASPIN JAN 2008©2008.

Acknowledgements

We have used terms like:�Scrum Alliance (SM)

�Agile Alliance

�CMMI�® Capability Maturity Model, CMMI, and CMM are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University

Some slides are used under copyright agreement with the Scrum Alliance.

Monty Python is credited for intellectual inspiration and art work in most of the Holy Wars material

62

Backup Slides

63ASPIN JAN 2008©2008.

Back to Basics

Let there be Deming…

�reduce waste,

�rework,

�staff attrition and

� litigation

while

� increasing

customer loyalty

64ASPIN JAN 2008©2008.

Deming’s 14 Points for Management

1."Create constancy of purpose towards improvement“

3."Cease dependence on inspection"

5."Improve constantly and forever"

7."Institute leadership"

9."Break down barriers between departments"

11."Eliminate management by objectives"

13."Institute education and self-improvement “

2."Adopt the new philosophy"

4."Move towards a single supplier for any one item"

6."Institute training on the job"

8."Drive out fear"

10."Eliminate slogans"

12."Remove barriers to pride of workmanship"

14."The transformation is everyone's job"

65ASPIN JAN 2008©2008.

Agility vs. Discipline

If one has strong discipline without agility,

the result is bureaucracy and stagnation.

Agility without discipline is the

unencumbered enthusiasm of a startup

company before it has to turn a profit

Boehm and Turner

Balancing Agility and Discipline

66ASPIN JAN 2008©2008.


Waterfall-based projects need:




processes

�process assets

�customer representatives that are


committed and knowledgeable (CRACK)

67ASPIN JAN 2008©2008.


Agile projects need:




processes

� leads that can break the rules and make

new ones as needed

�full-time customer representatives that are



68ASPIN JAN 2008©2008.

Why Go Agile

Right reasons

�we have CRACK

customers

� our projects are small

to medium

� criticality is low to

medium

�we have experienced

people that have

succeeded with it

Wrong reasons


time for process


time to document the

system

� our engineers are

young and

inexperienced

69ASPIN JAN 2008©2008.

When Not to Go Agile

Product is mission-critical

�requirements of traceability very strict

No CRACK users

�customer is reluctant to commit a valuable

player to the team

Architectural concerns are high

�non functional aspects are dominant

�YAGNI does not apply

Project demands large team

70ASPIN JAN 2008©2008.

The Agile Manifesto - 1

Principles behind the Agile Manifesto

We follow these principles:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

� short feedback loops

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

� include the customer

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

� feedback based on real product

71ASPIN JAN 2008©2008.


4. Business people and developers must work together daily throughout the project.

� feedback should happen daily

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

� trust your developers

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

� continuous knowledge improvement

7. Working software is the primary measure of progress.� continuous visibility

72ASPIN JAN 2008©2008.


8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

� no iterative death marches

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity--the art of maximizing the amount of work not done--is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

73ASPIN JAN 2008©2008.

Scrum

�One of the “agile processes”

�Self-organizing teams

�Product progresses in a series of month-

long “sprints”

�Requirements are captured as items in a

list of “product backlog”

�No specific engineering practices

prescribed

�Uses generative rules to create an agile

environment for delivering projects

used under perm


74ASPIN JAN 2008©2008.

Project Noise Level

Simple

Complicated

Anarchy

Complex

Close to

Certainty

Far from

CertaintyTechnology

Close to

Agreement

Far from

Agreement

Requirements

Source: Strategic Management and

Organizational Dynamics by Ralph Stacey

in Agile Software Development with Scrum

by Ken Schwaber and Mike Beedle.

used under perm


76ASPIN JAN 2008©2008.

The Scrum Master

�Represents management

to the project

�Typically filled by a

Project Manager or Team

Leader

�Responsible for enacting

Scrum values and

practices

�Main job is to remove

impediments

used under perm


77ASPIN JAN 2008©2008.

The Scrum Team

�Typically 5-10 people

�Cross-functional�QA, Programmers, UI Designers, etc.

�Members should be full-time�May be exceptions (e.g., System Admin, etc.)

�Teams are self-organizing�What to do if a team self-organizes someone off the team??

�Ideally, no titles but rarely a possibility

�Membership can change only between sprints

used under perm


78ASPIN JAN 2008©2008.

Sprints

Scrum projects make progress in a series

of “sprints”

�Analogous to XP iterations

Target duration is one month

�+/- a week or two

�But, a constant duration leads to a better

rhythm

Product is designed, coded, and tested

during the sprint

used under perm


79ASPIN JAN 2008©2008.

Sequential vs. Overlapping Development

Source: “The New New Product

Development Game”, Hirotaka Takeuchi

and Ikujiro Nonaka, Harvard Business

Review, January 1986.

used under perm


80ASPIN JAN 2008©2008.

No changes during the sprint

SprintInputs Tested Code

Change

Plan sprint durations around how long you can commit to keeping change out of the sprint

used under perm


81ASPIN JAN 2008©2008.

Product Backlog

A list of all desired work on the project

�Usually a combination of

�story-based work (“let user search and

replace”)

�task-based work (“improve exception handling”)

List is prioritized by the Product Owner

�Typically a Product Manager, Marketing,

Internal Customer, etc.

used under perm


83ASPIN JAN 2008©2008.

Sprint Planning Meeting

Sprint Planning

Meeting

Product Backlog

Team Capabilities

Business Conditions

Technology

Current Product

Sprint Backlog

Product Owner

Scrum

Team

Managem

ent

Customers

Sprint Goal

used under perm


84ASPIN JAN 2008©2008.

The Sprint Goal

Database Application

“Make the application

run on SQL Server in

addition to Oracle.”

Life Sciences

“Support features

necessary for

population genetics

studies.”

Financial Services

“Support more

technical indicators

than company ABC

with real-time,

streaming data.”

A short “theme” for the sprint:

used under perm


85ASPIN JAN 2008©2008.

From Sprint Goal to Sprint Backlog

Scrum team takes the Sprint Goal and

decides what tasks are necessary

Team self-organizes around how they’ll

meet the Sprint Goal

�Manager doesn’t assign tasks to individuals

Managers don’t make decisions for the

team

Sprint Backlog is created

used under perm


87ASPIN JAN 2008©2008.

Sprint Backlog during the Sprint

Changes

�Team adds new tasks whenever they need

to in order to meet the Sprint Goal

�Team can remove unnecessary tasks

�But: Sprint Backlog can only be updated by

the team

Estimates are updated whenever there’s

new information

used under perm


88ASPIN JAN 2008©2008.

Sprint Burndown Chart

Progress

752 762

664619

304264

180104

200

100

200

300

400

500

600

700

800

900

5/3/

2002

5/5/

2002

5/7/

2002

5/9/

2002

5/11

/200

25/

13/2

002

5/15

/200

25/

17/2

002

5/19

/200

25/

21/2

002

5/23

/200

25/

25/2

002

5/27

/200

25/

29/2

002

5/31

/200

2

Date

Remaining E

ffort in H

ours

used under perm


89ASPIN JAN 2008©2008.

� Parameters� Daily

� 15-minutes

� Stand-up

� Not for problem solving

� Three questions:1. What did you do yesterday

2. What will you do today?

3. What obstacles are in your way?

� Chickens and pigs are invited� Help avoid other unnecessary meetings

� Only pigs can talk

Daily Scrum meetingsused under perm


90ASPIN JAN 2008©2008.

Questions about Scrum meetings?

Why daily?

�“How does a project get to be a year late?”

�“One day at a time.”

�Fred Brooks, The Mythical Man-Month.

Can Scrum meetings be replaced by

emailed status reports?

�No

�Entire team sees the whole picture every day

�Create peer pressure to do what you say you’ll

do

used under perm


91ASPIN JAN 2008©2008.

Constraints

A complete list of constraints put on the

team during a Sprint:

</end of list>

used under perm


92ASPIN JAN 2008©2008.

Sprint Review Meeting

Team presents what it accomplished during the sprint

Typically takes the form of a demo of new features or underlying architecture

Informal� 2-hour prep time rule

Participants�Customers

�Management

�Product Owner

�Other engineers

used under perm


93ASPIN JAN 2008©2008.

Stabilization Sprints

During “regular” sprints target friendly first use

� Beta customers and similar can use immediately after sprint

During “stabilization sprints”

� Team prepares a product for release

� Useful during� active beta periods

� when transitioning a team to Scrum

� if quality isn’t quite where it should be on an initial release

Not a part of standard Scrum, just something I’ve found useful

Sprint 1 Sprint 2 Sprint 3 Sprint 4

Sprint 1 Sprint 2 Sprint 3Stabilization

Sprint

used under perm


94ASPIN JAN 2008©2008.

Where to go next?

Scrum

�www.mountaingoatsoftware.com/scrum

�www.controlchaos.com

�[email protected]

�Agile Software Development with Scrum�Ken Schwaber and Mike Beedle

�Agile Project Management with Scrum�Ken Schwaber and Mike Beedle

�General information�www.agilealliance.com

used under perm


95ASPIN JAN 2008©2008.

Xbreed - 1Goal of XBreed is to support multiple projects, reusing

components such as

� architectural services

� workflows

� units of work

� services

� transactions

� business objects

Xbreed uses most Scrum practices, plus

� using chief programmers as team leads

� uses hierarchies of teams

� uses Scrum practices at each level of hierarchy

96ASPIN JAN 2008©2008.

XBreed - 2

Leverage XP practices with some differences

� planning game replaced by Scrum

� some YAGNI, only in known domain "hot spots“

�Classes, Responsibility, and Collaboration (CRC)

stories used for representing requirements

�eliciting requirements

�discussing design

�Supplement with use case for complex functionality

97ASPIN JAN 2008©2008.

Components of XBreed

Uses design patterns in defining products

Uses "Shared Services" teams to handle

several increments concurrently

Includes architect roles on the teams

Shares knowledge through weekly brown bag

lunches, mixing presentations and workshops

on topics like: patterns, refactoring, new

technologies, architectural vision exercises,

best practices, etc.

Scrum holds the whole thing together.

98ASPIN JAN 2008©2008.

Feature Driven Development

(more shape

than content)

An object model

+ informal features list

+ notes on alternatives

Categorized

list of

features

Development

plan

A design

package

(sequences)

(more content

than shape)

Completed

client-valued

function

Develop

an

Overall

Model

Build a

Feature

List

Plan

by

Feature

Design

by

Feature

Build

by

Feature

99ASPIN JAN 2008©2008.

FDD vs XP Similarities�Enable teams to deliver results

�quicker

�without compromising quality

�Highly iterative results-oriented processes

�People focused, not document focused

�Dismantle traditional separation of domain and

business experts/analysts from designers and

implementers�analysts are dragged out of their abstractions and put in the

same room as developers and users

�enabling and encouraging analysis, design, code, test and

deployment to be done concurrently

100ASPIN JAN 2008©2008.

FDD vs XP Differences - 1

XP:

� Team sizes

� teams of two to ten

programmers

� Metaphor and

Model

� Business writing

stories on index

cards

� analogous to driving

a car - continual little

course adjustments

FDD:

�Team sizes

� team of 16-20

developers, designed

to scale to much

larger team sizes

�Metaphor and Model

�adds development of

an overall domain

object model

�analogous to using

the domain object

model as the map to

guide the journey

101ASPIN JAN 2008©2008.

FDD vs XP Differences - 2XP:

� Collective Ownership or Class

Ownership

� collective ownership of code

� Inspections and Pair Programming

� pair programming provides

continuous design and code

inspection.

� Testing

� XP: unit and functional tests

� FDD: unit testing part of Build By

Feature

� Reporting

� XP: tracking by project managers

� FDD: Tracking By Feature low-

overhead, highly accurate progress

measuring

FDD:

� Collective Ownership or Class

Ownership

� individual code ownership

� Inspections and Pair Programming

� formal inspections by feature teams

102ASPIN JAN 2008©2008.

FDD vs XP Differences - 3

XP:

� Testing

� unit and functional

tests

� Reporting

� tracking by project

managers

FDD:

�Testing

�unit testing part of

Build By Feature

�Reporting

�Tracking By Feature

low-overhead, highly

accurate progress

measuring

103ASPIN JAN 2008©2008.

Dynamic System Development

DSDM is a variant of RAD

� developed in the UK by a consortium

� very successful since 1995

� has not crossed into mainstream yet

� focuses on short cycles and changing requirements

Claims of DSDM

� users have ownership

� risk of building the wrong system is minimized

� users are trained

� smooth implementation through cooperation

Applies only when all users are identified and few

104ASPIN JAN 2008©2008.

DSDM Lifecycle

Tailorable generic process

Iterates as needed

through

� Functional model and

� Design and build

Implementation can end

with

� a finished product

� more feasibility studies

� more functionality

� changes to the design

prototypes

105ASPIN JAN 2008©2008.

DSDM Principles

Active user involvement

Empowered teams

Frequent product delivery

Fitness for business purposes

Iterative and incremental development

Reversible changes

Baselined high level requirements

Testing integrated throughout the lifecycle

Stakeholder collaboration and cooperation

evolution of software development lifecycles - … · evolution of software development lifecycles:...

Documents