Hi all,
I think the presentation of Mr. Quan and Mr. Tu is so pro(...). We would like to say thanks to Mr. Nguyen for giving us one interesting video clip. I've sent our business plan document to Miss Sang. In the next phase , we'll go through design and implementation. So, we need to work harder in order to have good product. I think that in the next meeting, we should concentrate on reviewing interface design (Mr. Nam), database design (Long, Quan), then we can have more test case for OURS (Tu, Nguyen). Anyway, enjoy U're weekend and OURS project (^==^).
Best Regards,
HNLong
8 Nov 2007
7 Nov 2007
Preview 2 is comming...^=^
Hi all,
In the next Friday (9-11-2007), we're going to have preview 2 of this course. At time, we've aready had use-case, funtional requirements, non-funtional requirement, test plan, schedule, risk plan, short video clip of discussion . As we discuss in the last afternoon, Quan and Tu would do the presentation for the next Friday. I hope that U'll do well. U can send it to me and I will refine it. Beside that, tomorrow, Nam have to send to me the estimate plan, every one have to take a look at the inspection log.
Best Regards,
HNLong,
We do the best we can...
In the next Friday (9-11-2007), we're going to have preview 2 of this course. At time, we've aready had use-case, funtional requirements, non-funtional requirement, test plan, schedule, risk plan, short video clip of discussion . As we discuss in the last afternoon, Quan and Tu would do the presentation for the next Friday. I hope that U'll do well. U can send it to me and I will refine it. Beside that, tomorrow, Nam have to send to me the estimate plan, every one have to take a look at the inspection log.
Best Regards,
HNLong,
We do the best we can...
27 Oct 2007
Delay the schedule....
Hi all,
I think that in the meeting we have a chance to make clear about the test plan and the use case requirements. As we discuss, we need to review it in the next Monday to have a better understanding. I hope that Mr. Quan'll guide us through the difficulties. If U have some problems we can discuss and try to help U. I hope that, after all, we can put our product in the site like other group.
Anyway, have a good weekend and enjoy the project!
Best Regards,
HNLong
I think that in the meeting we have a chance to make clear about the test plan and the use case requirements. As we discuss, we need to review it in the next Monday to have a better understanding. I hope that Mr. Quan'll guide us through the difficulties. If U have some problems we can discuss and try to help U. I hope that, after all, we can put our product in the site like other group.
Anyway, have a good weekend and enjoy the project!
Best Regards,
HNLong
20 Oct 2007
Finished draft schedule plan, test plan, requirement plan...
Hi all,
Today, we've already finished some draft of main part from the plan of last week such as schedule for the whole project, test plan, requirement plan. I hope we'll follow the schedule as we discussed and we try to find out the solution for estimate plan and risk plan. Thus we'll have the update version of each document in next Wednesday...
Best Regards,
HNLong
Today, we've already finished some draft of main part from the plan of last week such as schedule for the whole project, test plan, requirement plan. I hope we'll follow the schedule as we discussed and we try to find out the solution for estimate plan and risk plan. Thus we'll have the update version of each document in next Wednesday...
Best Regards,
HNLong
11 Oct 2007
Finished Vision and Scope for Preview 1...
I would like to say thanks to all team members. In the meeting today, all of us did agree about the vision and scope of OURS, what we would like to present in front of other group tomorrow, have a short video of our acitvities,.. It was really interesting since we discuss by English in every face-to-face meetings until now. I also study from all of U a lot. Anyway, keep what we're doing...We're going to become professional software project manager......Cheer!!!
Best Regards,
HNLong
Best Regards,
HNLong
28 Sept 2007
Software Estimates
“How long would it take you to walk the marathon?” If some one asked me this question, am I able to answer it? I never walked 42 kilometers, but I think so. I once did half a marathon, so I have some indication (believe me, this was years ago). I would just multiply that time by two and add a little thing. So, although I didn’t do the job previously, I can give a reasonable estimation on the duration.
“How long would it take to make your own dress?” If some one asked me this question, I am in trouble. First, I would be worried by the question itself, and second, even if I tried, I would be unable to give you a proper estimate. I would know how to make a small web site. I would know how to make a excellent spaghetti. My best guess would be something in between the site and the pasta.
Yep, we are now talking all about estimating. So, pick up the dice, and start rolling them…
Getting an estimate
You created already a nice WBS and put some millstones (just kidding, milestones) in them. That’s just fine. It is a nice structure, but it tells you nothing about the most important part of a schedule; time. Some one has to yell some dates, how long will it take, when can you start?
The best people to provide you with an estimate, are the people who will have to perform the task. First of all, they probably know what they are talking about. But most of all, it will be their estimation. Otherwise, if you have to work with the people later on in the project, and you provided the estimate, they normally will not agree and will not feel committed to do the work in your estimated time. Getting a good estimate from e.g. a programmer is not just a task for the programmer himself. The project manager plays a critical role in getting quality numbers. He has to talk with the guy (or gal), to see why he thinks it will take 7 days… Because he already walked half a marathon, or because he thinks a dress and spaghetti are the same to create. I know, I repeat myself. I already stated this before. But, just do it, for … sake.
So, the project manager is a kind of shrink for the programmers. That’s right. They just have to kick back and tell what comes to their minds, and that’s it. Yeah, right, duh! The programmer, in this case, should take steps to ensure that his estimates are getting more and more accurate. He can do this by keeping statistics on how much time he spend on what. How accurate were his previous estimates, etc.
I dug this quote up on an internet newsgroup:
“My experience is that people work to deadlines. If an engineer estimates a task will take 4 weeks, they do *not* mean 4×40=160 Hrs. They mean its feasible that it will be done 4 weeks after the start, and the Engineer will put in as many or few hours as necessary to get it done. On one hand, the Engineer will be factoring in such things as other workload going on, planned days off, etc. On the other, most people will underestimate the time it actually takes, and the experienced manager will know how to “pad” (or in some cases shrink) the estimate based on the track record of the individual.”
“How long would it take to make your own dress?” If some one asked me this question, I am in trouble. First, I would be worried by the question itself, and second, even if I tried, I would be unable to give you a proper estimate. I would know how to make a small web site. I would know how to make a excellent spaghetti. My best guess would be something in between the site and the pasta.
Yep, we are now talking all about estimating. So, pick up the dice, and start rolling them…
Getting an estimate
You created already a nice WBS and put some millstones (just kidding, milestones) in them. That’s just fine. It is a nice structure, but it tells you nothing about the most important part of a schedule; time. Some one has to yell some dates, how long will it take, when can you start?
The best people to provide you with an estimate, are the people who will have to perform the task. First of all, they probably know what they are talking about. But most of all, it will be their estimation. Otherwise, if you have to work with the people later on in the project, and you provided the estimate, they normally will not agree and will not feel committed to do the work in your estimated time. Getting a good estimate from e.g. a programmer is not just a task for the programmer himself. The project manager plays a critical role in getting quality numbers. He has to talk with the guy (or gal), to see why he thinks it will take 7 days… Because he already walked half a marathon, or because he thinks a dress and spaghetti are the same to create. I know, I repeat myself. I already stated this before. But, just do it, for … sake.
So, the project manager is a kind of shrink for the programmers. That’s right. They just have to kick back and tell what comes to their minds, and that’s it. Yeah, right, duh! The programmer, in this case, should take steps to ensure that his estimates are getting more and more accurate. He can do this by keeping statistics on how much time he spend on what. How accurate were his previous estimates, etc.
I dug this quote up on an internet newsgroup:
“My experience is that people work to deadlines. If an engineer estimates a task will take 4 weeks, they do *not* mean 4×40=160 Hrs. They mean its feasible that it will be done 4 weeks after the start, and the Engineer will put in as many or few hours as necessary to get it done. On one hand, the Engineer will be factoring in such things as other workload going on, planned days off, etc. On the other, most people will underestimate the time it actually takes, and the experienced manager will know how to “pad” (or in some cases shrink) the estimate based on the track record of the individual.”
Subscribe to:
Posts (Atom)