13 terms

Extreme Programming Practices


Terms in this set (...)

Planning Game
The purpose of the Planning Game is to guide the product into delivery. Instead of predicting the exact dates of when deliverables will be needed and produced, which is difficult to do, it aims to "steer the project" into delivery using a straightforward approach
Pair Programming
The pairs are not fixed; programmers switch partners frequently, so that everyone knows what everyone is doing, and everybody remains familiar with the whole system, even the parts outside their skill set. This way, pair programming also can enhance team-wide communication
Small Releases
The delivery of the software is done via frequent releases of live functionality creating concrete value. The small releases help the customer to gain confidence in the progress of the project. This helps maintain the concept of the whole team as the customer can now come up with his suggestions on the project based on real experience.
Collective Code Ownership
Collective code ownership means that everyone is responsible for all the code; this, in turn, means that everybody is allowed to change any part of the code
The system metaphor is a story that everyone - customers, programmers, and managers - can tell about how the system works.
Continuous Integration
The development team should always be working on the latest version of the software. Since different team members may have versions saved locally with various changes and improvements, they should try to upload their current version to the code repository every few hours, or when a significant break presents itself. Continuous integration will avoid delays later on in the project cycle, caused by integration problems.
Simple Design
Programmers should take a "simple is best" approach to software design. Whenever a new piece of code is written, the author should ask themselves 'is there a simpler way to introduce the same functionality?'. If the answer is yes, the simpler course should be chosen
Sustainable Pace
The concept is that programmers or software developers should not work more than 40 hour weeks
Test-Driven Development
Within XP, unit tests are written before the eventual code is coded. This approach is intended to stimulate the programmer to think about conditions in which his or her code could fail. XP says that the programmer is finished with a certain piece of code when he or she cannot come up with any further condition on which the code may fail.
Whole Team
XP says that the customer should be on hand at all times and available for questions. For instance, the team developing a financial administration system should include a financial administrator.
Code refactoring is a "disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior" undertaken in order to improve some of the nonfunctional attributes of the software
Coding standard
Coding standard is an agreed upon set of rules that the entire development team agree to adhere to throughout the project
XP Criticisms
Cannot be scaled to large problems. Relies on generalists. Quality is only tested through testing, needs management support