CSC/ECE 517 Fall 2011/ch6 6d sk

The Agile Landscape

Overview

Traditionally, software has been developed using rigid methodologies such as the Waterfall method of software development. The Waterfall methodology is a set of stages such as - Analysis, Design, Implementation, Testing and Maintenance. These stages follow a strictly linear sequence as mentioned in the last sentence. This method works perfectly well when a project is completely planned, but it has been observed that it is not always the case. The waterfall model is not capable to handle changes requested by the customers when the project has gone deep into the pipeline. In such cases, all the processes have to be followed to incorporate the requested changes, which consumes time and costs dearly to the customer.

Developers who were facing this problem more often started to realize that real world tends to have quite an impact on the development of any process or product. It was time to have a new strategy for software development which was capable enough to overcome the shortcomings of traditional software development methodologies. There are various such methodologies which provide fast and iterative development, ability to handle late changes in requirements and many more features. These methodologies are collectively called as Agile Software Development Methodologies.

The following article provides a brief introduction to Agile Software Development, the various methodologies for agile development, their comparison and some statistics to demonstrate the acceptance and the success rates of agile methodologies.

Introduction to Agile Software Development

In 1990's, software developers started to realize that a planned waterfall approach for software development had many shortcomings and did not facilitate speedy and flexible software development. There were many efforts to devise new methodologies which overcame those shortcomings. These methodologies were called the Agile Methodologies for software development. They allowed developers to adapt to the changes in demands during software development as well as incorporate future changes to the software during any stage of software development.

The agile methodologies are based on iterative and incremental development. In organizations who follow agile development, requirements for a product are formed mainly through collaboration between small teams which are cross-functional and self-organizing. It allows the process of software development to be iterative, time bound, adaptive, evolutionary and flexible. A team learns how to be Agile in the environment provided by the Agile processes. There is more importance to how a team works together, allowing teams to work in a cohesive fashion, increasing the productivity many times. The increase in productivity is such as a team can provide a working software in the first week, and then improve with subsequent iterations.

Agile Manifesto

n February 2001, a group of software developers, interested in developing new lightweight methodologies for software development, published the Manifesto for Agile Software Development. The Agile Manifesto forms the core of agile software development. The manifesto reads as follows: [1]

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The text in bold face are the main terms used in the Manifesto. We describe each of them below: [2]

Individuals and Interactions: Agile methodologies are focused on individuals and interactions between them. They have more emphasis on self-organization and motivation and are based on the principles of co-location and pair-programming.

Working Software: A working software developed quickly will be useful rather than presenting documents to customers

Customer Collaboration: It is not possible to fully gather requirements at the beginning of a software development cycle. so it is important to keep the customer involved during the development process and receive their feedback

Responding to change: Quickly respond to changes in requirements through continuous iterative development process.

If you believe in and endorse the Agile Manifesto, you can become a signatory here.

Principles of Agile Manifesto

The supporters of Agile Manifesto follow the 12 principles mentioned below:[3]

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

• Business people and developers must work together daily throughout the project.

• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

• Working software is the primary measure of progress.

• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

• Continuous attention to technical excellence and good design enhances agility.

• Simplicity--the art of maximizing the amount of work not done--is essential.

• The best architectures, requirements, and designs emerge from self-organizing teams.

• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Agile Methodologies

Extreme Programming

XP Process Model

Extreme programming (XP) is a popular approach to agile software development and was created by Kent Beck in 1996. XP is defined by a set of five values that establish a foundation for all work performed as part of development process. These five values are communication, simplicity, feedback, courage, and respect. Each individual value serves as a driver for specific activities, actions, and tasks.

• Communication - XP emphasize close, yet informal communication between customers and developers. This helps ensure effective communication between software engineers and other stakeholders.
• Simplicity - In order to achieve simplicity, XP requires developers to design only for the immediate needs of the project. This results in a simple design that can be implemented easy.
• Feedback - Feedback is received from three sources: software tests, the customer, and other software team members.
• Courage - In order to adhere to certain XP practices, Beck states that is requires courage.
• Respect - By following the other four values, an agile team will develop respect among its members and other stakeholder. As the team begins to achieve success in their delivery of software increments, they will also develop respect for the XP process itself.

XP consists of four framework activities: planning, design, coding, and testing as seen in the figure to the right. Each phase is summarized in the paragraphs that follow.

• Planning - The initial phase of the process involves the planning game. It is a requirements gathering activity that enables the members of the team to understand the business context for the software and involves listening to the customer. This leads to the creation of a set of user stories that describe the required output, features, and functionality of the software. Each story written by the customer is written on a index card and assigned a value based on its overall business value. Members of the team will then determine a cost (measured in weeks) for each story based on their estimation for how much work would be required to implement the story. The customers and developers will then work together to determine which group of stories will be implemented in the next iteration of the software.
• Design - The design phase of the process involves the creation of a simple design of the system and also provides implementation guidance for each story to be included in the iteration.
• Coding - After a preliminary design for the system is created, the team will then develop a set of unit tests for the system. These tests will serve as guidelines for the developers to focus only on getting the tests to pass and nothing more. One of the defining aspects of XP, involves the pair programming concept. XP recommends that two programmers should work together at one computer workstation to develop code. One person writes the code, while the other will watch and provide feedback. After a period of time, the two programmers will switch their roles.
• Test - In order to place an emphasize on tests, the unit tests generated during the code phase are ran anytime the code is modified to ensure no problems exist in the codebase.

Scrum

Scrum Process Model

Scrum (derived from a term used in rugby) is an agile process created by Jeff Sutherland in the early 1990s. The basic principles of Scrum are consistent with the Agile Manifesto and serve to guide development. Some of the distinguishing features of Scrum include:

• Work occurs in “sprints” and is derived from a “backlog” of existing requirements
• Testing and documentation are on-going as the product is constructed
• Meetings are very short and sometimes conducted without chairs
• Product demonstrations are delivered to the customer with the time-box allocated

The overall flow of the Scrum process is illustrated in the diagram to the right. Scrum emphasizes the use of a set of software process patterns that have proven effective for projects with tight timelines, changing requirements, and business criticality.

The defining characteristics of Scrum include:

• Product Backlog - A list of project features that provide business value for the customer. New requirements can be added to the backlog at any time. The project manager is responsible for accessing the backlog and updating the priority of each individual requirement.
• Sprint Backlog - Each iteration of the process (called a Sprint) involves choosing a subset of the product backlog that will be implemented.
• Sprint - A typical sprint occurs over a 30 day time-box and involves the implementation of requirements currently in the sprint backlog
• Scrum Meetings - Every 24 hours, the project team will hold a meeting to discuss three key questions; what did you do since the last team meeting?, what obstacles are you encountering?, what do you plan to accomplish by the next team meeting?
• Release - At the end of each sprint, a working iteration of the software is release to the customer to evaluate. Any new features requested will then be entered into the product backlog for another iteration of the software.

Dynamic Systems Development Method

DSDM Process Model

The Dynamic Systems Development Method (DSDM) is another agile software process that "provides a framework for building and maintaining systems which meet tight time constraints through the use of incremental prototyping in a controlled project environment." DRDM is an iterative process which follows the 80 percent rule, meaning that 80 percent of an application can be delivered in 20 percent of the time it would take to deliver the complete application.

DSDM defining characteristics include:

• Feasibility study
• Business Study
• Functional Model Iteration
• Design and Build iteration
• Implementation

Crystal

Choosing a Crystal Methodology

The Crystal family of agile methods were create by Alistair Cockburn and Jim Highsmith. The main goal was to achieve a software development approach that puts an emphasize on "maneuverability" during "a resource-limited, cooperative game of invention and communication, with a primary goal of delivering useful, working software and a secondary goal of setting up for the next game."

Crystal includes:

• A family of methods to choose from (based on needs)
• Colocation to facilitate constant communication
• Frequent code delivery