在澳洲实施Scrum方法2年感受
由 kiluyar 发布于 2014年10月14日tinyfool haiwuxing akunamotata 等3人欣赏。
背景
团队不大，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的团队是非常难得的。没有有效激励措施和融洽的氛围来鼓励成员发挥主观能动性，任何框架或者流程都是白瞎。
写得很详细，赞一个。
发现我们项目组现在的流程和Scrum很像~~~
这个流程给我最大的感受是:
- 对开发，需求确定，要变更也是在sprint结束之后有目的性的变，而不是随客户、PM突然一个想法就变。开发去sprint拿任务，每个requirement都有文档可查，这样可以量化任务，时间久了也不用担心，有据可查。
- 对测试，工作应该会比以前多，不过也更细一点，sprint多了，得看情况安排回归测试。
- 对Product Manager，可以更有针对性的制定feature，而且也更有利于深入产品的细节
不同的是，我们feature在确定之后，会由Team Leader再根据开发的实力来分配requirement，相对来说Team Leader会更累点，Project Manager放权给Team Leader。
成功实施Scrum的团队本身就不简单啦，从领导到每一位普通成员都要积极进取才行得通啊。国内不少公司都热过一阵Scrum，但是最终圆满的不多啊。
文档你现在人太少还不会感受到，以前50人团队的时候我就发现文档极端重要。原因如下：
- 没有详细的文档，就会导致模糊的地方出现开发人员决定实施方式的问题。最简单的比如：这里有一个输入框。具体到这个输入框接受什么，多少个字符，验证不通过应该显示什么，空的时候显示什么都是需要明确定义的。否则产品的品质（或者说情怀，等会儿我吐一下），就会有最差的开发人员决定。
- 不同人对于某一句话的理解是很随机的，而一个人对于记忆也是很随意的。PM说这里需要一个多选框，他以为是ComboBox，你错误的记成了DropDownList，于是你们就浪费了时间来改正错误，以及无止境的扯皮。
- 有些时候一些升级维护以及错误修复工具，尤其是上古时代产品，有一个文档解释一下一些奇怪设计的原因你会发现帮助会很大的。
- 你以后逐渐会发现，Spec不够清晰的情况下有可能出现做着做着会发现我操这个想法不对完全做不下去的情况，所以整个Sprint可能就会彻底失败的情况。其实瀑布和Scrum不是冲突的而是一个正交项，Scrum只不过是把颗粒度切细，力图（或者说试图）在尽可能短的时间里面看到成果而不是有人在做和尚撞钟，有的人则在瞎折腾一会儿这样一会儿那样，有的人则胡吹乱侃马屁火车满嘴跑而已。如果理解成有scrum就不需要文档了，那我只能说有一天你会遇到大问题的。
4楼 @kiluyar 你要理解当前速度和历史长河里面的速度不是一件事情。就算你用纯瀑布流，省略文档步骤也会在一开始剩下不少时间。但是以后你就知道了，这个擦屁股的事情迟早你是要还的。
之所以说大团队很快遇到，小团队现在可能还好，并不是说人多沟通成本高（当然这也是真的），而是人多速度快。好比远处有个冰山，你开泰坦尼克号一晚上就会出事，你一个人划个橡皮艇大概得要划一两个月。虽然总成本大团队会更高，但是单位成本就不好说了。因为你团队小，划得时间长，回头等发现问题再来回忆当初怎么想的，就好比你想搞清楚女娲补天这个故事是怎么来的一样。
另外，团队小的时候，即便你发现有问题，有可能时间赶你就会糊弄过去。等到时候发现搞不下去了才发现问题已经堆积成山了。大团队有的时候因为出于超大的总体成本，会更容易下决心在当下正确的解决问题。
反正，呃，你自己感受一下吧。也许对，也许不对。
废话多说几句，打wow的时候一个大型raid，不是几个人一拥而上，而是先少数几个人组成一个队伍，然后几个队伍拉出一个团队，每个团队先要人员配置，那些是1组，负责主攻，那些辅助组，在raid时，什么时候该做什么事，每个队伍应该怎么安排自己的节奏，这些都是有逻辑道理可研究的。玩一个游戏杀一个boss尚且如此，更何况一个大帮子人搞开发。试问你的50人团队是怎么分组的呢，一拥而上？分组没有，核心组，清道夫组，辅助组，有研究这些么？文档说白了就是一大堆人拉开了嗓子在raid频道里面的发言，有据可依，实操性欠缺。把事情越做越简单吧，不要瞎折腾。（PS：开发和游戏扯到一起，有点扯，不过瞎聊天，别太当真）
感觉解决问题的那几点都很棒，但如果不采用scrum仍旧是传统的瀑布方式，可以如何改进呢？
首先我感觉你们的pm有点搞，既然有客户为啥他会有自己的想法而又不和客户沟通？ 同时针对测试前期太闲后期太忙，可以大胆取消测试人员，让开发人员去交叉测试代码。 你们就7个人，不是70个人，真没必要还分那么多。
大赞！
用了两年Scrum了，非常喜欢。我们也没有专门的文档，都是在TFS (类似JIRA) 上面把关键点记录下来，搞不清楚的再去问product owner。
有一点感受是，团队里的developer要能力差不多才行，如果有个别人能力不行影响了Sprint的进度，真的会有怨言。
19楼 @coolesting 是的。利益关系太多。其实大部分人都是想少干活多拿钱还不负责的。Scrum要求团队集体负责，结果集体负责经常变成没人负责，最后发现还是被老板指定了要负责的Team Lead一个人在那里上火。Self-Organization是Scrum理论里面最诡异的一个地方了。Scrum Guide说的好像特别轻松。现实是大家只想混口饭而已。如果不是团队成员互相信任并且互相喜欢的情况，搞Scrum就很痛苦。
方法论这些东西只是一个工具。
想把事情做好的这个热情才是最重要的。如果一个团队有这个热情，大家就会选择出一个适合当前项目还有实际情况需要的工具。即便当时没有这个工具，大家也会发明出来的。
譬如 scrum 强调每两周一个 demo，实际上，你做出一个很酷的东西的时候，你就恨不得马上拿给人家看，还需要等到两周么？ 对于某些好的创业公司而言，他们甚至可以做到每天发布，或者每两三天。
再譬如，scrum 强调 一个 每天 standup，汇报一下个人工作情况。在一个好的团队里头，这些东西就自发做了。
当大家都很喜欢这个产品的时候，大家经常用，还需要文档么？（或许还是需要的，一个 wiki）
话又说回来，热情是一个很飘忽的东西 ：）
项目跟人的心情都是会起起落落的。
所以一些 日常固定的行为可能还是需要吧。
方法论其实就是提供了一些 toolset，然后大家可以加以裁剪地用到自己项目上，不必照搬。