Agile Methodologies

The most widely used methodologies based on the agile philosophy are XP and Scrum. These differ in particulars but share the iterative approach described above.

Xp
XP stands for extreme programming. It concentrates on the development rather than managerial aspects of soft-ware projects. XP was designed so that organizations would be free to adopt all or part of the methodology.

XP development
XP projects start with a release planning phase, followed by several iterations, each of which concludes with user acceptance testing. When the product has enough features to satisfy users, the team terminates iteration and releases the software.Users write “user stories” to describe the need the software should fulill. User stories help the team to esti-mate the time and resources necessary to build the release and to deine user acceptance tests. A user or a representative is part of the XP team, so he or she can add detail to requirements as the software is being built. This allows requirements to evolve as both users and developers deine what the product will look like. To create a release plan, the team breaks up the development tasks into iterations. The release plan deines each iteration plan, which drives the development for that iteration. At the end of an iteration, users perform acceptance tests against the user stories. If they ind bugs, ixing the bugs becomes a step in the next iteration.Iterative user acceptance testing, in theory, can result in release of the software. If users decide that enough user stories have been delivered, the team can choose to terminate the project before all of the originally planned user stories have been implemented.

XP rules and concepts
Here are the most important concepts:
Integrate often. Development teams must integrate changes into the development baseline at least once aday. This concept is also called continuous integration.
Project velocity. Velocity is a measure of how much work is getting done on the project. This important metric drives release planning and schedule updates.
Pair programming. All code for a production release is created by two people working together at a single computer. XP proposes that two coders working together will satisfy user stories at the same rate as two coders working alone, but with much higher quality.
User story. A user story describes problems to be solved by the system being built. These stories must be written by the user and should be about three sentences long. User stories do not describe a solution, use technical language, or contain traditional requirements-speak, such as “shall” statements. Instead, a sample user story might go like this: Search for customers. The user tells the application to search for customers. The application asks the user to specify which customers. After the user speciies the search criteria, the applica-tion returns a list of customers meeting those criteria.

Because user stories are short and somewhat vague, XP will only work if the customer representative is on hand to review and approve user story implementations. This is one of the main objections to the XP meth-odology, but also one of its greatest strengths.

Scrum
In rugby, ‘scrum’ (related to “scrimmage”) is the term for a huddled mass of players engaged with each other to get a job done. In software development, the job is to put out a release. Scrum for software development came out of the rapid prototyping community because prototypers wanted a methodology that would sup-port an environment in which the requirements were not only incomplete at the start, but also could change 5rapidly during development. Unlike XP, Scrum methodology includes both managerial and development processes.

Scrum management
At the center of each Scrum project is a backlog of work to be done. This backlog is populated during the planning phase of a release and deines the scope of the release.
After the team completes the project scope and high-level designs, it divides the development process into a series of short iterations called sprints. Each sprint aims to implement a ixed number of backlog items.Before each sprint, the team members identify the backlog items for the sprint. At the end of a sprint, the team reviews the sprint to articulate lessons learned and check progress.
During a sprint, the team has a daily meeting called a scrum. Each team member describes the work to be done that day, progress from the day before, and any blocks that must be cleared. To keep the meetings short, the scrum is supposed to be conducted with everyone in the same room—standing up for the whole meeting.
When enough of the backlog has been implemented so that the end users believe the release is worth put-ting into production, management closes development. The team then performs integration testing, training, and documentation as necessary for product release.

Scrum development
The Scrum development process concentrates on managing sprints. Before each sprint begins, the team plans the sprint, identifying the backlog items and assigning teams to these items. Teams develop, wrap, review, and adjust each of the backlog items.

During development, the team determines the changes necessary to implement a backlog item. The team then writes the code, tests it, and documents the changes. During wrap, the team creates the executable necessary to demonstrate the changes. In review, the team demonstrates the new features, adds new backlog items, and assesses risk. Finally, the team consolidates data from the review to update the changes as necessary.

Following each sprint, the entire team—including management, users, and other interested parties—demonstrates progress from the sprint and reviews the backlog progress. The team then reviews the remaining backlog and adds, removes, or reprioritizes items as necessary to account for new information and understanding gathered during the sprint.

Scrum concepts
Here are a few of the most important concepts:
Burndown chart. This chart, updated every day, shows the work remaining within the sprint. The burndown chart is used both to track sprint progress and to decide when items must be removed from the sprint back-log and deferred to the next sprint.
Product backlog. Product backlog is the complete list of requirements—including bugs, enhancement requests, and usability and performance improvements—that are not currently in the product release.
Scrummaster. The ScrumMaster is the person responsible for managing the Scrum project. Sometimes it refers to a person who has become certiied as a ScrumMaster by taking ScrumMaster training.
Sprint backlog. Sprint backlog is the list of backlog items assigned to a sprint, but not yet completed. In common practice, no sprint backlog item should take more than two days to complete. The sprint backlog helps the team predict the level of effort required to complete a sprint.