Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Rapid release of code improvements on a short time-scale
Cycling through: requirements, arcitecture, design, code, and test phases for each small release.
Continuous integration – keep code at production level through life of project.
Continual improvement of code design through refactoring.
Extreme Programming
Scrum
Crystal
Test Driven Development (TDD)
Lean Development
Mainly Agile software Development is used when requirements can NOT be nailed down in advance of a project. Because it's costs are lowest to introduce requirements early in the process – if it's possible to know all the requirements in advance – you can build software most effectively by a the more traditional approaches of: requirements, architect, design, code, and test phases. However, if requirements can NOT be nailed down in advance – an Agile process that allows for change through the process cycle may make more sense.
Agile can also be used for a project that has NO software development process – in order to rapidly adopt strategies and processes that will improve quality, improve estimates, and facilitate communication between developers. Agile also makes sense in Scientific Software Development environments where requirements can NOT be known in advance – because of unexpected scienctific research interactions not known or appreaciated in advance of building the software. Scientific Software development environments are also often adverse to creating significant volumes of documentation for the requirements and design phase of a project. Hence, the low formality of Agile and emphasis on the ability to adapt the software for changing requirements – makes sense in the Scientific Software development environment.
Requirements are known (or can be known) completely before the project starts.
In development cultures that require or are used to good requirements, design and development documentation. And these documents are updated and utilized through the life of the project.
When a specific process is required for the project.
Sometimes Agile software development methods are misunderstood to NOT use requirements analysis. This is simply NOT true – what is true is that in Agile methodology requirements analysis is done incrementally – and it's done less formally. XP for example has "User Stories" that are the analogue to requirements. Agile also makes the assumption that you don't need to get all requirements up front for a software project – you need to get them for each smaller release (on the order of a week to a month at a time).
Likewise, scientific software often can NOT have all the requirements laid out ahead of time – because scientific codes are research tools which means you don't know ahead of time what will happen when you build scientific software. And often it is difficult to get scientists to spend significant chunks of time writing or reading lengthy requirements documents. Also for existing Legacy codes – it is a significant effort to create a requirements document – and often it is difficult to get the buy-in to do the work neccessary to create such a document. This is where Agile methods can help. Some ideas that may apply in this case are:
Document requirements in a less formal – easily read and editable way (such as a SWIKI page).
Document requirements in terms of the up coming release or set of changes to take place.
Document current requirements in terms of the testing required for the components or system.
Requirements documentation in terms of testing can be a useful tool in scientific software development environments. Instead of documenting minute details of the behavior of each component of a complex scientific software system – simply document the required tests that must be performed for the code to be acceptable. Perforably an automated test script can do all of this testing – but a document on what tests are required – can also be useful. Much of the testing can be centered around the input options and configurations to be tested, and on rigourous software engineering tests that can be easily verified (such as answers are the same regardless of the number of parallel tasks assigned to the program). It is easier to get buy-in from scientists on what testing must be done and developing crititeria for such testing.
The Agile software process is sometimes abused by assuming it does away with the "Software Design phase". This is actually NOT true. With Agile methodology you are continually in the design phase and continually talk about and refine the design of the system through refactoring. However, design in Agile projects is typically done less formally with less formal written documentation with a greater emphasis on face to face communication. For example, an Agile design session may be done with several folks around a white-board, and the results of the white-board discussion photographed and saved for later reference. Agile methodology also tries to put effort into finding simple analogies or metaphors that describe the design of the system. It's also a goal of Agile projects to have a simple design that is readily understood by those examining the code – hence extensive documentation on the design is not needed.
Note, that in more traditional methods – having to refactor a design is a negative – in Agile methodology refactoring is viewed as a way of responding to changing requirements. This is because the primary assumption of an Agile project – is that requirements will change throughout the life of the project. Hence, re-factoring to improve the design is a given. In projects where requirements do NOT change – re-factoring implies that your initial design was NOT satisfactory.
