Ken Dopierala Jr. said:
Hi,
The best thing is to have experience and also know the skill level of your
team with both ASP.Net and VB.Net. If you've coded the tasks before (or
if
you've been a team lead before) then using your past experience will help.
If you've only coded before then talk to the developers you now lead to
guage their skill level. If you've neither coded in .Net or been a team
lead before then enjoy the paycheck and dole out your responsibilities to
one of your developers. Have them report to you and try to understand the
terminology they are using with you, or at the very least memorize it. If
it is confusing to you then it will probably be confusing to the people
you
report to which means you can regurgitate this terminology to them and
hopefully hold onto your job. Keep your lead developers happy and never
let
on about what you don't know. Just write it down and while they are
performing your responsibilities bust your butt to investigate and do that
dreaded "reading" thing and try to learn.
As lead this is what you should be doing:
1. Find out if ASP.Net and VB.Net are the tools you need to finish the
project.
2. Define your layers: UI, Data Access, Business Logic, and etc.
3. Use visio or pen and paper to create the prototypes of all objects.
4. Break your project down into a series of tasks for each of the layers.
5. Create milestones at which time the current version goes to QA.
6. Create a document and submit it to your boss(es). Make sure you let
them know that a change in architecture and agressive QA can offset
milestones.
7. Get the project approved and then get it finished.
8. Learn from the successes and failures of the project and use those
lessons next time around. In particular, try to learn from the outcome of
each milestone, and try to make the milestones small enough to learn from.
Good luck. I've never heard of anyone being successful at estimating
projects based on spreadsheets and documents. I've also never had the
pleasure of working in an environment where projects take the amount of time
and money that they "should take".
But then again, I've always been cynical about metrics. I don't think humans
are very good at estimating human error. It may be a better idea to reduce
the amount possible human error rather than trying to estimate the amount.
Good Software Engineering practices can help with this - things like design
and code reviews, unit, integration and regression testing, nightly builds
followed by test runs, good source control and bug tracking, and tying bugs
back into the testing cycle.
If your processes reduce the number of errors, that may make your estimates
more accurate.
John Saunders
