Agile Methodologies and Extreme Programmingcv.znu.ac.ir/afsharchim/lectures/Agile.pdfPrinciples of...

Agile Methodologies

and Extreme Programming

Mohsen Afsharchi

Evolution of Methodology

Lots of thought on this subject since groups started

building software

“Use of GOTO Considered Harmful” Communications of

the ACM, Dijkstra

By the 1990’s, we had arrived at the Waterfall

methodology

Also known as BDUF (Big Design Up Front)

Waterfall and Similar Methodologies

Characteristics of Waterfall Methodologies

Requirements are gathered up front

Business analysts

End users

Interested departments

Maybe a JAD (Joint Application Design session?)

Requirements lead to design

Design leads to implementation

Implementation leads to acceptance testing

It is deployed

Where Does Waterfall Work Well?

Organizations where requirements don’t change

Stable requirements leads to stable design…

Stable design leads to “no surprise” implementation

Etc.

Who has requirements like this?

NASA

. . .

Does this reflect your requirements?

What happens when requirements change?

Changing Requirements

The later in the development cycle that a requirement

changes, the bigger the impact on the scope of the change

Documented by Barry Boehm

Changes to well established code may have a ripple effect,

causing side effects in other code

How can you make coding changes with confidence?

The Evolution of Agility

Problem: much of the methodology work in software

engineering has been based on traditional engineering

Design

Implement

Deploy

Software is fundamentally different

In its very nature

The way that people want to design, use, and modify software

Problem: we’ve been trying to tell developers how to

successfully write software…maybe we should find out

how they work best

Agility

Lots of smart guys got together and re-thought how software is built

In the nick of time

Most software projects fail

The business risk of software development is far too high

It seems hard to predict what will cause one project to succeed and another fail

Observe successful projects and figure out what they did right

Observe unsuccessful projects and figure out what they did wrong

This led to the Agile Manifesto

The Agile Alliance

17 Really Smart Guys met in Snowbird, Utah in February

2001:

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn,

Ward Cunningham, Martin Fowler, James Grenning, Jim

Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick,

Robert C. Martin, Stephen J. Mellor, Ken Schwaber, Jeff

Sutherland, Dave Thomas

The agreed on a manifesto and supporting principles

The Agile Manifesto

“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”.

The Agile Alliance

The Culmination of Current Thinking

The ideas in the Agile Manifesto didn’t just fall from the

sky

They had been percolating for several years in different

forms

The Agile Manifesto just documented what a lot of people

were already thinking

Principles of Agile Development

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

Agile focuses on the delivery of software

Delivering software early and often allows for quick wins and early feedback about the requirements, the team, and the process

The emphasis is to deliver the most important parts first

If the project ends, there are still valuable artifacts

Development proceeds from most important to less important

Note that this may (and will!) change during the course of the project


Deliver working software frequently, from a

couple of weeks to a couple of months, with a

preference to the shorter timescale.

Most projects run 1 to 3 month cycles [Cockburn]

Within the cycle, work is done in short iterations

Iterations usually last from 2 to 4 weeks

The iteration is complete at the end of the iteration, at the

expense of moving requirements

XP iterations are 2 to 3 weeks

Users review progress throughout the process


Working software is the primary measure of

progress.

Code is the most important deliverable

Agile methodologies place a premium on getting

something up and running early and evolving it over time

Agile does not discard the need for design

documentation

Diagram to understand, then move to code

Documentation is secondary to working code


Welcome changing requirements, even late in

development. Agile processes harness change for

the customer's competitive advantage.

This works because of

Early and frequent delivery of running software

Use of iterative and timeboxing techniques

Continual attention to architecture

Willingness to update the design

If you can gracefully accommodate changing requirements

and your competition cannot, you win


Business people and developers must work

together daily throughout the project.

There is a strong correlation between links to users and

project success

The best links are through onsite business expertise and

daily discussion

The longer it takes to get information to and from the

developers, the more damage will occur in the project

Information flow is similar to convection currents

XP insists that business stakeholders are part of the

development team


Build projects around motivated individuals. Give

them the environment and support they need, and

trust them to get the job done.

“It is better to have motivated, skilled people

communicating well and using no process at all than a

well-defined process used by unmotivated individuals.”

[Cockburn 2002]

“We hire good people, give them the tools and training to

get their work done, and get out of their way.” [Thomas]

Developers are the Key

You cannot overemphasize this point: developers, project

managers, and business analysts make or break the

project

"All other factors being equal, a 90th-percentile team of

analysts and programmers will be about four times as

productive as a 15th-percentile team.“ [Boehm 1981]

You should hire the smartest people you can find


The most efficient and effective method of

conveying information to and within a

development team is face-to-face conversation.

Communication is like air conditioning

Cockburn defines modalities of communications and their

effectiveness (Agile Software Development, 2002)

Cockburn’s Modalities and Effectiveness

Communication

Face to face communication about specific topics is most

efficient

Agile also takes advantage of “knowledge radiators”

Simple, low-tech information stores

Poster board with index cards or Post-it notes

Project status beside the coffee pot

Automated build report via web browser


The best architectures, requirements, and designs

emerge from self-organizing teams.

This means either that architectures, requirements, and

designs emerge

in small steps over time

as a logical consequence of human-centric rules the team uses

All 3 must be allowed to adjust over time

An architecture that grows in steps can follow the

changing knowledge of the team and the changing wishes

of the users


Continuous attention to technical excellence and

good design enhances agility.

The design must evolve

You must create good designs initially

You must review and improve designs regularly

Technical excellence applies to all aspects of the project

Build management

Coding standards

Collaboration documentation


Agile processes promote sustainable development. The

sponsors, developers, and users should be able to

maintain a constant pace indefinitely.

Social aspect

An alert, engaged staff is more effect than a tired, plodding staff

Long hours are a symptom that something has gone wrong

Only work 8 hours a day; never put in overtime 2 weeks in a

row

Technical aspect

Software development can be viewed as a long strategic game

Each move sets up the next move


Simplicity--the art of maximizing the amount of

work not done--is essential.

“This letter is longer than I wish, for I had not the time to

make it shorter” Blaise Pascal

It is sometimes more difficult to make things simpler

A cumbersome model is easier to produce than a simple

one

DRY principle (Don’t Repeat Yourself)

“Design for simplicity; add complexity only where you

must.” Art of Unix Programming, Raymond 2003


At regular intervals, the team reflects on how to

become more effective, then tunes and adjusts its

behavior accordingly.

Constant awareness is key

Never get lazy

XP encourages this every step of the way

Questions:

How light is too light?

How simple is too simple?

Can we make this simpler

Some Agile Methodologies

Extreme programming

Scrum

The Crystal Methodologies

Crystal Clear

Crystal Orange

Crystal Orange Web

What Spawned Extreme Programming?

In the early 1990s, Kent Beck was thinking about better ways to develop software.

He and Ward Cunningham had experienced an approach to software development that made every thing seem simple and more efficient.

Kent contemplated on

What made software simple to create

What made it difficult

In March of 1996 Kent started a project at DaimlerChrysler using new concepts in software development -- the result was the Extreme Programming (XP) methodology.

The 4 XP Dimensions

What Kent came to realize is that there are four

dimensions along which one can improve any software

project.

You need to improve communication.

You need to seek simplicity.

You need to get feedback on how well you are doing.

And you need to always proceed with courage.

Communication, Simplicity, Feedback, and Courage are

the four values sought out by XP programmers.

XP: Rules and Practices

Planning

User stories are written.

Release planning creates the schedule.

Make frequent small releases.

The Project Velocity is measured.

The project is divided into iterations.

Iteration planning starts each iteration.

Move people around.

A stand-up meeting starts each day.

Fix XP when it breaks.


Design

Simplicity.

Choose a system metaphor.

Use CRC cards for design sessions.

Create spike solutions to reduce risk.

No functionality is added early.

Refactor whenever and wherever possible.


Coding

The customer is always available.

Code must be written to agreed standards.

Code the unit test first.

All production code is pair programmed.

Only one pair integrates code at a time.

Integrate often.

Use collective code ownership.

Leave optimization till last.

No overtime.


Testing

All code must have unit tests.

All code must pass all unit tests before it can be released.

When a bug is found tests are created.

Acceptance tests are run often and the score is published.

A Tour Through XP: The Project

A Tour Through XP: Iteration

A Tour Through XP: Development

A Tour Through XP: Collective Code

Ownership

Feedback Loops

Recall the 4 dimensions of XP

You need to improve communication.

You need to seek simplicity.

You need to get feedback on how well you are doing.

And you need to always proceed with courage.

The goal: a less extreme (pragmatic?) version of XP

First pass: let’s get rid of the stuff that scares the boss and

just do the rest

Why You can’t Pick and Choose Your

Practices

XP isn’t just a group of fun activities that fit together

because Kent Beck says they do

XP is carefully calibrated for feedback

Remember the diagrams for XP?

Feedback Loops in XP

XP relies on

feedback to

work

Feedback loops

relate to time

scales

The tighter the

time scale, the

more

immediate the

feedback

Creating a Kinder, Gentler XP

If you want to only do some of the XP practices, you have

to replace the current XP activity with something that

gives you the approximate same level of feedback

That’s the only way you get the benefits from XP

You cannot randomly pick and choose what practices you

want to use!

XP becomes worse than many other methodologies because

you’ve destroyed one of the dimensions

You are sure to fail with XP

You’ll unfairly talk badly about XP to others

Substituting Practices: Planning

The Planning Practices


Release planning creates the schedule.

Make frequent small releases.

The Project Velocity is measured.

The project is divided into iterations.

Iteration planning starts each iteration.

Move people around.

A stand-up meeting starts each day.

Fix XP when it breaks.

User Stories


User stories

Used to create the time estimates for release planning and

acceptance testing

Written by the customers as things the system needs to do for

them

Similar to usage scenarios but not limited to describing a user

interface

In the format of about 3 sentences of text written by the

customer in the customer’s terminology without techno-speak

Differ from traditional requirements in the level of detail

User Story Substitutions

Traditional requirements gathering tools

Must be very flexible

Must be granular

CaliberRM is an outstanding choice for this

Especially for companies that require traceability for

requirements

Easy to modify requirements

Easy to attach custom fields to requirements records

Requirements should be as narrative as possible, not just

a dry list of facts

The narrative conveys not just functionality but also workflow

User Story Substitutions

Requirements must be flexible

User stories have lower detail than traditional

requirements

The developers and customer create detailed requirements

face to face when it comes time to implement the feature

Requirements and dependencies must be fluid

Neither user stories or requirements should ever delve

into technical details

Release Planning

Release planning creates the schedule

A release plan meeting is used to create a release plan,

which lays out the overall project

The release plan is used to create iteration plans for each

individual iteration

Decisions

Technical decisions made by technical people

Business decisions made by business people

The development team estimates each user story in

terms of ideal programming weeks

Release Planning

Do not change the estimates for user stories if

management is displeased with the amount of time it

takes

A project may be quantified by 4 variables

Scope - how much is to be done

Resources - how many people are available

Time - when the project or release will be done

Quality - how good the software will be and how well tested

Management may choose 3 of the 4 values

Development gets the remaining variable

Lowering quality may have later project impact

Release Planning Substitutions

The goal is to achieve consensus between developers,

management, and business people

Don’t stop until everyone is happy (or at least equally

unhappy)

XP release planning makes the business stakeholders a

integral part -- don’t allow the substitution to leave them

out

You must have business stakeholders to make it work

You wouldn’t change your accounting practices without

someone from accounting there, would you?

Small Releases

Make frequent small releases to customers (or customer

proxies)

These are releases, not “90% done”

This is a critical feedback loop

You need customer feedback to feed the remainder of the

development cycle

The longer you wait to introduce an important feature, the less

time you will have to fix it

Small releases tend to focus developer productivity

Forces the development team to solve tough problems

rather than delay them

Small Release Substitutions

This one is hard to substitute

This is the feedback loop between the customer (i.e., consumers of the application) and the developers

You can simulate this by creating small releases within your department

You’ve got to be diligent

If you start slipping into the “90% done” mode, you’re sunk

Try hard to get User Acceptance Testing into this small release cycle if you can

“Quick releases:

Help find bugs faster

Let’s the users get to play with it faster”

Project Velocity

The Project Velocity is measured

This is the measure of how fast work is getting done on

your project

Count how many user stories (or programming tasks) were

completed during the iteration

Total up the estimates that these stories received

This helps future estimations during the next Iteration

Planning Meeting

During the Iteration Planning Meeting, developers sign up

for the same number of programming tasks equal to the

project velocity measured in the previous meeting

Project Velocity

This mechanism allows developers to recover and clean-

up after a difficult iteration

Don’t divide the velocity by the number of developers in

the iteration

Doesn’t help determining the overall velocity

Can’t compare it to other projects

Discourages team building

Project velocity will rise and fall during the project, which

is normal

Re-estimate if you see dramatic changes

Project Velocity Substitutions

It’s OK to use other metrics for this as long as

They are reasonable, accurate metrics1

They are team based, not individual based

They provide real value

They are simple enough to understand

In general, don’t try to measure this with Microsoft

Project

Perhaps the most misused piece of software ever written

People use it to create meaningless charts and statistics

Testing is important in XP, including Meta-testing of the

methodology as it proceeds

1 There are very, very few of these -- see Brian Sletten’s Applied Object-oriented Metrics or

David Bock’s Software Metrics and the Great Pyramid of Giza

Iterations

The project is divided into iterations

Divide the development schedule into about a dozen

iterations, each lasting 1 to 3 weeks

Don’t schedule tasks in advance

Schedule tasks in the Iteration Planning Meeting

It is against the rules to look ahead and try to implement

anything not scheduled in this iteration

YAGNI - You Ain’t Gonna Need It

There is plenty of time later to respond to changing

requirements

Iteration Substitutions

Iterative development is hard to substitute

Tight iterations provides valuable feedback

Keep development team focused

Keep iterations short and cohesive

Keep tasks very small and cohesive

Avoid the temptation of gold plating

Avoid “Big Bang” deployments

Even if you must deploy that way in your organization, do

internal “Little Bang” deployments

Deploy often to User Acceptance Testing

“Faster feedback on bugs and problems”

Iteration Planning

Iteration planning starts each iteration

A meeting is called at the first of every iteration

Development work is selected

User stories are chosen by the customer

From the release plan

Most important first

Failed acceptance tests

Development work is translated onto index cards

Each task should be 1 to 3 Ideal programming days

Developers sign up for tasks then estimate how long it will

take

Iteration Planning

The Project Velocity is used to determine if the iteration

is overbooked

Don’t be tempted to change your task and story

estimates

The planning process relies on the cold reality of consistent

estimates

Fudging them to be lower means you are lying to yourself

It is normal to re-estimate stories and release plan every

3 to 5 iterations

Always implement the most valuable stories first

Iteration Planning Substitutions

You can change this phase with a similar planning session

It should be tied to iterations

Long-term estimates must be fluid

It is important for developers to create their own

estimates

Gets developer buy-in

Their estimation skill gets better over time

“We’re getting developers more interested in the project

management side and honing their estimation skills”

Move People Around

Move people around

Change developer assignments weekly, daily, or hourly

Prevents serious knowledge loss and bottle necks

Spreads overall knowledge around

May be as simple as encouraging everyone to try working

on a different section of the system at least part of each

iteration

Pair programming eliminates transition time

Move one of a pair at a time

Play “Musical Chairs” after lunch every day

Move People Around Substitutions

Harder if you don’t pair program

The feedback goal here is to spread understanding

around the project

You can do this with regular code reviews

Much less effective than pair programming

Better than nothing

This helps avoid the Truck Number anti-pattern

Explain Truck Number

Call this “cross training”

Stand-up Meeting

A stand-up meeting starts each day

Every day starts with the entire development team

standing in a circle to communicate

Problems

Solutions

Impediments

To improve team focus

It is more efficient to have one short meeting with

everyone than a lot of little meetings

Cross-team communication is the primary purpose

Stand-up Meeting Substitutions

This is part of the daily feedback loop

Substitute with something that provides daily updates,

problems encountered and solved, etc.

You can set up

A Wiki to share information

Information Radiators

However, this isn’t as rich a communications channel

Cockburn defines modalities of communications and their

effectiveness (Agile Software Development, 2002)

Cockburn’s Modalities and Effectiveness

Fix XP

Fix XP when it breaks

Fix the process when it breaks

You should be willing to do this with any methodology

Don’t buy into strictly prescriptive solutions

Build Your Own Tools

At ThoughtWorks, most of the Project Managers create

their own tools for tracking projects

Mostly created around Excel

It is important to evolve your approach over time

It changes from project to project

You get better and better at it

By the way - it's really, really important that PMs (especially client PMs) build their own tracking sheet. Taking someone else’s and mushing it around to make it work for the next project doesn't work. It's a psychology thing about owning the thing you built - and it's really important that PMs own their tracking tools.

Roger Marlow, PM, ThoughtWorks

Substituting Practices: Designing

The Designing Practices

Simplicity.

Choose a system metaphor.

Use CRC cards for design sessions.

Create spike solutions to reduce risk.

No functionality is added early.

Refactor whenever and wherever possible.

Simplicity

Simplicity

A simple design takes less time than a complex one

When you find something complex, replace it with

something simple

Keep things as simple as possible as long as possible by

never adding functionality before it is scheduled

Keeping a design simple is hard work

“The present letter is a very long one, simply because I had no leisure to make it shorter. “

Blaise Pascal

Simplicity Substitutions

There is no substitute!

Follow

The Pragmatic Programmer rules

The Art of Unix Programming

2. Rule of Clarity - Clarity is better than cleverness.

5. Rule of Simplicity - Design for simplicity; add complexity only where

you must

6. Rule of Parsimony- Write a big program only when it is clear by

demonstration that nothing else will do.

13. Rule of Economy - Programmer time is expensive; conserve it in

preference to machine time.

14. Rule of Generation -Avoid hand-hacking; write programs to write

programs when you can.

System Metaphor

Choose a system metaphor

Keeps the team on the same page by naming classes and

methods consistently

Good names =>

Understanding the overall design of the system

Code reuse

Stick as close to the problem domain as possible

System Metaphor Substitutions

Take the time to do this no matter what your

methodology

Makes everything in the project make sense because it

provides context

“We’re trying to create a way that we can describe this to

the business side to get their buy-in”

CRC Cards

Use CRC (Class, Responsibility, and Collaboration) cards

for design sessions

Allows people to break away from procedural thought

and more fully appreciate object technology

Individual CRC Cards represent objects

CRC Cards

A CRC session proceeds with someone simulating the

system by talking about which objects send messages to

other objects

By stepping through the process weaknesses and

problems are easily uncovered

Design alternatives can be explored quickly by simulating

the design being proposed

CRC Card Substitutions

This is one of the easier characteristics to change

Make sure that you find a design technique that is

Very flexible

Interactive

Involves the entire development team

Serves the needs of the stakeholders

Allows for “What if” games

Many organizations prefer more documentation CRC

cards

OK as long as you don’t get the cart before the horse

Don’t let a static medium discourage flexibility

Documentation

“We have to have documentation so that…

We can re-create it?

We can kill more trees?

We know what it does?”

The tests are better documentation than any outdated Word document

You have to keep them updated if the requirements change

You can verify the requirements (tests) anytime

You know what it does by the tests

If he has to have documentation…

Make it a task within the iteration

Spread it around

Try to apply the DRY principle to it as much as possible

Spikes

Create spike solutions to reduce risk

Proof of concept projects to reduce technical risk

Ignores all outside concerns

Expect to throw it away (this is not a prototype!)

This is common in most methodologies

Avoid the temptation to just build up from the spike

YAGNI

No functionality is added early

One of the hardest things for developers to not do!

We are all tempted to add functionality now that we are

just sure is going to be needed later

Extra functionality always slows us down and squanders

resources

No Functionality Added Early Substitutions

Don’t!

You start creeping towards Big Design Up Front

Focus on the task at hand

Refactor

Refactor whenever and wherever possible

You must be willing to change code anytime it should be

changed

Don’t’ live with broken windows

Too much software becomes brittle because of 100’s of

tiny compromises

You must be willing to refactor

Substituting Practices: Coding

The Coding Practices

The customer is always available.

Code must be written to agreed standards.

Code the unit test first.

All code is pair programmed.

Only one pair integrates code at a time.

Integrate often.

Use collective code ownership.

Leave optimization till last.

No overtime.

Customers

The customer is always available

Business stakeholder must be available

If you can’t get a business person, get a worthy substitute

One of the few hard requirements of XP

“We have to know what to build…

Requirements documents are out of date as soon as they are

written

Getting this right is important to the business

We want to be able to respond quickly to changing

requirements

Developers != business people”

Standards

Code must be written to agreed standards

Almost every methodology does this

Don’t try to substitute this!

Test-first Coding

Code the unit test first

Creating a unit test helps a developer to really consider

what needs to be done

Requirements are nailed down firmly by tests

There can be no misunderstanding a specification written

in the form of executable code

Test-first Coding Substitutions

Test-first coding is the most effective way to write code

You get nearly as good feedback if you make sure you write tests concurrently

They must be written right away

Planning to write them next week doesn’t count!

You can delay testing your code slightly, but you must write tests!

Tests are the only way you can write code with confidence

“This is the set of requirements”

“Here is a coverage test that shows how much of our code is verified.”

Pair Programming

All code is pair programmed

The most Extreme practice in XP!

Two people working at the same computer will add as

much functionality (or more) than 2 people working

separately except that it will be much higher in quality

Pair programming increases software quality without

impacting time to deliver

Works best with 2 developers of more or less equal skill

Get Comfortable

Pair programming feels awkward at first

It helps if you are set up for it

Pair Programming at ThoughtWorks

Pair Programming Substitutions

Tough because this represents the most immediate code

feedback loop, on the order of minutes

You can achieve the (greatly diminished) similar effect

with very frequent code reviews

Very frequent means daily or at least once weekly

Think about how much code is written before it is peer

reviewed

Still pair on particularly complex parts (to help figure out

how to make it simpler)

Try it, with useful metrics, to help convince your boss

Pair Programming -- Politically

“You’re going to do what!?!”

You must show quantifiable results

Try keeping useful metrics before and after

Don’t make it about silly things like lines of code

Use bug counts

Use passed tests

If you already support code reviews in your

organization, this is really just real-time code reviews

Start doing it without telling anyone on really

complex parts

Integration

Only one pair integrates code at a time

Designed to cut down on regression test failures that

cascade

This is do if you have effective source code control in

place

This assume a canonical source for your code

Strongly consider continuous integration to automate

testing

Integrate Often

Integrate often

Developers should be integrating and releasing code into

the code repository every few hours, whenever possible

Always work in the context of the latest code

There is a direct correlation to this feedback loop and its

benefit which has nothing to do with XP

Collective Code Ownership

Use collective code ownership

Any developer can change any line of code to

Add functionality

Fix bugs

Refactor

There is no one person (not even an architect) who has

the entire vision

The code base is continually changing

Unit tests and frequent integration preserve order

Collective Code Ownership Substitutions

Hard!

You should try to adopt this attitude no matter what

your methodology

This is a meta-feedback loop -- it enables the others to

work

This is one of the enabling characteristics for real

teamwork

Optimization

Leave optimization until last

Do not optimize until the end

Never try to guess what the system's bottle neck will be

Measure it!

Make it work, make it right, then make it fast

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

Donald Knuth

Overtime

No overtime

Working overtime sucks the spirit and motivation out of

a team

Projects that require overtime to be finished on time will

be late no matter what you do

Hard to substitute this because its worth is self evident

Make a rule that you never work overtime 2 weeks in a

row

Prevents the (very real) danger of complete burnout

“Our developers start writing code that causes a lot of

test failures after 12 hour days!”

Substituting Practices: Testing

The Testing Practices

All code must have unit tests.

All code must pass all unit tests before it can be released.

When a bug is found tests are created.

Acceptance tests are run often and the score is published.

Testing: Unit Tests

All code must have unit tests

One of the cornerstones of XP (and modern

development practices)

Compilers only tell you if the spelling is right

Tests tell you if it does what you think it does

Don’t substitute for this, incorporate it

Unit Tests

All code must pass all unit tests before it can be released

to version control

Unit tests are both feedback and meta-feedback

A strong suite of unit tests enables refactoring, collective

code ownership, etc.

Don’t substitute or slack on this one either

Be careful about getting behind on tests (you’ll never

catch up)

Won’t happen if you do Test-first development

Don’t substitute, incorporate

Bugs and Tests

When a bug is found tests are created

If you are testing anyway, you should create a test every

time you find a new bug

Prevents that bug from ever reoccurring

Don’t substitute, incorporate

Acceptance Tests

Acceptance tests are run often and the scores are

published

Created from user stories

Another important part of testing

Provides confidence that you are creating the right thing

The highest scope feedback loop, from Create User

Stories all the way to final coding

You must have some criteria to determine when you are

done

Requirements => Acceptance tests

Organization Roles in XP Projects

Project Manager Planning

Project Velocity

Cat herding

Business Analyst/Stakeholder Knows why the application is being written

Developer

Tester

Architect Doesn’t remove the need for Enterprise Architecture

Application Architects act as on-going policeman for the overall structure of the code

May be overridden at any time by developers

Substitution Scale User Stories, Release Planning, Fix XP, CRC Cards,

Spike Solutions

Easy

Small Releases, Project Velocity, Iteration Planning,

Move People Around, Stand-up Meeting, Coding

Standards, Pair Programming, No overtime

Intermediate

Iterations, Simplicity, System Metaphor, Early

Functionality, Test-first Coding, Integrate Often,

Collective Code Ownership, Optimize last, Acceptance

tests are run often

Hard

Refactor, Customer is Always Available, All code must

have unit tests, All code must pass unit tests, Create

tests when a bug is found

No

Substitute

What to Tell

You are never going to convince him with just arguments

Too much of XP is counter-intuitive

He thinks you are trying to pull a fast one

Demonstrate that this works

Create a pilot project

Pick a small-scoped, orthogonal project

Pick a team that can work together

Rock and roll!

Use useful metrics

Number of tests passed (should be higher)

Number of bugs (should be lower)

Extrapolate

When All Else Fails…

Trade this guy for that guy

Agile Methodologies and Extreme Programmingcv.znu.ac.ir/afsharchim/lectures/Agile.pdfPrinciples of...

Documents

Transcript of Agile Methodologies and Extreme Programmingcv.znu.ac.ir/afsharchim/lectures/Agile.pdfPrinciples of...