Scrum敏捷开发 - 经验篇

什么是Scrum敏捷开发

Scrum是敏捷开发的一种，是一种以人为本，迭代式增量软件开发的过程，以英式橄榄球争球队形（Scrum）为名，因此可以想象，整个团队是高效而富有激情的。以人为本，即Scrum开发特别强调沟通，要求团队所有人员都坐着一起工作，通过高效的沟通解决问题。

为什么要敏捷开发

传统的软件公司大都是使用瀑布开发模式，流程是以下这样的：

瀑布开发模式一般都需要很久的开发时间才能交付，笔者目前所在公司，以前开发产品都是利用瀑布开发模型，往往需要至少三个月到半年的开发周期，而过程往往都是这样的：产品经理完成一款产品的所有需求—UE设计出原型和视觉— 开发完成开发— 测试完成— 产品经理和UE验收的时候永远是一副不可思议的惊讶表情，觉得交付的产品和自己当初的设计相差甚远，这个时候就会出现很纠结的事情，改？还是不改？改，牵扯到软件结构，项目周期，交付时间等一系列问题；不改，产品最终效果无法交付。因此最终的结果都会是稍微改一点，即产品结果接近而不同于原本需求，所要增加的人力和时间成本又不会太高。另外还有一种情况，就是开发过程中遇到不可抗拒的需求变更，这个时候对开发的架构、交付日期都有非常大的影响，经常出现一个变更导致前3个月甚至更久的工作返工白做，而这个时候浪费的成本是非常大的。久而久之，会发现每次的产品开发都是这样一种令人疲惫的模式。

上述这种情况，我相信有很多团队都会遇到，而且很普遍。当然这里有最大的问题是，产品经理和UE交付了需求和设计之后，则和开发团队的沟通变得很少，开发和测试团队遇到问题，也很少和产品经理沟通。这里原因很复杂，可能和人有关，可能和公司文化或者公司流程有关。当然，这不能说是瀑布开发模型的错，只能说瀑布开发模型比较容易出现这种问题，原因很简单，开发周期越久，不可控的因素和风险就越大，最终的结果就越容易偏离最初想法。

而敏捷开发的流程是这样的：

可以看出和瀑布开发模型的区别了吗？就是将一个完整的瀑布开发过程切成很多个短的，迭代式的瀑布开发过程，即迭代瀑布。那么这么做，就一定能解决上述遇到的问题吗？本文将在最后给出答案。

Scrum的模式和流程

标准的Scrum开发模式

以下是标准的Scrum开发模式：所有的需求都到达PO/PM这里，整理出Product backlog，每次的迭代开发（Sprint）都是PO/PM从Product backlog里挑出需要开发的部分需求，然后团队一起开planning meeting，确定出sprint backlog及交付日期。接下来利用2到4周的时间进行开发和测试，其中每天都要开站会（Scrum meeting），团队内部成员在这个会议上了解整个迭代的进展情况，最终交付后，团队一起开sprint review和retrospective会议，而这整个过程都有一个很关键的角色Scrum Master来把控和组织。

这样描述可能还不太理解，下面则进行详细的分类描述。

开发周期

Scrum开发一般建议为2-4周为一个周期，以两周为例，整个时间线大概如下，可以看到第一个迭代的结束和第二个迭代的开始是有重合部分的。

三三四原则

Scrum开发有一个“三三四”原则，即三个角色、三个产出物、四个会议：三个角色：PO、Scrum Master、Dev Team

PO：Product Owner，一般都是产品经理，负责需求分析和整理、分解验收story、维护Product backlog等（关于backlog和story会在下面有详细的描述）。

Scrum Master：扮演推动者的角色，他要负责主持会议、协助团队内部成员解决困难、解决外部对团队内部的过分干扰、和外界的主要沟通工作等。Master可以由专门的人来担当，也可以由团队内部的成员来担当，很多团队都是由PO来同时兼任Master，笔者建议由团队内部成员轮流担当，这样能够培养团队成员的责任感，增强团队的凝聚力，并让大家更加容易理解敏捷开发的精髓。

Dev Team：整个开发和测试团队，包括UI设计师等所有相关人员。

三个产出物：Product Backlog、Sprint Backlog、Potential Shippable Product Increment

Product Backlog：产品需求池

Sprint Backlog：此次需要开发的需求集合

Potential Shippable Product Increment：可交付的结果

四个会议：Sprint Planning、Daily Scrum Planning、Sprint Review、Sprint RetrospectiveSprint Planning：需求评审会和迭代启动会，这个会议上，需要得出以下结论：

全员明确清晰的迭代目标

澄清所有的需求及技术实现风险

评估需要的工作量，以及需要投入的人员

确定出所有最终需要发布的功能集合及工作量，需要将Story拆解成Task，以小时为单位。

Daily Scrum Planning：每日站会，顾名思义，就是站着开会，大家围成一个圈或者半圈，这样做有两个目的，一个是高效，另一个是可以方便团队所有人都可以看见对方。站会的目的有以下3个：

监督个人的承诺：确认个人是否完成昨日的目标

培养团队文化

了解项目进展：团队中每个人都应该了解其他人在做的事情，以及当前团队的进展和风险。最实际的好处就是这样可以清楚的知道别人做的事情是否对自己有影响，或者自己是否可以提供帮助等。

站会的时间，建议不超过15分钟，只描述状态和任务，不讨论技术细节，另外，每个人围绕以下3个话题来简单描述自己的进展：

昨天完成了什么？

目前有什么困难，需要帮助的？

今天准备做什么？

站会的时候，Scrum Master一定要注意以下问题：制止不必要的讨论、禁止小会、控制发言时间、不要跑题等，另外，站会的时候，Master需要修改燃尽图（后面会有对燃尽图的详细描述）。Sprint Review：迭代评审会，此次会议的主要内容是相关利益者及团队成员展现本次迭代的功能增量，需要注意的是不展示未完成的功能，也不需要PPT，演示结束后记录好相关反馈。很多采用敏捷开的团队都不开Review会议，其实Review会议是有一定的好处和目的的：

可以让团队的成果得到认可，提升团队的自我价值感

其他人可以了解团队在做的事情

可以吸引一些利益相关者的注意，并得到一些反馈

演示能够对团队成员造成的一定的压力，迫使团队认真完成工作Sprint Retrospective：迭代回顾会，会议主要是回顾此次迭代的整体情况，一定要全员参加，一起回顾此次迭代做的好的地方，以及需要改进的地方，并对这些需要改进的点，提出改进措施。

Product Backlog & User StoryUser Story：即用户故事，是一个解决用户某个问题的，对用户有价值的，某个功能的，一目了然的描述。这里有一个理念需要注意，即多个小故事胜过一个庞大的故事，因此User Story的描述非常重要，好的用户故事具备INVEST原则：

Independent：可以独立开发

Negotiable：可以协商

Valuable：有价值

Estimable：大小可评估

Sized appropriately：合适粒度

Testable：可测试验证的

User Story的描述一定要站着用户角度，而且一定要注意颗粒度，一般以这种格式”作为一个<角色>，想要<活动>，达到<目的>”来描述。另外，根据经验，笔者建议描述的时候可以不用这种句式，但是思考的时候一定要这样思考，因为所有事情，过分的追求形式就会失去他本身的价值，但是从这个角度去思考每一个需求和功能点，对产品经理分析需求确实有非常大的帮助。接下来举几个User Story的例子：

“图片编辑功能“：不是一个好的User Story，首先颗粒度太大，其实大小不可评估，因此需要对这个需求做拆分，拆分成小的User Story；

”作为一个喜欢自拍，又希望自己可以拍出来比较白的用户，可以通过图片编辑的美白功能，使自己看起来白一点“：该Story是一个比较好的User Story，当然，思考这样思考，记录的时候，完全可以简单描述为”图片编辑增加美白功能“。

User Story的分解是一个技术活，对产品经理是有一定的要求的，当然，一切从用户角度出发，多思考用户场景，那么这个问题也就也就没有那么难了。

Product Backlog：User Story的集合，即产品需求池，这里面包含所有和该产品相关的需求，根据笔者经验，这些需求最好包含以下状态：need to check、pending、reject、planning、developing、released、wait to dev，这些状态基本包含了一个需求的所有可能的状态，对产品经理管理需求有非常大的帮助。

看板 & 燃尽图

看板一般是一个物理白板，目的是做迭代进展可视化跟踪和协作沟通。看板上需要将每个人的任务，以对应的状态（To Do/Not checked out、Doing/Checked out、Done）展示出来，一般使用便签纸。

同时要在白板上画出燃尽图，燃尽图指示的是当前剩余的工作量，是一个跟踪项目进展非常好的指示器。燃尽图上一般有2条曲线，如下图的燃尽图，灰色的直线表示的是最优剩余工作量曲线，蓝色的表示实际的剩余工作量曲线，正常情况下，蓝色的线应该在灰色的线上下浮动，并在最后一天合到同一个点上。燃尽图可以在每天站会的时候由PO更新状态。

关于看板和燃尽图，有以下一些需要注意的点：

每个功能通过测试，且PO认可，才算结束；

白板上也要讲测试、UE等的任务放上去；

bug修复的任务可以估算出工作量，作为单独的任务放在看板上；

延期的任务，应该注明延期天数；

只有完成的任务才在燃尽图中删减工作量，所以，如果增加了工作量，燃尽图的曲线可能会向上。

一定要注意的问题

上述基本将Scrum敏捷开发的核心内容和工作流程描述完全，那么在实际操作过程中，难免会遇到各种问题，下面笔者将根据经验，提出实操过程中需要注意的事项：

关于团队，Scrum敏捷开发原则上是需要团队所有人坐在一起的，但是实际情况中，难免遇到异地问题，异地问题确实会对Scrum的实施过程造成一定的困难，并且也会将效果大打折扣。百度为了解决这个问题，研发了专门用于解决异地敏捷开发的显示器和看板工具，团队每天面对显示器进行开会和状态沟通。当然，大部分团队是没有这种条件的，但是现在有很多在线Scrum开发 工具 来跟踪状态代替看板，比如Leangoo、禅道等，站会大家无法面对面，最简单的办法只能是采用电话会议。不过笔者建议，在需求启动会、回顾会和评审会的时候，团队部分成员最好出差，确保团队所有成员可以面对面来开会，否则只要无法面对面，就会有大量的潜在风险，导致Scrum开发变成形式主义。但是，只要团队没有坐在一起，Scrum开发就会大打折扣，所以异地团队在实行Scrum开发的时候需要做好这个心理准备。

站会的时候，一般可以由PO来移动任务卡片，这里建议由团队成员分别移动自己的卡片，这样做的好处是，可以培养成员的责任感，并在发生delay的时候，造成一定的压力。

Scrum开发的团队成员一般建议在7人左右，不要超过10人，如果团队成员太多，建议分成小的Scrum团队，然后每个Scrum团队的PO再聚到一起沟通状态。如果每个Scrum团队的成员过多，很容易造成效率的低下和沟通问题。

Scrum强调的是团队，因此是整个团队成功或者失败，而不是某个人，需要和团队的成员强化这个观念，来培养团队的责任感。

需求评审会一定要确保所有人对需求完全了解，并达成一致的认可。不要觉得在开发过程遇到需求不理解再进行沟通，这样会给此次迭代带来非常大的风险。

很多情况下，站会往往会变成”汇报会“，即团队成员向PO汇报工作，并且成员并不听别人在讲什么。因此，首先从PO这里，需要注意不要给团队一种压迫式的听取汇报的感觉，并且，刻意地将站会培养成沟通会。

Task的分解一定要注意工作量，工作量越大就会潜在越多不可控的风险，因此原则上，每个task不能超过8小时。

测试人员在Scrum开发中，很容易被遗漏掉，而导致测试过程中出现风险，比如不清楚需求，测试case没有按期编写完成导致测试delay等。因此从一开始需求评审的时候，就要注意除了开发人员，测试人员也要对需求完全理解。

SW和VAL人员的沟通不积极，经常需要Scrum master或者其他人推一把，这个是很多传统的IT公司的通病，尤其是进行瀑布开发时有非常严格的开发流程的公司，这种问题更加严重。工程师往往习惯了在系统上提交bug，查看bug，通过在系统上添加comment沟通的形式，而Scrum开发，强调的就是通过面对面沟通来提高效率。因此当团地成员出现沟通问题时，Scrum Master一定要提出来进行告诫。

产品的质量大于需求，这点是很多产品经理往往忽略的，和Scrum开发无关，而是做产品的基本要求。因为很多团队在开发的时候，产品经理为了快速将需求投入市场，而忽略的产品本身的质量，结果导致用户对产品较低的评价甚至产品死亡。Google数据称，Play Store上60%的差评是因为产品质量。

以上提到的所有问题，或者这里没有提到的，Scrum开发中可能遇到的各种问题，最直接的解决办法就是”提高工程师的意识''，当然，这是最简单，也是最困难的解决办法，需要时间以及Scrum master的培养。

敏捷带来的价值

快速响应变化，及时响应用户反馈，调整优先级：Scrum开发可以完全适应现在互联网开发里的”小步快跑“，以轻量级的Story作为需求进行迭代式开发，保证最重要的总是优先做。

可以持续向用户交付有价值的软件产品，以及短的软件交付周期：这是现在的互联网开发的基本要求，就是不停的通过每次迭代和升级，进行产品的优化和提升。

项目团队的透明性：团队所有成员都可以完全了解当前的项目进展和问题。

低的软件成本：Scrum开发可以让产品快速试错，即使错了，浪费的也最多是一个迭代的资源，而不会像瀑布开发，有可能浪费的是好几个月的资源。

高的投资回报率：以较低的成本，和高效的模式进行产品的迭代，回报率当然会较高。

总结

首先，回顾下文章一开始的问题，文章开始提到瀑布开发模型容易遇到的2个问题；

第一，开发结束时，交付产品无法达到预期：Scrum开发将开发周期缩短到了2到4周，并且每天通过站会的形式进行状态的沟通和跟踪，团队成员通过沟通来解决问题，这些工作方式理论上可以完全避免这种问题的出现。

第二，不可抗拒的需求变更，导致大量的资源浪费：根据上述敏捷带来的价值，我们可以看到，小步快跑+快速试错，即使浪费，最多也只是浪费2-4周的资源。

当然，Scrum开发只是帮助团队减少上述问题的出现概率，而非完全解决，这里的核心不是瀑布开发模式或者Scrum开发模式，而是团队责任感和意识的问题，没有责任感的团队，无论如何使用Scrum开发模式，也只会到徒有其表，甚至可能造成反作用，团队成员为了敏捷而敏捷，没有交付出好的产品，反而在这些形式上浪费大量的时间。所以，敏捷开发不是万能钥匙，有些领导一听说敏捷开发，就要团队去实行，结果往往造成更大的问题，因此，团队出现任何问题，都首先要从根本出发，寻找问题原因，再进行对症解决，Scrum开发模式只是办法之一。

另外，Scrum开发里所有的工具和方法都只是协助，不要过分的依赖形式很重要，敏捷只是一种方法和理念，或者说是一种态度。现在很多互联网公司，虽然没有在嘴上每天吵着敏捷开发，没有看板，也没有站会，或者将Scrum开发的流程“本土化”，但是他们依然敏捷，依然可以高效的开发和产品迭代，原因很简单，使用了敏捷工具和流程并不是真正的敏捷，“敏捷意识”最重要。