一、知之为知之，并真实的告之

敏捷开发，其实不仅限于敏捷开发，信任都是大家合作的基础。信任来自于几次成功合作的基础。其中，“知之为知之，并真实的告之”是一个重要的原则。我自己有一正一反的两个例子：

A、 部署到生产平台上的系统，有一个统计存在误差，有两个可能的原因：程序存在Bug，另一个是业务逻辑设计有问题。前者是开发Team的责任，后者是PO的责任。经过验证，确实是开发Team的Bug，于是真实的告之管理层，得到的反馈是找到改善质量的办法，OK。

B、 产品在试商用时，一个省公司的用户发现了问题，是邮件通知的，我们这里不能重现，于是以我们的判断告之管理层，并提出了解决方案。自己觉得不放心，第二天去用户的现场实际分析，和我们的判断场景截然不同。于是又向管理层重新做解释。在出现第二个问题时，再向管理层解释时，第一个反馈是：经过验证了吗?

知之为知之，并真实的告之，反复的重复，就会建立信任。

二、坚持原则

敏捷开发中在每一个sprint中都会出现需求变更的情况，特别是增加需求的情况。Scrum理论上讲，Team会拒绝sprint内任何需求变更的情况，但实践中是不可能的，不接受就不会被用户验收，最简单的道理。这里的用户指的是最终用户、公司的管理层，而不只是PO。需求的变更，特别是增加需求，不但会增加开发的工作量，而且会更加测试的工作量，导致发布的产品质量存在问题。所以PM/SM在对待需求变更时一定要坚持原则：

1. 首先要求PO给出变更需求的Business Value，PM/SM要和PO一起讨论，因为很多时候PO提出的变更需求是市场或者销售临时提出的，并不经过综合的论证

2. PM/SM要根据变更需求给出影响的工作量，和现在的工作量进行比较。一定不要直接告诉PO不能接受变更的需求而不给出任何原因，或者只是告之影响太大，一定要给出数据，否则会导致情绪上的对立

3. PM/SM需要给Team留出Buffer，因为变更的需求在短时间内不可能评估的非常准确。我个人的经验是Buffer一定至少有20%

4. 即使老板自己布置的新需求，也要根据前三步进行分析，并将结果抄送给老板。即使当时老板会觉得不爽，但随后他会赞同你在遵守流程和原则。

三、开发团队是主角?

和开发团队的成员经常沟通，听到最多的就是“敏捷开发”中开发团队应该是项目的主导，不应该是业务(也可以说是PO)是主导，而在实践中一般都是业务是主导，开发团队是支撑，这是敏捷开发无法在国内彻底敏捷的原因之一。

这应该是开发团队的误解。项目的主导是Business Value，PO更多关心的是Business Value，所以PO应该是项目的主导。开发团队可以进行“Self-Organization”，可以提出技术类的Story写入Product Backlog，但Product Backlog的优先级始终应该是以Business Value为出发点，如果开发团队认为某个Story的工作量很大，我们可以拆分此story。当然，在第一、二个sprint，技术类的story会实现的较多，主要是因为技术的infrastructure要先实现。

内容导航

四、独立的User Story

敏捷开发有两个很有意思的观点：“尽量晚的做决定”和“尽量快的定义和实现”。前者是为了规避需求变更的风险，后者是为了快速提交。这些对项目的成功非常重要，但这两个观点看起来是矛盾的。决定的晚了，自然没有足够的时间实现，如何快速提交?敏捷中有一个实践，也是我们正在用的，可以很好解决这个问题，那就是将Backlog分解为User Story时尽量落实为松耦合的User Story。

五、PO的能力

敏捷开发中对PO(Product Owner)的要求是很高的，对产品的business value，Roadmap，产品功能，沟通能力等各方面都要可以独当一面。但现实中某些PO对business value没有自己的判断，只是从销售或者市场部门获得需求，同时在产品功能的细节上也没有深入的考量。我们公司现有的PO大多数是在30岁以上，在电信行业都有7年以上的产品经验，合作很好。但也有一位新的产品经理，最初只是做产品经理的助理，后来不知如何也可以设计产品，根本没有business value的概念，只是老板说什么就做什么，还经常自己造一些需求，功能的细节自己也想不清楚，很难沟通。直接的影响就是开发人员需要花费大量的时间帮助 PO分析需求，真正开发的时间就很少了，每次都很被动。为此，我们是这么做的：

在团队中增加了“RA”(Requirement Analyst)的角色，每次由RA、PO、开发人员共同讨论。

对RA的要求是既要有技术背景，同时也要可以站在用户角度去根据用户使用场景分析功能需求。其实RA和QA有工作重叠的情况，但为了提高开发效率，增加RA的角色是值得的。

六、主动性

敏捷开发要求PO(product owner)和Team要充分沟通，但在实践中往往会出现以下情况：

1. PO在sprint planning会议中讲了Feature后，Team成员没有主动和PO进行细节的沟通，很多时候有不明确的地方，会按照自己的理解进行设计、编码

2. 每日构建后，PO不会去review今天完成了哪些feature，是否有不符合需求的，而是要等到在testing server上之后再去验收

原则上讲，双方的不主动是“习惯”使然，大家习惯于“各扫门前雪”，同时也会和东方人内敛的性格有关。我们在实践中是这样做的：

1. 在制定sprint plan时，不会在sprint的末端再做Demo，而是将sprint分为更小的阶段，每一个阶段做一个正式的Demo，这样从制度上保证PO对产品的关注，更早的发现风险。

2. 在绩效考核上，项目奖金的发放对象是PO和开发团队，即PO和开发团队作为一个整体对项目的成败负责，在我们公司PO的项目奖金比例是25%，开发团队是75%。项目是否成功由公司的管理层(其实就是PO的manager)决定。