Ch7 21 bi: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
Line 5: Line 5:


==History and the Agile manifesto ==
==History and the Agile manifesto ==
Historically, software development has followed the waterflow model
Historically, software development has followed the waterfall model [reference] with clear delineation of the various phases such as gathering requirements, design, implementation, verification and maintenance, with very little cross communication between these phases. This rigidity built into this model doesn't always reflect the real world requirements of software development, for e.g., the requirements could change after the design has been completed and a failure to accomodate the new set of requirements is often considered a failure of the project. This has resulted in a significant percentage of software development projects being delayed and in some cases being completely stopped.
In the late 1990’s several methodologies began to get increasing public attention. Each had a different combination of old ideas, new ideas, and transmuted old ideas. But they all emphasized close collaboration between the programmer team and business experts; face-to-face communication (as more efficient than written documentation); frequent delivery of new deployable business value; tight, self-organizing teams; and ways to craft the code and the team such that the inevitable requirements churn was not a crisis.


== Agile Manifesto  ==
As a reaction to the failure of the traditional software development models, quite a few new techniques started to develop in the late 1990's.  They all emphasized close collaboration between the programmer team and business experts and a built in ability to be able to deal with and manage change. The core ideas behind these loosely defined methods, referred to as light-weight software development or Agile methods, were finally crystallized into a set of principles, i.e., the Agile manifesto.


The Agile Manifesto reads, in its entirety, as follows:<ref name="Agile Manifesto"/>


<blockquote>We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:


:'''Individuals and interactions''' over processes and tools
:'''Working software''' over comprehensive documentation
:'''Customer collaboration''' over contract negotiation
:'''Responding to change''' over following a plan
That is, while there is value in the items on the right, we value the items on the left more.</blockquote>
=='''References'''==


http://www.extremeprogramming.org/
http://www.extremeprogramming.org/

Revision as of 17:20, 2 December 2011

Introduction

Agile methodologies are software development techniques based on software and management principles that have been distilled over the past few decades. The primary differentiating factor between Agile methodology and traditional software development methods is the fluidity that the Agile methodologies inject in all stages of software development.

Agile software development is an umbrella term that encompasses various development techniques and philosophies, however, there are certain core characteristics that all of these share. The key features of Agile development are that it is based on iterative and incremental development encouraging an evolution of the requirements and solutions. Agile software development teams also tend to be more fluid, self-organizing and are often cross-functional. Agile software development at the core of it, strives to break the rigid boundaries that traditional software development techniques introduce.

History and the Agile manifesto

Historically, software development has followed the waterfall model [reference] with clear delineation of the various phases such as gathering requirements, design, implementation, verification and maintenance, with very little cross communication between these phases. This rigidity built into this model doesn't always reflect the real world requirements of software development, for e.g., the requirements could change after the design has been completed and a failure to accomodate the new set of requirements is often considered a failure of the project. This has resulted in a significant percentage of software development projects being delayed and in some cases being completely stopped.

As a reaction to the failure of the traditional software development models, quite a few new techniques started to develop in the late 1990's. They all emphasized close collaboration between the programmer team and business experts and a built in ability to be able to deal with and manage change. The core ideas behind these loosely defined methods, referred to as light-weight software development or Agile methods, were finally crystallized into a set of principles, i.e., the Agile manifesto.

The Agile Manifesto reads, in its entirety, as follows:<ref name="Agile Manifesto"/>

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.


References

http://www.extremeprogramming.org/ http://agilemanifesto.org/ http://en.wikipedia.org/wiki/Agile_software_development http://www.extremeprogramming.org/ http://www.industrialxp.org/ http://agilescout.com/best-agile-scrum-tools/ http://www.21scrum.com/ http://agilebuddy.com/