Agile mashup in practice

“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

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.

Hello world!

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!

The role of a team lead in agile environment

I think pure waterfall model is impractical. It is as impractical as the pendulum in pure physics where the thread is of no weight and no friction exists. And that is what you can never have in the lab.

We, the software developers know there is always ‘friction’ and nothing is ‘massless’. The ever changing nature of the human mind and limitation to perceive what it needs results in modification in the requirement. That why we are agile, we don’t just fall.

Now, trust and sense of responsibility are at the base of agile methodologies among some other. Here, every member in a team is expected to be self driven and self motivated. They are given task and set free to accomplish that at their own choice. Formal managing, let alone macro managing, hardly gets its place. Then what would the team-lead do ? Should s/he dive into developing? or is there indeed any need of a team leader?

Actually, there is an unavoidable need of the team-lead-role. And s/he should never dive into developing unless it is that required. Rather, he(please add an ’s’ before ‘h’, I’m lazy.) role is to keep all his mets connected as well observe aspect of their work.

Team-Lead role is almost similar to the role of the wicket keeper in cricket; cheering up the players and catch all the balls behind. A team lead should also look for the quality and security of the code component. As well, he will also ensure development path is not deviated from the path. As we are talking about agile methodologies, change may come, but that change should be verified by the team lead.

Besides, the team lead should accumulate the knowledge learned by each of the team members. He is to somehow implement the notion of adaptive software development(ASD proposed by Jim Highsmith) i.e. focus on collaboration and learning. He is to arrange an meeting to share the knowledge of the team mets. It can be in lunch time, can be after lunch hour or whenever seems appropriate. Remember, there is no need to prepare presentation as it often time consuming and deviates the concentration from the development. Main idea is to use any wheel if developed already by a team.

One point must be concerned about at this regard is to maintain the motivation and positive team spirit. Say two techniques are developed by two of the team members for similar type of problem. Both the developers are smart and techniques are smart too. Now, to server in future which method is to be used? The team lead should carefully analyze(don’t take too much time, if not resolved drop it till a right time) the two techniques with participation of them and expectedly he should sort out the right one and has to convince both of them positively.

Always keep in concern to maintain the team spirit and motivation.

Books I have read.

Reading is my hobby and forgetting is my nature. In continuation to this, I have just started reading the book “Agile Software Development Qauality Assurance” by Ioannis Stamelos and Panagiotis Sfetsos.

Recently I was very much inspired by Hasin Hayder to read on, since that, I like to share my reading experience.

This post will contain all my read books gradually

1. Agile software development quality assurance
by Ioannis G. Stamelos, Panagiotis Sfetsos

2. Test-Driven Development By Example
by Kent Beck

3. Software engineering A practitioner’s approach
by Roger S. Pressman

4. Object-oriented PHP, concepts, techniques and code
By Peter Lavin

JQuiery

Once it used to be stated that to be a good developer one should learn a language every year. Why? The basic reason was to widen up ones view. By learning new language we can come to know about new techniques to solve a problem. Following that rule, I tasted some languages like C/C++(:P), java, Perl, PHP VB, Bash, VRML, JavaScript, C#, VC++/MFC(it should fall in C++ !), Flash Action script, SQL, Ferite etc.

Now, should I start learning python or ruby? I know they worth knowing, those are suppose to be a pleasant experience. But, what else might be done? I think knowing some api/libs can do the same! So, we learn GTK, XFC, Enlightenment, JFP, Struts, Tapestry etc.

In this way, I have started tasting JQuery. I am not saying learning, as to ‘learn’or to say “I know THIS” not just means I read few books, some articles and a handful of codes to demonstrate, rather it’s a matter of a longer period than 24 hours or 30 days.

Anyway, I am just writing about what I understand while going through the journey with JQuery( JQ ). Btw, I am studying the book, “Learing JQuery” by Jonathan Chaffer and Karl Swedberg.

What we can do with JQ:

1. Easily access to any DOM element
2. Modify the appearance on the fly [using css]
3. Change the content of the page
4. A wide range event handling to make the page more responsive to the user

Besides these using jq we can do animation on the page,

ajax

integration and simplify other javascript tasks.

JQ has an interesting factory function $() and it can refer to any object very easily, like:

1. Elements : $(‘p’) : Gets all the paragraphs
2. A particular element: $(‘#an_id’): gets the element with id ‘an_id’
3. Elements with same class: $(‘.className’)

[to be continued, feeling sleepy..]

Powered by Zoundry