|
|
|
Written by Martin Kenneth Lopez
|
Mostly of the software developers don’t like to make schedules. They always said “Will be done when its done” well that’s not correct at all, because a very good pacification is really necessary; of course if your planning to make good software otherwise keep doing with what you are doing.
Of course a schedule must be real, I mean is worthless if you make a schedule and you forgot about it until 3 months after the development is on the way, or if you don’t follow that schedule.
The times on the schedules.. in this point everyone must be really real, even is the client is telling you that everything must be done in a month… If that is not possible.. you must be realistic the day doesn’t have 50 hours, and you cant have 10 people on an small project thinking that less time more people, because that wont work.
Continue with the time of the task on the schedules you must realize that time is money, I don’t want to sound like a person that only cares about money but sadly in the real world companies and corporations only care about money and time, well both are related. The problem is that you don’t schedule your project right, you wont know how long will take, so how do you know how much to charge for the project? Or you will give the client a blind number? What happened if this amount is less than the real one? You loose.
|
Here the big question why the developers don’t like schedules?
- Is really a pain in the ass
- Nobody even the one how makes it believe that the schedule is realistic
What can we do to fix this problem?
There is a solution call EBS (Evidence Based Scheduling) you gather evidence from historical projects that you feed back on to your schedules. This will help you to slowing down the probability that you will ship on any given date.
I been using this technique on most of the projects that I’m participating, so far is working fine. There is still a long way to follow, but at least the schedules are realistic. Of course for new projects where there is no historical data is kind of uncertain but still a beginning.
Next the steps so you can make your realistic schedule and a brief description:
1) Break the task down
This means that you must have task A in hours here an example:
Create Database structure, Time 5 hours
Not something like:
Create Database structure: Time 2 days
When you measure your task in days you really are not measuring nothing, to be realistic you must measure in hours, that’s the only way that you will create a realistic schedule. If you have general task that could take days or week you must break and break the task until you can measure them in hours, because if you leave then in days or weeks, you didn’t think how long is going to take each task that is related to the bigger one so you really don’t know how long will take that task, means that your guessing remember: Nothing longer than 16 hours for a task.
2) Track Elapsed Time
Keeping track of the time of task is very important, of course is hard to estimate the correct time for each task because there are always delays, interruptions that doesn’t depend of us.
If your keep track of your time in your task you can compare with the estimated and realize if was correct of not, if was, perfect, if not now you have feedback for future projects.
Remember if you don’t have any historical records of a task in a project assume the worst, a wide range of time.
3) Simulate the Future
Rather than just adding up estimates to get a single ship date, which sounds right but gives you a profoundly wrong result, you’re going to use the Monte Carlo method to simulate many possible futures. In a Monte Carlo simulation, you can create 100 possible scenarios for the future. Each of these possible futures has 1% probability, so you can make a chart of the probability that you will ship by any given date.
In each round of the Monte Carlo simulation, of course, you have to convert the hourly data to calendar data, which means you have to take into account each developer’s work schedule, vacations, holidays, etc. And then you have to see, for each round, which developer is finishing last, because that’s when the whole team will be done. These calculations are painstaking, but luckily, painstaking is what computers are good at.
Other good thing that could be measure but is not a requeriment is the silly time, at least that how I call the times that your boss is taking you or asking you silly things, or the time in the coffee breaks, or when you have to make interviews or go to not schedules meetings. If you can add this to your schedule will be great because you’re measuring everything.
4) Manage your projects actively
Once you’ve got this set up, you can actively manage projects to ship on time.
Here a few tips that are good to remember:
- Only the programmer doing the work can create the estimate
- Fix bugs as you find them, and charge the time back to the original task
- Don’t let managers badger developers into shorter estimates
- A schedule is a box of wood blocks
- When you make the schedule be aware of weekends and holidays, remember people are not robots.
- The day doesn’t have 50 hours, and even with the 24 people must not work 20 of those hours
- If you have to work overtime schedule that too.
Now that I mention it, one of the great benefits of realistic schedules is that you are forced to delete features. Why is this good?
Suppose you have two features in mind. One is really useful and will make your product really great. The other is really easy and the programmers can’t wait to code it up (”Look! <blink>!”), but it serves no useful purpose.
If you don’t make a schedule, the programmers will do the easy/fun feature first. Then they’ll run out of time, and you will have no choice but to slip the schedule to do the useful/important feature.
If you do make a schedule, even before you start working, you’ll realize that you have to cut something, so you’ll cut the easy/fun feature and just do the useful/important feature. By forcing yourself to chose some features to cut, you wind up making a more powerful, better product with a better mix of good features that ships sooner.
Summary
Using Evidence-Based Scheduling is pretty easy: it will take you a day or two at the beginning of every iteration to produce detailed estimates, and it’ll take a few seconds every day to record when you start working on a new task on a timesheet. The benefits, though, are huge: realistic schedules.
Realistic schedules are the key to creating good software. It forces you to do the best features first and allows you to make the right decisions about what to build. Which makes your product better, your boss happier, delights your customers, and—best of all—lets you go home at five o’clock.
Reference Joel on Software (EBS)
Mostly of the software developers don’t like to make schedules. They always said “Will be done when its done” well that’s not correct at all, because a very good pacification is really necessary; of course if your planning to make good software otherwise keep doing with what you are doing.
Of course a schedule must be real, I mean is worthless if you make a schedule and you forgot about it until 3 months after the development is on the way, or if you don’t follow that schedule.
The times on the schedules.. in this point everyone must be really real, even is the client is telling you that everything must be done in a month… If that is not possible.. you must be realistic the day doesn’t have 50 hours, and you cant have 10 people on an small project thinking that less time more people, because that wont work.
Continue with the time of the task on the schedules you must realize that time is money, I don’t want to sound like a person that only cares about money but sadly in the real world companies and corporations only care about money and time, well both are related. The problem is that you don’t schedule your project right, you wont know how long will take, so how do you know how much to charge for the project? Or you will give the client a blind number? What happened if this amount is less than the real one? You loose.
|
|
|
Last Updated ( Monday, 31 March 2008 )
|
|
