CSC/ECE 517 Fall 2010/ch6 6c VP

What is agile project methodology?

While computer software has become a driving force for the modern world, software development itself is not a perfect process. Today, software development has gained pace and needs to become more flexible. To meet the needs of today’s customers, a new software development methodology called Agile Software Development has come into existence. Agile methodologies is a completely different approach compared to the traditional software development methodologies. Agile means quick and active. Agile methodology is based on iterative development, where whole team collaborates to decide on requirements and solution to solve a particular problem. Agile project management is an application of these Agile software development ideas into project management.

How agile projects are different from projects

Agile methodology is totally different than traditional software development techniques. This is due to the fact that unlike traditional techniques, agile process works in iterations, each of which are of a short time frame and do not involve long term planning. Iteration period differs from team to team and all project participants view themselves as one team to achieve the goal. In agile process, the stages are also slightly different from that of the traditional processes like Waterfall. The 5 stages that are described in the agile development methodologies can be defined as follows

Envision: This is the phase where the team visualizes the requirements through a data sheet. This is analogous to use case list in UML.

Speculate: This phase is to provide a general direction of the project and begin the planning phase. Though it is similar to that of waterfall model, the plan is broken down into short iterations based on the features.

Explore: This phase acts as an execution phase in the lifecycle. The distribution of work, technical practices, team development are all done during this phase. This is different from the Implementation phase of the waterfall model as it focuses on the complete dynamics of the project.

Adapt: In this phase, all the corrections and changes that are to be made are applied to the project. This can be analogous to the testing phase in waterfall model. The major difference here is that the results of this phase are sent to the re-planning of the next iteration.

Close: The objective of this phase is incorporate the learning of this iteration or project into next iteration or passing it on to the next project team.

Purpose of estimations

Estimation and planning are critical steps of any software development project irrespective of its size. Planning plays a prominent role in deciding on the investments, availability of the resources and customer values. In any case, good estimation leads to good planning. Estimation of cost and schedule is the deciding factor when it comes to whether a particular feature has to be implemented in an iteration.

There are 3 types of planning namely: Release planning, Iteration planning and Daily planning.

Release planning

Both size and velocity estimations are helpful for release planning phase. The estimation of the capability of a team to deliver the product in the given time is called Velocity. This velocity combined with the total feature size, which is another estimate of project will help in deciding the release date.

Iteration planning

The major focus of this phase of planning is to decide on the features that are to be selected for the current iteration and which one’s are to be moved to the next iterations. This phase of planning helps the product owners to prioritize the features and redesign the scope of the project if required.

Daily planning

Traditional methods decide on scope and delivers all features together whereas agile projects deliver in units of features. These features are describe as user stories and user stories has business values for customers. This phase is mainly used to track the progress of these user stories.

Estimation in agile projects

Agile process separates estimation of size from estimation of duration. Initially, estimation of size is done and it is followed by estimation of duration. Both these estimations are done at 'user story' level.

Size Estimation

The size of a particular user story is determined after considering all the activities that are needed to be done to complete that user story. These activities include all the phases like Envision, Speculate, Explore and Adapt.When the user story is completed, one can assume that a part of the feature to the customer is completed. As with any estimation technique, size estimates has certain units which are as follows:

Estimation units

1. Story point - Story point is a random measure used by team to rate each user story and they are actually of no physical significance. This unit signifies the efforts required to complete the user story. As its unit do not give any significant meaning sometimes it is referred as bucks or points. This point system is a relative scale. It has no effect of any variance in time or team size and hence this unit is consistent among different person and time. After few estimations when team gets stable story points, estimation of further user stories becomes fast and easy.

2. Ideal time - This is absolute scale to measure estimation. The ideal time is the actual time needed to complete a user story in an ideal case i.e., without considering any interrupts. Generally ideal time gets calculated in days or hours. It is practically observed that the actual elapse time is greater than the ideal time. Due to its absolute nature is it easy to understand this measure for person outside the team but meaning of ideal time may vary from person to person.

Velocity Estimation

Velocity is the term which is used to describe the estimation of the capability of the team to deliver. Total story points or ideal days completed in an iteration is referred as velocity. It helps us to determine the scope of each iteration and total duration of the project. The equation to find the total number of iterations to complete the project is given by the total number of story points divided by the velocity. Here, the length of each iteration is fixed and hence the total duration of the project can be calculated by multiplying the duration of each individual iteration by the total number of iterations to complete all user stories defined in a project.

Estimation techniques

The best estimate for any work can be given by person who is actually going to work on it. Hence unlike traditional estimation techniques where one or few teammates get to involve in estimation, agile processes believe on estimation done by the entire team itself.

Techniques for Size Estimation

The different techniques that can be used to carry out size estimations are given as follows:

1. Expert opinion: As the name explains, these are the judgements of the experts in that particular fields. One of the teammate explains the user story to expert and then they discuss about it at length. All the doubts and clarifications are done and then depending on the experience and expertise of the expert, the estimate is provided. This type of estimate, though, is very less useful in agile methodology as a single person’s estimation does not get considered as valid.

2. Analogy: The estimates are provided upon comparisons between different user stories. Though it is a bit difficult initially for the first few user stories, it works fine for all other user stories where the only work is to compare with previous user story estimates. This method is favorable for user story estimation

3. Break down the story: This estimate works when user stories are too big to get an estimate directly. In that case, the story can be broken into small user stories, called as tasks and estimates can be calculated for each of these tasks to evaluate points for one big user story.

this also makes tracking easier during iteration.

4. Planning poker: This is an easy method of estimation developed by Mike Cohn [1]. It is a group activity either done at either the iteration planning phase or the release planning phase. Each member of the team carries a deck of 13 cards. These cards have 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?, break on them. The high priority user stories are sorted listing highest priority user story at the beginning and the lowest priority story at the end. After he/she explains the scope of that user story, each participant puts the estimation card facing down. After everyone gets some estimation, these cards are revealed. If the estimation given by everyone is same then it is recorded. In case where there is a high difference in the estimations, then each teammate explains their estimation and the reason for that score. They resolve the differences and start the process all over again. This process is continued till all estimates comes to close estimation. The ? card is used if scope is not clear and participant cant estimate the time.The break card is used to ask for break.

References

1. NameSpace
2. Explicit Namespaces
3. Closures
4. Code blocks, execution frames, and namespaces
5. Namespaces in Javascript
6. Namespace vs. Packages
7. Ruby Modules and Mixins
8. XML Namespace
9. Namespace in C++
10. PHP Manual by Mehdi Achour, Friedhelm Betz, Antony Dovgal, Nuno Lopes, Hannes Magnusson, Georg Richter, Damien Seguy, Jakub Vrana
11. Namespaces in C#