Lecture 3: XP

*Incremental Planning*

- Requirements are recorded on story cards - Stories to be included in a release are determined by the time available and their relative priority. - The developers break these stories into development 'Tasks'.

*Scenarios*

- Scenarios are written on cards. - The development team break them down into *implementation tasks.* - These tasks are the *basis of schedule and cost estimates.* - The customer chooses the stories for inclusion in the next release *based on their priorities and the schedule estimates.*

*Testing Features of XP

- Test-first development. - Incremental test development from scenarios. - User involvement in test development and validation. - Automated test harnesses are used to run all component tests each time that a new release is built.

*Test-first development*

- Writing tests before code clarifies the requirements to be implemented. - Tests are written as programs rather than data so that they can be executed automatically. - All previous and new tests are run automatically when new functionality is added, thus checking that the new functionality has not introduced errors.

*Continuous integration*

As soon as the work on a task is complete, it is integrated into the whole system. After any such integration, all the unit tests in the system must pass.

*Describe the XP approach*

- New versions may be built several times per day; - Increments are delivered to customers every 2 weeks; - All tests must be run for every build and the build is only accepted if tests run successfully. - Maintaining simplicity through constant refactoring of code.

*XP testing difficulties*

- Programmers get lazy at testing phase - Some tests are difficult to write incrementally. - It is difficult to judge the completeness of a set of tests.

*Pair Programming*

- Programmers sit together at the same workstation to develop the software. - The sharing of knowledge is very important as it reduces the overall risks to a project when team members leave. - Pair programming is not necessarily inefficient and there is evidence that a pair working together is more efficient than 2 programmers working separately.

*Refactoring*

- Programming team look for possible software improvements and make these improvements even where there is no immediate need for them. - Some changes requires architecture refactoring and this is much more expensive.

*Practices of XP*

1. Incremental Planning 2. Small Releases 3. Simple Design 4. Test-first Development 5. Refactoring 6. Pair Programming 7. Collective Ownership 8. Continuous Integration 9. Sustainable Pace 10. On-site customer

*Advantages of Pair Programming*

1. It supports the idea of collective ownership and responsibility for the system. 2. It acts as an informal review process because each line of code is looked at by at least two people. 3. It helps support refactoring, which is a process of software improvement.

*Role of Customer in XP*

In XP, a customer or user is part of the XP team. S/He is responsible for making decisions on requirements, which are expressed as scenarios or user stories.

*Collective Ownership*

No islands of expertise develop and all the developers take responsibility for all of the code. Anyone can change anything.

*What is Test Automation?*

Test are written as executable components before the task is implemented. These testing components should be stand-alone, should simulate the submission of input to be tested and should check that the result meets the output specification.

*Responsibility of software project managers*

The principal responsibility of software project managers is to manage the project so that the *software is delivered on time and within the planned budget for the project.* *Standard approach to PM is plan-driven*

*Customer Involvement in Testing*

The role of the customer in the testing process is to *help develop acceptance tests for the successive stories.* The customer who is part of the team writes tests as development proceeds. Usually customers are reluctant to be involved in testing phase.

*XP approach to change*

XP maintains that it is not worthwhile to design for change as changes cannot be reliably anticipated. Rather, it proposes constant code improvement (refactoring) to make changes easier when they have to be implemented