SCRUM – putting a value on features, and other

I already wrote how overjoyed I was about using SCRUM, and the joy and the enthusiasm just keeps growing. After a few iterations on my latest (Srum-runned project), I’ve discovered a few things different than my previous work methods.

  • importance on putting a value on features
  • breaking down “complicated” features to more simple ones
  • the obvious scope increase after some “clarifications”

Putting a value on features

All features are not all as hard and as complicated as others, some are easier, and other are harder. Some are “unknown”, and other known, so estimations are practically impossible to define unless we break up all tasks to simple features. So burnup/burndown charts of finished features finally make sense. Usually if the tasks are listed and progress is shown in a burnup/burndown chart, the actual work done and work remaining on the chart have nothing to do with the actual progress, usually due to “not clarified” or “misunderstood” client requests and features that have not yet been started.

Breaking down complicated features to more simple ones

I’ve read a “rule” for estimations is never to estimate anything as a single task if the estimate is longer than 2 days. I absolutely agree with this. I’ve seen features estimated to take 20 days or 50 days. I consider this estimations to be lazy and risky, and this is often done to the lack of specifications or clear client requests. Cure for this would be to (even if you do not have clear client requests or specifications) write the list of features as you understood, estimate them and offer that those features will “cost” that many days/points/money. This brings another issue to this whole story.

Obvious scope increase after “clarifications”

Sure, I could misunderstand the client request, or specification, but I did promise to finish the estimated tasks in that period at that price, and if that’s wrong, it’s my problem, but if the scope increases after “clarifications”, it should be a normal thing to:

  • increase the period in which the final product will be finished
  • increase the price
  • if this clarified feature must be finished in the current iteration, the client can:
    • select a feature (weighing same amount of points) that will be excluded from this iteration
    • understand that it cannot be done, finally understanding the importance of clear specifications we’re all talking about

Finally, clients are not stupid or disrespectful of our work as we often feel. Working with SCRUM has helped me demystify the whole request/specification/estimate/development process. Earning me reduced pressure, more respect and trust from the client, and more pleasure in working on the project for both of us.

Posted in Agile | Tagged , , , , , | Leave a comment

PHP’s HttpRequest object – delayed and fragmented requests

Having trouble receiving HTTP requests made by PHP’s HttpRequest object? Well I did… A HTTP request made by a proxy service written in PHP was being send to a Web-Interface-Server written in QT, and it mostly worked fine, but every now and then, and almost always with large requests (with lots of POST parameter data) it became laggy, and lasted for 2 seconds without any good reason.

The problem appeared to be that the request came in two parts, and the second part was send about 2 seconds after the first one. After a colleague of mine point out a solution to this same problem when using curl, I fixed the problem with the HttpRequest in the same manner.

Curl solution:

curl_setopt($ch, CURLOPT_HTTPHEADER, array('Expect:'));

HttpRequest equivalent:

$r->setOptions
(
    array
    (
        'headers' => array('Expect:' => ''),    // send the request as a whole
    )
);

What does this actually mean? Well, when making a request, either by curl or by HttpRequest object, by default, header contains “Expect: 100″ parameter, meaning that the server should return HTTP code 100 before receiving the other part of the request. As this wasn’t the case on our server, we had slow and delayed HTTP requests (and I wonder why there was any in the first place). By removing or at least modifying the Expect parameter to have no value rather than 100, we fixed the issue. I hope this helps you out…

Whole request code:

$r = new HttpRequest($requestUrl, HttpRequest::METH_POST);

// configure the request options
$r->setOptions
(
    array
    (
        'headers' => array('Expect:' => ''),    // remove the expect parameter
    )
);

$r->addPostFields(array('proxy' => 'proxy'));    // add some post parameters

try
{
    // make the request
    $r->send();

    // check the return code and render contents or an error message
    if ($r->getResponseCode() == 200)
    {
        $responseBody = $r->getResponseBody();

        echo $responseBody;
        die();
    }
    else
    {
        // handle this yourself
    }
}
catch (HttpException $ex)
{
    // handle this yourself
}

Posted in PHP | Leave a comment

For loop with a delay in JavaScript

I recently had a need to run a simple for loop in JavaScript, but with a delay (or a pause, or sleep…) of few milliseconds in between iterations. It’s not as simple as I thought, but it can be done, with plane old JavaScript. This is that simple for loop I was talking about:

var words = ['Hello', ', ', 'I ', 'am ', 'in ', 'a ', 'loop', '...'];
for(var i in words)
{
    document.getElementById('output').innerHTML += words[i];
    sleep(1000);
}

Simple, yes, but it doesn’t work, however you can make something similar to have this functionality, but it won’t be a loop, and it won’t look this simple, but at least it’s possible.

var words = ['Hello', ', ', 'I ', 'am ', 'in ', 'a ', 'loop', '...'];

// (1) define the variable for the array index
var i = 0;

// (2) define the delayed loop function
function delayedLoop()
{
    // (3) do action
    document.getElementById('output').innerHTML += words[i];

    // (4) if the end of the array has been reached, stop
    if(++i == words.length)
    {
        return;
    }

    // (5) recursively call the delayed loop function with a delay
    window.setTimeout(delayedLoop, 1000);
}
delayedLoop(); // (6) start the loop

What is this example doing:

  1. define the variable for the array index
  2. define the function which will pose for the loop
  3. that function does the same action as in the loop in the first example
  4. make a check if the loop should end
  5. uses the window.setTimeout(function, delay) to recursively start that function again, but with a 1000 ms delay
  6. everything above only defined the delayedLoop funcion, so you need to call it to do anything

Working example below:

Start…

Output area…

Posted in Javascript | Tagged , , , | Leave a comment

Running multiple web-sites in your local WAMP root folder

Confused already? Of course, I’ll try to explain, so suggest a better title if you wish. If you’re using WAMP server on MS Windows (perhaps this would be even simpler to do on Linux) like I do, sometimes you add new applications to new folders in your default root folder of your WAMP server, for example:

  • c:\wamp\www\app1\
  • c:\wamp\www\site2\

which are respectively accessible from the follwing URLs:

  • http://localhost/app1/
  • http://localhost/site2/

Sometimes you will need to run an application in your root folder (http://localhost/). Sometimes you will need to run multiple applications or websites in your WAMP root folder, and since you can’t run multiple websites in your root at the same time, what would be the easiest way to switch between rooted applications?

You can do this:

  • create a set of batch scripts which would make switching websites in WAMP root fast and easy
  • and an added bonus you can even modify your hosts (c:\WINDOWS\system32\drivers\etc\hosts) file to have the www.mylatestsite.com requests redirect to localhost

Main advantage of these two things is that you can develop the website locally and just deploy it to the live server without any patching for absolute URLs to your local server. More on running multiple web-sites in your local WAMP root folder

Posted in Uncategorized | Tagged , | Leave a comment

My first SCRUM

A while ago I wrote my first article about my experience with CakePHP, and now I am so pleased with using Agile software development methods (maybe it’s beginner’s enthusiasm, but…) I’ve decided to write about Agile and everything about it as I work with it.

Today (actually 10 days ago, but I’m writing now :-) ) I had my first SCRUM meeting. A company where I work has changed it’s name and it was a great opportunity to revamp the old website, and by revamp make a new website design and concept from scratch with salvage of some existing content.

SCRUM is a completely new and revolutionary concept for myself, and from what I’ve just experienced, it:

  • significantly increases code quality
  • simplifies project planning and tracking (no more MS Project)
  • demystifies project tasks/features
  • reduces pressure on developers
  • increases satisfaction in work as you can actually
    • take part in the planning, which gives countless advantages and motivation
    • see the actual progress and your part in the “done” section
    • feel and see the finish date of the project instead of the deadline

More on My First SCRUM Meeting…

Posted in Agile | Tagged , , | Leave a comment
Stop ACTA