1.定义项目成功的标准

在项目的开始，要保证各参与方对于判断项目是否成功有统一的认识。通 常，跟紧预定的进度是唯一明显的成功要素，但是肯定还有冥他的因素存在， 比如，増圮市场占有率、获得指定的销售量或销售额、取得特定用户满意程度 等。

2.把握各种要求之间的平衡

每个项目都需要平衡它的功能、人员、工具、预算、迸度和修量目标。我们把 以上六个项目方面中的每一个方面，综合成一个约束条件，你必须在这个约束中进 行操作:你也可以定义成与项目成功对应的驱动力，或者定义成通向成功的自由程 度。项目管理铁三角:成本、时间与渍量，我们可以在这样一个铁三角规定的范围内调整，保证项目的进度。

3.定义产品发布标准

在项目早期,要决定用什么标准来谖定产品是否准备好发布了。你可以将发布标准 基于:还存在有多少个高优先级的缺陷，性能度量，待定功能完全可操作，或其他方面 表明项目我达到了它的目的。不管你选择了什么标准，都应该是可实现的、可浏量 的、文档化的,并且与客户所指的”质量"一致。

4.沟通承诺

80%的失败源于沟通。尽管可能无意中承渚不可能的事件，但不要做一 个明知不能保证的承诺。坦诚地和客户和管理人员沟通哪些实际成果。任何以 前项目的数据会帮助你做说服他们的论据，虽然这对于不讲道理的人来说没有 真正的作用。

5.写一个计划

有些人认为，花时间写计划还不如花时间写代码，但是我不这么认为。困难的部分 不是写计划，困雄的部分是做这个计划提问、倾听、思考,沟通、权衡及分析。你用来分析解决问题需要花费的时间，会滅少项目以后会带给你的意外、风险。

6.把任务分解成"英寸大小的小圆石"

"英寸大小的小园石"是缩小了的里程碑。把大任务分解成 多个小任务,设置任务过程中的里程碑，有助于你更加精确的地估计它们.暴露出在其他情况下你可能没有想到的工作活动，并且 保证更加精碓、细密的状态跟踪。

7.为大任务制定计划工作表

如果你的组经常承担某种待定的通用任务，你需要为这些任务开发一个活动检查列 表和计划工作表。每个检查列表应该包括这个大任务可能需要的所有步聚这些检查列 表和工作任务帮助小组成员确定定和评估与他必须处理的大任务相关的工作量。 8 .计划中，在质量控制活动后应该有修改工作

几乎所有的质量控制活动，如，测试和技术评亩.都会发现缺陷或其他提高的可能。 你的项目迸度或工作细分结构，应该把每次测量控制活动后的修改,作为一个单独的任 务包括进去。如果你事实上不用做任何的侈改，很好,你已经走在了计划的前面。

9.为"过程改逬“安排时间

你的小组成员已经淹没在他们当前的项目中，但是如果你想把你的组提升到更高的软件工程能力水平，你就必须投一些时间在"过程改进"上。从你的项目进度中留 出一些时间，因为软件项目活动应该包括，做能够帮助你下个项目更加成功的过程改进。不要把你项目成员可以利用的时间100%的投入到项目任务中，然后惊讶于为什么他们在主动提高方面没有任何进展。

10.管理项目的风险

如果你不去识别和控制风险,那么它们会控制你。在项目计划时花一些时间集体讨 论可能存在的风险因素，评估它们的潜在危害,并且想好措施去如何减轻或预防它们。

11 .根据工作计划而不是日历来估计

人们通常以日历时间做估计，但是我倾向于估计与任务相关联的工作计划如"人 时”为单位的数量，然后把工作计划转换为日历时间的估计。这个转换基于每天我有多 少有效的小时渗在项目任务上,我可能碰到的任何打断或突发凋整请求、会议，所 有其他会让耗费时间的地方。

12 .不要为人员安排超过工作时间80%的任务量

跟踪你的组员每周实际花费在项目指定工作上的平均小时数，实在会让人吃惊。与 我们被要求做的许多活动相关的任务切换的开销.显著地降低了我们的工作效率一个 员工一周理论上工作40小时,但不要只是因为有人在一项待定工作上每周花费10小时, 就去假设他或她可以马上做4个这种任务,如果他或她能够处理完3个任务,你就很幸运 了。项目经理应该做的是如何跟迸、管控项目的进度，而不是去对人员的工作分配进行 管理,这是项目管理中的大忌。

13.将培训时间放到计划中

确定你的组员每年在培训上花费多少时间，并把它从组员工作在指定项目任务上的 可用时间中滅去。你可能在平均值中早已经滅去了休假时间、生病时间和其他的时间， 对于培训时间也要同样的处理。

14.记录你的估算和你是如何达到估算的

当你准备估算你的工作时,把它们记录下来,并且记录你是如何完成每个任务的。 理解创建估算所用的假设和方法，能够使它们在必要的时候更容易防护和调整，而且它将帮助你改善你的估算过程。

15.记录估算并且使用估算工具 有很多商业工具可以帮助你估算整个项目。根据它们真实项目经验的巨大数据库， 这些工具可以给你一个可能的进度和人员分配安排选择。它们同样能够帮助你避免进 入不可能区域，即将任务量、小组劳动力和进度安排组合起来一看，根本不可能成 功。

16遵守学习曲线

如果你在项目中第一次尝试新的适程、工具或技术，你必须承受短期内生产力降低 的代价。不要期望在新软件工程方法的第一次尝试中就获得惊人的效益,在进度安排中 考虑不可避免的学习曲线。

17.考虑意外缓冲

事情不会像你项目计划的一样准碓地进行,所以你的预算和进度安排应该在主要阶 段忌面包括一些意外的缓冲，以适应无法预料的事件。不幸的是，你的管理者或客户可 能把这些缓冲作为你的托辞，而不是明智地承认事实碓实如此。向他们指明一些以前项 目不愉快的意外，来说明你的深谋远志。

18.记录实际情况与估算情况

如果你不记录花费在每项任务上的实孫工作时间，并和你的估算做比较,你名永远 不能提高你的估算能力,你的估算将永远是猜双

19.只有当任务100%完成时，才认为该任务完成

使用英寸大小的小园石的好处是：你可以区分每个小任务要么完成了,要么没 有完成。这比估计大任务在某个时候完成了多少百分比要实在得多。使用明确的标准来判断一个步骤是否真正的完成了。

20.公开、公正地跟踪项目状态 创建良好的风气，让项目成员对准确地报告项目的状态感到安全。努力让项目在准确的、基于数据的事实基础上运行,而不是从因为害怕报告坏消息而产生的令人误解的乐观主义。使用项目状态信息在必要的时候进行纠正操作，井且在条件允许时迸行 表扬。