Shaikh Sonny Aman’s Blog

Lets learn and share!

Agile mashup in practice

Posted on | January 22, 2008 |

“Traditional methodologies are a bunch of stick-in-the-muds who’d rather produce flawless documentation than a working system that meets business needs, Lightweight, er, ‘agile’ methodologists are a bunch of glorified hackers who are doing to be in for a heck of a surprise when they try to scale up their toys into enterprise-wide-software.”

– Jim Highsmith, in “Great methodologies Debate: Part 2″, Cutter IT journal

That says, none of the methodologies is perfect alone. Since traditional/formal models like Waterfall, Incremental,RAD model, Evolutionary, Spiral, Component-Based development etc are almost obsolete and impractical. They lost their feasibility in most cases for their time-consuming and expensive nature. Besides, few developers have the necessary background to apply formal methods, they often need extensive training on the model and methods. Furthermore, these models does not support a good communication with technically unsophisticated customers.

Hence come the agile methodologies. To produce the product right we encounter many implementation in this agile era, there are many paths originated from the agile development practice.

Now, which to choose ? Should you choose one and stick to that ? In my experience I found choosing a single methodologies is quite impractical, partly because none can match up with the unique project requirement, partly because there are way too many methodologies defined :P
Lets look at the core blocks of some major agile practices.

Extreme Programming (XP)
Planning:
Planning goes along with the creation of user stories. Stories are kept in index cards with priority value set by the customer. The xp team assigns a cost in terms of estimate time to complete. If the cost is more than three weeks, the story is broken into smaller ones. Needless to say, as agile goes, stories can be added any time!

Stories which will be included are set with customer’s approval along with the delevary date. The stories with highest value and the most risky ones are implemented first.

Project velocity:
Project velocity is calculated after each release. It is a simple calculation based on how many storeis are implemented in the release. Project velocity helps estimating the next release and understand the estimation accuracy.

Design and Spikes:
XP design provides only the implementation guidelines for a story as it is written. Specifying extra functionality is highly discouraged. Do only the things that is required for the current sotry in next release. If encountered a difficult design problem, create a spike solution i.e. an operational prototype.

One thing that you must need is the use of CRC cards. These cards also contains the release and story information. They are the only design artifacts produced by XP.

Coding:
Having done with the story and desing, now dive into development ? No, wait ! First write up some test cases and unit tests. Once the unit tests are created, focus only on what must be implemented. XP also encourages pair programing.

Testing:
As mentioned earlier,testing starts before coding. Tests should be done using a framework which will enable regression testing as the iteration goes on.

Adaptive software development(ASD)

It is based on team self-organization and collaboration. It is almost a formal incremental and iterative method which gives high value on learing practice.

Speculation:
First statge of ASD is speculation when the project goal, constraints etc are decided.

Collaboration:
Collaboration in this methodology does not mean simply being a motivated team working together. It is based on trust, the team met must trust each other to
1. Criticize without anmosity
2. Assist without resentment
3. Communicate to solve a problem

Learning:
Learning is practiced by formal technical review of the component built by the team members.

Dynamic system development method (dsdm)

It is a superset of XP and ASD butt his framwork deals with highly time constrained situation under a controlled project with incremental prototyping.

DSDM approach to each iteration following the 80% rule i.e. only doing the must-do works to move to the next increment. The remainin details are left for later completion when more related requirement, change request are requested and depends on the “time-gaps”.

Interestingly, DSDM creates a prototype which will ultimately the deliverable product.

Feasibility study:
Prepare the basic business requirement and figure out the constraints.

Business study:
Breaks down the busness requirement into functional requirement, defines overall application architecture.

Function model iteration:
Prepare a fucntional prototype from the sub set of all to be demonstrated to the customer. This where 80% rule comes. Customer feedback are gathered during the cycle and work on those to make it 100%.

Scrum

Scrum is actually not a methodology, rather it is framework which will use any effective agile methodologies.

First create the prodcut back log by the product owner(can be a customer) and prioritize, then create a sprint backlog i.e. which functions are to be imlemented. A sprint  generally spans 30 days and the team is consited of 5 to 9 people. The team lead is called the scrum master whoes main responsibility is to arrange daily scrum, sharing knowledge among the team and  to ensure the team gets the best possible circumstances to accomplish the next sprint.

Feature driven development

A feature in this contex is client’s on functional requirement that can be implemented in atmost 2 weeks. Features can be categorized into a hierachical way. The small size of the features, they are simpler to design, faster to implement and easier to inspect. Point to be noted, project planing and tracking is done according to the feature hierachy not to individual features chosen arbitarily or according to any criteria.

An example of a feature can be:
“Show the last 10 posts.”
“Auto save a post after 5 min.”

There are many other methodolgies exists out there. I think methodology practice in real life is often a combination of more than one.

Do you agree ?

Category: Software Engineering

Comments

One Response to “Agile mashup in practice”

  1. Software Engineering » Blog Archive » Agile mashup in practice
    January 24th, 2008 @ 11:44 am

    [...] to front and back of audio files. Great audio information products and web site audio buttons. Agile mashup in practice “Traditional methodologies are a bunch of stick-in-the-muds who’d rather produce flawless [...]

Leave a Reply