<!-- Main Content Begins -->
<p>
<b>Overview of Agile and Iterative Development </b>
</p>
<hr />
Agile and Iterative methdologies are a more fluid, customer-driven, and evolutionary-designed approach to developing applications.
<hr />
<span class="normal">
By: <b>Brian Mains</b>
<img src="../images/spacer.gif" alt="Spacer" height="1" width="8" />
Date: May 2, 2007
</span>
<hr />
<p>
Iterative and Agile development provide a different approach to developing applications that traditional 
"waterfall" methodologies.  Agile and Iterative methdologies are a more fluid, customer-driven, and 
evolutionary-designed approach to developing applications.  Whereas waterfall development likes to develop 
applications by performing big up-front design first, agile avoids that approach and develops the requirements 
along the way.  There are many reasons for doing this, and this is not a foolish approach to designing software.  
It also does not support starting development of an application without any requirements at all; we will 
overview how requirements are developed later. 
</p>

<h3>The Problem</h3>

<p>
The more important question is: is there a reason for another methodology?  The answer to that question is 
yes, because there are considerable reasons for doing so.  There can be problems with big up-front design and 
developing a complete specification before developing the application.  Several of the problems are: 
</p>

<ul>
	<li>Not all of the problems have been completely thought through.</li>
	<li>Information comes to light that changes the application.</li>
	<li>In addition, most common projects using these methodologies are not unit-tested, though that is not always the case.</li>
	<li>Some research has stated that this approach is more fix in the future, and often contains more bugs in the software.</li>
</ul>

<p>
Note that using the waterfall methodology doesn't mean the project won't work, and using an iterative approach 
doesn't always mean that there will be significant performance gains.  "A study by Boehm and Papaccio showed 
that a typical software project experienced a 25% change in requirements" (AID, p. 72).  In addition, another 
study showed that "45% of features were never used" (AID, p. 73).  With traditional software development, these 
pose huge problems. 
</p>

<h3>Agile and Iterative Development Overview</h3>

<p>
There are many projects that fit into the agile group of methodologies that are in existence today.  The major 
methodologies are Scrum, eXtreme Programming, Unified Process, and EVO.  These methodologies mix and max some 
of their features and differ in some ways, but some of the feature are: 
</p>

<ul>
	<li>Iterative development - Development is done in iterations, which each iteration is a specific length of 
	time.  Scrum iterations are a month-long "sprint", XP iterations are 1-3 weeks, UP iterations are 2-6 weeks, 
	and Evo has 1-2 weeks.  At the end of each iteration, the team determines whether to release the product with 
	the functionality created.  The goal at the end of each iteration is to get a working product.  By getting a 
	working product at the end of each iteration, it is possible to release smaller changes more frequently, 
	making it better for the users.</li>
	<li>Up-Front Requirements Gathering - Requirements are gathered up front.  Some methodologies plan a two-day (
	or so) requirements gathering session to determine what the high-level requirements and features of the system 
	will be.  This is not a full-blown requirement specification meeting, but rather to get a high-level overview 
	of what the system will do.  XP uses story cards for this, and Evo has its own custom specification language 
	called Planguage.  UP uses UML specifications, where Scrum documents requirements in a Product Backlog and 
	uses rough-sketch UML diagrams to flesh out design. </li>
	<li>Iterative Requirement Sessions - The actual work that will be done for a system is determined a day or 
	two before the actual iteration begins, not during the requirements gathering sessions.  This is important, 
	because plans can change in the system that cause the work to be done to change during that iteration, usually 
	for good reason.  So if an iteration is about to end on Friday, the team will use some of Thursday and Friday 
	to plan work for the next iteration.</li>
	<li>Stand-up Meetings - XP and Scrum have daily stand-up meetings that last 20 minutes or so.  This meeting 
	is designed to talk about the previous day's activities and to discuss any problems that may occur or that 
	may be foreseen.</li>
	<li>Visible product output – Most agile methodologies have some sort of project output; that is, something 
	visual that the team can see.  Scrum has a product backlog, which tracks the project hours per feature, and 
	produces a chart of the current progress.  XP does something similar as well.</li>
	<li>Customer-Focused - Agile methodologies are people-focused, meaning what the customer has to say is very 
	important.  After all, developers develop software for customers.  So, customers are always involved in the 
	system.  In most methodologies, this means that the customer is a part of the project team, and that they 
	are directly involved in the process, as well as through the iterations.  In XP, requirements are verbally 
	spoken, so the XP team interacts with the customers a lot; however, all of the methodologies require asking 
	the customers about any problems/questions that may come up.</li>
	<li>Team-Oriented - In agile methodologies, the team makes decisions about the software product.  The team 
	volunteers for work, designs the project, and makes any corrections that were found from testing.  It is the 
	team that succeeds or fails as a whole, and not as the result of one person.</li>
	<li>TDD/Refactoring - Test-Driven Development and Refactoring are two techniques widely supported in 
	iterative development.  Test-Driven development is the process of creating a unit test before you actually 
	create code in your application.  This helps to flesh out a better design of a component in the system you 
	are developing.  While not really understanding the usefulness of TDD in the past, I have come to see this 
	as a great benefit for developing great software.  Refactoring is the process of making good code better by 
	changing the way that it works in small ways.  By making slight changes to the code, you can improve how 
	the code interrelates, or improve the maintainability of the code.  Sometimes we are forced to develop 
	software that turns out to be hard to maintain or understand.  However, Refactoring is the tool to help 
	make a stronger design and increase the maintainability in the application, through small changes.</li>
</ul>

<p>
This methodology as a whole has proven very successful.  In my personal development experience, this 
methodology has been very helpful for me to design software.  Because it can be very hard to design a system 
completely up-front, I am more comfortable and relaxed when using this methodology because as I design software, 
I can see how one part of the system interrelates with the other system, or it points out code that I need to 
refactor.  And, when I use this design methdology, I reduce the amount of code I have to rewrite later. 
</p>

<h3>Additional Information</h3>

<p>
To find out more information about iterative development, consult the following resources: 
</p>

<ul>
<li>Wikipedia definition of Scrum</li>
<li>Wikipedia definition of eXtreme Programming</li>
<li>Wikipedia definition of Unified Process</li>
<li>EVO methods</li>
<li>More resources at agilealliance.org</li>
</ul>

<p>
There are many more site available if you google the appropriate terms.
</p>

<h3>Resources </h3>

<p>
(AID) Craig Larman, Agile and Iterative Development, Addison Wesley
</p>
<!-- Main Content Ends -->