Agile Software Development

Pair programming is one of the most known Extreme Programming practices. In essence it means creating the code in pairs trying to get multiple perspectives on the code created. One of the participants, called driver, types the code and thinks about the low level details. Another one, called navigator, thinks about what the typed code is for. The participants periodically switch roles. The definition of "low level" depends on the skills of the concrete pair and their experience in the subject area. For example, when using test-driven development the driver might be focused on the writing the production code, while the navigator could be thinking about how the next unit test should look like in order to change the system architecture in the desired direction.

In traditional software development the design phase happens in the beginning of the project, takes quite a long no-coding or little-coding time. At the end of the phase, the design is considered being more-or less frozen. It might sound logical to plan ahead in a detail, however, in the case of software only the final source code is the real design - any diagrams or descriptions can at best be the higher level design abstractions. Therefore attempts to fix the design well in advance often lead to the wrong assumption and sub-optimal solutions.

Test-First Programming (TFP) and its sometimes more known related practice Test-Driven Development(TDD)  are not very usual for the traditional software development cycle. Test-driven development simply means creating tests before writing the code they are supposed to test. A canonical test-driven cycle is as follows:

1. Write a test for the functionality you are going to implement
2. Write as little code as possible to make the test compile. Make sure that at this step the test fails
3. Write minimal or almost minimal code needed to make the test pass
4. Once the test passes, refactor the code to make it better, prettier or simpler. The test and other existing tests will guard against accidental functionality breaks during the refactoring process

Extreme programming weekly cycle is an efficient tool against over-planning that allows for focusing on implementing the top priority stories and getting the user feedback as soon as possible. While it is indeed important to deliver in small chunks of the high priority functionality, permanent work on the low level of detail can lead to the sub-optimization, when you might be polishing the already good enough product while loosing the opportunity to recognize the need for the completely new feature.

Weekly Cycle practice is a recommendation for reducing the short term planning period to one week. When developing software in the evolutionary way the architecture and design of the system under development are supposed to change. The high level decomposition usually stays intact for a reasonably long time, while low level details can get outdated often. The weekly cycle practice takes this fact into account and recommends for planning in detail for no longer, than a week.

Stories or User Stories is the XP practice of thinking about software in terms of units of customer-visible functionality. A canonical form of a user story looks like "As a <user-type> I want to a <goal> so that <reason>". For example, "As a Frequent Flier, I want to rebook a trip so that I save time when booking trips I take frequently" (from Mike Cohn's User Stories applied).

Values are the the roots of Extreme Programming stating what we like and not like. Principles guide applying the values to the realities of software development. Engineering and not so engineering practices compose the lowest and the most explicit layer of XP. These are known best ways of implementing the values and principles in the daily work. Primary practices are the ones that are useful on their own. Corollary practices are not so safe to start with and are best applied after most of the primary ones are implemented and there is a certain level of understanding the XP values and culture in the organization.

Integration is often one of the most difficult moments in software projects. In traditional waterfall development, the integration phase at the end of development can take a lot of time and reveal many design deficiencies. Things become easier if the organization adopts the practice of bi-weekly, weekly, or daily builds. The more frequently the system is built, tested, and verified, the earlier problems and deviations are found.

Advertisement:

Sit Together practice is one of the simplest to define and sometimes one of the most difficult to implement in eXtreme Programming. It namely means co-locating the whole team in a single room often called "war room". The idea behind it is to stimulate the information exchange by making it simple to just turn to the colleague and ask. Encouraging free conversation leads to the much quicker information exchange as tacit knowledge is transferred by gestures, information and buzz around.

Slack is one of the primary Extreme Programming practices, i.e. is one of those that can stand out and bring value on its own. Slack is a practice of of including in every plan a number of tasks or user stories that can be dropped if team runs out of time. The reason for including slack is to be honest and transparent about the workload estimation. Software production is always a new product development and every estimation is namely an estimation.

Advertisement: