#6: Decompose tasks to inch-pebble granularity. Inch-pebbles are miniature milestones. Breaking large tasks into multiple small tasks helps you estimate them more accurately, reveals work activities you might not have thought of otherwise, and permits more accurate, fine-grained status tracking.
Tip #7: Develop planning worksheets for common large tasks. If your team frequently undertakes certain common tasks, such as implementing a new object class, develop activity checklists and planning worksheets for these tasks. Each checklist should include all of the steps the large task might need. These checklists and worksheets will help each team member identify and estimate the effort associated with each instance of the large task he or she must tackle.
Tip #8: Plan to do rework after a quality control activity. Almost all quality control activities, such as testing and technical reviews, find defects or other improvement opportunities. Your project schedule or work breakdown structure should include rework as a discrete task after every quality control activity. If you don’t actually have to do any rework, great; you’re ahead of schedule on that task. But don’t count on it.
Tip #9: Plan time for process improvement. Your team members are already swamped with their current project assignments, but if you want the group to rise to a higher plane of software engineering capability, you’ll have to invest some time in process improvement. Set aside some time from your proje无忧论文 【http://www.uklunwen.com】ct schedule, because software project activities should include making process changes that will help your next project be even more successful. Don’t allocate 100% of your team members’ available time to project tasks and then wonder why they don’t make any progress on the improvement initiatives.
Tip #10: Manage project risks. If you don’t identify and control risks , they will control you. Spend some time during project planning to brainstorm possible risk factors, evaluate their potential threat, and decide how you can mitigate or prevent them. For a concise tutorial on software risk management, see my article "Know Your Enemy: Software Risk Management" (Oct. 1998).
Estimating the Project
Tip #11: Estimate based on effort, not calendar time. People generally provide estimates in units of calendar time, but I prefer to estimate the amount of effort (in labor-hours) associated with a task, then translate the effort into a calendar-time estimate. This translation is based on estimates of how many effective hours I can spend on project tasks per day, any interruptions or emergency bug fix requests I might get, meetings, and all the other places into which time disappears.
Tip #12: Don’t schedule people for more than 80%of their time. Tracking the average weekly hours that your team members actually spend working on their project assignments is a real eye-opener. The task-switching overhead associated with the many activities we are all asked to do reduces our effe |
|
论文题目：
成功项目管理的秘密 
