Extreme Programming: Author: Hue Nguyen Duration: 1.5 Hour

Extreme Programming
Author: Hue Nguyen Duration: 1.5 hour
Agenda
Whats eXtreme Programing
The Overall XP Lifecycle

XP Development XP Core Values XP practices XP Ground rules! Advantages and Disadvantages Process Focus
QA Team Sharing Program
8/17/2011
What is Extreme Programming?

An agile development methodology
Created by Kent Beck in the mid 1990s

A set of 12 key practices taken to their extremes A mindset for developers and customers
8/17/2011
8/17/2011
8/17/2011
XP Path
8/17/2011
XP Development
8/17/2011
XP Core Values
Four Core Values of XP
Communication Simplicity
Feedback
Courage
Communication
What does lack of communication do to projects? XP emphasizes value of communication in many of its practices:
On-site customer, user stories, pair programming, collective ownership (popular with open source developers), daily standup meetings, etc.
XP employs a coach whose job is noticing when
people arent communicating and reintroduce them

9 QA Team Sharing Program 8/17/2011
Simplicity
A simple design always takes less time to finish than a complex one. It's always faster and cheaper to replace complex code now, before you waste a lot more time on it. Keep things as simple as possible as long as possible by never adding functionality before it is scheduled. Beware though, keeping a design simple is hard work.
10
8/17/2011
Feedback
Feedback at different time scales
Unit tests tell programmers status of the system

When customers write new user stories,
programmers estimate time required to deliver changes Programmers produce new releases every 2-3 weeks for customers to review How does valuing feedback turn the waterfall model upside down?
11
8/17/2011
Courage
The courage to communicate and accept feedback
The courage to throw code away (prototypes) The courage to refactor the architecture of a
system Do you have what it takes?
12
XP practices
The XP practices we will emphasize are: Daily standup meeting Pair Programming
Teams of two people
Test Driven Development Writing lots of tests, and writing them early Continuous Integration Putting code together as you write it, not at the last minute Coding Standards Learn and follow well-established conventions Collective Code Ownership You are responsible for your partners code Simple Design Eschew obfuscation
14
8/17/2011
Daily standup meeting

Goal: Identify items to be accomplished for the day and raise issues
Everyone attends, including the customer Not a discussion forum Take discussions offline Everyone gets to speak 15 minutes
15
8/17/2011
Pair programming
TWO programmers working side-by-side, collaborating on the
same design, algorithm, code or test. One programmer, the driver, has control of the keyboard/mouse and actively implements the program. The other programmer, the observer, continuously observes the work of the driver to identify tactical (syntactic, spelling, etc.) defects and also thinks strategically about the direction of the work.
On demand, the two programmers can brainstorm any
challenging problem. Because the two programmers periodically switch roles, they work together as equals to develop software.
16
8/17/2011
Test-Driven Development (TDD)

TDD is a technique in which you write the tests
before you write the code you want to test This seems backward, but it really does work better:
When tests are written first, you have a clearer idea what to
do when you write the methods Because the tests are written first, the code is necessarily written to be testable Writing tests first encourages you to write simpler, singlepurpose methods
17
8/17/2011
Continuous integration
Unit testing is testing a single, more-or-less
independent part of a program in isolation Integration testing is testing the complete program with all its parts, to make certain they all work together Continuous integration is performing integration tests frequently (usually daily)
Continuous integration is more important on larger
projects For class projects, last-minute integration is still a bad idea

Coding standards
Coding standards make it simpler for your teammates (or yourself, weeks later) to read your code Java has some very well defined conventions you should learn Some conventions are strictly mechanical, such as formatting (spacing and indentation)
Eclipse can, upon request, correct your formatting for you
Some conventions require human intelligence Use meaningful names, with the correct part of speech Use adequate comments, written for the correct audience Prefer clearly written code to clever code
19
8/17/2011
Simple design
Do the simplest thing that can possibly work Complexity to achieve program efficiency is almost always a
very bad investment Complexity to support future features is seldom a good idea Program for the features you need today, not the ones you think you will want tomorrow. With good unit tests, you can easily refactor (revise) your code to do additional tests Follow the DRY principle: Dont repeat yourself Dont have multiple copies of identical (or very similar) code Dont have redundant copies of information
20
8/17/2011
More XP practices
Refactoring
Refactor out any duplicate code generated in a coding session
You can do this with confidence that you didn't break anything
because you have the tests
Collective code ownership

No single person "owns" a module
Any developer can work on any part of the code base at any
time
Continuous integration
All changes are integrated into the code base at least daily Tests have to run 100% both before and after integration
More practices
40-hour work week Programmers go home on time fresh and eager every morning, and tired and satisfied every night In crunch mode, up to one week of overtime is allowed More than that and theres something wrong with the process On-site customer Development team has continuous access to a real live customer, that is, someone who will actually be using the system, or a proxy Coding standards Everyone codes to the same standards Ideally, you shouldn't be able to tell by looking at it who on the team has touched a specific piece of code
Lessons Learned
23
8/17/2011
Successful XP Projects
Very rapid development
Exceptional responsiveness to user and customer
change requests High customer satisfaction Amazingly low error rates System begins returning value to customers very early in the process
XP Ground rules!
Extreme Programming (XP) is a lightweight process
Small team (2 to 12) Continuous access to customers OO design and code (Smalltalk, Java) Change management system (code and tests) The system is always working (growing functionality over time) Overall development cycle between 4 and 12 months New release to customer every 2-3 months Internal iterations every two weeks Not for life-critical systems (heart monitor, nuclear power plant,
avionics systems, etc.)
XP Advantages
Built-In Quality
Overall Simplicity
Programmer Power Customer Power Synergy Between Practices
26
8/17/2011
XP Disadvantages
Informal, little, or no documentation
Scalability
Contract Issues Misconception on the cost of change Tailoring
27
8/17/2011
Process Focus
1.
Requirement Management

Requirement workflow (Working Process) Requirement specification Q&A Tracking Requirement Traceability Matrix Change workflow (Working process) Change logs / analyze / implement / Tracking
2.
Change Request Management

3.
Technical Solution
Technical working process Coding standard / Convention Code review

8/17/2011
28
Process Focus
Integration Process 5. Testing Process
4.

Testing workflow Test Plan (include in project schedule) Testcase / Test checklist/ Report Project Plan/ Project schedule Project Estimation Process Tailoring
6.
Planning Planning

7.
Project Monitoring and Control
Project report (Team, Client) Risk/ Issue report
29
8/17/2011
Process Focus
8.
Configuration Management

CM Plan (include in schedule) Baseline audit report Build note Release note
Process Quality Assurance

QA Schedule QA weekly report QA Audit report
30
8/17/2011
Q&A
Appendix
The Core XP Practices
Advantage and Disadvantage
Rapid, fine feedback: Shared Understanding: Test-driven design (via unit Planning game and acceptance tests) Simple Design On-site customer System Metaphor Pair programming Collective Code Ownership Coding Conventions Continuous process: Continuous integration Merciless refactoring Developer Welfare: Small, frequent releases Forty-hour week
1 - The Planning Game

Planning for the upcoming iteration
Uses stories provided by the customer

Technical persons determine schedules,
estimates, costs, etc A result of collaboration between the customer and the developers
33
8/17/2011
The Planning Game Advantages

Reduction in time wasted on useless features
Greater customer appreciation of the cost of a
feature Less guesswork in planning
34
8/17/2011
The Planning Game Disadvantages

Customer availability
Is planning this often necessary?
35
8/17/2011
2- Small Releases
Small in terms of functionality
Less functionality means releases happen more
frequently Support the planning game
36
8/17/2011
Small Releases Advantages

Frequent feedback
Tracking
Reduce chance of overall project slippage
37
8/17/2011
Small Releases Disadvantages

Not easy for all projects
Not needed for all projects

Versioning issues
38
8/17/2011
3 Metaphor
The oral architecture of the system
A common set of terminology
39
8/17/2011
Metaphor Advantages
Encourages a common set of terms for the
system Reduction of buzz words and jargon A quick and easy way to explain the system
40
8/17/2011
Metaphor Disadvantages
Often the metaphor is the system
Another opportunity for miscommunication

The system is often not well understood as a
metaphor
41
8/17/2011
4 Simple Design
K.I.S.S.
Do as little as needed, nothing more
42
8/17/2011
Simple Design Advantages

Time is not wasted adding superfluous
functionality Easier to understand what is going on Refactoring and collective ownership is made possible Helps keeps programmers on track
43
8/17/2011
Simple Design Disadvantages

What is simple?
Simple isnt always best
44
8/17/2011
6 Testing
Unit testing
Test-first design
All automated
45
8/17/2011
Testing Advantages
Unit testing promote testing completeness
Test-first gives developers a goal

Automation gives a suite of regression test
46
8/17/2011
Testing Disadvantages
Automated unit testing isnt for everything
Reliance on unit testing isnt a good idea

A test result is only as good as the test itself
47
8/17/2011
6 Refactoring
Changing how the system does something but
not what is done Improves the quality of the system in some way
48
8/17/2011
Refactoring Advantages
Prompts developers to proactively improve the
product as a whole Increases developer knowledge of the system
49
8/17/2011
Refactoring Disadvantages
Not everyone is capable of refactoring
Refactoring may not always be appropriate

Would upfront design eliminate refactoring?
50
8/17/2011
7 Pair Programming
Two Developers, One monitor, One Keyboard
One drives and the other thinks

Switch roles as needed
51
8/17/2011
Pair Programming Advantages

Two heads are better than one Focus Two people are more likely to answer the
following questions:
Is this whole approach going to work? What are some test cases that may not work yet? Is there a way to simplify this?
52
8/17/2011
Pair Programming Disadvantages

http://www.cenqua.com/pairon/
Many tasks really dont require two programmers

A hard sell to the customers Not for everyone
53
8/17/2011
8 Collective Ownership
The idea that all developers own all of the code
Enables refactoring
54
8/17/2011
Collective Ownership Advantages

Helps mitigate the loss of a team member leaving
Promotes developers to take responsibility for the
system as a whole rather then parts of the system
55
8/17/2011
Collective Ownership - Disadvantages

Loss of accountability
Limitation to how much of a large system that an
individual can practically own
56
8/17/2011
9 Continuous Integration
New features and changes are worked into the
system immediately Code is not worked on without being integrated for more than a day
57
8/17/2011
Continuous Integration - Advantages

Reduces to lengthy process
Enables the Small Releases practice
58
8/17/2011
Continuous Integration Disadvantages

The one day limit is not always practical
Reduces the importance of a well-thought-out
architecture
59
8/17/2011
10 40-Hour Week
The work week should be limited to 40 hours
Regular overtime is a symptom of a problem and
not a long term solution
60
8/17/2011
40-Hour Week Advantage

Most developers lose effectiveness past 40-Hours
Value is placed on the developers well-being

Management is forced to find real solutions
61
8/17/2011
40-Hour Week - Disadvantages

The underlying principle is flawed
40-Hours is a magic number

Some may like to work more than 40-Hours
62
8/17/2011
11 On-Site Customer
Just like the title says!
Acts to steer the project

Gives quick and continuous feedback to the
development team
63
8/17/2011
On-Site Customer Advantages

Can give quick and knowledgeable answers to
real development questions Makes sure that what is developed is what is needed Functionality is prioritized correctly
64
8/17/2011
On-Site Customer Disadvantages

Difficult to get an On-Site Customer
The On-Site customer that is given may not be
fully knowledgeable about what the company May not have authority to make many decisions Loss of work to the customers company
65
8/17/2011
12 Coding Standards
All code should look the same
It should not possible to determine who coded
what based on the code itself
66
8/17/2011
Coding Standards Advantages

Reduces the amount of time developers spend
reformatting other peoples code Reduces the need for internal commenting Call for clear, unambiguous code
67
8/17/2011
Coding Standards Disadvantages

Degrading the quality of inline documentation
68
8/17/2011

Extreme Programming: Author: Hue Nguyen Duration: 1.5 Hour

Uploaded by

Copyright:

Available Formats

You might also like

Extreme Programming: Author: Hue Nguyen Duration: 1.5 Hour

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Extreme Programming: Author: Hue Nguyen Duration: 1.5 Hour

Uploaded by

Copyright:

Available Formats

Extreme Programming

Author: Hue Nguyen Duration: 1.5 hour

The Overall XP Lifecycle

QA Team Sharing Program

What is Extreme Programming?

Created by Kent Beck in the mid 1990s

QA Team Sharing Program

The Overall XP Lifecycle

QA Team Sharing Program

The Overall XP Lifecycle

QA Team Sharing Program

QA Team Sharing Program

QA Team Sharing Program

people arent communicating and reintroduce them

QA Team Sharing Program

Unit tests tell programmers status of the system

QA Team Sharing Program

system Do you have what it takes?

QA Team Sharing Program

Daily standup meeting

QA Team Sharing Program

QA Team Sharing Program

Test-Driven Development (TDD)

QA Team Sharing Program

projects For class projects, last-minute integration is still a bad idea

QA Team Sharing Program

QA Team Sharing Program

because you have the tests

Collective code ownership

QA Team Sharing Program

Exceptional responsiveness to user and customer

QA Team Sharing Program

avionics systems, etc.)

QA Team Sharing Program

QA Team Sharing Program

QA Team Sharing Program

Change Request Management

Technical working process Coding standard / Convention Code review

QA Team Sharing Program

Project Monitoring and Control

Project report (Team, Client) Risk/ Issue report

QA Team Sharing Program

Process Quality Assurance

QA Schedule QA weekly report QA Audit report

QA Team Sharing Program

QA Team Sharing Program

1 - The Planning Game

Uses stories provided by the customer

QA Team Sharing Program

The Planning Game Advantages

Greater customer appreciation of the cost of a

feature Less guesswork in planning

QA Team Sharing Program

The Planning Game Disadvantages

Is planning this often necessary?

QA Team Sharing Program

Less functionality means releases happen more