1

Extreme ProgrammingHow Agile Practices can make the difference

Aniruddha ChakrabartiSr. Solution Architect

2

AgendaAgile MethodologyAgile Manifesto & Agile PhilosophyDifferent Agile methodologiesExtreme Programming/XPBrief History of XPXP Values, Principles and PracticesCore XP ValuesXP PrinciplesDifferent XP Practices

3

Agile MethodologyDefinition 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 ManifestoWe 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 interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following 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 CockburnWard Cunningham Martin Fowler James Grenning Jim HighsmithAndrew Hunt Ron Jeffries Jon Kern Brian MarickRobert C. Martin Steve Mellor Ken Schwaber Jeff SutherlandDave Thomas

www.AgileManifesto.org, http://AgileManifesto.org/history.html

5

Agile PhilosophyIndividuals 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 negotiationResponding to change over following a plan

6

Different Agile MethodologiesExtreme Programming / XP (Kent Beck, Ward

Cunningham, Martin Fowler, Ron Jeffries) Scrum (Ken Schwaber, Jeff Sutherland)

Crystal (Alistair Cockburn)

DSDMLean Software DevelopmentFeature Driven Development / FDD (Peter Coad)

XBreedAdaptive 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 HistoryAgile 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 communityEarly 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

Values PracticesPrinciples

CommunicationSimplicityFeedback…

Humanity ImprovementQualityAccepted

Responsibility…

Planning GameShort ReleaseContinuous IntegrationSimple DesignPair Programming…

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

10

Core Values of XPCommunication

Problems with projects can invariably be traced back to somebody not talking to somebody else about something

SimplicityDo the simplest thing that could possibly work

FeedbackShould always be able to measure the system and to know how far it is

from the needed featuresConcrete 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

CourageRespect

11

Basic Fundamental PrinciplesRapid FeedbackAssume SimplicityMake Incremental ChangeEmbracing ChangeQuality Work

www.AgileManifesto.org/principles.html http://en.csharp-online.net/Introducing_XP%E2%80%94Fifteen_XP_Principles

12

Further PrinciplesTeach 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 NecessaryTravel LightHonest Measurement

13

XP Practices (Rules)

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

Planning related practices Design related practicesCoding/Programming/Release related practicesTesting related practicesGeneral/Human practices

14

XP Practices: PlanningUser Stories

Functionalities of the system are described using stories, short descriptions of customer-visible functionalities

Planning Game/Release PlanningSmall & 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 DevelopmentDaily Standup meeting

15

Planning GameNeither 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

ScopePriorityComposition of releasesDate of releases

Technical people decide aboutEstimatesConsequencesProcessDetailed Scheduling

16

Daily Standup MeetingProblem:

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 minsA 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 HandsTime-box the meetingLast Arrival Speaks First

18

XP Practices: DesigningSimple Design (avoid YAGNI)System MetaphorCRC Cards: Class, Responsibility, Collaborator

Spike SolutionsNo functionality is added earlyDesign Improvement / Refactoring

Related Article: Is Design Dead? – Martin Fowler

19

Simple DesignMisconception about XP: XP advices to avoid

designTruth: XP advices

Avoid too much Up Front Design / extra design at early phase, as requirement is not clear – Evolutionary Approach

Simple and elegant designa) Runs all the tests.b) Has no duplicated logic. Be wary of hidden duplication like parallel

class hierarchies.c) States every intention important to the programmers.d) Has the fewest possible classes and methods.

Avoid over designAvoid design that would not be required: YAGNI

20

CRC CardsUsed 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 Cockburnhttp://www.extremeprogramming.org/rules/crccards.html

ClassResponsibility Collaborator

21

XP Practices: Coding/ReleaseOnsite Customer: Customer is always availableCoding StandardsTest Driven Development (TDD): code unit tests firstPair ProgrammingContinuous Integration (CI)Ten-minute buildDaily DeploymentCollective Code OwnershipSustainable Pace: 40-hour week

22

Continuous Integration (CI)Maintain a single source repository Automate the build Make your build self-testingEveryone commits every dayEvery commit should build the mainline on an Integration

machineKeep the build fastTest in a clone of the production environmentMake it easy for anyone to get the latest executableEveryone can see what's happeningAutomate deployment

Related Article: Continuous Integration – Martin Fowler

23

Steps to do for CI with a Source ControlDev begins by taking a copy of current integrated source onto local

dev machine: Check out from Source ControlDev 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: TestingAll code should have Unit TestsAll 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 & HumanSeat togetherWhole team approachInformative workspaceEnergized WorkPair ProgrammingTeam Continuity

26

ResourcesExtreme Programming Explained: Embrace

Change – Kent Beck (Ver 1 and 2)Apress Pro .NET 2.0 Extreme Programming

ebookRefactoring: Improving the Design of Existing

Code - Matrin Fowler, Kent Beck …Agile Project Management with Scrum - Ken

Schwaber www.ExtremeProgramming.orgwww.AgileManifesto.org http://www.xprogramming.com