Agile Methods (Extreme Programming)

A Framework For Pulling It All Together

Extreme Programming

• A deliberate and disciplined approach to software development

• Suited to risky projects with dynamic requirements– Including late life cycle changes

• Emphasizes customer satisfaction• Unproductive activities have been trimmed from

the process– Reduces cost– Reduces frustration

Extreme Programming (cont.)• Promotes team work

– Managers– Customers– Developers

• Software project improvements (see following slides)

– Communication– Simplicity– Feedback– Courage

Software project improvements• Communication

– Between developers– Between managers and developers– Between customer and developers

• Simplicity– Designs are keep simple– Designs are keep “clean” (uncluttered with

extraneous features)

Software project improvements (cont.)• Feedback

– Testing begins on day 1 thus encouraging feedback

– Customer feedback/requests are implemented immediately

• Courage– Programmers respond to changing requirements– Programmers respond to changing technology– No fear of repercussion such as cost/time

Something New?

• “software engineered to be simple and elegant is no more valuable than software that is complex and hard to maintain”– XP refutes this view– Programs that are easy to understand and

maintain save time and money

Something New? (cont.)

• Testing is a crucial part of development– Tests are created before, during, and after

code is written– Tests are well matched to the code they

are testing– Identification of bugs leads to new tests to

ensure that the same bugs do not reoccur

Something New? (cont.)

• Change is embraced– Customer feedback is encouraged

throughout development– Allows customers to take full advantage of

unseen/unanticipated opportunities in the marketplace

When?

• Created in response to problem domains whose requirements change

• Address areas of risk– Time schedule– Unproven/unfamiliar technology

• Small groups of developers (2-10)– Not good for large teams of developers

When? (cont.)

• Extended development team– Developers– Managers– Customers– All must “buy in” to the process

Another Methodology?

• Software methodology– The set of rules and practices used to create

computer programs

• Heavyweight methodology– Many rules, practices, and documents

– Requires discipline and time to follow correctly

• Lightweight methodology– Few rules, practices, and documents

– Easy to follow

Another Methodology? (cont.)• To facilitate use of heavyweight

methodologies, tools were invented– CASE (Computer Aided Software

Engineering) tools, but the tools themselves are often difficult to learn

– Time that could be spent on the problem is redirected to the “meta-problem”

Another Methodology? (cont.)• For the lightweight methodologies we pick

and choose the rules to follow– Learn from the past– Keep rules that directly lead to the creation of

quality software– Omit the rules that hinder progress– Simplify the rules that are too complex– Make programmers feel free to be creative and

productive while remaining organized and focused

What is Extreme Programming?• A collection of rules and practices each

of which supports the development and delivery of quality software

• The rules and practices support each other (are used together)

• It’s an iterative process

Stages

• Planning– User Stories

• Design of the system architecture– Architectural spikes or prototypes

• Code creation• Testing

– From day 1

• Not necessarily in this order

User Stories

• Similar in purpose to use cases• Create time estimates for release

planning (to be defined later)• Replace large requirements documents• Written by customers as things the

system must do for them (like scenarios)– Helps to avoid technical jargon

User Stories (cont.)

• Drive the creation of acceptance tests– Derive tests to verify the implementation of

the story as the story is being written

• Provide only enough detail to make an implementation time estimate– Detailed descriptions will be solicited

during implementation (i.e. questions for the domain expert or customer)

User Stories (cont.)

• Time estimates– Provided by developers– “ideal development time” units

• Assuming no distractions• Assuming no other assignments• Assuming you know exactly what to do

– Should be 1-3 weeks in duration• Shorter stories get merged• Long stories get split

User Stories (cont.)

• Focus is on user needs– As opposed to technical details that may

be present in a “classical” requirements specification

– As opposed to GUI designs that may be present in a “classical” requirements specification

Release Plan/Planning

• Layout the overall project• Layout individual iterations through the

project• Release planning follows a set of rules

– Development team estimates user story times

– Customer determines user story priorities– Management make resource decisions

Release Plan/Planning (cont.)• Business people make business decisions• Technical people make technical

decisions• Negotiation results in a schedule all can

commit to• The approach yields a useable system (in

terms of customer needs and technical abilities) delivered as early as possible

Release Plan/Planning (cont.)• Planning may be based on time or scope

– Time• How many user stories can be implemented by a

specified date

– Scope• How long it will take to complete a set of user stories

– Project velocity is used in the estimates• A measure for time estimates and progress• More on this later

Release Plan/Planning (cont.)• Iterations are not planned in detail until

just before they begin– Facilitates scheduling change– Addresses issue of poor estimates in time– Facilitates task (user story) priority

changes

Release Plan/Planning (cont.)• “But it looks like it’s going to take too long”

– Don’t change estimates based on such statements

– This will cause problems later (when they’re more difficult to correct)

– Negotiate a release plan that is acceptable to all parties…developers, customers, management

Release Plan/Planning (cont.)• A release plan can be quantified by four

variables– Scope – how much is to be done– Resources – how many people are [how

much equipment is] available– Time – when will the project be done– Quality – how good will the finished

produce be

Release Plan/Planning (cont.)• Management can only choose to

manipulate 3 of these variables• Developers always get the 4th

• …and, skimping on quality is never acceptable– Always causes problems at a later date

• Let developers have a say in how many people get “dumped” onto the project

Release Plan

• Result of Release Planning– Based on user stories and release

planning– Specifies exactly which user stories are

going to be implemented for each release date

Release Plan (cont.)

• Provide a set of user stories for the customer to choose from for the next iteration (iteration planning)

• Translate these stories into programming tasks for the iteration– Will be translated into acceptance tests during the

iteration

• If the project velocity changes for an iteration, schedule another release planning meeting and update the release plan

Releases

• Results of the Release Plan– Release iterative versions often

• Get the software into the customer’s environment as soon as possible

• Get meaningful feedback from the customer in a timely manner

– The longer you wait, the less time you have to fix problems

Project Velocity

• A measure of how fast work is getting completed

• The number of user stories (programming tasks) that were completed during an iteration

• Used for subsequent release planning– Update estimates/priorities

• Hopefully it’s more meaningful than “lines of code”

Project Velocity (cont.)• Used for subsequent iteration planning

– Developers “sign-up” for programming tasks equal to the current project velocity

– Allows developers to “recover and clean up” after iterations – i.e. they don’t become overworked and stressed

– Developers can ask for another user story (programming task) in the event that they finish early

• Causes project velocity to increase

Project Velocity (cont.)• Project velocity will vary throughout

system development– Use release planning and iteration

planning to smooth out the ups and downs

Iterative Development

• Each iteration should be of limited time (1 to 3 weeks?)

• Don’t schedule programming tasks in advance (just-in-time planning)

• Don’t implement anything that was not planned for a given iteration (never add functionality)

• Facilitates dealing with changing user requirements

Iteration Planning

• Meet prior to each iteration

• Map out programming tasks for the iteration

• User stories are selected by the customer based on their priorities

• Failed acceptance tests [from the previous iteration] are selected

Iteration Planning (cont.)• User stories are translated into

programming tasks• Tasks are written down on cards which

become the detailed iteration plan• Tasks should be 1-3 days “ideal

development time” units– Shorter tasks are merged– Longer tasks are split

Iteration Planning (cont.)• The developer does the time estimate

– There’s a novel approach

• Project velocity is used to check the “booking” of the iteration– If over booked, the customer must choose

which user stories are to be eliminated (moved to the next iteration) (snow plowing)

– If under booked, the customer may add user stories

Iteration Planning (cont.)• Don’t fudge your time estimates, no

matter how tempting this may be– And don’t let others fudge your time

estimates either

Moving People Around

• One expert in a given area can be disastrous– Moving people from one task to another allows

all to become knowledgeable in various areas– Loss of a team member is now manageable

• Pair programming (discussed later) eases the pain of cross training people– Avoids productivity loss– Ensures continuity of thought

Daily Stand Up Meeting

• Communicate problems, solutions, and promote team focus

• Avoid long, drawn out meetings that leave people feeling demoralized and stressed out (due to not working on the project)

• Specialized meetings can be scheduled as the need arises– Involve only pertainent team members

Simplicity

• Avoid complexity– Difficult to implement– Difficult to debug– Difficult to maintain

• Not always possible, but try anyway

• “KISS approach” – Keep It Simple Stupid

CRC Cards

• Class, Responsibility, and Collaboration– Object-oriented design– Cards represent objects (instances)

• Class• Responsibility• Collaborating classes

• Cards are easily manipulated (physically) facilitating stepping through the process

CRC Cards (cont.)

• Easy for many people to become involved in the class design process/verification– Informal walk-through or structured walk-

though may be stifling to some people

• Criticism – Cards result in lack of written documentation– Solution is to write one card from each class

formally and store it away

Spike Solution

• A simple program used to explore potential solutions– Also known as a prototype

• Figure out answers to tough technical questions• Reduce technical risk• Increase user story estimate reliability• This used to scare developers for fear that at

spike solution will be made “the solution” through a business/management decision

Spike Solution (cont.)

• Only addresses the problem at hand

• Total disregard to all other issues

• Throw-away code

Never Add Functionality Early• Keep the system focused and

uncluttered

• Items you predict might be useful may turn out to be totally unnecessary

• Concentrate on today’s tasks– These are the high priority items as

specified by the customer

Refactor

• Learn to “let go”– Perhaps the hardest thing for a software

developer to do is to walk away from something they’ve poured their heart into

– “Ego-less” programming

• This is a key part of XP (and iterative design methodologies in general)

Refactor (cont.)

• Refactor– Remove redundancy– Eliminate unused functionality– Rejuvenate obsolete designs

• Constant refactoring results in– Life cycle time savings– Increased software quality– Design simplicity

Include the Customer

• Throughout the process– Beginning to end– Develop user stories – it’s their system so who

better to describe how it will be used– Prioritize user stories – it’s their system so

who better to decide which parts are most important

– Release planning – it’s their system so who better to decide which parts to deliver first

Include the Customer (cont.)• Throughout the process (cont.)

– During iterations – to fill in details [intentionally] left out of user stories

– Functional testing – creation of test data and verification of results (on site quality assurance)

• Requires full cooperation/buy-in– Trade-off up front “requirements specification” time

for “development” time through-out– Don’t settle for a trainee, even though that may

seem cost effective – you need a “domain expert”

Coding Standards

• Define them and stick to them

• Provides consistency facilitating team understanding and refactoring– Supports moving people around and pair

programming

• More on this later

Unit Test

• Create the unit test [plan] prior to creating the code– Aids in describing exactly what the

software unit must do– Makes requirements very specific– Provides immediate feedback (the tests

either pass or fail)– Provides a definite finish point (when all

the tests pass)

Unit Test (cont.)

• Designs are then driven by the desire of the customer to have all tests pass– Remember – the customer is also involved in

designing the tests (the functionality to be tested) as well as performance of the testing

• The resulting code does exactly what the tests specify…no more, no less– Better make sure the tests are all

encompassing

Pair Programming

• Two people work together at a single computer– Driver/backseat driver

• Two people working together on one task will be more productive than two people working on separate tasks– Very counter intuitive

Pair Programming (cont.)• Reason – Quality!

– Higher quality now results in lower [more costly] maintenance later

• Two people physically sit at one computer– One thinks tactically – e.g. doing the current

class method– One think strategically – e.g. envisioning how

current class method interacts with other methods

Pair Programming (cont.)• Very awkward at first…

• …but it beats talking to yourself

Sequential Integration

• Integration is the act of taking one task and making it work with the rest of the system

• Classically, this is done simultaneously (by all developers) when all individual tasks are completed– Or by a development team trained at such

tasks

Sequential Integration (cont.)• XP specifies that each developer (pair?)

should integrate their task into the system– This is done one developer (pair?) at a time

(sequentially)

• The mechanics of this is some sort of source code repository with locking method that allows only one developer access at a time– MicroSoft™ has a product called SourceSafe for

such a system

Integrate Often

• Integrating often should shorten the “lock-out” time from the repository

• Reduces the complexity of the integration task

• Makes latest code available to all developers

• Identifies incompatibilities early (before it’s too late)

Collective Code Ownership• Everyone has full access to all code

– Not allowed to label something as “my code”– Anyone can fix any portion of the code– Anyone can break any portion of the code– Hopefully, since designs are simple, someone

won’t misconstrue working code for a bug• Unit testing plays an influential role here too

Optimize Last

• Don’t guess what the system bottleneck will be– Measure performance when the system is

complete– Address performance when the

bottlenecks are well known

No Overtime

• Don’t ask (make?) developers to work overtime– Call a release planning meeting to change

project scope or timing– Over worked developers make bad

decisions leading to low quality software…

• Don’t add people to the team without consulting existing developers

Unit Test Frameworks

• We’ve discussed this previously

• A test suite for performing regression testing automatically– JUnit– others

Acceptance Tests

• Basically, when the software passes all of the customer defined functional tests, you’re done

Summary

• Extreme Programming (and other agile methods) suggests some software development practices and allows you to pick and choose the ones that work best for your team

• Most of all, it stresses– Teamwork– Communication