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
QA Team Sharing Program
8/17/2011
The Overall XP Lifecycle
QA Team Sharing Program
8/17/2011
The Overall XP Lifecycle
QA Team Sharing Program
8/17/2011
XP Path
QA Team Sharing Program
8/17/2011
XP Development
QA Team Sharing Program
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
QA Team Sharing Program
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
QA Team Sharing Program
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
QA Team Sharing Program
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
QA Team Sharing Program
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
QA Team Sharing Program
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
QA Team Sharing Program
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
18 QA Team Sharing Program 8/17/2011
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
QA Team Sharing Program
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
QA Team Sharing Program
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
21 QA Team Sharing Program 8/17/2011
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
22 QA Team Sharing Program 8/17/2011
Lessons Learned
23
QA Team Sharing Program
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
QA Team Sharing Program
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.)
QA Team Sharing Program
XP Advantages
Built-In Quality
Overall Simplicity
Programmer Power Customer Power Synergy Between Practices
26
QA Team Sharing Program
8/17/2011
XP Disadvantages
Informal, little, or no documentation
Scalability
Contract Issues Misconception on the cost of change Tailoring
27
QA Team Sharing Program
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
QA Team Sharing Program
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
QA Team Sharing Program
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
QA Team Sharing Program
8/17/2011
Q&A
QA Team Sharing Program
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
QA Team Sharing Program
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
QA Team Sharing Program
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
QA Team Sharing Program
8/17/2011
The Planning Game Disadvantages
Customer availability
Is planning this often necessary?
35
QA Team Sharing Program
8/17/2011
2- Small Releases
Small in terms of functionality
Less functionality means releases happen more
frequently Support the planning game
36
QA Team Sharing Program
8/17/2011
Small Releases Advantages
Frequent feedback
Tracking
Reduce chance of overall project slippage
37
QA Team Sharing Program
8/17/2011
Small Releases Disadvantages
Not easy for all projects
Not needed for all projects
Versioning issues
38
QA Team Sharing Program
8/17/2011
3 Metaphor
The oral architecture of the system
A common set of terminology
39
QA Team Sharing Program
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
QA Team Sharing Program
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
QA Team Sharing Program
8/17/2011
4 Simple Design
K.I.S.S.
Do as little as needed, nothing more
42
QA Team Sharing Program
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
QA Team Sharing Program
8/17/2011
Simple Design Disadvantages
What is simple?
Simple isnt always best
44
QA Team Sharing Program
8/17/2011
6 Testing
Unit testing
Test-first design
All automated
45
QA Team Sharing Program
8/17/2011
Testing Advantages
Unit testing promote testing completeness
Test-first gives developers a goal
Automation gives a suite of regression test
46
QA Team Sharing Program
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
QA Team Sharing Program
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
QA Team Sharing Program
8/17/2011
Refactoring Advantages
Prompts developers to proactively improve the
product as a whole Increases developer knowledge of the system
49
QA Team Sharing Program
8/17/2011
Refactoring Disadvantages
Not everyone is capable of refactoring
Refactoring may not always be appropriate
Would upfront design eliminate refactoring?
50
QA Team Sharing Program
8/17/2011
7 Pair Programming
Two Developers, One monitor, One Keyboard
One drives and the other thinks
Switch roles as needed
51
QA Team Sharing Program
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
QA Team Sharing Program
8/17/2011
Pair Programming Disadvantages
[Link]
Many tasks really dont require two programmers
A hard sell to the customers Not for everyone
53
QA Team Sharing Program
8/17/2011
8 Collective Ownership
The idea that all developers own all of the code
Enables refactoring
54
QA Team Sharing Program
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
QA Team Sharing Program
8/17/2011
Collective Ownership - Disadvantages
Loss of accountability
Limitation to how much of a large system that an
individual can practically own
56
QA Team Sharing Program
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
QA Team Sharing Program
8/17/2011
Continuous Integration - Advantages
Reduces to lengthy process
Enables the Small Releases practice
58
QA Team Sharing Program
8/17/2011
Continuous Integration Disadvantages
The one day limit is not always practical
Reduces the importance of a well-thought-out
architecture
59
QA Team Sharing Program
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
QA Team Sharing Program
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
QA Team Sharing Program
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
QA Team Sharing Program
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
QA Team Sharing Program
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
QA Team Sharing Program
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
QA Team Sharing Program
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
QA Team Sharing Program
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
QA Team Sharing Program
8/17/2011
Coding Standards Disadvantages
Degrading the quality of inline documentation
68
QA Team Sharing Program
8/17/2011
