问题/现象：

业务信息流转的某些环节，会向相关人员发送通知邮件，邮件中附带有链接，供相关人员进入察看或处理业务。客户要求邮件中的链接，需要进行限制，只有特定人员才能进入处理或察看。总管想了想，应道没问题，不一会儿就改好了，在业务信息的查询方法中添加了限制——非处理人不得进入。测试这边，忙得脚不沾地，一人扛了两个项目的测试，但还是按照预先设计的测试用例，对该修改进行了测试，测试结果ok，非处理人通过邮件链接进入后，确实提示了“你没有权限，翻滚着离去吧”。

当晚发布生产后，客户一封邮件甩过来：管理员和法律部的为何看不到业务数据了！？没法工作了！

以为我们很辛苦才找出问题所在？No，一干人等晃眼一看，不，连代码都没有看，把总管一审问，就清楚原因了。总管修改的查询方法是公用的，管理员和法律部查看、维护业务信息，都得从这过；他这一修改，相当于加了个栅栏，全给拦住了，而他自己根本就没有想到会影响其它功能。项目经理郁闷，这么简单个原因，就得发紧急版本，咋个跟领导解释嘛，你好歹也整个高难深的问题撒。测试也后悔，当时真不应该把这个场景的回归优先级放那么低。

原因：

流入：1、开发人员对哪些是公用方法只有一个模糊的意识，不清楚具体有哪些故事涉及到了这个方法，也没有与相关负责人沟通修改方案，也没有将此信息在站会或其它形式上分享出来。

流出：1、测试没有对相应的回归场景进行测试，其原因在于当时测试人力存在瓶颈，故对回归用例排定了优先级，该场景的优先级较低，最后由于需按时封版，就舍去了这部分用例。优先级的排定，是测试根据经验和与各故事负责人讨论的结果，平衡质量风险和进度后确定的。

预防措施：

1、建立影响评估机制。

添加检查项，开发人员在将故事、故障、技术任务转换为开发完成状态时，须检查是否修改了特定类中间的方法，只要有修改，就须在卡片中标出，并在站会上分享出来。

所有人员在站会上获取信息后，评估自己的故事是否有受到影响。

测试人员根据大家提供的信息，排定回归测试用例及其优先级。

这个特定类，将根据项目的运行，每个迭代进行回顾和更新（如有必要）。

2、建立最小测试集。

业务代表和测试人员，根据业务特点，制定最小测试集，覆盖所有必需的故事。每次迭代，不管有无影响，均须完整执行这个测试集。

经验：

放过没有系统的权限设计不谈，此次问题说明了变更影响分析的重要性。

最重要的两点是信息的收集和影响点的识别。具体方法可以视项目特点而定。可以是重量级的追踪矩阵，也可以是轻量级的检查单加头脑风暴，成本和收益对等即可。关键是保证影响所带来的质量风险被压缩在可控和可接受的范围内。

同时，对于会给业务造成致命和重大影响的故事，是无论如何都需要测试通过的。如果没有时间进行全回归（对于很多项目，测试人力估计都是瓶颈所在），这一块测试所需的资源，是必需保证的。

所以，启动会上，迭代范围和故事点的评估，并不只是开发关注的事情，测试也需要给出信息，以便让项目组给出更为符合自身节奏的迭代计划。

Lessons Learned 1（敏捷项目中的变更影响分析）