- 为什么需要保护？
- 谁来保护？
- 如何保护？
敏捷项目因为透明而往往趋向于脆弱——一个鼓励提前暴露风险和缺陷的精益环境，它把交付团队的一切都展露无疑，风险或者坏味道在第一时间就可以被暴露。风险或缺陷的提前暴露，在某种情况下会引起客户的不安，如果没有适当的引导和疏解，这样的不安会变成很多“反敏捷”的动作，例如：填写每日工作日志审核，或者按照合同强压开发上。结果是，我们推崇的敏捷特性——越早发现缺陷，浪费越少——最后走向了敏捷的反面。
通常的做法，其实也是最简单的做法就是有选择性地暴露，对于某些影响小的，可控的风险或缺陷，只将它在团队内部暴露，希求在内部便解决，不至于告知客户让其过度紧张而强加失去理智之物于开发团队。但是，问题往往在于，作为交付团队思考的往往是功能实现上的风险，无法站在客户的角度思考便很难在所谓什么需要暴露，什么不需要暴露问题上缺乏审慎的判断。结果是，我们暴露的风险往往不是客户关注的风险，而我们隐藏的风险往往在最后对客户产生重大的影响。
的确，这个多由程序员组成的团队充满着技术和实现的心智模型，能够站在业务级别和客户达成一致的交付团队成员少之又少，那么一个成功的敏捷团队需要有一只保护团队，形成多层的保护网，让团队反馈的风险不至于让客户抓狂，又能让真正的风险及时解决。
这个保护团队的核心是业务分析师和项目经理的配合，而站在外围负责支援的客户代表（TW的标准配置中除了业务分析师BA、项目经理PM、客户代表Client Principal之外还有交付经理Delivery Assurance——可以在更高的级别引入资源帮助成功交付）。这个组合的特点在于，业务分析师和项目经理分别在业务和团队治理领域暴露风险，而外围的客户代表或者交付经理在更高的层面，引入资源，帮助团队处理团队内部无法解决的风险。
业务分析师在业务层面暴露风险的表现在于：
及时发现需求范围之外的需求，并与客户达成共识，排除在这个需求之外。交付中最大的风险来自于交付范围，范围所指绝不单单是“这个需求包含什么”，而更重要的在于“这个需求不包含什么”。请不必担心“我没有足够能力预测到需求的变化和发展”，只要能够在基本面上分拆出不在范围里的特性，很多你没有想到的东西最后都可以归在那个被分拆出去的部分里。
及时确定需求不明确。需求不明确造成的风险是，方案频繁更改甚至回滚代码。要做到的是及时向客户明视不能达成共识的需求之风险，或者分拆出不明确的部分等待明确后进行开发，将等待的责任和后果反复提醒客户。
及时要求客户的反馈。客户往往在前若干个迭代没有任何反馈，业务分析师应鼓励和引导客户进行真正的反馈，反馈集中在最后爆发对于项目来说是极大的风险，此外，如何合理地设计迭代计划，使得客户尽早地“有感觉”并提出反馈，也是及时暴露风险，及早解决的方法之一。
在项目管理和团队治理层面项目经理暴露风险的表现在于：
建立各种渠道收集来自于团队的风险担忧。利用各种手段，获取团队内部各种声音，可以通过回顾会议、心情曲线回顾或者一对一的沟通，收集一定时间内项目内部的“坏味道”，区分出可以内部解决的和需要客户帮助一起解决的，并努力解决。
与客户端项目经理紧密的绑定关系。由于业务分析师对应的往往是某个业务点上的代言人，当在多个业务点上需要达成一致的时候，项目经理的作用体现在于，和客户项目经理的关系越紧密，寻找到仲裁者的成本就越低，在客户端达成一致的速度就越快，对团队的风险就越小。
及时向上反馈，获取帮助。如果说业务分析师连接客户和交付团队的桥梁，那么项目经理便是为团队寻求外部资源的管道。当团队遇到不可解决的问题的时候，项目经理的职责在于向上反馈，典型的情景是联合客户代表，利用其深厚的客户关系资源，和处理客户关系的技巧，为团队缓解压力。
敏捷团队的技术保护网是自动化测试和持续基础环境，而在项目管理方面，这个保护网体现在项目经理和业务分析师良好的互动，在团队治理和需求管理两方面及时暴露风险，寻求解决，在这个内部保护网之外是和团队通力合作的客户代表。三方一起的协助，才能使及时暴露的风险可以被及时处理，保障敏捷项目的顺利交付。