The document discusses Extreme Programming (XP) as a lightweight and efficient software development methodology characterized by short cycles, incremental planning, and close collaboration among programmers. It outlines key principles such as rapid feedback, communication, and embracing change, while also highlighting strategies for adoption and management. Additionally, it addresses challenges that may arise when implementing XP and provides a structure for roles within a development team.

1. Fundamentals of XPFundamentals of XP
Himanshu Gupta
Sr. Software Consultant
Knoldus Software LLP
Himanshu Gupta
Sr. Software Consultant
Knoldus Software LLP

2. XP – eXtreme ProgrammingXP – eXtreme Programming
● Lightweight
● Efficient
● Low-risk
● Flexible
● Predictable
● Scientific
● Fun way of programming
● Lightweight
● Efficient
● Low-risk
● Flexible
● Predictable
● Scientific
● Fun way of programming

3. DifferenceDifference
● Short Cycles
● Incremental planning approach
● Able to create flexible development schedules
● Rely on
● Automated tests
● Oral Communication
● Evolutionary design process
● Close collaboration of programmers
● Short Cycles
● Incremental planning approach
● Able to create flexible development schedules
● Rely on
● Automated tests
● Oral Communication
● Evolutionary design process
● Close collaboration of programmers

4. Problems & SolutionsProblems & Solutions
Problems
● Schedule Slips
● Project Canceled
● System goes sour
● Defect rate
● Business misunderstood
● Business changes
● False feature rich
● Staff turnover
Problems
● Schedule Slips
● Project Canceled
● System goes sour
● Defect rate
● Business misunderstood
● Business changes
● False feature rich
● Staff turnover
Solutions
● Short cycles
● MBS (Most Business Sense)
● Automated Tests
● Acceptance Tests
● Oral communication
● Short cycles
● Prioritizing tasks
● Individual ownership
Solutions
● Short cycles
● MBS (Most Business Sense)
● Automated Tests
● Acceptance Tests
● Oral communication
● Short cycles
● Prioritizing tasks
● Individual ownership

5. Day-to-day programming proceeds from a task clearly
connected to a feature the customer wants, to tests, to
implementation, to design, and through to integration. A
little of each of the activities of software development are
packed into each episode.
Day-to-day programming proceeds from a task clearly
connected to a feature the customer wants, to tests, to
implementation, to design, and through to integration. A
little of each of the activities of software development are
packed into each episode.
An EpisodeAn Episode

6. Four VariablesFour Variables
● Cost
● Time
● Quality
● Scope
● Cost
● Time
● Quality
● Scope

7. Cost of ChangeCost of Change
The cost of change may not rise dramatically over time
src: Extreme Programming Explained by Kent Beck, First Editionsrc: Extreme Programming Explained by Kent Beck, First Edition

8. Learning to DriveLearning to Drive
"Driving is not about getting the car going in the right
direction. Driving is about constantly paying attention,
making a little correction this way, a
little correction that way."
"Driving is not about getting the car going in the right
direction. Driving is about constantly paying attention,
making a little correction this way, a
little correction that way."

9. Four ValuesFour Values
● Communication
● Simplicity
● Feedback
● Courage
● Communication
● Simplicity
● Feedback
● Courage
* A value, that lies below the surface of the other these four is Respect.* A value, that lies below the surface of the other these four is Respect.

10. Basic PrinciplesBasic Principles
● Rapid feedback
● Assume simplicity
● Incremental change
● Embracing change
● Quality work
● Rapid feedback
● Assume simplicity
● Incremental change
● Embracing change
● Quality work
Fundamental PrinciplesFundamental Principles

11. Basic PrinciplesBasic Principles
● Teach learning
● Small initial investment
● Play to win
● Concrete experiments
● Open, honest communication
● Work with people's instincts, not against them
● Accepted responsibility
● Local adaptation
● Travel light
● Honest measurement
● Teach learning
● Small initial investment
● Play to win
● Concrete experiments
● Open, honest communication
● Work with people's instincts, not against them
● Accepted responsibility
● Local adaptation
● Travel light
● Honest measurement
Central PrinciplesCentral Principles

12. Back to BasicsBack to Basics
● Coding
● Testing
● Listening
● Designing
● Coding
● Testing
● Listening
● Designing
We code because if we don't code, we haven't done anything. We test
because if we don't test, we don't know when we are done coding. We
listen because if we don't listen we don't know what to code or what to
test. And we design so we can keep coding and testing and listening
indefinitely.

13. A Quick OverviewA Quick Overview
● The Planning Game
● Small Releases
● Metaphor
● Simple Design
● Testing
● Refactoring
● Pair Programming
● Collective Ownership
● Continuous Integration
● 40 Hour Week
● On-site Customer
● Coding Standards
● The Planning Game
● Small Releases
● Metaphor
● Simple Design
● Testing
● Refactoring
● Pair Programming
● Collective Ownership
● Continuous Integration
● 40 Hour Week
● On-site Customer
● Coding Standards

14. Practices Support each otherPractices Support each other
How could this Work ?How could this Work ?
src: Extreme Programming Explained by Kent Beck, First Editionsrc: Extreme Programming Explained by Kent Beck, First Edition

15. Management StrategyManagement Strategy
● Metrics
● Coaching
● Tracking
● Intervention
● Metrics
● Coaching
● Tracking
● Intervention

16. Facilities StrategyFacilities Strategy
src: Extreme Programming Explained by Kent Beck, First Editionsrc: Extreme Programming Explained by Kent Beck, First Edition

17. Splitting Business and
Technical Responsibility
Splitting Business and
Technical Responsibility
The choice between selecting a Ferrari and a Minivan is made
on the basis of:
● Cost – Ferrari($200,000) & Minivan($40,000)
● Requirement -
● Should be able to carry five people.
● Should be able to run at 200km/h.
The choice between selecting a Ferrari and a Minivan is made
on the basis of:
● Cost – Ferrari($200,000) & Minivan($40,000)
● Requirement -
● Should be able to carry five people.
● Should be able to run at 200km/h.

18. Planning StrategyPlanning Strategy
● The Goal
● The Strategy
● The Pieces
● The Players
● The Moves
● Iteration Planning
● Exploration Phase
● Commitment Phase
● Steering Phase
● Planning in a Week
● The Goal
● The Strategy
● The Pieces
● The Players
● The Moves
● Iteration Planning
● Exploration Phase
● Commitment Phase
● Steering Phase
● Planning in a Week

19. Development StrategyDevelopment Strategy
● Continuous Integration
Learn/Test/Code/Release
● Collective Ownership
Removes Complex Code from Project
● Pair Programming
● Continuous Integration
Learn/Test/Code/Release
● Collective Ownership
Removes Complex Code from Project
● Pair Programming
src: https://www.google.co.in/imghp?hl=en&tab=wi&ei=C2aDVvfcLYWgugTKs6_4Dg&ved=0EKouCBQoAQsrc: https://www.google.co.in/imghp?hl=en&tab=wi&ei=C2aDVvfcLYWgugTKs6_4Dg&ved=0EKouCBQoAQ

20. Design StrategyDesign Strategy
We should design for today's problems today, and tomorrow's
problems tomorrow
We should design for today's problems today, and tomorrow's
problems tomorrow
src: Extreme Programming Explained by Kent Beck, First Editionsrc: Extreme Programming Explained by Kent Beck, First Edition

21. Testing StrategyTesting Strategy
An outline that describes the testing approach of the Software
Development Cycle
- Wikipedia
An outline that describes the testing approach of the Software
Development Cycle
- Wikipedia

22. Adopting XPAdopting XP
How to adopt XP ?
1. Pick your worst problem.
2. Solve it the XP way.
3. When it's no longer your worst problem, repeat.
How to adopt XP ?
1. Pick your worst problem.
2. Solve it the XP way.
3. When it's no longer your worst problem, repeat.

23. Retrofitting XPRetrofitting XP
● Start with Testing
● Change Design
● Do Planning on regular basis
● Include everyone in Management
● Don't leave Development
● Start with Testing
● Change Design
● Do Planning on regular basis
● Include everyone in Management
● Don't leave Development

24. Lifecycle of an Ideal XP
Project
Lifecycle of an Ideal XP
Project
● Exploration
● Planning
● Iterations to First Release
● Productionizing
● Maintenance
● Death
● Exploration
● Planning
● Iterations to First Release
● Productionizing
● Maintenance
● Death

25. Roles for PeopleRoles for People
● Programmer
● Customer
● Tester
● Tracker
● Coach
● Consultant
● Big Boss
● Programmer
● Customer
● Tester
● Tracker
● Coach
● Consultant
● Big Boss

26. 20-80 Rule20-80 Rule
80% of the benefit comes from 20% of the work.
XP makes use of this rule itself, by putting the most
valuable 20% of functionality into production, do
the most valuable 20% of the design
80% of the benefit comes from 20% of the work.
XP makes use of this rule itself, by putting the most
valuable 20% of functionality into production, do
the most valuable 20% of the design

27. What Makes XP Hard ?What Makes XP Hard ?
By adopting XP as our development process, we are accepting
responsibility for being aware and modifying it when there is
a problem.
By adopting XP as our development process, we are accepting
responsibility for being aware and modifying it when there is
a problem.

28. When You Shouldn't Try XP ?When You Shouldn't Try XP ?
● Complete Analysis of Design
● Too much Documentation
● Long Working Hours
● Large Team
● Expensive Technology
● Long gaps in Feedback
● Complete Analysis of Design
● Too much Documentation
● Long Working Hours
● Large Team
● Expensive Technology
● Long gaps in Feedback

29. Questions & Option[A]Questions & Option[A]

30. Thank youThank you

31. ReferencesReferences
● Extreme Programming Explained, Kent Beck
● http://www.extremeprogramming.org/
● Extreme Programming Explained, Kent Beck
● http://www.extremeprogramming.org/