User:NcsuOO517: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
Line 12: Line 12:
** What did I do yesterday?
** What did I do yesterday?
** What do I plan to do today?
** What do I plan to do today?
** What obstacles are standing in my way?
** 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.
* '''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'''
* '''Feature-driven development''' [3]
* '''Requirements analysis'''
* '''Requirements analysis'''
* '''User stories''' - a story represents a feature that can be completed in one iteration.
* '''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.
* '''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.
* '''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.

Revision as of 02:28, 9 November 2010

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:

  • Iterative, incremental development cycle
  • Extreme Programming (XP) - XP includes such practices as 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

Waterfall vs. Agile

Spiral

Spiral vs. Agile

Iterative

Iterative vs. Agile

Rapid Application Development (RAD)

RAD vs. Agile

Rational Unified Process (RUP)

RUP vs. Agile

Conclusion

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.

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"