Agile Practices - eXtreme Programming

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

0 comments

Post a comment

    Post a comment
    Embed Video
    Edit your comment Cancel

    1 Favorite

    Agile Practices - eXtreme Programming - Presentation Transcript

    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.
    9. 9
      XP Values, Principles & Practices
      • Principles are bridge between Values, which is synthetic and abstract, and Practices, which tell how to actually develop software.
      Values
      Practices
      Principles
      • Planning Game
      • Short Release
      • Continuous Integration
      • Simple Design
      • Pair Programming
      • Communication
      • Simplicity
      • Feedback
      • Humanity
      • Improvement
      • Quality
      • Accepted Responsibility
    10. 10
      Core Values of XP
      Communication
      Problems with projects can invariably be traced back to somebody not talking to somebody else about something
      Simplicity
      Do the simplest thing that could possibly work
      Feedback
      Should always be able to measure the system and to know how far it is from the needed features
      Concrete 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
      Courage
      Respect
    11. 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
    12. 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
    13. 13
      XP Practices (Rules)
      • Planning related practices
      • Design related practices
      • Coding/Programming/Release related practices
      • Testing related practices
      • General/Human practices
      http://www.xprogramming.com/Practices/xpractices.htm
      http://www.extremeprogramming.org/rules.html
    14. 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
    15. 15
      Planning Game
      • Neither 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
      • Scope
      • Priority
      • Composition of releases
      • Date of releases
      • Technical people decide about
      • Estimates
      • Consequences
      • Process
      • Detailed Scheduling
    16. 16
      Daily Standup Meeting
      Problem:
      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 mins
      A 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. 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
    18. 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
    19. 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
    20. 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
    21. 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
    22. 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
    23. 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
    24. 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.
    25. 25
      XP Practices: Team & Human
      Seat together
      Whole team approach
      Informative workspace
      Energized Work
      Pair Programming
      Team Continuity
    26. 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

    + Aniruddha ChakrabartiAniruddha Chakrabarti, 4 months ago

    custom

    742 views, 1 favs, 0 embeds more stats

    Introduction to Agile Methodologies and specially t more

    More info about this document

    © All Rights Reserved

    Go to text version

    • Total Views 742
      • 742 on SlideShare
      • 0 from embeds
    • Comments 0
    • Favorites 1
    • Downloads 55
    Most viewed embeds

    more

    All embeds

    less

    Flagged as inappropriate Flag as inappropriate
    Flag as inappropriate

    Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

    Cancel
    File a copyright complaint
    Having problems? Go to our helpdesk?

    Categories