敏捷实践：Scrum的核心概念和基本实践（一）

　　Scrum是迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum是一种产品开发过程的模式，包括了过程中的具体实践和角色定义，它也是一种计划管理方式。
　　本文主要介绍Scrum的核心概念和基本实践，让大家可以快速在团队中开始运用Scrum的管理方式，并能初步看到采用Scrum的好处。
　　一、迭代式增量开发
　　迭代式增量开发是相对于瀑布式开发而言的。瀑布模型是由W。W。Royce在1970年最初提出的软件开发模型，是一种老旧的计算机软件开发方法。
　　瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行。瀑布模型一般用于需求固定，开发周期较长的过程管理。
　　在互联网项目中，首先不满足瀑布开发的一个条件就是“需求固定”。一般瀑布模型的开发过程会持续半年或者几年，如果互联网早期项目采用传统的瀑布模型，可能产品没做出来，公司的钱就烧光了。并且一般的互联网产品的需求会经常发生变化，来自老板的、市场的、运营的等等。
　　瀑布式模型把开发的角色定义为单向流水线，但Scrum的开发过程如下图所示：
　　〔截图1：Scrum过程管理〕
　　完整的Scrum流程看起来还是很复杂，不过现在大家没有必要完全看懂，只要知道Scrum是按照迭代周期（2～4周，也可以是1周）为单位制定开发计划和节奏的。
　　二、从需求池开始
　　瀑布模型中认为，需求需要事先完整地确定下来，然后形成文档后交给开发进行架构、数据库、编码的设计。需求文档就是产品出来前的非常细致的产品文档。
　　Scrum模型中认为，需求是会随时变化并且增加的，需求是用需求池（ProductBacklog）的方式管理，每次的迭代周期从需求池中挑选当前最重要的需求来实现，其他需求等到下次迭代再来处理。Scrum中的需求根据优先级分层次进行管理。
　　〔截图2：需求优先级〕
　　〔截图3：完整的需求池〕
　　关于需求池的管理，大家可以参考我的另外一篇文章《【十年老产品】教你管理需求池》。产品经理将搜集的需求通过需求管理工具进行管理，需求池是进行下一个步骤的前提。
　　三、计划会
　　在进入迭代周期前，首要确定的一件事情是更新自己的版本库，确定这次即将迭代的版本号。
　　在每次迭代周期前的固定时间，团队成员会开一次需求计划会，这个会议会确定下一个迭代需要完成的任务的优先级。建议参会的人员有：产品经理（ProductOwner）、Scrum主管、开发团队、设计团队、测试团队。如果公司老板有时间，强烈建议让老板参与计划会，这是一个“培训”老板产品意识的好机会。
　　需求池中的需求分为：待处理、开发中、已验收三个状态。在计划会中我们把所有“待处理”的需求按照优先级排列。
　　开发人员确定周期内可以完成的需求，将挑选出来的需求指定到新的版本号，这些需求的状态会更新为“开发中”。
　　
　　需求确定后，由Scrum团队将需求进一步分解成具体的开发、设计、测试的任务，Scrum团队成员按照任务列表进行后续的任务分配。
　　在做工期评估时一定要根据产品和团队的具体状态留出部分的bug修复时间。并且工期由Scrum团队来决定，产品经理（包括老板）只是确定优先级，解释需求内容，一定不要强制给团队安排开发任务。
　　1。MVP
　　MVP（minimumviableproduct，最小化可行产品）和常规产品不同，MVP更侧重于对未知市场的勘测，用最小的代价来验证你的商业可行性。举个例子，如果你希望做一个图片分享网站，那么作为产品原型，MVP仅仅包含最基础的功能，形态或许就是一个提交图片的按钮以及图片的展示。
　　需求分为核心需求、基本需求、扩展需求。MVP只会包含核心需求部分。一般的产品，在前一两个迭代周期就应该完成MVP的产品开发，让市场运营人员投放给用户使用。MVP应该作为互联网产品的一个起点，后续的迭代开发都是以它为内核不断扩展。
　　2。需求锁定
　　迭代开发的方式相比瀑布模型加快了开发团队的节奏，其实对开发团队的规划、设计能力提出了更高的要求。但是迭代周期不要定得短于一周，需要给团队留出一个相对完整的时间进行代码结构的整体优化和调整。
　　并且这里需要特别指出的是，在进入迭代周期后，所有“开发中”的需求是锁定的，不允许随意增加和修改。当然老板和产品经理在遇到特殊情况时还是有一定的特权，但特权使用是在消耗团队成员的信任，所以慎用！！！
　　四、每日立会
　　每天早上，Scrum团队会开一个15分钟左右的立会（站着开的会，为了限制会议时间）。立会的工作就是将周期内需要完成的任务清单列出来，由每个成员根据自身的情况来领取当天的任务。所有的任务分解粒度必须在一天以内完成，需要以小时为单位估算。
　　立会要求每个成员对自己的能力有足够的认识，确定自己能做到什么，是否能按时保质完成。
　　每日立会是产品经理不需要参与的。在开发周期内，产品经理需要做到的就是需求答疑，同时维护并分析需求池中的新需求。
　　五、评审会
　　在迭代周期结束的评审会时，Scrum团队向产品经理展示迭代周期的开发成果，产品经理对需求进行验收。
　　程序员和产品经理对同一个问题理解往往是有偏差的，产品经理贴近用户、程序员贴近代码。任何一个需求最后必须交由产品经理验收合格后才允许上线。
　　
　　评审会代表迭代周期的结束，也是可以让老板参与的一个重要会议。产品经理让老板理解开发过程，看到开发结果是非常重要的环节，能够增强老板对开发团队，产品经理的信心。
　　小型团队也可以考虑把评审会和下一周期的计划会一起召开。
　　六、反思会
　　反思会是Scrum团队内部对上一周期的开发任务回顾的会议，产品开发计划需要迭代，同时每个成员的成长也需要迭代。通过不断的反思，逐步加强团队成员对开发过程的理解，对自身开发能力的理解和提高。
　　Scrum是一套完整的产品开发理论，我们在刚开始实践时只需要关注几个重要的节点：迭代周期、需求池、版本库、计划会、每日立会、评审会、反思会，其他的地方可以根据团队、产品的具体情况灵活变通。最关键的是建立起产品开发良好的节奏感和风险控制能力。
　　在后面的文章中，我会进一步介绍Scrum的成员，以及Scrum实践中必须打通的外部节点。