在澳洲实施Scrum方法2年感受

背景

团队不大，7个人，再外加一个Project Manager。

为何要Scrum实施Scrum前，公司搞的基本是很自然地瀑布流程，需求-》设计-》编码-》测试-》发布-》后期维护，很简单。长期存在的问题主要是3个：

1) 需求变得太快导致延迟交付

基本需求由Project Manager说了算。Project Manager又喜欢变想法，有时候脑袋一拍或者和市场一聊天临时起意就要改需求。大家按照他的吩咐开始改文档改设计改代码。结果做的差不多了给他一看他又有了别的想法，最后转到到了客户那里又会变更。非常折磨。

2) 测试人员前期没事后期太累

前期搞需求细化，搞设计文档的时候，测试人员都很闲。因为怕他们闲老板让他们先写测试计划。但是因为需求一直在变，所以计划也赶不上变化。等到了后期有东西可以运行了，测试又忙的半死，呼哧呼哧啊总喊时间不够。

3) 废纸一般的文档

在文档上花费的时间实在太多。公司要求从需求到测试发布一一齐全，但是文档似乎被写出来就不是为了给人看的。测试们不看（他们直接问开发和PM），PM不看（他直接问开发和客户），开发也不看（直接看代码）。最后文档就被默默地扔到一个地方再也没有人关心。

实施中的问题和解决

人都是不愿改变的。

首先是Project Manager不愿意。经常和市场客户打交道的他角色从Project Manager变成了Product Owner。以前只需要随时口头讲一下自己想要什么。现在却必须在每一个Sprint之前参加Grooming会议。一个Sprint通常2周对应的Grooming会议一下就要开4到5个小时。这让他觉得自己做的工作变多了。而一旦Sprint开始，需求就不能轻易改变。这又让他觉得自己的权力变小了，不能动辄就换想法。Sprint结束后的Review客户也会经常参加，这让Project Manager觉得自己的中间人作用被削弱。

开发人员不愿意。以前反正Team Lead让干嘛就干嘛呗，听命令就行了省的操心。现在要自己在Sprint中拿任务。Stand up会每天早晨都要开不说，每个Sprint结束要有Review和Retrospective会。但是以前的每周例会都还保留着，导致会议的数量有增无减。每个Sprint都要经历设计编码测试发布的完整周期，又还没有引入持续集成。这在以前不是问题，现在却要在每个Sprint内重复手工发布，很枯燥也耗费时间。

测试人员不高兴。每个Scprint Release都是Shippable的产品而且还经常变更功能让他们不得不反复进行回归测试和新的功能测试。

实行了3个月后大家纷纷诉苦。Project Manager觉得自己的新角色不能控制Sprint因此自己对进度没有把握。 开发测试人员都觉得干得太累一个接一个的Sprint简直没日没夜了，恨不得每一个Sprint之后都去休病假几天。

另外Sprint是以团队整体来看绩效。但是有的人能力强干得多觉得自己的成绩被别人拉平了担心到时候做绩效评估自己吃亏。

总的来说问题无非三方面：人，流程，技术

人的问题：关键是寻求公司大老板的支持，由他来发声搞定角色的定位问题。首先摆平原来的Project Manager和两个Tech Lead，让他们接受转变。同时也承诺他们在功能划定和排序上的权威性。

然后对开发团队每一个成功的Sprint都会有一点奖励（放假半天+Team Building）。Sprint翻译成中文叫冲刺，但是总是冲刺没有休息就提不上速度了。

虽然Scrum强调的是团体绩效，但是我们每个Sprint结束后还是有一张不公开的表（仅给高层可见）来显示每个人的任务完成量。每个Sprint做最难或者最多任务的开发人员，通常我们让他来在Reivew 会议上来给客户和管理层做演示，一方面让他有被重视的感觉；一方面也增强他的沟通能力为以后进一步发展做潜在铺垫。另外绩效考核方面要将个人对团队贡献比重提高。

流程问题：直接取消Team的例行周会。有Team Building替代足矣。Scrum Retrospective如果Sprint很顺利且团队一致同意，可以跳过不开。

技术问题：我们引入了TDD和CI，使得产品编译发布单元测试执行完全自动化以使得Sprint可以主要集中在编码上，同时也提高了版本健壮性。测试人员被要求和开发人员一起设计Test Case并尽量利用工具自动化测试来减轻工作量。

成效

开始提到的3个主要问题得到了不错的解决。

首先项目的变更和延迟交付问题得到了不错的修正。Product Owner和客户由于可以每2周就看到演示并讨论产品变更，基本上也不会再头脑发热随便干扰Sprint。而客户由于总是不断看到产品的演进和并得到发布的版本，也就不再对延迟问题耿耿于怀。

开发人员的积极性有提高。每一次Sprint Review对主力开发人员也是一次Show off的机会。相对于以前单纯地被分配任务，Self-Organization初见成效。

测试人员的水平则被倒逼出来了。平时不会写程序的人都从纯粹的Tester变成了会写程序的Test Developer。测试的枯燥性有很大的降低。Cross-Functional的感觉有了。

文档被弱化了。因为成员之间联系更紧密沟通更频繁，很多东西不再需要文档化了（本来也没人看）。客户虽然还是要文档的，但是他们由于能够更紧密地参与产品开发周期，对系统已相当熟悉，很多问题也不用再求助文档。

感受

高层支持第一位。至少不能反对。Scrum很可能会削弱/增强某些角色，牵扯到已存在角色的定位和利益。这些事情没有高层来逼迫是万万不行的。Scrum master其实是弱角色（Servant-Lead)。主要是保证Scrum框架不乱并且Sprint不受干扰。如果全体人员对Scrum抱有坚定信心，此角色可以由开发团队成员轮流兼任即可。Product Owner需要被激发。他们初期提出的需求经常和宽泛且容易漏掉诸如性能之类的“隐形需求”。所以Grooming非常关键。整个开发团队和Product Ower的讨论能够有效发现并细化需求。Grooming会议开3,4个小时，真的一点都不浪费时间。设计很重要。没有经验的设计会导致频繁的Refactoring。虽然Scrum标准不反对Refactoring，但是实践中发现会死人（甭管你用多么牛逼的工具）。松耦合，高内聚，可扩展的原型设计很关键。测试要会开发。测试不能只是单纯点鼠标写文档而要尽量使测试自动化。没有CI，Sprint的快速迭代式发布就是噩梦。

最后想说的是，Scrum Guide一直强调Scrum是一个“Simple but Extremely difficult to master"的框架，我个人觉得其中很重要的原因是Self-Organized的团队是非常难得的。没有有效激励措施和融洽的氛围来鼓励成员发挥主观能动性，任何框架或者流程都是白瞎。