【IT168 分析评论】

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

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

    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要先实现。