Agile Practices - eXtreme Programming

8,725 views

Published on

Introduction to Agile Methodologies and specially to XP (Extreme Programming)

Published in: Technology
0 Comments
9 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
8,725
On SlideShare
0
From Embeds
0
Number of Embeds
86
Actions
Shares
0
Downloads
451
Comments
0
Likes
9
Embeds 0
No embeds

No notes for slide

Agile Practices - eXtreme Programming

  1. 1. 1<br />Extreme Programming<br />How Agile Practices can make the difference<br />AniruddhaChakrabarti<br />Sr. Solution Architect<br />
  2. 2. 2<br />Agenda<br />Agile Methodology<br />Agile Manifesto & Agile Philosophy<br />Different Agile methodologies<br />Extreme Programming/XP<br />Brief History of XP<br />XP Values, Principles and Practices<br />Core XP Values<br />XP Principles<br />Different XP Practices<br />
  3. 3. 3<br />Agile Methodology<br />Definition of Agile:<br />Characterized by quickness, lightness, and ease of movement; nimble. <br />Mentally quick or alert: an agile mind.<br />Agile Methodology promotes: <br />Project management process that encourages frequent inspection and adaptation; <br />Leadership philosophy that encourages team work, self-organization and accountability; <br />Set of engineering best practices that allow for rapid delivery of high-quality software; <br />Business approach that aligns development with customer needs and company goals. <br />
  4. 4. 4<br />Agile Philosophy: Agile Manifesto<br />We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:<br />Individuals and interactionsoverprocesses and tools<br />Working softwareovercomprehensive documentation<br />Customer collaborationover contract negotiation<br />Responding to changeoverfollowing a plan<br />That is, while there is value in the items on the right, we value the items on the left more.<br />Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn<br />Ward Cunningham Martin Fowler James Grenning Jim Highsmith<br />Andrew Hunt Ron Jeffries Jon Kern Brian Marick<br />Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland<br />Dave Thomas<br />www.AgileManifesto.org, http://AgileManifesto.org/history.html<br />
  5. 5. 5<br />Agile Philosophy<br />Individuals and interactions over processes and tools<br />Software without documentation is a disaster. Code is not the ideal medium for communicating the rationale and structure of a system<br />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.<br />Working software over comprehensive documentation<br />Software without documentation is a disaster. Code is not the ideal medium for communicating the rationale and structure of a system<br />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.<br />Customer collaboration over contract negotiation<br />Responding to change over following a plan<br />
  6. 6. 6<br />Different Agile Methodologies<br />Extreme Programming / XP (Kent Beck, Ward Cunningham, Martin Fowler, Ron Jeffries)<br />Scrum (Ken Schwaber, Jeff Sutherland)<br />Crystal (Alistair Cockburn)<br />DSDM<br />Lean Software Development<br />Feature Driven Development / FDD (Peter Coad)<br />XBreed<br />Adaptive Software Development / ASD (Jim Highsmith)<br />
  7. 7. 7<br />What is Extreme Programming (XP)<br />XP is actually a deliberate and disciplined approach to software development.<br />Discipline of software development based on Values of simplicity, communication, feedback, and courage. <br />Works by - <br />Bringing the whole team together in the presence of simple practices<br />Enough feedback to enable the team to see where they are and to tune the practices to their unique situation. <br />Proven at companies like Bayerische Landesbank, Credit Swiss Life, DaimlerChrysler, First Union National Bank, Ford Motor Company and UBS.<br />Empowers developers to confidently respond to changing customer requirements, even late in life cycle.<br />
  8. 8. 8<br />Agile & XP: A bit of History<br />Agile software development evolved in mid-90s as part of a reaction against &quot;heavyweight&quot; methods.<br />Initially they were called &quot;lightweight methods”.<br />In 2001, prominent members of the community met at Snowbird, Utah, and adopted the name &quot;agile methods&quot;.<br />Root of XP lies in Smalltalk community<br />Early 90s: Kent Beck and Ward Cunningham came up with an approach to software development that made every thing simple and more efficient.<br />Mar 96: Kent started Chrysler Comprehensive Compensation/C3) at DaimlerChrysler using new concepts in software development.<br />The result was Extreme Programming (XP) methodology.<br />
  9. 9. 9<br />XP Values, Principles & Practices<br /><ul><li>Principles are bridge between Values, which is synthetic and abstract, and Practices, which tell how to actually develop software. </li></ul>Values<br />Practices<br />Principles<br /><ul><li>Planning Game
  10. 10. Short Release
  11. 11. Continuous Integration
  12. 12. Simple Design
  13. 13. Pair Programming
  14. 14.
  15. 15. Communication
  16. 16. Simplicity
  17. 17. Feedback
  18. 18.
  19. 19. Humanity
  20. 20. Improvement
  21. 21. Quality
  22. 22. Accepted Responsibility
  23. 23. …</li></li></ul><li>10<br />Core Values of XP<br />Communication<br />Problems with projects can invariably be traced back to somebody not talking to somebody else about something<br />Simplicity<br />Do the simplest thing that could possibly work<br />Feedback<br />Should always be able to measure the system and to know how far it is from the needed features<br />Concrete feedback early and often from the customer, from the team, and from real end users gives you more opportunity to steer your efforts<br />Close customer contact & availability of automated tests<br />Courage<br />Respect<br />
  24. 24. 11<br />Basic Fundamental Principles<br />Rapid Feedback<br />Assume Simplicity<br />Make Incremental Change<br />Embracing Change<br />Quality Work<br />www.AgileManifesto.org/principles.html<br />http://en.csharp-online.net/Introducing_XP%E2%80%94Fifteen_XP_Principles<br />
  25. 25. 12<br />Further Principles<br />Teach Learning <br />Make a Small Initial Investment <br />Play to Win – do what is required to succeed <br />Concrete Experiments – use proper reports <br />Open, honest Communication <br />Work with people&apos;s instincts - not against them <br />Accepted Responsibility <br />Local Adaptation / Accept as Necessary<br />Travel Light<br />Honest Measurement <br />
  26. 26. 13<br />XP Practices (Rules)<br /><ul><li>Planning related practices
  27. 27. Design related practices
  28. 28. Coding/Programming/Release related practices
  29. 29. Testing related practices
  30. 30. General/Human practices</li></ul>http://www.xprogramming.com/Practices/xpractices.htm<br />http://www.extremeprogramming.org/rules.html<br />
  31. 31. 14<br />XP Practices: Planning<br />User Stories<br />Functionalities of the system are described using stories, short descriptions of customer-visible functionalities<br />Planning Game/Release Planning<br />Small & Short Releases<br />Every release should be as small as possible, containing the most valuable business requirements.<br />It is far better to plan a month or two at a time than six months or a year at a time<br />Iterative Development<br />Daily Standup meeting<br />
  32. 32. 15<br />Planning Game<br /><ul><li>Neither business considerations nor technical considerations should be paramount.
  33. 33. Software development is always an evolving dialog between the possible and the desirable.
  34. 34. Business people decide about
  35. 35. Scope
  36. 36. Priority
  37. 37. Composition of releases
  38. 38. Date of releases
  39. 39. Technical people decide about
  40. 40. Estimates
  41. 41. Consequences
  42. 42. Process
  43. 43. Detailed Scheduling</li></li></ul><li>16<br />Daily Standup Meeting<br />Problem: <br />Typical project meeting - most attendees do not contribute, but attend just to hear the outcome. <br />Large amount of developer time is wasted to gain a trivial amount of communication. <br />Having many people attend every meeting drains resources from the project and also creates a scheduling nightmare.<br />Solution: <br />Short and brief standup (no one seats to keep it short)<br />Should be less than 15 mins<br />A stand up meeting every morning is used to communicate problems, solutions, and promote team focus. <br />Not a Status Reporting Meeting<br />It&apos;s Not Just Standing Up: Patterns of Daily Stand-up Meetings – Jason Yip<br />
  44. 44. 17<br />Daily Standup Meeting (Cont’d)<br />Everyone answers three questions – <br />What did I accomplish yesterday? <br />What will I do today? <br />What obstacles are impeding my progress?<br />Focus on the Backlog <br />Same Place, Same Time <br />Who attends the daily stand-up? – All Hands<br />Time-box the meeting<br />Last Arrival Speaks First<br />
  45. 45. 18<br />XP Practices: Designing<br />Simple Design (avoid YAGNI)<br />System Metaphor<br />CRC Cards: Class, Responsibility, Collaborator<br />Spike Solutions<br />No functionality is added early<br />Design Improvement / Refactoring<br />Related Article: Is Design Dead? – Martin Fowler<br />
  46. 46. 19<br />Simple Design<br />Misconception about XP: XP advices to avoid design<br />Truth: XP advices <br />Avoid too much Up Front Design / extra design at early phase, as requirement is not clear – Evolutionary Approach <br />Simple and elegant design<br />Runs all the tests.<br />Has no duplicated logic. Be wary of hidden duplication like parallel class hierarchies.<br />States every intention important to the programmers.<br />Has the fewest possible classes and methods.<br />Avoid over design<br />Avoid design that would not be required: YAGNI<br />
  47. 47. 20<br />CRC Cards<br />Used to identify Classes, Responsibilities and Collaborations between objects.<br />Created from index cards with these info - <br />Class name <br />Its Super and Sub classes (if applicable) <br />Responsibilities of the class. <br />Names of other classes with which the class will collaborate to fulfill its responsibilities. <br />Author<br />Related Article: http://c2.com/doc/oopsla89/paper.html<br />Using CRC cards – Alistair Cockburn<br />http://www.extremeprogramming.org/rules/crccards.html<br />
  48. 48. 21<br />XP Practices: Coding/Release<br />Onsite Customer: Customer is always available<br />Coding Standards<br />Test Driven Development (TDD): code unit tests first<br />Pair Programming<br />Continuous Integration (CI)<br />Ten-minute build<br />Daily Deployment<br />Collective Code Ownership<br />Sustainable Pace: 40-hour week<br />
  49. 49. 22<br />Continuous Integration (CI)<br />Maintain a single source repository <br />Automate the build <br />Make your build self-testing<br />Everyone commits every day<br />Every commit should build the mainline on an Integration machine<br />Keep the build fast<br />Test in a clone of the production environment<br />Make it easy for anyone to get the latest executable<br />Everyone can see what&apos;s happening<br />Automate deployment<br />Related Article: Continuous Integration – Martin Fowler<br />
  50. 50. Steps to do for CI with a Source Control<br />23<br />Dev begins by taking a copy of current integrated source onto local dev machine: Check out from Source Control<br />Dev makes the necessary changes - It consist of both altering the code, and also adding or changing automated tests. <br />Dev carries out an automated build on dev machine - takes source code in working copy, compiles and runs the automated tests. <br />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. <br />Once dev have made his own build of a properly synchronized working copy he can finally commit changes into the mainline <br />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 <br />
  51. 51. 24<br />XP Practices: Testing<br />All code should have Unit Tests<br />All code must pass all unit tests before it can be released.<br />When a bug is found tests are created.<br />Unit Tests and Acceptance tests are run often and the score is published. <br />
  52. 52. 25<br />XP Practices: Team & Human<br />Seat together<br />Whole team approach<br />Informative workspace<br />Energized Work<br />Pair Programming<br />Team Continuity <br />
  53. 53. 26<br />Resources<br />Extreme Programming Explained: Embrace Change – Kent Beck (Ver 1 and 2)<br />Apress Pro .NET 2.0 Extreme Programming ebook<br />Refactoring: Improving the Design of Existing Code - Matrin Fowler, Kent Beck …<br />Agile Project Management with Scrum - Ken Schwaber  <br />www.ExtremeProgramming.org<br />www.AgileManifesto.org<br />http://www.xprogramming.com<br />

×