User:NcsuOO517

Agile Software Development

Many software development teams are adopting the relatively new Agile process of development.

Purpose

The agile software development process is a relatively new process introduced in the 1990s [2]. The main purpose behind agile development is to address the inevitable changes that arise as the development process progresses. It consists of short iterations of development, encouraging feedback after each iteration so that requirements can be adjusted accordingly. "Agile is set up to strongly support garnering feedback and guiding the customer toward better understanding what they want and need" [1]. Consequently, the short iterations lead to lower risk and higher productivity in the development cycle [2].

Common Practices

Some common practices that are incorporated into the agile development process include, but are not limited to:

• Extreme Programming (XP) - XP includes such practices as iterative development, team continuity, shared code, and real customer involvement. More about XP
• Scrum - short, daily meetings held by all members of the team, in which each team member answers three questions:
  • What did I do yesterday?
  • What do I plan to do today?
  • What obstacles are standing in my way? [3]
• Retrospectives - held at every iteration meeting, this practice involves each team member writing on an index card. On one side they write what they think went well during the iteration; on the other, they write what they think did not go well. The cards are then passed around and read by each other member of the team, which leads to a discussion about what was said.
• Feature-driven development [3]
• Requirements analysis
• User stories - a story represents a feature that can be completed in one iteration. [3]
• Planning Poker - a practice held at each iteration meeting. Each team member holds a set of "poker" cards that have numbers on them, typically 1, 2, 3, 5, 8, 13, 20, 40, and 100. Team members use the cards to present their estimation of how many story points each user story will take to complete - 8 represents a full iteration. If there is disagreement in estimations, team members discuss why they chose the number they did, and a re-vote is taken. The process continues until the team members agree on an estimation number.
• Team velocities - represent the number of story points a team is able to complete in one iteration. The team velociy is used to decide how many points to assign for the next iteration, based on the "Yesterday's Weather" concept, or the idea that a velocity will remain consistent for every iteration.
• Release planning

To Agile or not to Agile?

Despite its growing popularity in the software industry, a recent study indicates that agile may not be right for everyone. When adhering to the strict principles of agile, teams reported the following disadvantages of the agile process:

• Lack of customer involvement - made gathering requirements extremely difficult, leading to loss of productivity and rework.
• Contract negotiation problems - many customers want a "fixed deadline, fixed price, and fixed scope." Agile embraces change, which isn't possible with a fixed price project.
• Conflicts with design-intensive projects - due to this type of projects implementation, which basically starts with a full set of requirements, it was difficult to implement all aspects of agile.
• Superficial documentation - agile doesn't put much emphasis on documentation which is unacceptable for many projects.
• Adaptation to changing requirements not always needed - in which case, most agile methodologies become pointless.
• Difficulty breaking down the project - with complicated development, small user stories aren't always feasible.
• Distributed team discrepancies - some team collaboration tasks require face-to-face interaction which is lost when teams are spread out nationally or globally.

Obviously the study proved that agile may not be right for everyone. In order to know which software development methodology is best for a team, it is important to look at all the options available and to understand what situations each methodology is best suited for.

Other Software Development Methodologies

Waterfall Method

The Waterfall software development process is a plan driven methodology that must begin with a full, static set of requirements. The process starts at the top of the "waterfall", as seen in Figure 1, and flows downward through the different phases in a linear fashion, like an actual waterfall [5].

Figure 1. The Waterfall Model

Waterfall vs. Agile

The waterfall method is effective when the development team is provided with a rigid set of requirements, and wishes to have more control over the project [5,6]. It does not require very much customer interaction as the requirements are already laid out [6]. If a customer insists on setting a timeline and budget, the Waterfall method is useful in ensuring that these restrictions are met [5]. It is generally used for large projects [7].

The waterfall method is often criticized for leaving no room for change [5]. Defining all the requirements in the beginning without any modifications is not very realistic, nor does it provide any flexibility for the customer. If problems are found in the end product, the process must start from the beginning again [6].

Iterative/Spiral

While the spiral and iterative methods are not identical, they have similar characteristics that can be grouped together to compare them to agile. The iterative method emphasizes feature driven development by employing cycles of development. It iterates between planning, development, and release (which can be internal). After each release it is tested, reviewed, and reevaluated, and the cycle begins again. The iterations leave room for change and improvements. [8]

Figure 2. The Iterative Model

The spiral method differs somewhat from the iterative method in that it can accommodate the deployment of multiple task simultaneously and in any order. It is characterized by a definitive scope and expectations which must be managed accordingly. [9]

Figure 3. The Spiral Model

Iterative/Spiral vs. Agile

Agile incorporates iterative development into its process, along with a lot more - so why would someone want to cut out the "more"? "Iterative projects are best suited for organizations that want incremental delivery but aren't yet willing to move to the more apparently free-form agile methods," writes Matthew Hotle [7]. Hotle points out that not all projects are suitable for agile development. Iterative development supports a sequenced approach and rapid changes in requirements. It often requires less time and resources than agile, and typically works for any size project. With more interaction with the customer and organization of teams and tasks, it is easier to meet deadlines and cost restrictions [10].

Agile still dominates over iterative and spiral methods when the customer has very unstable requirements. Its lack of structure and expectations of change provide the best solution in this situation. [7]

References

[1] Hoda, Rashina et al. "Agility in Context." Proceedings of the ACM international conference on Object oriented programming systems languages and applications. OOPSLA Conference 2010: 74-88. ACM DL.

[2] Williams, Laurie. "A Survey of Agile Development Methodologies." 2007.

[3] Williams, Laurie. "Agile Software Development Methods and Practices." 2009.

[4] Williams, Laurie. "[ Agile Estimating and Planning]."

[5] Rising, Jim. "Sashimi Waterfall Software Development Process." Managed Mayhem. 6 May 2009.

[6] Kaushik, Preetam. "Agile vs. Waterfall - Is There a Real Winner?" Bright Hub. 27 Sep 2009.

[7] Hotle, Matthew. "Waterfalls, Products and Projects: A Primer to Software Development Methods." Gartner. 26 Feb 2008.

[8] Smith, S.E. "What is Iterative Development?" WiseGEEK. 8 Sep 2010.

[9] Inmon, William H. et al. DW 2.0: The Architecture for the Next Generation of Data Warehousing. Morgan Kaufmann: 2008.

[10] Lucks, Steven. "Agile / Extreme Programming or Spiral method - You Decide?" Ecademy. 7 Apr 2007.

[11] Shelly, Gary B. and Harry J. Rosenblatt. Systems Analysis and Design. Cengage Learning: 2009.

The study led to the conclusion that the fully "both Scrum and XP suit similar kinds of projects: a small, co-located team; an on-site or available customer representative; an emphasis on coding and testing early; and frequent feedback into updated requirements"