Agile and Extreme Programming: A Pragmatic Approach Neal Ford Application Architect ThoughtWorks ...

Agile and Extreme Programming:

A Pragmatic Approach

Neal Ford

Application Architect

ThoughtWorks

www.nealford.com

www.thoughtworks.com

[email protected]

Blog: memeagora.blogspot.com

2

Questions, Slides, and Samples

• Please feel free to ask questions anytime• The slides will be available at www.nealford.com• I’ll show that address again at the end

3

What This Session Covers

• The history and context of Agile development generally and Extreme Programming specifically

• What makes XP a discipline and not just a random set of activities

• How to gradually introduce Agile practices within an organization and still get the benefits

• What to say to your boss• What to say to your boss’s boss• Lots of questions and answers

4

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)

5

Waterfall and Similar Methodologies

6

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

7

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?

8

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?

9

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

10

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

11

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

12

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

13

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

14

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

15


• 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

16


• 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

17


• 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

18


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

• There is a strong correlation between links to users and project success [Frakes 1995]

• 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

19


• 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]

20

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

21


• 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)

22

Cockburn’s Modalities and Effectiveness

23

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 (I’ll talk about

continuous integration later)

24


• 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

25


• 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• Design cleanup as compared to debt [Cunningham 2001]

• Technical excellence applies to all aspects of the project• Build management• Coding standards• Collaboration documentation

26


• 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

27


• 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• “Code smell”

28


• 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

29

Some Agile Methodologies

• Extreme programming• Scrum• The Crystal Methodologies

• Crystal Clear• Crystal Orange• Crystal Orange Web

30

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.

31

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.

32

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.

33


• 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.

34


• 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.

35


• 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.

36

A Tour Through XP: The Project

37

A Tour Through XP: Iteration

38

A Tour Through XP: Development

39

A Tour Through XP: Collective Code Ownership

40

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

41

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?

42

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

43

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

44

Substituting Practices: Planning

• The Planning Practices• 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.

45

User Stories

• User stories are written.• 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

46

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

47

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

48

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

49

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

50

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?

51

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

52

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”

53

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

54

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

55

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

56

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

57

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”

58

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

59

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

60

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”

61

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

62

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”

63

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

64

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)

65

Cockburn’s Modalities and Effectiveness

66

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

67

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

68

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.

69

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

70

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.

71

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

72

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”

73

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

74

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

75

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

76

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

77

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

78

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

79

No Functionality Added Early Substitutions

• Don’t!• You start creeping towards Big Design Up Front• Focus on the task at hand

80

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

81

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.

82

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”

83

Standards

• Code must be written to agreed standards• Almost every methodology does this• Don’t try to substitute this!

84

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

85

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

86

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

87

Get Comfortable

• Pair programming feels awkward at first• It helps if you are set up for it• Pair Programming at ThoughtWorks

88

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

89

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

90

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

91

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

92

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

93

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

94

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

95

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!”

96

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.

97

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

98

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

99

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

100

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

101

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

102

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

103

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

104

When All Else Fails…

• Trade this guy for that guy

Neal Ford

www.nealford.com

[email protected]

memeagora.blogspot.com

Questions?

Samples & slides at www.nealford.com

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 license. http://creativecommons.org/licenses/by-nc-sa/2.5/

http://creativecommons.org/licenses/by-sa/2.5/

Agile and Extreme Programming: A Pragmatic Approach Neal Ford Application Architect ThoughtWorks ...

Documents

Transcript of Agile and Extreme Programming: A Pragmatic Approach Neal Ford Application Architect ThoughtWorks ...