Sunday, July 3, 2011 10 comments

My two cents on Scrum

Scrum is an agile methodology which helps companies iterate through a product/project development to successful completion. Back in the days we all know that we were limited to the water fall model which was later extended to be known as the V-Model. Gantt charts and the like were included with these methodologies.

The practices defined within these traditional methods were concise and precise. We start off with gathering of requirements from the client, document it which usually goes as the Software Requirement Document (Known as SRS), which is later signed off by the client after user acceptance testing is done. Afterwards we have the design phase where all our class diagrams come into play as well as use case diagrams, ER diagrams and the like. Then it’s time to implement this well designed product with technologies that fit the choice. Testing and product release follows the implementation phase.

Though there were no intrinsic problems with this methodology, the problem lied in the fact that we humans are involved in every phase. In a perfect world (such as what skynet once planned) this methodology would work seamlessly and we would have picture perfect product releases. But alas, with us humans nothing is guaranteed. We all know how hard it is for us to make a decision on something at certain times. In terms of a company, when they approach a software company to build a piece of software for them, they might not know what they exactly want early on. As time goes on as they see the product they might and most usually do want something radically different to what they wanted earlier.

The problem posed by the traditional methodologies as everyone knows is that it’s very hard to go back from once phase to a previous phase as the cost and time involved in the process is of great monetary value to the company. We can’t coerce the customer to agree on our basis as client’s request are always dynamic and we as a company should have the processes in place to adapt to such changes.
This is where Scrum shines as I see. I’m quite new to the scrum process. In scrum what is usually done is that we start off with a base Product backlog which has feature tasks that the client requested. There are a few entities that are involved within the process of Scrum such as;

The Product Owner(PO) – The product owner is the one who gathers requirements from the client and creates and maintains the product backlog. Also he/she is responsible in assigning a priority to each task defined within the product backlog.
The Scrum Master(SM) – The scrum master does not involve with anything specific to the project, but acts as a supervisor helping the team and the product owner to adhere to scrum practices whenever he/she sees that they are deviating from proper processes.
The Team  – is that development team involved in the development as well as the testing of the project features.

Ok now that we have met the people involved in the Scrum, let’s see why it is so awesome. One of the eye catching points of Scrum is the fact that the team decides on the time lines rather than your project manager deciding it for you. I have been any many meetings where the developers stand there like deaf or dumb people and watch as their Project manger do the estimation giving unrealistic deadlines. In scrum the practice is that the team decides along with the PO which tasks they can take on. Usually in Scrum features are taken to fit into one sprint which is more less a month of time. This is the most efficient time as proposed by Scrum. So the team decides what they can achieve within the month and take on the tasks that fit the timeline.

The key feature to note is that they do not make the estimation based on the high level task defined within the Product backlog. They break it down to meaningful development tasks and estimate based on that. If a feature has work for more than one sprint, some features are pushed to the next release. This is a very efficient way of estimating as I see because you do not leave anything out in your estimate and are able to give credible estimates to your Product owner.

Also Scrum is dynamic in which if a customer wants a new feature added on whilst a spring is going on, though they can’t achieve it within this sprint they can always push it to the next sprint  and the wait time of the customer is minimized to just a month.

Also usually whilst a Sprint is coming to an end, the team gets together with the PO to estimate on the upcoming spring to. In scrum momentum is key, which allows teams and companies achieve its development goals in a timely manner without pressurizing the developers with unrealistic deadlines. So the team is aware of upcoming work load as well whilst within the current spring. This is a great feature of scrum the scrum practice. Planning ahead, but not too far ahead.

And also if for any reason they are unable to deliver a feature within the current Sprint they can always push it to the next Sprint and finish off.

As a couple or so Sprints go on, the team gets the feeling of the kind of work it can achieve within a particular sprint which allows them to make timely, accurate estimates on future tasks.
All in all, I believe these agile practices is the way ahead for all companies big or small as the benefits it brings along supersedes the switching costs involved with moving away from your current practices.
What are your thoughts on Scrum? Pls do leave a comment with your own thoughts on the same.

God Bless 

2 comments

Font resizing and IE

Font Size mishaps

When it comes to declaring font size we know we have a variety of methods in order to achieve it. Few of them are as below;

1.    px – the size in number of pixels
2.    em – the size relative to the parent element
3.    in – the size in inches
4.    cm – the size in centi-meters
And a few others are there as well. On top of these there are a few keywords available to define text size such as;
1.    xx-small
2.    x-small
3.    small
4.    medium
5.    large
6.    x-large
7.    xx-large
In general I have seen many people using px(pixel) definition to markup your text size. Of course this works well out of the box but one caveat it brings along with it is a small scalability issue that I am going to touch upon this article.
To start off lets vamp up a test html plus a css file to go along with it.


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> 
   
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" id="vista"> 
 
 <head>
 <title>Test my font size</title>
 <link rel="stylesheet" href="style.css" type="text/css" media="screen" />
</head>

<body>
<h1>My Awesome Article</h1>
	<p>
		Though i started the heading as my awesome article i do not actually know
		what to write about that simply could be awesome.
	</p>
</body>

</html>

body{
font-size:15px;
font-family:"Times New Roman",Georgia,Serif;
}
h1{
font-size:20px;
}
p{
font-size:18px;
}

Nothing special as you can see. It’s just a simple definition of a header and a paragraph element. And within our style sheet we have defined a font-size attribute specifying it to by 15px which will be the default size on which elements will base on. Now let’s run this and see how this looks like;






Ok looks fine to me. How about you guys? So what is the problem you might ask? You probably must be thinking I’m nuts to assume something was going to be wrong.  Though there is nothing wrong implicitly in this markup it fails in one area where if for an instance a person with bad eye sight wants to increase the default text size through the browser by going to View->Text size in Internet explorer and selecting a text size, the text in our site won’t budge. It will always stay on the default 15px size we defined.

Not what you want for your site right? A website should be accessible, readable no matter if you have a disability or not. So in this instance how are we going to fix this problem with our sites text? We want it to scale according to the user preference.

In order to do that we first need to specify the size in any one of the keywords I mentioned earlier. Afterwards any subsequent element you want to increase/decrease the size, we use percentages to define the size based on the base keyword size we defined. Ok enough words; let’s put this into action shall we?


body{
font-size:small;
font-family:"Times New Roman",Georgia,Serif;
}
h1{
font-size:180%;
}
p{
font-size:90%;
}


So now if we try to resize again we will see this time our text within the page will scale according to the user’s need. Following is a screen shot of the same;


One thing before i forget, for this to work in IE 5 you need to apply something called the Box model hack which was developed by Tantek Celik. . You need this hack because in IE 5 it displays the text one step larger than the font size keyword we define.This is the short version of the same hack defined in the site;

* html body{
font-size:x-small;/* for IE5*/
f\ont-size:small;/* for all other IE versions*/
}

That’s it guys. Most of you might already know this. So for you guys this is just a revision, for all others I hope this helped you in anyway. Comments are as usual always welcome.

God Bless


 
;