觉得最实用的还是每日站会和任务看板。
每日站会控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报三个问题【每日盘点】：
（1）你昨天完成了什么任务
（2）今天要完成什么目标
（3）有什么问题不能解决
每日站会的重要性在于，软件开发细枝末节很多，如果不进行每天盘点，很容易失控。
下面是开发团队里经常发生的问题：
代码缺少严苛的审核环节，导致规范失效，给后续的运维带来巨大的成本。
某个开发人员所谓的完成在交付测试的时候问题一大堆。
前后端开发人员没有按约定开发，沟通也不及时，出现互相等待的无效浪费。
产品经理和开发人员互相扯皮，推脱责任，最后不知道听谁的。
第一责任人缺失，等验收的时候才发现大家都不知道有这档事，最后延误工期等等。
https://www.cnblogs.com/jackyfei/p/12914933.html
产品任务列表（Product Backlog Item/PBI）是可以预知的所有任务，包括功能性的和非功能性的任务，PBI属于计划阶段，指出了我们目标，PBI表述的时候建议的原则：
Independent 独立性，避免与其他Story的依赖性。
Negotiable 可谈判性，Scrum中的story不是瀑布开始某事中的Contract, Stories不必太过详细，开发人员可以给出适当的建议。
Valueable 有价值性， Story需要体现出对于用户的价值。
Estimable 可估计性，Story应可以估计出Task的开发时间。
Sized Right 合理的尺寸， Stories应该尽量小，并且使得团队尽量在1个sprint(2 weeks)中完成。
Testable 可测试性， User Story应该是可以测试的，最好有界面可以测试和自动化测试。每个任务都应有Junit Test。
353: 三个角色 ：产品负责人（Product Owner）、流程管理员（Scrum Master）、开发团队（Scrum Team）
现在敏捷开发是越来越火了，人人都在谈敏捷，人人都在学习Scrum和XP...
为了不落后他人，于是我也开始学习Scrum，今天主要是对我最近阅读的相关资料，根据自己的理解，用自己的话来讲述Scrum中的各个环节，主要目的有两个，一个是进行知识的总结，另外一个是觉得网上很多学习资料的讲述方式让初学者不太容易理解；所以我决定写一篇扫盲性的博文，同时试着也与园内的朋友一起分享交流一下，希望对初学者有帮助。
什么是敏捷开发？
敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。
怎么理解呢？首先，我们要理解它不是一门技术，它是一种开发方法，也就是一种软件开发的流程，它会指导我们用规定的环节去一步一步完成项目的开发；而这种开发方式的主要驱动核心是人；它采用的是迭代式开发；
为什么说是以人为核心？
我们大部分人都学过瀑布开发模型，它是以文档为驱动的，为什么呢？因为在瀑布的整个开发过程中，要写大量的文档，把需求文档写出来后，开发人员都是根据文档进行开发的，一切以文档为依据；而敏捷开发它只写有必要的文档，或尽量少写文档，敏捷开发注重的是人与人之间，面对面的交流，所以它强调以人为核心。
什么是迭代？
迭代是指把一个复杂且开发周期很长的开发任务，分解为很多小周期可完成的任务，这样的一个周期就是一次迭代的过程；同时每一次迭代都可以生产或开发出一个可以交付的软件产品。
关于Scrum和XP
前面说了敏捷它是一种指导思想或开发方式，但是它没有明确告诉我们到底采用什么样的流程进行开发，而Scrum和XP就是敏捷开发的具体方式了，你可以采用Scrum方式也可以采用XP方式；Scrum和XP的区别是，Scrum偏重于过程，XP则偏重于实践，但是实际中，两者是结合一起应用的，这里我主要讲Scrum。
什么是Scrum？
Scrum的英文意思是橄榄球运动的一个专业术语，表示“争球”的动作；把一个开发流程的名字取名为Scrum，我想你一定能想象出你的开发团队在开发一个项目时，大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它，你一定会感到非常兴奋的。
而Scrum就是这样的一个开发流程，运用该流程，你就能看到你团队高效的工作。
【Scrum开发流程中的三大角色】
产品负责人（Product Owner）
主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果
流程管理员（Scrum Master）
主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。
开发团队（Scrum Team）
主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。
Scrum流程图
//------------------------
下面，我们开始讲具体实施流程，但是在讲之前，我还要对一个英文单词进行讲解。
什么是Sprint？
Sprint是短距离赛跑的意思，这里面指的是一次迭代，而一次迭代的周期是1个月时间（即4个星期），也就是我们要把一次迭代的开发内容以最快的速度完成它，这个过程我们称它为Sprint。
如何进行Scrum开发？
1、我们首先需要确定一个Product Backlog（按优先顺序排列的一个产品需求列表），这个是由Product Owner 负责的；
2、Scrum Team根据Product Backlog列表，做工作量的预估和安排；
3、有了Product Backlog列表，我们需要通过 Sprint Planning Meeting（Sprint计划会议） 来从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog；
4、Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）；
5、在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）；
6、做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；很多人可能还没有用过自动化的每日集成，其实TFS就有这个功能，它可以支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存到TFS中，中间有任何失败，都会用邮件通知项目管理人员；
7、当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；
8、最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；
下面是运用Scrum开发流程中的一些场景图：
上图是一个 Product Backlog 的示例。
上图就是每日的站立会议了，参会人员可以随意姿势站立，任务看板要保证让每个人看到，当每个人发言完后，要走到任务版前更新自己的燃尽图。
任务看版包含 未完成、正在做、已完成 的工作状态，假设你今天把一个未完成的工作已经完成，那么你要把小卡片从未完成区域贴到已完成区域。
每个人的工作进度和完成情况都是公开的，如果有一个人的工作任务在某一个位置放了好几天，大家都能发现他的工作进度出现了什么问题（成员人数最好是5~7个，这样每人可以使用一种专用颜色的标签纸，一眼就可以从任务版看出谁的工作进度快，谁的工作进度慢）
上图可不是扑克牌，它是计划纸牌，它的作用是防止项目在开发过程中，被某些人所领导。
怎么用的呢？比如A程序员开发一个功能，需要5个小时，B程序员认为只需要半小时，那他们各自取相应的牌，藏在手中，最后摊牌，如果时间差距很大，那么A和B就可以讨论A为什么要5个小时...
敏捷开发的4句宣言
个体与交互 胜过 过程与工具
可以工作的软件 胜过 面面俱到的文挡
客户协作 胜过 合同谈判
响应变化 胜过 遵循计划
https://www.cnblogs.com/qixuejia/p/5863216.html
Scrum浅析
1. Team
Scrum是跨职能团队以迭代、增量的方式开发产品或项目的一种开发框架，区别于其他开发框架最突出的方面应该体现在“跨职能团队”这几个关键字。由此，Team这个单词可谓是Scrum中的万能钥匙，几乎可以解决一切难题。
在Scrum中有三个角色：产品负责人、团队和ScrumMaster，他们在一起被称为Scrum团队。
团队中的每个成员都只是“团队成员”。请注意在采用Scrum的团体中没有任何固定的专业头衔。不会有系统分析师，没有数据库管理员，没有架构师，没有团队组长，没有开发人员，也没有测试人员，他们在每个Sprint中以任何恰当的方式一起工作来达到他们为自己设置的目标。
这种团队不只是跨职能的，而且还会表现出“多重学习”的特点。每个人当然都有特长，但仍继续学习其他专长。每个人都会有主要的、次要的甚至是第三位的技能，并准备好“到工作所需要的地方去”。每个人都可能承担自己并不熟悉领域的任务来帮助完成一个事项。例如，一个主要技能是交互设计的人可能以自动化测试为次要技能。以技术文档写作为主要技能的人可能同时帮助做分析和编程。
Scrum难免会与传统的职能团队冲突，因为他的团队是跨职能的。既然我们目标是相同的，那么我们就应该站在统一战线上一起前进。
另外，Scrum团队提倡是一个自组织的团队，团队成员要群策群力，无领导模式下协作工作，工作激情和效率会大大提升。
2. 透明（可视化）
在Scrum中提出了3个工件：产品待办列表（PBI:Product Backlog Item），迭代待办列表（SBI：Sprint Backlog Item），燃烧图/燃尽图。比起传统的需求文档，产品待办列表会对业务期望进行分解，迭代待办列表更是精细到开发可执行程度，同时用户故事鼓励把用户真实期望与紧急程度暴漏给开发实施人员，这对实现用户最大价值和向用户快速交付产品都起到决定性作用。燃烧图/燃尽图是对进度及风险监控的更加可视化的工具。“表”与“图”无疑大大增加了可视化程度。
看板更不是Scrum中的特有产物，上到科研实验室，下到生产车间，都会使用看板作为进度及风险监控工具。实践证明，看板是生产过程中目标管理、进度监控、风险预知的最优秀的可视化工具。所以看板是一定要时刻置于公众面前随时起到提醒作用的，他的作用可决不仅仅是站会地点的标志。
总的来说，Scrum主张将生产流程的每个环节的透明、可视化程度的做到最佳；当然，如果你有一个新的可视化的好点子，完全可以大胆的应用到敏捷实践工作中来。
3. PDCA循环
引入一个管理学的模型叫“PDCA循环（戴明环）”。PDCA的含义如下：P（PLAN）-计划；D（Do）-执行；C（Check）-反馈；A（Adjust）-调整。PDCA循环就是先制定计划，然后按照计划实施，最后通过检查和总结来反思从计划到实施的差距，最后把自己体会放到实施中去。
纵观Scrum框架中的流程分布，都可以归列到PDCA循环每一步：
P（PLAN）：计划会
D（Do）：迭代
C（Check）：站会、评审会
A（Action）：反思会
其中,站会、评审会只是体现了不同频率的反馈。在Scrum简章中还存在产品代办事项列表梳理会，也只是在为下一个迭代做更充分的计划而已。
经常听到有人抱怨说，敏捷实践中会议太多，形式主义严重。其实不然，只要在遵循PDCA循环的基础上，开会频率、会议名称都是可以自定义的，你想怎么称呼他都可以。Scrum的5个会议事件只是PDCA循环在整个软件开发过程中的最佳实践。
4. GTD（Get Things Done）
GTD是英文Getting Things Done的缩写，是一门无压力高效的时间管理方法学，其核心思想与Scrum不谋而合，提倡优先完成优先级较高且有价值大的工作，并要做到真正完成。
我们经常发现开发人员常常说一些工作已经完成了，但事实并非如此。即使你有一个很明确的对“完成”的定义，开发人员也会经常忘掉。我们这些编程的人都不怎么有耐心，一心想着尽快去做下一个条目。
在Daniel Greenfeld的文章《请不要打断开发人员》有说：“当看到一个程序员冥思苦想的时候，不要过去打扰，甚至在极端的情况下，一句友好的问候都是多余的。”
当开发人员没有真正意义上的完成某些开发任务时，后续的再开发将是影响产品产出效率和质量的最大阻碍。工作内容的频繁切换，大大增加了时间成本，降低产品质量。
所以，在敏捷开发流程中，要尽力规避这些问题。测试前置、严格控制每个迭代与迭代中各个环节的出口标准，是尤为重要的。同时只有产品增量做到真正意义的完成，才能实现拥抱变化，快速交付
5. 实干
“空谈误国，实干兴邦”是当下国家领导集体的治国方针，其应用在软件开发中同样适用。 传统的软件工程官僚，枯燥，束手束脚，而敏捷却变得十分活泼，有趣，但更难把握。重点在于，我们能否从两个世界中取其精华。
综述
Scrum只是把一些被广为认可的方法打包到简单的开发框架中，并不是那么脱离群众。只要在Team的指导思想下，借用透明（可视化）的工具，做到快速顺畅的PDCA循环，掌握GTD等的实践方法，实干到底，持续改进，那么每个团队都会成为最佳敏捷团队。
---------------------
作者：shixin747
来源：****
原文：https://blog.****.net/shixin747/article/details/24840413
版权声明：本文为博主原创文章，转载请附上博文链接！
Scrum guide中把固定时间盒周期称为sprint（冲刺）,但是为什么大家在平时都愿意把它称为迭代（iteration）呢？
以下是剑桥词典对于iteration和sprint的解释：
Iteration :
the process of doing something again and again, usually to improve it, or one of the times you do it.
Sprint：
to run as fast as you can over a short distance, either in a race or because you are in a great hurry to get somewhere。
在wiki中：
迭代是重复反馈过程的活动，其目的通常是为了接近并到达所需的目标或结果。每一次对过程的重复被称为一次“迭代”，而每一次迭代得到的结果会被用来作为下一次迭代的初始值。
在Scrum中，Sprint 说的是类似橄榄球比赛中的冲刺：大家团结一致，为了完成该Sprint的目标疯狂向前冲。
通过以上对于冲刺和迭代的字面分析，我们可以看到迭代的重点在于重复（again and again）过程，而冲刺的重点则是在相对短的时间尽快（run as fast as you can）到达终点。
这也和我们在产品开发管理中运用这两个词语的场景基本符合，下面我们从产品开发过程来更深入认识下面这两个单词是从哪里来，要到哪里去这个深刻的哲学问题。
早在20世纪50年代末期，软件领域中就出现了迭代模型。
最早的迭代过程可能被描述为“分段模型（stagewise model）”。迭代模型是RUP推荐的周期模型。被定义为：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。
在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：需求分析、设计、实施和测试工作流程。
实质上，它类似小型的瀑布式项目。
RUP认为，所有的阶段都可以细分为迭代，每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。
https://www.sohu.com/a/202842160_99965738
本文主要参考《Scrum精髓》这本书的内容
每个Sprint都是从Sprint Planning Meeting开始，Scrum团队成员聚集在一起商定下个Sprint目标，并且确定在Sprint中交付哪些功能。
Sprint规划由整个Scrum团队协作完成。PO展示排定优先级的Product Backlog，回答团队对Product Backlog Item提出的任何问题；开发团队确定可以交付哪些功能，并做出一个靠谱的承诺；ScrumMaster观察规划活动，提出深入细节的问题，引导并且帮助团队确保有成果，ScrumMaster不能代替团队做出承诺。
Sprint Planning Meeting 依赖于一组输入：
- Product Backlog：PBI已经梳理到就绪状态
- 团队速率：团队在一个sprint里能够完成的多少任务指标
- 约束：识别出业务或技术的限制，可能影响到团队的交付能力
- 团队生产能力：团队成员都有哪些技能以及在当前Sprint中他们的可用情况
- Sprint目标：Po希望在这个Sprint内完成的业务目标
Sprint规划：在规划过程中，第一个重要的活动是确定团队的生产能力，影响团队生成能力的因素有：Scrum会议、其他承诺、个人休假和缓冲时间等。
- Scrum会议：Sprint 计划会议、Sprint 评审会议、Sprint 回顾会议等
- 其他承诺：与本次Sprint无关的承诺，比如：需要支持其他项目。
- 个人休假：是不是有人休假
- 缓冲时间：工作中的一些日常事务，比如：回复邮件以及各种干扰。
除去以上占用的时间，剩下的就是团队在这个Sprint中能够用来做Product Backlog Item的时间。
基于可用的生产能力，团队选择一个Product Backlog Item，然后表示有信心在当前Sprint做完它，并且做出承诺，这时Sprint目标可能需要进行细化。重复这个过程，直到团队没有余力再做更多工作时，完成规划活动。
Sprint Planning Meeting 最终的输出：
- Sprint目标：Sprint的业务目标和价值
- Sprint Backlog：当前Sprint所要完成的所有故事。
https://www.cnblogs.com/jetlian/p/sprint-planning-meeting.html
