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 requires more than 80% project understanding before kicking off the project which is impossible in major cases. Cause of volatile requirements and understanding business feels, 80% of software projects using this methodologyfail to meet their objectives.
Typical 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 evaluated 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 to more collaboration and interaction between different departments at enterprise level and delivers 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.
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 the user, the team terminates iteration cycle and releases the software.
Other elements of Extreme Programming include: programming in pairs, continuous integration, add only needed features for a particular release.
Users write a story which helps the team to estimate the time to build the release and to define acceptance testing. A user is a part of XP team and 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 wherein requirement changes 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
No comments:
Post a Comment