Agile Practices - eXtreme Programming

1
Extreme Programming
How Agile Practices can make the difference
AniruddhaChakrabarti
Sr. Solution Architect

2
Agenda
Agile Methodology
Agile Manifesto & Agile Philosophy
Different Agile methodologies
Extreme Programming/XP
Brief History of XP
XP Values, Principles and Practices
Core XP Values
XP Principles
Different XP Practices

3
Agile Methodology
Definition of Agile:
Characterized by quickness, lightness, and ease of movement; nimble.
Mentally quick or alert: an agile mind.
Agile Methodology promotes:
Project management process that encourages frequent inspection and adaptation;
Leadership philosophy that encourages team work, self-organization and accountability;
Set of engineering best practices that allow for rapid delivery of high-quality software;
Business approach that aligns development with customer needs and company goals.

4
Agile Philosophy: 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 interactionsoverprocesses and tools
Working softwareovercomprehensive documentation
Customer collaborationover contract negotiation
Responding to changeoverfollowing a plan
That is, while there is value in the items on the right, we value the items on the left more.
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 Steve Mellor Ken Schwaber Jeff Sutherland
Dave Thomas
www.AgileManifesto.org, http://AgileManifesto.org/history.html

5
Agile Philosophy
Individuals and interactions over processes and tools
Software without documentation is a disaster. Code is not the ideal medium for communicating the rationale and structure of a system
However, too much documentation is worse than too little. Huge software documents take a great deal of time to produce, and even more time to keep in sync with the code.
Working software over comprehensive documentation
Software without documentation is a disaster. Code is not the ideal medium for communicating the rationale and structure of a system
However, too much documentation is worse than too little. Huge software documents take a great deal of time to produce, and even more time to keep in sync with the code.
Customer collaboration over contract negotiation
Responding to change over following a plan

6
Different Agile Methodologies
Extreme Programming / XP (Kent Beck, Ward Cunningham, Martin Fowler, Ron Jeffries)
Scrum (Ken Schwaber, Jeff Sutherland)
Crystal (Alistair Cockburn)
DSDM
Lean Software Development
Feature Driven Development / FDD (Peter Coad)
XBreed
Adaptive Software Development / ASD (Jim Highsmith)

7
What is Extreme Programming (XP)
XP is actually a deliberate and disciplined approach to software development.
Discipline of software development based on Values of simplicity, communication, feedback, and courage.
Works by -
Bringing the whole team together in the presence of simple practices
Enough feedback to enable the team to see where they are and to tune the practices to their unique situation.
Proven at companies like Bayerische Landesbank, Credit Swiss Life, DaimlerChrysler, First Union National Bank, Ford Motor Company and UBS.
Empowers developers to confidently respond to changing customer requirements, even late in life cycle.

8
Agile & XP: A bit of History
Agile software development evolved in mid-90s as part of a reaction against "heavyweight" methods.
Initially they were called "lightweight methods”.
In 2001, prominent members of the community met at Snowbird, Utah, and adopted the name "agile methods".
Root of XP lies in Smalltalk community
Early 90s: Kent Beck and Ward Cunningham came up with an approach to software development that made every thing simple and more efficient.
Mar 96: Kent started Chrysler Comprehensive Compensation/C3) at DaimlerChrysler using new concepts in software development.
The result was Extreme Programming (XP) methodology.

9
XP Values, Principles & Practices

Principles are bridge between Values, which is synthetic and abstract, and Practices, which tell how to actually develop software.

Values
Practices
Principles

Planning Game
Short Release
Continuous Integration
Simple Design
Pair Programming
…
Communication
Simplicity
Feedback
…
Humanity
Improvement
Quality
Accepted Responsibility
…

10
Core Values of XP
Communication
Problems with projects can invariably be traced back to somebody not talking to somebody else about something
Simplicity
Do the simplest thing that could possibly work
Feedback
Should always be able to measure the system and to know how far it is from the needed features
Concrete feedback early and often from the customer, from the team, and from real end users gives you more opportunity to steer your efforts
Close customer contact & availability of automated tests
Courage
Respect

11
Basic Fundamental Principles
Rapid Feedback
Assume Simplicity
Make Incremental Change
Embracing Change
Quality Work
www.AgileManifesto.org/principles.html
http://en.csharp-online.net/Introducing_XP%E2%80%94Fifteen_XP_Principles

12
Further Principles
Teach Learning
Make a Small Initial Investment
Play to Win – do what is required to succeed
Concrete Experiments – use proper reports
Open, honest Communication
Work with people's instincts - not against them
Accepted Responsibility
Local Adaptation / Accept as Necessary
Travel Light
Honest Measurement

13
XP Practices (Rules)

Planning related practices
Design related practices
Coding/Programming/Release related practices
Testing related practices
General/Human practices

http://www.xprogramming.com/Practices/xpractices.htm
http://www.extremeprogramming.org/rules.html

14
XP Practices: Planning
User Stories
Functionalities of the system are described using stories, short descriptions of customer-visible functionalities
Planning Game/Release Planning
Small & Short Releases
Every release should be as small as possible, containing the most valuable business requirements.
It is far better to plan a month or two at a time than six months or a year at a time
Iterative Development
Daily Standup meeting

15
Planning Game

Neither business considerations nor technical considerations should be paramount.
Software development is always an evolving dialog between the possible and the desirable.
Business people decide about
Scope
Priority
Composition of releases
Date of releases
Technical people decide about
Estimates
Consequences
Process
Detailed Scheduling

16
Daily Standup Meeting
Problem:
Typical project meeting - most attendees do not contribute, but attend just to hear the outcome.
Large amount of developer time is wasted to gain a trivial amount of communication.
Having many people attend every meeting drains resources from the project and also creates a scheduling nightmare.
Solution:
Short and brief standup (no one seats to keep it short)
Should be less than 15 mins
A stand up meeting every morning is used to communicate problems, solutions, and promote team focus.
Not a Status Reporting Meeting
It's Not Just Standing Up: Patterns of Daily Stand-up Meetings – Jason Yip

17
Daily Standup Meeting (Cont’d)
Everyone answers three questions –
What did I accomplish yesterday?
What will I do today?
What obstacles are impeding my progress?
Focus on the Backlog
Same Place, Same Time
Who attends the daily stand-up? – All Hands
Time-box the meeting
Last Arrival Speaks First

18
XP Practices: Designing
Simple Design (avoid YAGNI)
System Metaphor
CRC Cards: Class, Responsibility, Collaborator
Spike Solutions
No functionality is added early
Design Improvement / Refactoring
Related Article: Is Design Dead? – Martin Fowler

19
Simple Design
Misconception about XP: XP advices to avoid design
Truth: XP advices
Avoid too much Up Front Design / extra design at early phase, as requirement is not clear – Evolutionary Approach
Simple and elegant design
Runs all the tests.
Has no duplicated logic. Be wary of hidden duplication like parallel class hierarchies.
States every intention important to the programmers.
Has the fewest possible classes and methods.
Avoid over design
Avoid design that would not be required: YAGNI

20
CRC Cards
Used to identify Classes, Responsibilities and Collaborations between objects.
Created from index cards with these info -
Class name
Its Super and Sub classes (if applicable)
Responsibilities of the class.
Names of other classes with which the class will collaborate to fulfill its responsibilities.
Author
Related Article: http://c2.com/doc/oopsla89/paper.html
Using CRC cards – Alistair Cockburn
http://www.extremeprogramming.org/rules/crccards.html

21
XP Practices: Coding/Release
Onsite Customer: Customer is always available
Coding Standards
Test Driven Development (TDD): code unit tests first
Pair Programming
Continuous Integration (CI)
Ten-minute build
Daily Deployment
Collective Code Ownership
Sustainable Pace: 40-hour week

22
Continuous Integration (CI)
Maintain a single source repository
Automate the build
Make your build self-testing
Everyone commits every day
Every commit should build the mainline on an Integration machine
Keep the build fast
Test in a clone of the production environment
Make it easy for anyone to get the latest executable
Everyone can see what's happening
Automate deployment
Related Article: Continuous Integration – Martin Fowler

Steps to do for CI with a Source Control
23
Dev begins by taking a copy of current integrated source onto local dev machine: Check out from Source Control
Dev makes the necessary changes - It consist of both altering the code, and also adding or changing automated tests.
Dev carries out an automated build on dev machine - takes source code in working copy, compiles and runs the automated tests.
Update working copy with changes in Source Control and rebuild. If other’s changes clash with dev’s changes dev will fix this and repeat until he can build a working copy that is properly synchronized with the mainline.
Once dev have made his own build of a properly synchronized working copy he can finally commit changes into the mainline
Build again, but this time on an integration machine based on the mainline code. Only when this build succeeds can we say that my changes are done

24
XP Practices: Testing
All code should have Unit Tests
All code must pass all unit tests before it can be released.
When a bug is found tests are created.
Unit Tests and Acceptance tests are run often and the score is published.

25
XP Practices: Team & Human
Seat together
Whole team approach
Informative workspace
Energized Work
Pair Programming
Team Continuity

26
Resources
Extreme Programming Explained: Embrace Change – Kent Beck (Ver 1 and 2)
Apress Pro .NET 2.0 Extreme Programming ebook
Refactoring: Improving the Design of Existing Code - Matrin Fowler, Kent Beck …
Agile Project Management with Scrum - Ken Schwaber
www.ExtremeProgramming.org
www.AgileManifesto.org
http://www.xprogramming.com