Extreme Programming XP: Why? Previously: Get all the requirements before starting design Freeze the requirements before starting development Resist changes: they will lengthen schedule Build a change control process to ensure that proposed changes are looked at carefully and no change is made without intense scrutiny Deliver a product that is obsolete on release eXtreme Programming A system of practices that a community of software developers is evolving to address the problems of quickly delivering quality software, and then evolving it to meet changing business needs. eXtreme… Taking proven practices to the extreme If testing is good, let everybody test all the time If code reviews are good, review all the time If design is good, refactor all the time If integration testing is good, integrate all the time If simplicity is good, do the simplest thing that could possibly work If short iterations are good, make them really, really short XP values Communication Simplicity Feedback Courage XP practices The Planning Game* Collective Ownership Small Releases Continuous Integration Metaphor 40-Hour Week Simple Design* On-Site Customer Testing* Coding Standards Refactoring* Open workspace Pair Programming* Daily Schema migration XP: Embrace Change Recognize that: All requirements will not be known at the beginning Requirements will change Use tools to accommodate change as a natural process Do the simplest thing that could possibly work and refactor mercilessly Emphasize values and principles rather than process XP Practices (Source: http://www.xprogramming.com/xpmag/whatisxp.htm) XP Practices: Whole Team All contributors to an XP project are one team Must include a business representative--the ‘Customer’ Provides requirements Sets priorities Steers project Team members are programmers, testers, analysts, coach, manager Best XP teams have no specialists XP Practices: Planning Game Two key questions in software development: Predict what will be accomplished by the due date Determine what to do next Need is to steer the project Exact prediction (which is difficult) is not necessary XP Practices: Planning Game XP Release Planning Customer presents required features Programmers estimate difficulty Imprecise but revised regularly XP Iteration Planning Two week iterations Customer presents features required Programmers break features down into tasks Team members sign up for tasks Running software at end of each iteration XP Practices: Customer Tests The Customer defines one or more automated acceptance tests for a feature Team builds these tests to verify that a feature is implemented correctly Once the test runs, the team ensures that it keeps running correctly thereafter System always improves, never backslides XP Practices: Small Releases Team releases running, tested software every iteration Releases are small and functional The Customer can evaluate or in turn, release to end users, and provide feedback Important thing is that the software is visible and given to the Customer at the end of every iteration XP Practices: Simple Design Build software to a simple design Through programmer testing and design improvement, keep the software simple and the design suited to current functionality Not a one-time thing nor an up-front thing Design steps in release planning and iteration planning Teams design and revise design through refactoring, through the course of the project XP Practices: Pair Programming TDD Continuous Integration Design Improvement Collective Code Ownership Coding Standard Sustainable Pace XP Practices: Design Improvement Continuous design improvement process called ‘refactoring’: Removal of duplication Increase cohesion Reduce coupling Refactoring is supported by comprehensive testing--customer tests and programmer tests XP Practices: Collective Code Ownership Any pair of programmers can improve any code at any time No ‘secure workspaces’ All code gets the benefit of many people’s attention Avoid duplication Programmer tests catch mistakes Pair with expert when working on unfamiliar code XP Practices: Coding Standard Use common coding standard All code in the system must look as though written by an individual Code must look familiar, to support collective code ownership XP Practices: Sustainable Pace Team will produce high quality product when not overly exerted Avoid overtime, maintain 40 hour weeks ‘Death march’ projects are unproductive and do not produce quality software Work at a pace that can be sustained indefinitely TDD Test-driven development (TDD), also called test-driven design, is a method of software development in which unit testing is repeatedly done on source code. The concept is to "get something working now and perfect it later." After each test, refactoring is done and then the same or a similar test is performed again. The process is iterated as many times as necessary until each unit is functioning according to the desired specifications. Test-driven development is part of a larger software design paradigm known as Extreme Programming (XP). CONTD… Test-driven development can produce applications of high quality in less time than is possible with older methods. Proper implementation of TDD requires the developers and testers to accurately anticipate how the application and its features will be used in the real world. Problems are approached in an incremental fashion and tests intended for the same unit of code must often be done many times over. The methodical nature of TDD ensures that all the units in an application have been tested for optimum functionality, both individually and in synergy with one another. CONTD.. Because tests are conducted from the very beginning of the design cycle, time and money spent in debugging at later stages is minimized. Test-Driven Development Process • Add a Test • Run all tests and see if the new one fails • Write some code • Run tests and Refactor code • Repeat EXAMPLE Context of Testing • Valid inputs • Invalid inputs • Errors, exceptions, and events • Boundary conditions • Everything that might break Benefits of TDD It can lead to simple, elegant, modular code. It can help developers find defects and bugs earlier than they otherwise would and it’s a commonly held belief that a bug is cheaper to fix the earlier you find it. The tests can serve as a kind of live documentation and make the code much easier to understand. It’s easier to maintain and refactor code, your own and other programmer’s code. It can speed up development in the long term. It can encourage developers to think from an end user point of view. DISADVANTAGES OF TDD It necessitates a lot of time and effort up front which can make development feel slow to begin with. Focusing on the simplest design now and not thinking ahead can mean major refactoring requirements. It’s difficult to write good tests that cover the essentials and avoid the superfluous. It takes time and effort to maintain the test suite and it must be reconfigured for maximum value. If the design is changing rapidly then you’ll need to keep changing your tests. You could end up wasting a lot of time writing tests for features that are quickly dropped. Pair programming Pairing involves having two programmers working at a single workstation. One programmer “drives,” operating the keyboard, while the other “navigates,” watching, learning, asking, talking, and making suggestions. The theory is that pairing results in better designs, fewer bugs, and much better spread of knowledge across a development team, and therefore more functionality per unit time, measured over the long term. The two programmers switch roles frequently. While reviewing, the observer also considers the "strategic" direction of the work, coming up with ideas for improvements and likely future problems to address. This frees the driver to focus all of his or her attention on the "tactical" aspects of completing the current task, using the observer as a safety net and guide. Advantages: We were able able to develop better communication skills More ideas We were able to learn different perspectives from other people Disadvantages: Conflict and debate break out among the group Everyone has their own ideas and sometimes its difficult to collaborate the ideas Possibly one person does more than half of the work on the project Continuous Integration 31 The term 'Continuous Integration' originated with the Extreme Programming development process, as one of its original twelve practices. Although Continuous Integration is a practice that requires no particular tooling to deploy, we've found that it is useful to use a Continuous Integration server. The best known such server is CruiseControl What is Continuous Integration? Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated build to detect integration errors as quickly as possible. Why Continuous Integration? Integration is hard Effort increases exponentially with Number of components, Number of bugs, Time since last integration. Building a Feature with Continuous Integration • Begin by taking a copy of the current integrated source onto the local development machine. Do this by using a source code management system by checking out a working copy from the mainline. • Now take the working copy and