Agile methodology

Introduction

Waterfall model follows application development in phases with checkpoint and deliverable documents in each checkpoint. It advocates rigours project management, strategy and processes to track the status. The main drawback is that it require more than 80% project understanding before kick off the project which is impossible in major cases. Cause of volatile requirements and understanding business feels, 80% of software projects using this methodology fail to meet their objectives.

Typical Waterfall Model

Waterfall model

Agile methodology

Agile mythology has small box iterations rather than phases. The output of each iteration will be production release deliverable and could be evaluate and get early feedback.

Agile was a significant departure from the heavyweight document-driven software development methodologies—such as waterfall—in general use at the time

Agile refers more collaboration and interaction between different departments at enterprise level and deliver the successful product with individual contribution

Agile methodologies embrace iterations. Small teams work together with stakeholders to define quick prototypes, proof of concepts, or other visual means to describe the problem to be solved. The team defines the requirements for the iteration, develops the code, and defines and runs integrated test scripts, and the users verify the results. Verification occurs much earlier in the development process than it would with waterfall, allowing stakeholders to fine-tune requirements while they’re still relatively easy to change.

It promotes adaptive planning, evolutionary development & delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change.

Agile Model

XP (extreme programming)

It advocates frequent “release” in short development cycles, each release follows with several iterations. When the product release has enough features to satisfy user, the team terminates iteration cycle and release the software.

Other elements of Extreme Programming include: programming in pairs, continuous integration, add only needed features for a particular release.

Users write story which help the team to estimate the time to build the release and to define acceptance testing. A user a part of XP team adds the detail requirement as the software is being built. This allows requirements to evolve as both users and developers define what the product will look like

  • Continuous Integration: Integrate often at least once a day using automated continuous integration tool.
  • Pair Programming: Pair programing to extensively code review while coding.
  • 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..

Scrum

Scrum is a way for teams to work together to develop a product whereas requirement change rapidly during development. Product development, using Scrum, occurs in small pieces, with each piece building upon previously created pieces. Building products one small piece at a time encourages creativity and enables teams to respond to feedback and change, to build exactly and only what is needed. Unlike XP, Scrum methodology includes both managerial and development processes.

  • Sprints: Short development process
  • Stand up meeting: Daily 10 minutes meeting status of the work to be done that day, progress from the day before, and any blocks that must be cleared
  • Scrum Master: The ScrumMaster is the person responsible for managing the Scrum project..
  • Sprint backlog: Sprint backlog is the list of backlog items assigned to a sprint, but not yet completed.
  • Burndown chart: This chart, updated every day, shows the work remaining within the sprint. The burn down chart is used both to track sprint progress and to decide when items must be removed from the sprint backlog and deferred to the next sprint.
  • Product backlog: Product backlog is the complete list of requirements

.References

About these ads

3 thoughts on “Agile methodology

  1. Pingback: Why we moved to an agile development process… | Valueworks Blog

  2. Pingback: Acknowledging the Common Good of Agile: Praising the good of Agile and Abrogating the minuscule negativity it brings | The Genius Way

  3. Pingback: Agile Software Development Process | TechMyTalk

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s