-
XP Practices and Principles
XP is made up of a set of twelve practices that can be used independently, but are far more powerful when used in concert.
Let's take a look at how these practices relate to the iterative development process.
1. Planning Game: The planning game captures the features of the system as user stories, and defines the releases of the project. During iteration planning, user stories selected for the iteration are broken down into development tasks.
2. System Metaphor: When communicating with the business, it helps to have a ubiquitous language so that complex systems can be explained easily.
3. Simple Design: High-level system design occurs at the start and during an iteration.
4. On-Site Customer: During an iteration, it is ideal for the customer to be on-site to aid in quickly answering details of a user story. While physical meetings are ideal, virtual meetings are better than no meeting at all. The important point is to have an available customer who can quickly provide answers as the developers explore the details of a user story.
5. Team Sitting Together: It’s important for all of the team committed to the project to be within shouting distance of each other. This improves communication and imparts a feeling of camaraderie.
6. Pair Programming: Pair programming is a development practice that pairs developers so that they can work on a problem together. A pair will share a development machine, and while one codes, the other will assist with design decisions and look ahead to the next feature. With pair programming, code reviews become “real time,” producing a level of quality that “inspection-only” cannot. With two people developing, it's highly unlikely that they will both overlook the same mistake.
7. Collective Code Ownership: Through sitting together and pair programming, the entire team shares a collective ownership of the code base. All developers are allowed to fix and work on any part of the code base.
8. Coding Standards: To help with collective ownership, best practices are used to keep a simple design and ensure all code is created in a consistent manner. This ensures that source code can be understood quickly when working on any part of the system and with any other developer.
9. Testing: To ensure quality is delivered to the customer, emphasis is placed on testing through the XP process. Testing starts by identifying acceptance criteria from user stories. These acceptance criteria are used to write unit tests and start development in TDD style. User acceptance testing also derives from the acceptance criteria and will be automated as much as possible.
10. Continuous Integration: To ensure that all of the code that the team is collectively developing actually works, the team integrates often and early. A continuous integration (CI) server will pull the code base from a source control repository, build it, and run all the automated tests to ensure the build is not broken. The publicly published output of the CI server can be notified instantly to developers, customers, and project managers. This report includes the number of tests that are pass/fail at this point. Daily tracking provides an indicator of progress in creating customer value. This quick feedback loop also
enables developers to fix the build. The sooner an issue is identified, the cheaper it is to fix.
11. Sustainable Pace: Because of the short release cycles and the iterative nature of XP, requirements gathering, design, development, testing, and deploying all happen often. This means that issues found after review and testing can be incorporated into the next iteration. This quick feedback model ensures that developers can work at a sustainable pace. Thus, they save long weeks compared to more traditional development methodologies that have clearly defined stages for the development life-cycle, leaving feedback and testing until the end. Sustainable pace also helps management to plan more efficiently for staff holidays, unplanned absences, and the occasional production “fire” that needs to be extinguished immediately.
12. Small Releases: XP is all about customer satisfaction and delivering business value through quality software. As far as the business is concerned, the more often this can happen, the better. XP promotes frequent releases, which may be relatively small, but highlights the features prioritized by the business. XP does not allow the development team to go into hiding for months on end, hoping that the project completes on time. This transparency of frequent releases encourages customers by showing them the team is adding value to the project all along the way.
Each of these twelve practices forms the practical application of XP, which realizes the five values discussed in the previous section.
The remainder of this chapter will take a more detailed look at the twelve XP practices, starting with project planning.
Source of Information : Pro Agile .NET Development with SCRUM
Subscribe to:
Post Comments (Atom)
0 comments: