December 01
Agile Development Strategy
I hear a lot about the agile development methodology, and from what I understand, it is supposed to allow for faster development times.
I also have heard and seen that some of the work created from this strategy often has to be re-done, due to a misunderstanding of the requirements.
How does a particular development strategy help define "clear" requirements? As a developer, must I also become an analyst as well? To a certain extent, the answer is yes, in my opinion. I'm going to do some research on the subject when I get some time and gather some expert opinions and see if I can't
determine why development methodologies’ are selected.
Well I have had a chance to at least look at the history of some agile development strategies, and it appears that most of the agile methodologies have been developed in an effort to get around the political barriers that were created by the waterfall methodologies in the mid 1990s.
That does seem unstanderable, as I have personally witnessed and been a victim of the political bantering and arguing that can take place in a waterfall method. As a developer, I just want the requirements from the customer/client, meaning that usually there is 1 stake holder that should make decisions on what the 'requirements' actually are. If I have to wait for several different people to sign off on a document, that will definitely increase development time. And from what I have found, upper management types usually don't read documents, until it is too late, and then they want to complain about something that they 'signed off' on but did not actually read.
What I have found in the agile development process is that a business analyst should always be involved in creating the requirements or stories. If you have just a technical architect or developer attempting comprehend the requirements, the development tasks will usually miss what the actual requirements are, which means that the architect is attempting to accomplish too many tasks or responsibilities, and they forget that they are just mere mortals like the rest of us. Whether the agile development or the waterfall method is selected, there is no substitute for clearly understanding the requirements, and communicating what you as a developer understand the requirements to be. If the basics of communicating are forgotten or simply by passed; when requirements are identified, then the developer has to guess at what the requirements are, and that usually means bad things for the developer if there‘re are not a good guesser. I guess there just isn’t a substitute for clear requirements regardless of the programming methodology that is chosen
Tools 
Help
