Human beings by nature are impatient. That reflects in software development industry as well now. Gone are the days when it used to take years to complete software, now we are talking about software delivery in months and at times in weeks. Due to this impatience, we are seeing a lot of emphasis on agile development practices.
Agile– the term means fast, quick. So we are looking for some way to fasten up our software development process in order to reach the end results quickly. Here are some key components of agile methodology which help us speed up development process
Iterative Development: Rather than following traditional waterfall model, we will get into more spiral mode. The idea is to divide the final requirements into small junks, where each chunk can be delivered one by one, in each iteration.
Continuous Client feedback: This is the most important factor in agile development mode. We do not wait till the end to get the product completed and then get it reviewed from client. The idea is to involve client at every stage by giving weekly or bi weekly demos of the product so that everyone is on the same page and last minute surprises can be avoided.
Test Driven Development: see here.
Emphasis on Face to Face communication: In a normal scenario, where development teams are sitting in different geographical locations, communication will flow through emails. And a query raised from one team will most probably take a day or two to get resolved. This delay can be a killer of agile development, so focus is laid on having team sitting close to each other.
Daily status meets: Generally a short meet of 10 to 30 minutes is scheduled every day where focus is on – previous day’s achievement, today’s plan and any issues being faced. This helps keep the team on track and use knowledge of whole team to solve any issues.
Pair Programming: Slightly controversial practice of2 people sitting together on a machine and writing the code. This is very tricky to implement as if team is not educated on the pair programming activity, we might end up losing productivity that two people are doing work of one.
The list is not exhaustive. Ideally there can be no complete list as every team should invent best practices of its own, of course keeping the tried and tested methodologies as the base.