The software development process is a creative process and we need adaptive method to be successful at it. The software development process has been evolving over 80 years now. During this period, lots of software development methodology emerged and gone extinct. Each one has or had some pros and some cons.
Initially, programmers wrote code and delivered it directly to the client and waited for any error occurrence either from clients’ dissatisfaction by not meeting their requirements or application malfunction. Then they rewrote the code and delivered it to the client. It is a challenging job. Moreover, the size of the code was getting bigger and more complex. To manage these challenges, the waterfall methodology was developed in 1956, though the term “waterfall” was coined at 1976. In the waterfall methodology, the software development process is split to several phases, including requirements analysis, design, coding, testing and deployment. In this methodology, each phase must be completed before the next phase began. In addition, the phases do not overlap and once you have completed a phase, you cannot go back to any previous phase, just like a waterfall flows in one direction. This methodology is suitable when requirements are well organized, fixed and clear, and the technology is clearly understood.
In practice, clients sometimes are not aware of what they exactly want before watching a functioning software, so they tend to change their requirements, which leads to redesign and development and increased costs. Also the designer sometimes could not predict the upcoming difficulties that require redesign for addressing the new constrains. That is why pure waterfall method is not suitable for complex, long, and ongoing projects. Also not recommended where there is a high chance of requirements change. Most important thing in this methodology is the limited involvement of the customer, which can result in failing to meet the market need.
Since the 80s, software engineers were searching for any good alternative to waterfall and experiments with ‘Iterative’ and ‘Incremental’ approaches where small chunk of workable code regularly delivered and capture the feedback to improve the delivery consecutively. In 1988, the “Spiral Model” was introduced which was the combination of the ‘Iterative’ and ‘Waterfall’.
In the Spiral Model, the development process has four phases, where a software project repeatedly passes through the phases in iterations called Spiral. The phases are 1) identification 2) design 3) construct and build 4) evaluation and risk analysis. This model allows requirements change, uses prototypes, allow user to see the system earlier and most importantly it divides the development into smaller parts which help to identify the risky part earlier. The problems of this methodology is that the management is more complex and this is not suitable for low risk or small projects. It also requires huge documentation during the intermediate stages.
In1991, another type of incremental model, named Rapid Application Development (RAD) model, came. In this model, features or the components are developed in parallel as if they were small discrete projects. This is suitable when there is urgency of quick software development, availability of high budget and skilled resources. In 1986, Scrum mythology came and in 1999 Extreme Programming (XP) was introduced. Both methodology follow the short iteration which lead to small incremental releases with focus on successfully serving the business.
In 2001, seventeen software developers met at a resort in Snowbird, Utah to discuss these lightweight development methods. They introduce the ‘Agile’ methodology which is more flexible, efficient, team-oriented and each iteration in the development cycle “learned” from the previous iteration. Although Rapid Application Development (RAD), Unified Process (UP) and Dynamic Systems Development Method (DSDM), Scrum, Crystal Clear and Extreme Programming (XP) and feature-driven development originated before the publication of the Agile Manifesto, they are now collectively referred to as agile software development methods. All the agile methods follow the Agile Manifesto and twelve core principles.
THE AGILE MANIFESTO
Based on their combined experience of developing software and helping others do that, the seventeen signatories to the manifesto proclaimed that they 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, they value the items on the left more.
AGILE SOFTWARE DEVELOPMENT CORE PRINCIPLES
The Manifesto for Agile Software Development is based on the following twelve principles –
1. Customer satisfaction by early and continuous delivery of valuable software
2. Welcome changing requirements, even in late development
3. Working software is delivered frequently (weeks rather than months)
4. Close, daily cooperation between business people and developers
5. Projects are built around motivated individuals, who should be trusted
6. Face-to-face conversation is the best form of communication (co-location)
7. Working software is the primary measure of progress
8. Sustainable development, able to maintain a constant pace
9. Continuous attention to technical excellence and good design
10. Simplicity—the art of maximizing the amount of work not done—is essential
11. Best architectures, requirements, and designs emerge from self-organizing teams
12. Regularly, the team reflects on how to become more effective, and adjusts accordingly
Agile definitely is a cool thing but you have to understand in which circumstances you should use and when not to use. I have defined and redefine many IT companies engineering process, which includes startup to fortune 100 companies. For example, few years back I revamped engineering process of GrameenPhone IT, which awarded as CMMI level 3. In that organization, for the VAS (Value Added Service) campaign development I used the waterfall methodology as the effort was less than 20 days and the requirements were pretty specific. But in the same organization, when we developed any large telco product or any COTS product, I preferred the agile. Unlike the waterfall model in agile model, very limited planning is required to get started with the project but this planning is very much important. Before jumping to Agile, an organization must think why do they should choose agile methodology. Is it beneficial? What are the challenges that this organization will face? Sometimes organization just chose agile but do not train their people or do not choose proper tools. It is very important to choose the right tools and train all the people, not limited to the developers only. Considering the above facts, a project can be chosen for Agile if it has an aggressive deadline, a high degree of complexity, and a high degree of uniqueness. ■