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

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

2. 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. 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. 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. 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. 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. 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. 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.

10. Short Release

11. Continuous Integration

12. Simple Design

13. Pair Programming

14. …

15. Communication

16. Simplicity

17. Feedback

18. …

19. Humanity

20. Improvement

21. Quality

22. Accepted Responsibility

24. 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

25. 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

27. Design related practices

28. Coding/Programming/Release related practices

29. Testing related practices

30. General/Human practiceshttp://www.xprogramming.com/Practices/xpractices.htm http://www.extremeprogramming.org/rules.html

31. 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

33. Software development is always an evolving dialog between the possible and the desirable.

34. Business people decide about

35. Scope

36. Priority

37. Composition of releases

38. Date of releases

39. Technical people decide about

40. Estimates

41. Consequences

42. Process

44. 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

45. 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

46. 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

47. 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

48. 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

49. 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

50. 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

51. 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.

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

53. 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