1  如何避免在产品开发后期不断有重大修改，导致其它模块的连锁反应?

DCR Tell mode vs. Ask mode设计变更

在项目早期，如果大家觉得要做一个设计变更，便可以采用告知模式(Tell-mode)的形式，也就是说，修改方必须通告所有关系人：“我在这里修改了某某界面, 我在某个API 增加了一个参数。”但是修改方不必取得其他关系人(或者模块)的事先同意，就是说可以先行设计并编码。当然，如果其他关系人不同意，修改还是不能签入。

当项目进行到稳定阶段，例如达到了代码完成(CC)阶段，Tell-mode 要改为请求模式(Ask-mode)，这时，修改方必须先问“我是否可以在这里修改某某界面？”(当然还要有更详尽和充分的理由)，得到肯定的答复后，才能进行修改。这时的默认回答是“不”。

2  每周进度报告——还有多少事没做完

小飞： 我们每天都在签入新的代码，每人都很忙，但是我总觉得不太对劲。感觉事情越做越多，我们离最终目标到底是更接近了，还是更远了呢？

阿超： 这时我们可以看看各种报表，首要推荐的是TFS 的“Remaining Work”，可以看敏捷流程的“燃尽图”(Burn down chart)。如果你看到每个人每天花费的时间在不断增加，但是真正需要解决的任务(Task)和缺陷(Bug)都没有变化，甚至缓慢增加，这意味着团队离最后目标越来越远了。

可以在TFS报表设置的控制板中，进一步选择你要报告的内容，如：Iteration，选择里程碑；Area，选择项目的不同部分，也可以修改报告的起始和终止日期等[i]。

3  如何避免诧异的反应

问：     每次里程碑结束后，我们向客户汇报的时候，客户总是会惊讶地说，某某功能不是我们当初商量的那样啊，而PM却也同样一脸诧异地说，不对啊，当时咱们就是这么说好的啊，有文档为证。客户不干了，威胁不加/不改xx功能就如何如何，这时PM该怎么办?

阿超： 我们在合同里要写明到底我们要交付的是什么，这就要看PM的分析和说明能力了。有时要对客户说“不”。同时，我们在需求说明中也要从用户的角度去描述问题和解决方案，这样用户才能了解他们最终会得到什么，另一个方面是，当你给用户演示一些界面的时候，要说明哪些界面只是示例而已，哪些界面是大家同意的最终设计。敏捷的开发流程鼓励用户经常参与设计和计划，如果有条件这么做，那当然很好。

问：     项目开发中后期，开发人员用工具一统计，乖乖，足足xx万行代码，xx千个存储过程，可是每到给客户演示时，却不时出现程序的各个功能相互不配合，不能自圆其说的尴尬场景，Dev leader很郁闷，想想自己可是没少加班啊，代码量也够多，可是问题究竟出在什么方面呢？

阿超： 一个原因是每个人都沉浸在“我要写出最强大的某某类或某某模块”中，不停地优化一些没有人用的功能，但是真正能够为其他模块使用的功能却未能实现。他们忘了他们写的代码是给别人用的，而且是为了解决用户问题的。所以这个时候我们要想想“用场景驱动”的方法，保证典型的用户场景能够实现。如果从“场景”出发，各个模块的互相集成就能得到充分的测试，按照场景演示起来就更有保障了。

问：     在项目开始之前, 有很多队员还没有接触过编程语言(例如C#)，导致PM在分配任务时很难用时间来衡量，就拿写一个Web Service这一模块来说，一个熟练的程序员可能只需要两个小时，而对于初学者来说，就得先花两天来理解Web Service的实现机制和原理。在有限时间的催促下，导致一些紧急的任务不断向高手集中，而初学者的任务越来越少。这时应该怎么办？

阿超： 对于这些队员，可以考虑在他们自己的任务估计值之上再乘以4。另外，如果你是写一个商业项目，请不要让连开发语言都没有接触过的队员进行开发工作。并不是非得 “写” 程序才是对项目有贡献，有时不写也有很好的贡献。如果他们有热情，就从测试开始学习吧。请参看前面提到的“大马哈鱼洄游模型“

4. 在这个时候是否碰到 “团队成员不给力” 的问题?  请看别的同学的吐槽：

http://www.cnblogs.com/xinz/archive/2010/11/27/1889935.html