Software Development Methodology
There are many agile Methods available, of which we find that Extreme Programming and Scrum are the two methods that are best suited for us to provide you the maximum benefits. Any one of these methods alone has inherent drawbacks. So we have adopted a hybrid method by blending the benefits of both.
Among the different agile practices, we have adopted Test Driven Development and Continuous Integration. Again, any one of these practices alone limits the flexibility in some solution development situations. So we have gone in for the concoction that is difficult for our competitors to beat.
Extreme Programming (or XP) is an agile methodology that aims to reduce the cost of changes that are an inevitable aspect of all software projects. Your requirements are bound to change a bit even as we are in the process of building the solution for you. Extreme Programming prescribes the set of practices to be followed to tackle and incorporate ongoing changes smoothly without upsetting the rhythm of the development process. By adopting the good aspects of Extreme Programming, we stress that we understand that changes in your requirements at any stage of solution development are very important to meet your business goals. This methodology ensures that your changes get incorporated with the lowest possible cost impact.
A simplified schematic of XP is shown.
Scrum is the other agile software development method that we use in combination with Extreme Programming for our hybrid agile software development method. It is an iterative incremental process with clear guidelines, practices to be followed, and predefined roles. The main roles in Scrum are:
ScrumMaster - similar to a project manager and responsible for maintaining the processes
Product Owner – represents the stakeholders
Team – all the developers
The method has incremental completion periods called sprints, the periodicity of which is decided by the team. Each sprint creates an increment of usable software. The Product Owner tells the team of the items in the product backlog during the sprint planning meeting. The team analyzes and decides how much of this backlog can be committed for the next sprint. Once the sprint is completed, we get a usable increment of software which is demonstrated to the client.
We find Scrum a beneficial method for you because of its empirical approach – accepting that the entire solution you need cannot be fully and accurately defined at the start of the project itself. Instead, the focus is on maximizing our team’s ability to deliver fast and respond quickly to your changing requirements. As the project completes, you get exactly you want now, instead of what you thought you wanted at the start of the project.
The process is shown below.
Test Driven Development, also known as TDD, uses short development iterations based of pre-written test cases. The test cases define desired improvements or new functions. Each iteration results in code needed to pass that iteration’s tests. Preparing tests before coding aids rapid feedback changes.
A typical cycle development cycle is as shown in the chart.
Write a test: The programmer clearly understands the feature through use cases and user stories. Thus the test is written based on the understanding of the requirements as opposed to the usual practice of writing unit tests after the code is written.
Check whether the new test fails: The new test should fail because code has not yet been written to pass it. This step is therefore a test for the new test itself.
Write some code: Now some code is actually written for the new test to pass. The programmer focuses on writing only the code needed to pass the test, which helps to keep the code clean and simple.
Run the automated tests and see if they succeed: Run all test cases. If all of them pass, it is a good stage from which the programmer can begin the final step of the development cycle.
Refactor code: This is the final step (not in the chart) where code is cleaned up if necessary. Removing duplication of code is an important action in this step. The test cases should be re-run to ensure that refactoring has not upset any existing functionality.
Better software can be built faster by using TDD. The reason is the ability to take small steps and also ensures that all written code is covered by a test. Large numbers of tests help to limit the number of defects in the code and also to catch them early in the development cycle. This obviates the need for tedious debugging at a later stage.
Verification of each integration is done by an automated build (including test) to detect and rectify integration errors as quickly as possible. We reap the full benefits of CI through keep the builds fast, automating them, maintaining a code repository, etc.
Continuous integration has many advantages:
- When a bug is discovered or when unit tests fail, instead of time-consuming debugs, developers can revert the codebase back to a bug-free state.
- Integration problems are detected and fixed continuously - no fixing on the eve of the delivery date
- Bad/incompatible code get detected early on
- Conflicting changes are detected early on
- Immediate unit testing of all changes
- For testing, demo, or release purposes, always a "current" build is available
- Developers get to see the impact of broken code immediately. This helps them learn to work in incremental steps with short feedback cycles.