Adobe Premiere Pro小组的Scrum实践

Adobe Premiere Pro小组的Scrum实践

①使用敏捷开发的原因：计划超期25％，重要的原因是在改Bug。敏捷转型首先使用的是Scrum

 

 

②人员比较多，Scrum团队如何组成？方案是：包含3个跨职能团队，Program manager作为三个团队的Scrum master，Senior Product Manager作为CPO，有最终的发言权，但是PO组包含了EngineeringManager、Scrum Master、Quality Engineering manage、User Experience designer。

 

 

③ Adobe Premiere Pro team 最初引用Scrum遇到的三个首要障碍：如何和异地团队协作、如何拆分需求并保证拆分后的需求仍然具有价值、如何和使用瀑布开发的其它团队协作

 

 

④如何和异地团队协作？他们做过一种尝试：把当地的团队组成一个Scrum团队。这样减少了沟通的障碍，但这样的尝试失败了，因为当地的团队不具备跨职能团队需要的技能组合，使得他们不能独立完成需求的交付。他们又做了另一种尝试：Scrum团队的组成原则，更多的考量技能组合以及人际的关系，而较少的考量地域。遇到的障碍是沟通。为了解决这个问题，所有的人被要求用Adobe Connect tool，达到模拟“在一起工作”的效果。

 

 

⑤如 何拆分需求并保证拆分后的需求仍然具有价值？需要从传统的根据架构分层开发转变到交付有商业价值的小需求。具体的做法就是根据价值拆分为小的需求，并纵向 切割架构的分层，以保证每一个价值可以交付，同时保证完整的测试可以进行。传统的架构分层的做法，完整的测试需要各层都完成后才可以进行。

 

 

⑥如 何和使用瀑布开发的其它团队协作？共同遵守重要的里程碑，向使用瀑布开发的团队推荐敏捷开发中的优秀实践以减少整合的风险，例如风险前移、测试前移、结对 编程、持续集成等。应该说，在这种场景下，使用敏捷开发的团队并不能轻易改变已经制定的整体协作计划，也就是说，应对变化的需求并不容易。如果要有好的效 果，瀑布开发的团队还是需要向敏捷开发演变。

 

 

⑦如何判断质量有了大幅提升？Adobe Premiere Pro team用的度量数据包括：1) 交付测试的严重bug；2) 回归测试Bug的收敛率 3) 实际bug修复的比例

 

 

⑧ Adobe Premiere Pro team使用瀑布开发的方式的教训：在测试阶段出现大量的bug，由于交付压力，往往采取“快速解决但增加长期成本”的做法，例如1) 延期修改bug，虽然这些bug会影响客户的使用；2) 修改bug的症状，但没有考量根本原因 3) 修复bug并没有重构代码以保持整洁，增加了代码的复杂性。以上都增加了代码级别的技术债务。另一个层面，大量的加班修改bug导致下一个版本的前期效率低下。

 

 

⑨优先级最高的需求不见得是功能级需求，很可能是技术类需求和非功能性需求，这要看产品所属的阶段。Adobe Premiere Pro team 最初引用Scrum，第一个发布的目标就是保证产品的可靠性和性能，因为这是该产品当时最大的问题。“非功能性需求不满足造成的损失往往是这类需求的最大价值”