A Brief on the Software Development Life CycleThe software development life cycle (SDLC) is the process of creating software solutions or modifying the existing structures intended to cater to a particular problem. It encompasses various steps, which are followed in a logical order. In traditional SDLC models, these are the steps that are followed one after the other, and are usually carried out in isolation:
- Requirements gathering from the clients
- System and feasibility analysis
- Design and modeling
- Coding or implementation
- Deployment and delivery
- Maintenance and change requests
Why Agile Development's DifferentThe most common traditional models of SDLC - the waterfall model, rapid application model, iterative model, spiral model, etc. - have their own set of pros and cons. It took ages before people could actually analyze how realistic these models were. They fit perfectly into ideal scenarios, but they weren't always practical when it came to real-world applications. As a result, software development teams faced a lot of challenges. Some of the limitations of conventional SDLC models include:
- They do not allow requirements to be changed at the later stages because these are frozen in the software requirements specification document. In certain cases, the users' expectations go unstated or misunderstood.
- The end users do not see the system until it is complete. This provides very little scope for making suggestions and changes.
- Traditional SDLC can create a huge communication gap between developers and testers, as they are separate phases, and there is no collaboration between the two parties.
- White box testing cannot be done effectively.
Agile PracticesThe emergence of Agile methodology is no less than a revolutionary reform in the software development methodology, because it provides enough room for the project teams to be creative and versatile while still taking collective ownership of each phase of the product. By following the Agile path, individual participants in the software development team are able to condition their minds to embrace uncertainty, cope with changes, and build a better product as a process, rather than in discrete, unattached steps.
Although there is no comprehensive list of Agile principles, there are certain practices that Agile propagates. These include:
- Test Driven Development (TDD)
Ideally, developers should first write test cases for the piece of functionality they are going to code for. This will ensure good-quality code, which is less likely to break in exceptional conditions. This process also helps to ensure that user specifications have been addressed.
- Pair Programming
In Agile development, programmers generally work on the same problem in pairs, where one person is writing the code (driver) and the other one is reviewing the code and providing ideas and suggestions (navigator). This enhances productivity and reduces the time required to review code.
- Code Refactoring
Code refactoring involves breaking down the code into smaller and simpler modules that can (and should) exist independently in the ideal scenario. This improves the readability, testability and maintainability of the code to a great extent.
- Active Participation from Actual Stakeholders
Following regular intervals of a definite time period (referred to as "sprints"), clients should receive a significant working prototype of the software. This allows developers to get feedback on what they're building as they go.
- Treat Requirements as a Prioritized Stack
In Agile, it is essential to categorize requirements on the basis of their importance. This may include both implicit as well as explicit customer expectations on the software product being developed. The software development team should collectively estimate the time and resources they are going to invest into implementing the feature, and map that based on user requirements and the relative order in which they'll be tackling each part of the project.
- Regression Testing
Regression testing involves testing the functionality of an entire application after adding a new feature or modifying the existing functionality in the code. This helps to ensure that the changes have not broken the existing code.