什么是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开发可以让产品快速试错，即使错了，浪费的也最多是一个迭代的资源，而不会像瀑布开发，有可能浪费的是好几个月的资源。

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

         由于团队最近计划执行不顺利，项目经理在知道我经历过敏捷开发的流程后，让我给团队内部的各个小组分享SCRUM敏捷开发相关的知识，并负责推动团队敏捷开发计划的建设。
          scrum 是一种迭代增量软件开发方法，通过该方法，你可以量化工作量，并且可以把每个任务量化成具体时间，得出最后一个项目的总时间（一般估算到小时）。能让管理者看清楚项目进度，把握项目进程的各种问题。scrum简单易用，但是简单的东西要掌握就容易犯错，大家可以在尝试中掌握这种项目管理方法，以下是我做内部培训个人写的教程，抛砖引玉，希望能普及该方法。
         什么是Sprint？？
        Sprint是短距离赛跑的意思，这里面指的是一次迭代，而一次迭代的周期是1个月时间（即4个星期），也就是我们要把一次迭代的开发内容以最快的速度完成它，这个过程我们称它为Sprint。


        在scrum里面，有3种角色，分别是product owner（产品负责人）scrum master（团队负责人）scrum team （开发团队）：


　　Product owner：是需求方，提出需求，能对功能流程，业务流程拍板的人。


　　Scrum master :团队负责人，一般是product manager,负责解决团队问题，领导项目。


　　Scrum team：项目执行人员，开发项目一般包括，前端后端开发，ui等。


        scrum的流程如下：


     
Scrum 步骤一：

　　头脑风暴，如果product owner 对产品需求非常清楚，就可以省略这个步骤，开发一个原则“先紧后松”， 必须先把需求了解清楚，这里product owner可以召集技术团队/用户群体对其需求进行公开征求意见，最后输出一个产品建议表。



　　Scrum 步骤二：

　　product owner 对产品建议表进行筛选，做减法提炼最核心的需求。在确定了需求后，这个时候由scrum master 进行输出prd (product requirement document) , 这里就和传统的瀑布流一样了，该有的文档都必须有了，必须由scrum
 master 和product owner 确定好需求，包括业务逻辑，功能流程等。

      

　    Scrum 步骤三：

　　原型，ui设计都不是在步骤二完成的，把任务量化，包括，原型，logo设计，ui设计，前端开发等。

　　尽量把每个工作分解到最小任务量，最小任务量标准为工作小时不能超过8小时。准备估算总体项目时间吧！

　　把每个任务都贴在任务看板上面，看板上分为四部分:

　　（1）to do待完成

　　（2）doing 正在做的

　　（3）done 已完成的

       （4）Cancel  推迟的

       

　    如何估算时间：玩扑克游戏这个方法估算出来的工作时间比较准，参与扑克游戏的最好有专家和开发涉及到的人员。

　　扑克游戏玩法：

　　（1）每个人发一部扑克牌，使用扑克牌来进行打分，扑克牌的面值分数有1分、2分、3分、5分和8分，1分代表1小时的工作量。

　　（2）同时展示该项目完成时间，肯定存在最大最小的工作时间，最大最小两个人请你们辩论吧，为什么要那么长时间完成，或者那么短时间完成，其他人可以提出疑问，在一定程度上达成认可。

　　（3）进行再次私下对该任务写时间，再公示，再辩论，这样下去，大家写出来的该任务的时间越来越接近了。

　　（4）最后达成一个共同认可的时间，这个就是该任务的工作时间！

  


　  Scrum 步骤四：

　　经过大家纠结讨论了好久，终于把任务量化到具体多少时间完成了！接下来，把n个任务按照开发的重要度，组合成n个sprint( 冲刺），每次执行一个sprint。




       每个sprint 都是独立的，一般先做主要功能，再到次要功能，再到小功能，最后的sprint 一般是修复bugs。

       因为任务都被量化了，每天工作了多少小时，完成了多少任务量，通过每天例会scrum master非常清楚，并且在时间燃尽图进行表示。我们就可以直观看到任务的进度了，而且是具体到多少小时！




         通过时间燃尽图可以可视化任务的时间进度，大家可以看下图，day1
 是整个任务的总共时间，每天按照任务完成度更新剩余时间，或者增加时间（例如发现一个技术难点，团队成员请假等要增加开发时间）。




         Scrum
 步骤五：

        需要进行
 每日站立会议，每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 时间燃尽图。

 
     

 
     Scrum 步骤六：



      当一个Story完成，也就表示一次Sprint完成，这时，我们要进行演示会议，也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；最后就是 回顾会议，也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中。

    
团队PM：袁佩佩
scrum敏捷开发计划制定：
确定项目实施具体阶段目标
确定项目相关任务分解
确定每日站立会议进行计划
确定项目计划总结日程
确定风险解决方案

转载于:https://www.cnblogs.com/programmers/p/4520182.html

引言
之前的博客中涉及原理和技术方面的内容较多，本篇博客主要谈一谈经常提到的敏捷开发和 scrum。
敏捷开发
相信大部分人都学过瀑布开发模型，它是以文档为驱动的，在瀑布的整个开发过程中，要写大量的文档，把需求文档写出来后，开发人员都是根据文档进行开发的，一切以文档为依据；而敏捷开发它只写有必要的文档，或尽量少写文档，敏捷开发注重的是人与人之间，面对面的交流，所以它强调以人为核心。
定义：敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
核心原则：

主张简单
拥抱变化
第二个目标是可持续性
递增的变化
令投资最大化
有目的的建模
多种模型
高质量的工作
快速反馈
软件是主要目标
轻装前进

常用工具：

Visual Studio Team Foundation Server
Atlassian Jira
Axosoft
LeanKit
Planbox

scrum
Scrum是一个偏重于过程的敏捷开发的具体方式。
Scrum开发流程中的三大角色：

产品负责人（Product Owner）


主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。


流程管理员（Scrum Master）


主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。


开发团队（Scrum Team）


主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。


Scrum的开发流程：

首先需要有一个 Vision ，就是所做的产品或者所做项目的愿景。这个需要所有 Team Members，包括 Product Owner 一起确定，然后大家朝着同样的目标前进。
维护 BacklogVision 出现后，Product Owner 会维护一个 Scrum 中我们提到的第一个文档，即 Backlog。它可以理解成从产品当中，从各个角度收集的需求， Product Owner 要做的事情就是维护 Product Backlog，并且将 Backlog 一条一条的按照优先级排好顺序。Product Owner 是唯一有权利维护这个列表的人。这个时候合理利用工具，就能免去写文档的的这一步，可以直接将需求通过任务的方式收集，每个需求就是一条任务，Product Owner 可以给任务打标签来标示优先级。
拆分 Sprint ，随后团队成员会针对这个 Scrum 把它拆分成一个个的 Sprint ，就是开发周期。然后将 Backlog 里面的项目添加到 Sprint 中去，成为 Sprint Backlog。每一个 Sprint 开始的时候，需要进行一个Sprint Plan。
运行 Sprint Plan，Sprint Plan 就是整个团队一起，通过 Backlog 从优先级最高的这个item 开始挑，挑出 ProductOwner 对Backlog 进行介绍。紧接着的是，大家将 Backlog 拆分成单个的Task，每一个成员在每一天的工作当中领 Task，完成 Task。
在 Scrum run 起来之后，还有一件事情是 Daily Scrum 。在 Daily Scrum 中，每个成员只需三件事情：我今天做了什么，明天要做什么，有什么是我搞不定的。Daily Scrum 一般来说会控制在15分钟之内，而且所有的成员必须要站着开会。
当 Scrum 结束后，每个成员会产出一个产出物。这个产出物在 Scrum 里面，可以是一个可以运行的软件，也可以是一个可展示的功能。之所以这么说是因为有一个Sprint Rview 的阶段，需要通过 Demo 在 Product Owner 以及其他的 Stake Holders 面前，现场演示你做好的东西。
在 Sprint Review 结束之后就是 Retrospective。整个团队的人都要坐下来聊一聊，Sprint 做得好不好，有哪些地方需要修改。

参考
https://baike.baidu.com/item/敏捷开发

https://www.zhihu.com/question/19638322/answer/107371902