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.

SCRUM Methodology

Scrum is an iterative incremental process of software development commonly used with agile software development
Characteristics

Scrum is a process skeleton that includes a set of practices and predefined roles. The main roles in Scrum are the ScrumMaster who maintains the processes and works similarly to a project manager, the Product Owner who represents the stakeholders, and the Team which includes the developers.
During each sprint, a 15-30 day period (length decided by the team), the team creates an increment of potentially shippable (usable) software. The set of features that go into each sprint come from the product backlog, which is a prioritized set of high level requirements of work to be done. Which backlog items go into the sprint is determined during the sprint planning meeting. During this meeting the Product Owner informs the team of the items in the product backlog that he wants completed. The team then determines how much of this they can commit to complete during the next sprint.[1] During the sprint, no one is able to change the sprint backlog, which means that the requirements are frozen for a sprint.
Scrum enables the creation of self-organizing teams by encouraging co-location of all team members, and verbal communication across all team members and disciplines that are involved in the project.
A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Scrum adopts an empirical approach – accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team's ability to deliver quickly and respond to emerging requirements.
There are several implementations of systems for managing the Scrum process which range from yellow stickers and white-boards to software packages. One of Scrum's biggest advantages is that it is very easy to learn and requires little effort to start using.

Roles
Scrum has three fundamental roles: Product Owner, ScrumMaster, and team member.

• Product Owner: In Scrum, the Product Owner is responsible for communicating the vision of the product to the development team. He or she must also represent the customer’s interests through requirements and prioritization. Because the Product Owner has the most authority of the three roles, it’s also the role with the most responsibility. In other words, the Product Owner is the single individual who must face the music when a project goes awry. The tension between authority and responsibility means that it’s hard for Product Owners to strike the right balance of involvement. Because Scrum values self-organization among teams, a Product Owner must fight the urge to micro-manage. At the same time, Product Owners must be available to answer questions from the team.
• ScrumMaster: The ScrumMaster acts as a liaison between the Product Owner and the team. The ScrumMaster does not manage the team. Instead, he or she works to remove any impediments that are obstructing the team from achieving its sprint goals. In short, this role helps the team remain creative and productive, while making sure its successes are visible to the Product Owner. The ScrumMaster also works to advise the Product Owner about how to maximize ROI for the team.
• Team Member: In the Scrum methodology, the team is responsible for completing work. Ideally, teams consist of seven cross-functional members, plus or minus two individuals. For software projects, a typical team includes a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers. Each sprint, the team is responsible for determining how it will accomplish the work to be completed. This grants teams a great deal of autonomy, but, similar to the Product Owner’s situation, that freedom is accompanied by a responsibility to meet the goals of the sprint.