agile practices - extreme programming
Post on 17-Jan-2015
6.329 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
top related