CSC/ECE 517 Fall 2010/ch6 6c VP: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
 
(101 intermediate revisions by 2 users not shown)
Line 1: Line 1:
'''Namespaces''' is a set of names which are bound together to form unique identifier in order to resolve conflict with same names from different context. [http://en.wikipedia.org/wiki/Namespace Namespaces] give you control over the visibility of the properties and methods that you create in a program.
'''Estimation in Agile Projects''' is calculated approximation of result and approach to result in agile projects which can be used even if complete and certain data is not available at the start of the project.


==What is agile project methodology?==
==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.
While [http://en.wikipedia.org/wiki/Computer_software computer software] has become a driving force for the modern world, software development itself is not a perfect process[http://portal.acm.org/citation.cfm?id=1363634&preflayout=flat]. 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[http://en.wikipedia.org/wiki/Agile_software_development] has come into existence. Agile methodologies is a completely different approach compared to the traditional [http://en.wikipedia.org/wiki/Software_development_methodologies software development methodologies]. Agile means quick and active. Agile methodology is based on [http://en.wikipedia.org/wiki/Iterative_and_incremental_development 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 [http://www.kruchten.org/agilevancouver/presentation_slides/Hewson%20APM%20intro.pdf project management].
 
Open source project [http://sourceforge.net/projects/expertiza/ 'Expertiza'] is a very good example of agile methodology application. Every group work on some part of currently working 'Expertiza' project to add more features, to make it more enhance or to correct functionality. They work on it around 2 to 4 weeks and add that functionality in existing project. After every such iteration we get working model which can be used in real life where as there is scope to decide on new features or more corrections which can cause more number of similar iterations. This process can be referred as agile method.


==How agile projects are different from projects==
==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
As discussed earlier agile methodology is totally different than traditional software development methodologies. 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[http://www.kruchten.org/agilevancouver/presentation_slides/Hewson%20APM%20intro.pdf]. In agile process, the stages are also slightly different from that of the traditional processes like [http://en.wikipedia.org/wiki/Waterfall_model Waterfall Model]. The 5 stages that are described in the agile development methodologies can be defined as follows
 
* Envision[http://www.artima.com/forums/flat.jsp?forum=152&thread=68916]: This is the phase where the team visualizes the requirements through a data sheet. This is analogous to use case list in [http://en.wikipedia.org/wiki/Unified_Modeling_Language UML].
 
* Speculate[http://www.testingreflections.com/node/view/664]: 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.


Envision: This is the phase where the team visualizes the requirements through a data sheet. This is analogous to use case list in UML.
* Explore[http://www.agileprojectmgt.com/docs/healthcareit.pdf]: This phase acts as an execution phase in the life cycle. 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.


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.
* 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.


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.
* 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.


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.
Coming back to 'Expertiza' example which can also be done in traditional way where we can decide on all features we want in 'Expertiza' and then plan how can we get them done in single iteration. But here we had to know all requirements at the beginning of planning which is not realistic approach. This is where agile process differs from traditional approach.  


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.
In case of an Agile approach, the entire work is divided into iterations. Consider that there is a task which is to be completed within 3 weeks. The requirements that are available are listed and the Envision phase is done. Next there is a series of iterations each having the Speculate-Explore-Adapt phases. After every Adapt phase, new changes or fixes are added to the Speculate phase of the next iteration. After these iterations are done the final Close phase is reached. These steps are explained further with the help of the figure below:


[[Image:Flow.png|frame|center]]
[[Image:Phases.png|frame|center]]


==Purpose of estimations==
==Purpose of estimations==
==Size estimation in agile projects==
Consider a student appearing for paper test where during test he comes to know that there are 20 minutes left and he has to cover 20 more subjective questions. He approximates that he can give 1 minute for each remaining question whereas in another approach for same situation he looks upon how much marks each question carried, which questions carried more marks and how much time those questions may take to complete. Accordingly he concentrates on fewer questions but completes them correctly. Later approach may take some time from 20 minutes but still it will work better towards achieving good marks in test. This example signifies how estimations are important.
==Estimation techniques==
 
==Re-estimation==
Before starting project the very obvious questions that arises is 'How long will it take to complete this?' which is not so easy to answer. One might give a range saying 'It may take around 10 months to 2 years'. Anyone listening to this starts expecting it close to 10 months but do not take into consideration of range up to 2 years. This consideration may cause problems if this estimation do not turn right. This is the major reason projects need to be estimated to reduce uncertainty[http://vimeo.com/5368440].
==Advantages of agile size estimation==
All further processes including planning, design, scheduling rely on these estimation which may turn unchangeable.
==Disadvantages of agile size estimation==
Estimation is critical step of any software development project irrespective of its size specially in agile processes where duration of iteration is very small compared to traditional processes. 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 [http://www.extremeprogramming.org/rules/planninggame.html 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 [http://www.extremeprogramming.org/rules/iterationplanning.html iteration planning] phase 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.


==Overview==
===Daily planning===
Traditional methods decide on scope and delivers all features together whereas agile projects deliver in units of features. These features are described as [http://en.wikipedia.org/wiki/User_story user stories] and user stories has business values for customers. This phase is mainly used to track the progress of these user stories.


A namespace is a way to keep names organized. Lets use an analogy to [http://en.wikipedia.org/wiki/File_system file system] in the computer which uses [http://en.wikipedia.org/wiki/Directory_%28file_systems%29 directories] and sub-directories. Namespaces in this context could be viewed as the path to a file in the directory/sub-directory which can uniquely identify each file. User can create more than one files with same name in different directories or sub-directories as they are in different namespaces.<sup>[http://snook.ca/archives/javascript/javascript_name]</sup>
==Estimation in agile projects==
Another advantage of namespace is logical grouping of source code.
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.  


                                                  [[Image:Namespaces.jpg|frame|center]]
===Size Estimation===
Above figure depicts the use of namespace in programming language. The left part of the diagram shows variable "var" used by two different contexts. Now, the context which wants to use the variable "var" should have some means of distinguishing between its declarations. This is where namespaces comes into account. As shown in the second part of the diagram each variable "var" can now be identified independently.
==Types of Namespaces==
Different languages support namespace either using implicit types or explicitly by using keyword 'namespace'.<sup>[http://www.springerlink.com/content/v04u888706r925k3/]</sup> 


===Implicit Namespaces===
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:


'''Implicit Namespaces''' are the abstraction defined by language itself in order to resolve name conflicts. Some of the constructs of implicit namespaces in different languages are [http://en.wikipedia.org/wiki/Interface_%28Java%29 interfaces], [http://en.wikipedia.org/wiki/Java_package packages], [http://en.wikipedia.org/wiki/Scope_%28programming%29 scope], [http://en.wikipedia.org/wiki/Attribute_%28computing%29 attributes],closure<sup>[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2007/wiki1b_3_an]</sup> etc.
====Estimation units====


====Blocks====
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.
Blocks are often used as an abstraction to resolve naming conflicts. In many languages blocks determine scope of the variables. Hence a variable declared in a particular block has its scope within the block. Hence, we can think of a block as a namespace.<sup>[http://docs.python.org/release/2.1.2/ref/execframes.html]</sup>


Below is the example that shows how a block resolves naming ambiguities.
Example, If one user story carries 3 story points other will get 5 points as in comparison current user story will take more time for test.


main()
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.
{
      int i=5;
      ------
      ------
      {
      int i=10;
              ------
              ------
              //printing I here gives value equal to 10
      }
//printing I here gives value equal to 5
}
The above program depicts the concept of [http://en.wikipedia.org/wiki/Global_variable global] and [http://en.wikipedia.org/wiki/Local_variable local] variable initialization which can be viewed as a example of implicit namespace handled by programming language constructs. Disadvantage of this type of namespace is that programmer has to keep track of all variables in program and their namespaces.


====Objects====
Example, Even if there are 2 user stories to be estimated, each user story will get ideal time independent of each other say 3 days and 5 days respectively.


In JavaScript, a namespace is actually an [http://en.wikipedia.org/wiki/Object_%28programming%29 object] which is used to reference methods, properties and other objects.Objects are all we need to create namespaces in Javascript.
===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.


Below is an example of a modules in [http://en.wikipedia.org/wiki/JavaScript_language Javascript]:
==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.  


var Val = {
===Techniques for Size Estimation===
    Hello: function() {
The different techniques that can be used to carry out size estimations are given as follows[http://www.slideshare.net/ritesh.tamrakar/estimation-in-agile-project]:
        alert("Hello...!!!");
    },
    Goodbye: function() {
        alert("Goodbye...!!");
    }
}
// In a nearby piece of code...
Val.Hello();
Val.Goodbye();


The above example shows the use of object to reference the methods in its namespace. Hence the functions above are called using the object.<sup>[http://www.codeproject.com/KB/scripting/jsnamespaces.aspx]</sup>
1. Expert opinion: As the name explains, these are the judgments 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.


====Packages====
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


[http://en.wikipedia.org/wiki/Java_package Packages] can be used as a mechanism to organize [http://en.wikipedia.org/wiki/Class_%28programming%29 classes] into namespaces which are mapped to file system. A unique namespace is provided by each package which gives flexibility to define same identifier name over different packages.
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.


Below is an example of a package in [http://en.wikipedia.org/wiki/Java_language Java]:
this also makes tracking easier during iteration.


package A;
4. Planning poker[http://en.wikipedia.org/wiki/Planning_poker]: This is an easy method of estimation developed by [http://en.wikipedia.org/wiki/Mike_Cohn Mike Cohn]. 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.
class A1  {
  int var = 4;
}
package B;
class B1  {
  int var = 12;
  }


The above code snippet shows how a package can behave as a namespace in some programming language. Here, package A and package B are two different namespaces with variable var in each of them.<sup>[http://www.javacamp.org/javavscsharp/namespace.html]</sup>
===Techniques for Velocity Estimation===


====Modules====
1. Calculated based on history: Empirical data of same team can be useful in calculating velocity. Either average or range between maximum and minimum can be considered. The limitations with this technique is that the project has different set of team or if its project with completely new technology then this method will not be useful at all


In some languages, different constructs are used to identify namespaces. Languages like [http://en.wikipedia.org/wiki/Ruby_language Ruby] maintains namespace at higher level of abstraction known as modules which can be thought to be similar to packages in Java.
2. Iteration run: Observes actual iteration. During the beginning of the project, teams provide at the beginning team provides some time developing obvious user stories observing team velocity. This observed velocity can be used for further estimation.


Below is an example of a modules in Ruby programming language:
3. Calculated based on available man-days and focus factor: Initially calculates the number of man-days available for an iteration. This is calculated multiplying total number of members working in that iteration with number of working hours for each member.Consider only productive time. In order to remove unproductive time use focus factor. Focus factor is a metric to decide how much each person can focus on given task. So if we consider 70% as the focus factor, then it shows total ideal days in iteration is 70% of total man-days which is estimated velocity.


module Trig
==Re-estimation==
PI = 3.141592654
 
def Trig.sin(x)
As the user story progresses further, the team comes to know more about the exact data and implementation details. There could be a difference between the estimated size of the user story and the observed complexity. If the difference between these two is large enough, then it is required to re-estimate the size of user story. Also while updating a particular user story estimates, all the other user stories that may be affected due to this or the stories that are similar to this can also be updated. Correct re-estimations makes schedules more accurate.  
  # ..
 
end
====When not to re-estimate====
def Trig.cos(x)
Care must be taken by the team in re-estimating. One must not re-estimate solely because the progress is not as rapid as they have expected it to be. The team can leave most of these inaccuracies to the velocity estimate.
# ..
end
end
module Moral
VERY_BAD = 0
BAD = 1
def Moral.sin(badness)
# ...
end
end
require 'trig'
require 'moral'
y = Trig.sin(Trig::PI/4)
wrongdoing = Moral.sin(Moral::VERY_BAD)


The above code snippet shows the use of modules in a form of namespace in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].The methods are referenced using the name of the module as shown in the code. Hence there is no clash on method name 'sin'.<sup>[http://www.tutorialspoint.com/ruby/ruby_modules.htm]</sup>
====When to re-estimate====


====Attributes====
During the project, there may be situations where there may be a user story that has not been completed in the iteration that it is supposed to complete in. Consider that the unfinished portion of the story is not done in the next iteration, in that case the remaining story is re-estimated, based on the knowledge about the project that the team already have[http://portal.acm.org/citation.cfm?id=1036751&coll=DL&dl=GUIDE].
[http://www.w3schools.com/xml/xml_namespaces.asp XML namespaces] provide method for qualifying element and attribute names by associating them with namespaces identified by unique [http://en.wikipedia.org/wiki/URI Uniform Resource Identifier] URI references. For example, Id could be in both vocabularies, employee and student, hence we can provide uniqueness for each vocabulary using namespaces to avoid conflicts.  


A namespace is declared using the reserved [http://en.wikipedia.org/wiki/XML XML] attribute xmlns, the value of which must be an [http://en.wikipedia.org/wiki/Internationalized_Resource_Identifier Internationalized Resource Identifier] (IRI),
==Advantages of agile size estimation==
usually a Uniform Resource Identifier (URI) reference.


Below is an example of a attributes as a namespace in XML:
Agile software development is the new norm in companies as it has many advantages over the traditional waterfall model. Estimation is an important aspect in agile development and its advantages in a company can be listed as follows:


<root
* All the estimates are done by all the members of the team. So it is more like the team estimating their own work and doing their planning by  themselves.  
  xmlns:fruits="http://www.w3schools.com/fruits"
  xmlns:furniture="http://www.w3schools.com/furniture">
  <fruits:table>
  <fruits:tr>
    <fruits:td>Apples</fruits:td>
    <fruits:td>Bananas</fruits:td>
  </fruits:tr>
  </fruits:table>
  <furniture:table>
  <furniture:name>Sofa</f:name>
  </furniture:table>
</root>
The above XML creates the namespace "fruits" and "furniture" in the attribute of xmlns in XML. This way we define namespaces in XML.<sup>[http://en.wikipedia.org/wiki/XML_namespace]</sup>


===Explicit Namespaces===
* The major concentration of these estimates is on delivering values and establishing trust between business and project teams.


Namespaces can be explicitly manipulated and composed, making it quite a simple matter to combine, rename and compose packages or modules. Hence some languages use keyword "namespaces" for declaring namespaces. For example, [http://en.wikipedia.org/wiki/C_language C], [http://en.wikipedia.org/wiki/C%2B%2B CPP], [http://en.wikipedia.org/wiki/PHP PHP], [http://en.wikipedia.org/wiki/C_Sharp_%28programming_language%29 C#].
* These estimates informs the business about all incoming changes.  
Below is the CPP code which depicts use of namespace keyword.


namespace Square{
* Using the size estimations reduces overall risk in project.
  int length = 4;
}
namespace Rectangle{
  int  length = 12;
  int  breath  = 8; 
}
int main () {
  cout << Square::length << endl;  //output 4
  cout << Rectangle::length << endl;  //output 12
  return 0;
}
The above code snippet tells us the use of explicit namespace by using the keyword "namespace" in C++. It defines length in two different namespaces using the keyword namespace. When the length is referenced it is referenced using the name of the namespace.<sup>[http://msdn.microsoft.com/en-us/library/014batd5%28VS.80%29.aspx]</sup>


Similarly, PHP uses the namespace keyword to distinguish between identifiers.Below is an example of PHP using namespace keyword:
==Disadvantages of agile size estimation==


<?php
Though the size estimation is advantageous, there are some problems or disadvantages of it. These can be enlisted as follows:
  Namespace A;
  Const NAME = ‘this is constant’
  Function FUN()
  {
      -----
      -----
      return _MYVARIABLE_;
  }
  Class C
  {
      function print_this()
      {
              ------
              ------
              return _THIS_METHOD_;
      }
  }
?>


The above example denotes the use of namespace keyword in PHP language. Hence in the code const NAME,function fun() and class C are defined in Namespace A. Therefore, they are referenced using the namespace A.<sup>[http://www.php.net/manual/en/language.namespaces.definition.php]</sup>
* As the estimation is done by the entire team this task needs a lot of horizontal communication. In teams where the size is relatively small, this is an easy task to achieve. But in teams where there is a large group working on a project, it makes it difficult to do this estimation[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2007/wiki3_10_10].


Similarly, C# also uses namespace keyword to distinguish names. Below is the code of C# showing use of namespace keyword.
* Switching from the traditional method of development to the agile development is a time taking process.


namespace A
* This development methodologies requires high level of customer involvement.
{
  public class A1
  {
      static void Main()
      {
          B.B1.welcome();
      }
  }
}
namespace B
{
  public class B1
  {
      public static void welcome()
      {
          Console.WriteLine("Welcome");
      }
  }
}
The above code snippet shows the use of namespace keyword in C# language. Here, function main in namespace A calls to function 'welcome' from namespace B by referring its namespace_name.class_name.function_name.<sup>[http://msdn.microsoft.com/en-us/library/z2kcy19k%28VS.80%29.aspx]</sup>


==Conclusion==
* In certain projects where there is a static requirement set, the agile development is almost equivalent to that of the traditional methods. Shifting to Agile for such projects would not cause any advantage.
Every programming language support namespaces at different abstraction level. They are not just containers but designed to allow simple,fast and efficient usage and understanding of the code. Namespaces actually provide luxury to declare multiple variable with same name which in turn protect code with name clashes. Using namespace generally gives a better structure to program which makes easier to maintain when the code length increases. In summary, different languages have different methods of providing namespace functionality be it explicit or implicit to provide better coding experience to the user.


==References==
== References ==
== References ==


# [http://snook.ca/archives/javascript/javascript_name NameSpace]
# [http://portal.acm.org/citation.cfm?id=1363634&preflayout=flat Tsun Chow, Dac-Buu Cao, A survey study of critical success factors in agile software projects, v.80 n.6, June 2008] [doi>10.1016/j.jss.2007.08.020]
# [http://www.springerlink.com/content/v04u888706r925k3/ Explicit Namespaces]
# [http://en.wikipedia.org/wiki/Agile_software_development Agile Development]
# [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2007/wiki1b_3_an Closures]
# [http://www.kruchten.org/agilevancouver/presentation_slides/Hewson%20APM%20intro.pdf Agile Project Management]
# [http://docs.python.org/release/2.1.2/ref/execframes.html Code blocks, execution frames, and namespaces]
# [http://www.artima.com/forums/flat.jsp?forum=152&thread=68916 Envision Phase]
# [http://www.codeproject.com/KB/scripting/jsnamespaces.aspx Namespaces in Javascript]
# [http://www.testingreflections.com/node/view/664 Speculate Phase]
# [http://www.javacamp.org/javavscsharp/namespace.html Namespace vs. Packages]
# [http://www.agileprojectmgt.com/docs/healthcareit.pdf Steps in Agile Development]
# [http://www.tutorialspoint.com/ruby/ruby_modules.htm Ruby Modules and Mixins]
# [http://vimeo.com/5368440 Agile Estimation by Alex Young]
# [http://en.wikipedia.org/wiki/XML_namespace XML Namespace]
# [http://www.slideshare.net/ritesh.tamrakar/estimation-in-agile-project Ritesh Man Tamrakar, Estimation in Agile Project, February 2010]
# [http://msdn.microsoft.com/en-us/library/014batd5%28VS.80%29.aspx Namespace in C++]
# [http://en.wikipedia.org/wiki/Planning_poker Planning Poker]
# [http://www.php.net/manual/en/language.namespaces.definition.php PHP Manual by Mehdi Achour, Friedhelm Betz, Antony Dovgal, Nuno Lopes, Hannes Magnusson, Georg Richter, Damien Seguy, Jakub Vrana]
# [http://portal.acm.org/citation.cfm?id=1036751&coll=DL&dl=GUIDE&CFID=114623625&CFTOKEN=63466653 Mike Cohn, Agile Estimating and Planning,2005]
# [http://msdn.microsoft.com/en-us/library/z2kcy19k%28VS.80%29.aspx Namespaces in C#]
# [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2007/wiki3_10_10 The Agile Debate]

Latest revision as of 22:01, 17 November 2010

Estimation in Agile Projects is calculated approximation of result and approach to result in agile projects which can be used even if complete and certain data is not available at the start of the project.

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[1]. 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[2] 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.

Open source project 'Expertiza' is a very good example of agile methodology application. Every group work on some part of currently working 'Expertiza' project to add more features, to make it more enhance or to correct functionality. They work on it around 2 to 4 weeks and add that functionality in existing project. After every such iteration we get working model which can be used in real life where as there is scope to decide on new features or more corrections which can cause more number of similar iterations. This process can be referred as agile method.

How agile projects are different from projects

As discussed earlier agile methodology is totally different than traditional software development methodologies. 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[3]. In agile process, the stages are also slightly different from that of the traditional processes like Waterfall Model. The 5 stages that are described in the agile development methodologies can be defined as follows

  • Envision[4]: This is the phase where the team visualizes the requirements through a data sheet. This is analogous to use case list in UML.
  • Speculate[5]: 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[6]: This phase acts as an execution phase in the life cycle. 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.

Coming back to 'Expertiza' example which can also be done in traditional way where we can decide on all features we want in 'Expertiza' and then plan how can we get them done in single iteration. But here we had to know all requirements at the beginning of planning which is not realistic approach. This is where agile process differs from traditional approach.

In case of an Agile approach, the entire work is divided into iterations. Consider that there is a task which is to be completed within 3 weeks. The requirements that are available are listed and the Envision phase is done. Next there is a series of iterations each having the Speculate-Explore-Adapt phases. After every Adapt phase, new changes or fixes are added to the Speculate phase of the next iteration. After these iterations are done the final Close phase is reached. These steps are explained further with the help of the figure below:

Purpose of estimations

Consider a student appearing for paper test where during test he comes to know that there are 20 minutes left and he has to cover 20 more subjective questions. He approximates that he can give 1 minute for each remaining question whereas in another approach for same situation he looks upon how much marks each question carried, which questions carried more marks and how much time those questions may take to complete. Accordingly he concentrates on fewer questions but completes them correctly. Later approach may take some time from 20 minutes but still it will work better towards achieving good marks in test. This example signifies how estimations are important.

Before starting project the very obvious questions that arises is 'How long will it take to complete this?' which is not so easy to answer. One might give a range saying 'It may take around 10 months to 2 years'. Anyone listening to this starts expecting it close to 10 months but do not take into consideration of range up to 2 years. This consideration may cause problems if this estimation do not turn right. This is the major reason projects need to be estimated to reduce uncertainty[7]. All further processes including planning, design, scheduling rely on these estimation which may turn unchangeable.

Estimation is critical step of any software development project irrespective of its size specially in agile processes where duration of iteration is very small compared to traditional processes. 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 iteration planning phase 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 described 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.

Example, If one user story carries 3 story points other will get 5 points as in comparison current user story will take more time for test.

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.

Example, Even if there are 2 user stories to be estimated, each user story will get ideal time independent of each other say 3 days and 5 days respectively.

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[8]:

1. Expert opinion: As the name explains, these are the judgments 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[9]: This is an easy method of estimation developed by Mike Cohn. 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.

Techniques for Velocity Estimation

1. Calculated based on history: Empirical data of same team can be useful in calculating velocity. Either average or range between maximum and minimum can be considered. The limitations with this technique is that the project has different set of team or if its project with completely new technology then this method will not be useful at all

2. Iteration run: Observes actual iteration. During the beginning of the project, teams provide at the beginning team provides some time developing obvious user stories observing team velocity. This observed velocity can be used for further estimation.

3. Calculated based on available man-days and focus factor: Initially calculates the number of man-days available for an iteration. This is calculated multiplying total number of members working in that iteration with number of working hours for each member.Consider only productive time. In order to remove unproductive time use focus factor. Focus factor is a metric to decide how much each person can focus on given task. So if we consider 70% as the focus factor, then it shows total ideal days in iteration is 70% of total man-days which is estimated velocity.

Re-estimation

As the user story progresses further, the team comes to know more about the exact data and implementation details. There could be a difference between the estimated size of the user story and the observed complexity. If the difference between these two is large enough, then it is required to re-estimate the size of user story. Also while updating a particular user story estimates, all the other user stories that may be affected due to this or the stories that are similar to this can also be updated. Correct re-estimations makes schedules more accurate.

When not to re-estimate

Care must be taken by the team in re-estimating. One must not re-estimate solely because the progress is not as rapid as they have expected it to be. The team can leave most of these inaccuracies to the velocity estimate.

When to re-estimate

During the project, there may be situations where there may be a user story that has not been completed in the iteration that it is supposed to complete in. Consider that the unfinished portion of the story is not done in the next iteration, in that case the remaining story is re-estimated, based on the knowledge about the project that the team already have[10].

Advantages of agile size estimation

Agile software development is the new norm in companies as it has many advantages over the traditional waterfall model. Estimation is an important aspect in agile development and its advantages in a company can be listed as follows:

  • All the estimates are done by all the members of the team. So it is more like the team estimating their own work and doing their planning by themselves.
  • The major concentration of these estimates is on delivering values and establishing trust between business and project teams.
  • These estimates informs the business about all incoming changes.
  • Using the size estimations reduces overall risk in project.

Disadvantages of agile size estimation

Though the size estimation is advantageous, there are some problems or disadvantages of it. These can be enlisted as follows:

  • As the estimation is done by the entire team this task needs a lot of horizontal communication. In teams where the size is relatively small, this is an easy task to achieve. But in teams where there is a large group working on a project, it makes it difficult to do this estimation[11].
  • Switching from the traditional method of development to the agile development is a time taking process.
  • This development methodologies requires high level of customer involvement.
  • In certain projects where there is a static requirement set, the agile development is almost equivalent to that of the traditional methods. Shifting to Agile for such projects would not cause any advantage.

References

  1. Tsun Chow, Dac-Buu Cao, A survey study of critical success factors in agile software projects, v.80 n.6, June 2008 [doi>10.1016/j.jss.2007.08.020]
  2. Agile Development
  3. Agile Project Management
  4. Envision Phase
  5. Speculate Phase
  6. Steps in Agile Development
  7. Agile Estimation by Alex Young
  8. Ritesh Man Tamrakar, Estimation in Agile Project, February 2010
  9. Planning Poker
  10. Mike Cohn, Agile Estimating and Planning,2005
  11. The Agile Debate
Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch6_6c_VP&oldid=41425"