What is Agile development and what is the history of the Agile Values and Principles? Lets take a look at the history of Agile development and the Agile Frameworks for Developers.
The History of Agile
A 59 Seconds Agile Video Animation
Agile Development: The History of Agile for Developers
A 59 Seconds Agile Article
Agile software development is widely accepted as the premier style of project management today. However, this was not always the case. Not two decades ago, Agile was yet to be created. More traditional methods of software development, such as waterfall, were used by most organizations. The rise to popularity of Agile is a consequential story. Developers and their role in software development are possibly the most affected by the history of Agile.
Agile Development: Waterfall Development History
Before Agile software development, waterfall was the preferred method of project management. The name comes from the way a product cascades through stages in one direction. At the most basic level, the steps of waterfall software development are requirements, design, implementation, verification, and maintenance. While some of these may sound similar to the steps of Agile software development, the fact that they only happen once per project is the key difference.
Agile Development: Waterfall Development Requirements
Requirements are set early and are difficult or impossible to change later. Customers must give an accurate depiction of what they want before they ever see any working software. Once development has begun, customers cannot change their minds since their requirements have already been committed. For developers, requirements will ultimately become programming assignments. Even if individual requirements turn out to be much more work than anticipated or generally bad ideas, they are part of the project and must be finished.
Similar to the requirements phase, the design is completed fully for all parts and features of a product. The development team must map out exactly how everything will be created, and stick to this plan. While planning and research are useful, it is cumbersome to require that a design is set in stone from the beginning. Developers occasionally find more efficient ways for a feature to work after development has begun. Since waterfall relies on all pieces fitting together the same way from start to finish, developers may be unable to make these changes. Their hands are tied, since revisiting requirements and design are often unfeasible.
Waterfall Development Implementation
Implementation, the step in which developers actually write code, is very rigid and inconvenient in waterfall development. Instead of allowing developers the creativity to make the code work in the way they see fit, they must stick to the completed design. Inevitably, this means that programming takes longer to finish. Also, developers might be less familiar with the design than what they may have chosen to use otherwise. This leaves them without as firm of an understanding of the code and often results in programming errors.
Agile Development: Waterfall Development Verification
Verification makes sure that software is working the way it was intended to. Software products can be extremely complex and may interact with unfamiliar applications, so the potential for bugs and issues with the product is high. The developers need to fix these before it goes to customers. The problem with verification in waterfall development is how quickly technical debt builds up, and how difficult it can be to address. Since everything up to this point sticks to the original requirements and design, changes and fixes must also keep up with documentation from the very beginning of the process. This can make an ideal fix hard to come up with, and increase the time it takes to implement. Developers in waterfall have fewer tools at their disposal and are thus less efficient at fixing bugs.
Prev <— Continue Reading —> Next
User Stories Applied by Mike Cohn is one of our favourite books on Agile User Stories. The book starts with an overview into user stories, and details what a user story is and the different aspects of them. He then discusses how to go about writing a user story, and provides details of the INVEST criteria that can be used to determine if the story is meeting all of its objectives. Next Mike gives an in depth discussion of who user stories are written for and where to begin when gathering the details for them. The book then discusses acceptance testing user stories, including how to go about specifying these criteria and the responsibilities of the development team and customers during this process.
