Tag Archives: Agile

Agile Mobile Development

One of the best candidates for agile development I have found is mobile app development. Why?

1. Requirements are usually not very clear as mobile app development itself is relatively new- so client demos and regular feedback helps us not to move away from what is required.

2. The mobile technologies have not been explored as much as we have already explored web technologies, so we still have lot of challenges to be faced. This means peer reviews and pair programming can be very helpful.

3. The apps are generally UI extensive, that means they are good candidates for client feedback. We need to get clarity on look and feel, and specially responsiveness of the app.

4. With frameworks like phonegap available and newly emerging augmented reality libraries, complex mobile apps are normally started in POC (proof of concept) mode. With hit and try approaches, it is good to have daily discussions to float ideas and get feedbacks within the teams.

Refer : http://kamalmeet.com/2013/06/agile-development-what-is-it/
http://kamalmeet.com/2013/06/agile-development-is-it-for-me/

 

Agile Development- Is it for me?

Agile practices are becoming popular day by day. In my last post I took up the question Agile Development- What is it? But the important question for a development team or manager should be Agile development- Is it for me? Is it the right choice? Should I use it just because it is working for someone else?

Every coin has 2 sides and so does agile methodology. If there are benefits of using it, it can also hurt the development process if not used intelligently. For example, if a project does not have many UI elements and has more complexity at backend like handling of MDBs and Web Services, having a client demo every week will not be very useful as we will not have anything new to demonstrate. Similarly, if the requirements are mundane and team has already worked on similar requirements already, pair programming will cause a negative impact on productivity.

While going for the agile approach, we will need to analyze if it will work for project in hand, rather than trusting it blindly. Ideally we should be checking each agile practice in detail and see if this is something I can use, and not go for the complete package.

For Example:

Continuous Client Feedback: If my requirements are not very clear, or are prone to changes or software has heavy UI element which needs to be verified by client, I should definitely plan weekly or biweekly demos based on project complexity and requirement.

Test Driven Development: Need to analyze how much automated test scripts will be required. Black box and white box test cases needs to be analyzed. Test cases can be created in parallel of code rather than before coding starts. If requirements are prone to change it might not be useful for me to create automated test scripts beforehand.

Face to Face Communication: if we are working in a model where teams are scattered across globe, we will not be able to follow this. Conference calls might be helpful.

Pair programming: In case we are working on a cutting edge technology which is new to team and having more than one mind concentrate on a problem will help, this is definitely the way to go.

Similarly we will need to take a call on what will work for my project rather than following the herd and going agile mindlessly.

Agile Development- What is it?

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.

Test Driven Development

One of the most important practices of Agile development process is Test Driven Development (TDD). It is not a complex term to understand, TDD simply means you are aware of test cases before you actually start development of a piece of code. You are supposed to write test cases, automated test scripts, Junit test suite before you actually went on to write the real code.

Though the concept is simple, but in real world the implementation is not that easy. Why? Lets look at some of the key challenges.

Challenges for TDD

1. How can you create a test plan for something which does not even exist?
2. What if Requirement gets changed or modified? Instead of just making code change, we are making change to test plan as well. If we were creating tests after code completion, we will have saved ourselves from the trouble of making the changes to test plan.

Ok we have talked about the challenges, so why should we take so much pain and not just stick to the regular practice of writing test cases after writing the code.

Advantages of TDD

1. You can test the code implementation the moment you have written it without waiting for the test to be ready as the test was written before code.
2. Errors are caught at the early stage rather than propagating till late stages.
3. Test cases can be confirmed by business team, so that any discrepancy in the requirements can be figured out at an initial stage.
4. Most importantly, a TDD makes sure improvement in code quality. As the test cases are written in advance, it makes sure that all the code written passes the test before getting checked in.