In software development Agile is a set of values and principles formulated by a group of the industry leading figures in 2001.
Scrum is a concrete software development methodology that can be traced back to 1995 and was created by two of the original signatories of Agile Manifesto. Scrum supports Agile values.
The early approach to software project management usually referred to as “waterfall model” implies a sequence of clearly defined steps necessary to complete any project: define, plan, organise, execute and then close.
This represents a very neat, simple and above all convenient abstraction from the project management theorist point of view. When one stage follows another it is possible to define clear inputs and outputs for each stage, isolate and identify techniques and tools that are most useful at every phase. This is a clear example of reductionism in tackling project management complexity: keep splitting the whole into smaller bits until you get to understand each bit in isolation and then hopefully you will master the mechanics of their totality.
But as soon as the waterfall abstraction was presented it started to leak. Firstly it turned out that real-life process can not be clearly cut into stages, often definition is still changed on what it seems to be planning, organisation or even execution stage. So, in theory, the stages were allowed to overlap and theoreticians started drawing all sorts of diagrams there it’s possible to see how the definition stage gradually runs out as execution starts picking up during the organisation stage. Then, again only in theory, it is possible to accurately estimate during the planning stage how long it is going to take to develop a piece of software. Obviously, in actual practise, the estimates and other plans have to be tweaked right through the execution phase which gave birth to a string of complex yet not very meaningful methods as Earned Value Management.
The chronic problems with the waterfall abstraction gave birth to a number of “agile” project management methods (Agile, Scrum, XP Programming etc) that despite many differences at the more detailed level use the same fundamental principles to tackle product development complexity:
Small increments help controlling the scope, evaluate utility of the changes and keep users involved since there is always a fresh version of fully functioning product. It is also much easier to organise a number of teams working on a large project simultaneously when increments are kept small, this really helps tackling task dependencies.
The user feedback is key to iterative methods, since it helps the product evolve gradually in a right direction providing greater utility at the end as opposed to the uncertainly of user reaction that is natural to punctuated equilibrium driven by the waterfall “big-bang” approach.
http://stackoverflow.com/questions/677778/what-are-agile-and-scrum-development-methodology
Scrum is a concrete software development methodology that can be traced back to 1995 and was created by two of the original signatories of Agile Manifesto. Scrum supports Agile values.
The early approach to software project management usually referred to as “waterfall model” implies a sequence of clearly defined steps necessary to complete any project: define, plan, organise, execute and then close.
This represents a very neat, simple and above all convenient abstraction from the project management theorist point of view. When one stage follows another it is possible to define clear inputs and outputs for each stage, isolate and identify techniques and tools that are most useful at every phase. This is a clear example of reductionism in tackling project management complexity: keep splitting the whole into smaller bits until you get to understand each bit in isolation and then hopefully you will master the mechanics of their totality.
But as soon as the waterfall abstraction was presented it started to leak. Firstly it turned out that real-life process can not be clearly cut into stages, often definition is still changed on what it seems to be planning, organisation or even execution stage. So, in theory, the stages were allowed to overlap and theoreticians started drawing all sorts of diagrams there it’s possible to see how the definition stage gradually runs out as execution starts picking up during the organisation stage. Then, again only in theory, it is possible to accurately estimate during the planning stage how long it is going to take to develop a piece of software. Obviously, in actual practise, the estimates and other plans have to be tweaked right through the execution phase which gave birth to a string of complex yet not very meaningful methods as Earned Value Management.
The chronic problems with the waterfall abstraction gave birth to a number of “agile” project management methods (Agile, Scrum, XP Programming etc) that despite many differences at the more detailed level use the same fundamental principles to tackle product development complexity:
- The project is organised as a number of small iterations through the classic project stages (definition, planning, organisation, execution and closure).
- Each iteration aims at a relatively small yet semantically complete increment in product functionality or non-functional characteristics.
- Strong end-user involvement throughout the project.
Small increments help controlling the scope, evaluate utility of the changes and keep users involved since there is always a fresh version of fully functioning product. It is also much easier to organise a number of teams working on a large project simultaneously when increments are kept small, this really helps tackling task dependencies.
The user feedback is key to iterative methods, since it helps the product evolve gradually in a right direction providing greater utility at the end as opposed to the uncertainly of user reaction that is natural to punctuated equilibrium driven by the waterfall “big-bang” approach.
http://stackoverflow.com/questions/677778/what-are-agile-and-scrum-development-methodology
No comments:
Post a Comment