Scrum敏捷开发
什么是Scrum敏捷开发 Scrum是敏捷开发的一种，是一种以人为本，迭代式增量软件开发的过程，以英式橄榄球争球队形（Scrum）为名，因此可以想象，整个团队是高效而富有激情的。以人为本，即Scrum开发特别强调沟通，要求团队所有人员都坐着一起工作，通过高效的沟通解决问题。
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 Retrospective
Sprint Planning：需求评审会和迭代启动会，这个会议上，需要得出以下结论：
全员明确清晰的迭代目标 澄清所有的需求及技术实现风险 评估需要的工作量，以及需要投入的人员 确定出所有最终需要发布的功能集合及工作量，需要将Story拆解成Task，以小时为单位。 Daily Scrum Planning：每日站会，顾名思义，就是站着开会，大家围成一个圈或者半圈，这样做有两个目的，一个是高效，另一个是可以方便团队所有人都可以看见对方。站会的目的有以下3个：
监督个人的承诺：确认个人是否完成昨日的目标 培养团队文化 了解项目进展：团队中每个人都应该了解其他人在做的事情，以及当前团队的进展和风险。最实际的好处就是这样可以清楚的知道别人做的事情是否对自己有影响，或者自己是否可以提供帮助等。 站会的时间，建议不超过15分钟，只描述状态和任务，不讨论技术细节，另外，每个人围绕以下3个话题来简单描述自己的进展：
昨天完成了什么？ 目前有什么困难，需要帮助的？ 今天准备做什么？ 站会的时候，Scrum Master一定要注意以下问题：制止不必要的讨论、禁止小会、控制发言时间、不要跑题等，另外，站会的时候，Master需要修改燃尽图（后面会有对燃尽图的详细描述）。
Sprint Review：迭代评审会，此次会议的主要内容是相关利益者及团队成员展现本次迭代的功能增量，需要注意的是不展示未完成的功能，也不需要PPT，演示结束后记录好相关反馈。很多采用敏捷开的团队都不开Review会议，其实Review会议是有一定的好处和目的的：
可以让团队的成果得到认可，提升团队的自我价值感 其他人可以了解团队在做的事情 可以吸引一些利益相关者的注意，并得到一些反馈 演示能够对团队成员造成的一定的压力，迫使团队认真完成工作 Sprint Retrospective：迭代回顾会，会议主要是回顾此次迭代的整体情况，一定要全员参加，一起回顾此次迭代做的好的地方，以及需要改进的地方，并对这些需要改进的点，提出改进措施。
Product Backlog & User Story User 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开发可以完全适应现在互联网开发里的”小步快跑“，以轻量级的Story作为需求进行迭代式开发，保证最重要的总是优先做。 可以持续向用户交付有价值的软件产品，以及短的软件交付周期：这是现在的互联网开发的基本要求，就是不停的通过每次迭代和升级，进行产品的优化和提升。 项目团队的透明性：团队所有成员都可以完全了解当前的项目进展和问题。 低的软件成本：Scrum开发可以让产品快速试错，即使错了，浪费的也最多是一个迭代的资源，而不会像瀑布开发，有可能浪费的是好几个月的资源。 高的投资回报率：以较低的成本，和高效的模式进行产品的迭代，回报率当然会较高。