Philosophy of the Agile Software Development Methodologies
Friday, April 08, 2005
In recent years many agile methodologies have been created to respond to the weaknesses of the traditional or waterfall life cycle methodologies.
The main philosophical underpining of the agile methodologies is to walk beside organisation's evolution. As modern organizations evolve and adapt to their environments rapidly so should software development.
Traditional development methodologies (waterfall lifecycle) were created upon the assumption that requirements never change. Software were created based on a snapshot of the organization's situation. Projects (price, time and design) were planned in advance and any deviation from them were considered a mistake which had to be corrected.
Agile methodologies are based on the assumption that organisations, users, and their requirements change. Agile methodologies are designed to adapt to changes: they are selfadaptive. To achieve that, users and developers work together and expect change all the time. Requirements, specs and code are reviewed constatly and changed when necessary. The aim is for a good quality software that meets the needs of the clients and not for meeting the deadlines and not running over the budget.
Today I've been reading blogs and forums about agile methodologies. So far this is what I've been able to gather:
1. Agile methodolgies prefer "Responding to custumer feedback" strategies reather than "Planning ahead" ones.
2. Agile methodologies are suitable for Incrementalists/realists kinds of developers. Incrementalists like to split software in bits and develop the most important bits first. They have an idea about what is achievable in real life in a certain period of time.
Traditional methodologies prefer Completionists or idealists because they can see the "big picture" (but fail at implementing because they have to account for every single detail in the design). In traditional methodologies every step has to be finished before attempting the next one.
3. Agile methodologies require more flexible customers capable of dealing with "uncertainty". Customers will receive the software in bits and will not have an idea about how the final will look like until the end of the project. They will give feedback to developers constantly and will work with them to decide on the course of actions.
On the other hand some developers say that agile methodologies are more "predictable". This is because it is more probable with agile that the final result will meet the customer needs. With waterfall one cannot predict if the final product will meet customer expectations, especially because the specifications are written so much in advance. One learns new and important things as one progresses in the programming.
4. Agile (XP), is not a cheaper alternative to waterfall. It was created to provide 100% customer satisfaction, that is, the customers gets what s/he wants. The final product is "good enough" to satisfy users.
5. Applications developed with agile approaches are more flexible and less resistant to change because of the constant additions and refactions during development time.
On the other hand because of constant change there is code in the applications that is no longer being used but rarely removed.
6. Agile works best in corporate solutions or business applications with big databases, where users can be consulted as opposed to shrinkwrap applications which can be more generic and where there are no users to talk to.
7. Agile are better fitted to ill-defined problems.
8. In agile methodologies design and coding are merged.
9. Most agile methodologies don't address maintenance which according to some (Boehm) is 80% of the SDLC.
10. There are two types of documentation, documentation for now (first development) and documentation for later (maintenance). IMO some agile methodologies like XP consider only the first type and neglet the other.
11. Most used techniques in agile methodologies -> pair programming, refactoring, test driven development, nunit testing... By the way, pair programming is the most mentioned by advocates and retractors. Some developers feel their productivity increases when they work in pairs, some others find it difficult to work with other people.
The main philosophical underpining of the agile methodologies is to walk beside organisation's evolution. As modern organizations evolve and adapt to their environments rapidly so should software development.
Traditional development methodologies (waterfall lifecycle) were created upon the assumption that requirements never change. Software were created based on a snapshot of the organization's situation. Projects (price, time and design) were planned in advance and any deviation from them were considered a mistake which had to be corrected.
Agile methodologies are based on the assumption that organisations, users, and their requirements change. Agile methodologies are designed to adapt to changes: they are selfadaptive. To achieve that, users and developers work together and expect change all the time. Requirements, specs and code are reviewed constatly and changed when necessary. The aim is for a good quality software that meets the needs of the clients and not for meeting the deadlines and not running over the budget.
Today I've been reading blogs and forums about agile methodologies. So far this is what I've been able to gather:
1. Agile methodolgies prefer "Responding to custumer feedback" strategies reather than "Planning ahead" ones.
2. Agile methodologies are suitable for Incrementalists/realists kinds of developers. Incrementalists like to split software in bits and develop the most important bits first. They have an idea about what is achievable in real life in a certain period of time.
Traditional methodologies prefer Completionists or idealists because they can see the "big picture" (but fail at implementing because they have to account for every single detail in the design). In traditional methodologies every step has to be finished before attempting the next one.
3. Agile methodologies require more flexible customers capable of dealing with "uncertainty". Customers will receive the software in bits and will not have an idea about how the final will look like until the end of the project. They will give feedback to developers constantly and will work with them to decide on the course of actions.
On the other hand some developers say that agile methodologies are more "predictable". This is because it is more probable with agile that the final result will meet the customer needs. With waterfall one cannot predict if the final product will meet customer expectations, especially because the specifications are written so much in advance. One learns new and important things as one progresses in the programming.
4. Agile (XP), is not a cheaper alternative to waterfall. It was created to provide 100% customer satisfaction, that is, the customers gets what s/he wants. The final product is "good enough" to satisfy users.
5. Applications developed with agile approaches are more flexible and less resistant to change because of the constant additions and refactions during development time.
On the other hand because of constant change there is code in the applications that is no longer being used but rarely removed.
6. Agile works best in corporate solutions or business applications with big databases, where users can be consulted as opposed to shrinkwrap applications which can be more generic and where there are no users to talk to.
7. Agile are better fitted to ill-defined problems.
8. In agile methodologies design and coding are merged.
9. Most agile methodologies don't address maintenance which according to some (Boehm) is 80% of the SDLC.
10. There are two types of documentation, documentation for now (first development) and documentation for later (maintenance). IMO some agile methodologies like XP consider only the first type and neglet the other.
11. Most used techniques in agile methodologies -> pair programming, refactoring, test driven development, nunit testing... By the way, pair programming is the most mentioned by advocates and retractors. Some developers feel their productivity increases when they work in pairs, some others find it difficult to work with other people.
Labels:
agile,
research,
software development
Posts
