[time warp here - I wrote this in late 2009, but only just noticed it was still just a draft]
We all know the drill. The Requirements have been reviewed, the Customer is on-board, and your manager wants to know how long it will take to make this thing. So you have to provide estimates.
First things first, as we all know, is to break the project down into smaller tasks, and estimate from that. The optimal size of a task to estimate depends on your environment, but it should be a small number of days.
Once you have a number of days, consider the granularity of time allowed you by your bosses and work environment - are you on a Maker schedule or a Manager schedule? If the latter, take that into consideration for any complicated sections of development.
The we get to the art of communicating this estimate to the management, and this post is a good discussion of that.
Finally, make sure that anything that your bosses ask you to do that is not already accounted for in the schedule is noted as a delaying factor.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Thursday, October 22, 2009
Wednesday, October 21, 2009
Crawling out of the chaos
Real Life has a way of sneaking up and consuming all of your time, in very amusing ways.
The job has been busy lately, but not in very productive ways. In light of that, here's a little rant on requirements for software. Unfortunately, there's often little the Ninja can do to improve this situation, because Requirements Gathering is often enshrined in the Marketing or Architecture Departments, well away from the developers who have to implement them (And as often well awat from the people who will use the system)
The things that the Ninja must do when Requirements are handed down from On High are:
Anything that is vague, get a clarification in writing - ideally in the documentation, but in an email with several of the developers and requirements authors cc'd.
Also, make sure that the requirements document is versioned, and that you have noted in email which version you are developing to. I have had more than one occasion where the document writer "improved" the requirements and "neglected" to inform development of these changes, which were well-publicized to the customer.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
The job has been busy lately, but not in very productive ways. In light of that, here's a little rant on requirements for software. Unfortunately, there's often little the Ninja can do to improve this situation, because Requirements Gathering is often enshrined in the Marketing or Architecture Departments, well away from the developers who have to implement them (And as often well awat from the people who will use the system)
The things that the Ninja must do when Requirements are handed down from On High are:
- Make sure there are as few conflicting requirements as possible.
- Make sure that each requirement is clear. Performance measured in transactions/second, for example
- Make sure that any external systems have a well-defined API to talk into the system
Anything that is vague, get a clarification in writing - ideally in the documentation, but in an email with several of the developers and requirements authors cc'd.
Also, make sure that the requirements document is versioned, and that you have noted in email which version you are developing to. I have had more than one occasion where the document writer "improved" the requirements and "neglected" to inform development of these changes, which were well-publicized to the customer.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Subscribe to:
Posts (Atom)