如何正确实施Scrum
如果严格按照书本上的 Scrum 法则一条条地看，那么我们队伍现在的做法也许根本不算 Scrum。不过好歹我们也被称作 Scrum 一段时间了，我的资历比不上前面的资深开发者，只能说一些目前的一点经验。
经验一：整个团队必须理解 Scrum 的目的和限制。
如果管理团队把 Scrum 当作一种新的管理流程，那么这个理解绝对是错误的，而且有害。要正确理解 Scrum 的实施原则，需要从理解其设计目的开始。
我所理解的 Scrum 的目的在于两点：
适应变化。Scrum 的一个基本假设，就是外部需求模糊而难以理解。Scrum 对此的理念是：让客户直接看到半成品，他们才知道自己要什么。很多 Scrum 的原则都是围绕如何解决这个问题的：比如每个 Sprint 结束时由 Product Owner 为客户进行展示，又比如任务细化一般不超过一个 Sprint。理解了这一点，才会理解为什么 Scrum 似乎总在变化，因为需求总在变化。
快速迭代。Scrum 的另一个基本假设，是团队生存在一个快速变化且充满竞争的世界。如果自己一年半才能发布一个新版本，而竞争对手半年就能发布，那么几年之内，我们就会被对手甩得远远的。Scrum 对此的理念是：发布即 Milestone（里程碑），宁可每次发布二十个功能发布五次，也不要在内部搞五个 Milestone 然后一口气发布一百个功能。理解了这一点，才会理解为什么 Scrum 会认为发布时砍功能是一种正常情况而非一种失败。
要实施 Scrum，整个团队至少必须取得共识，即以上两点是不能商量的。流程必须为目的服务。如果队伍相信增加前期沟通才是让需求清晰起来的最好方法，或者相信发布的功能必须是大批量一次性，那么请使用瀑布开发模式。
相应地，我们必须明白 Scrum 不能做什么。我的理解可能耸人听闻，仍是两点：
因为发布周期缩短，团队没有能力保证作出的每一个决定都正确，很多开销都必须花在试错上；
快速发布实际上导致 Scrum 团队的抗风险能力弱于瀑布模型团队，因为一个人的离职或病假都可能对单一功能的进度造成影响，不利于短期频繁发布。
Scrum 对此的解答是：不要试图不犯错误，而是保证小的错误能被尽快发现从而不会酿成大错。所以 Scrum 过程中总会有些不确定性，或者功能不合需求而返工，或者突然缺了人手导致一些单个功能必须延期完成。如果非要事先确定发布周期而且还得保证不许功能裁剪，请出门左转找 CMM 认证：它可以把任务精确到每个对话框上该用什么字体。前期计划精确到这个粒度，什么都可以在掌控之中。但问题是，我们必须用更长的发布周期来换。
理解了上面的内容，我们实施时就不会对某些形式性的东西过于纠结，比如 Burn down chart，比如 Scrum 扑克。需知形式服务于目的，而形式未必适用于每一个团队，正如瀑布模型在每一个团队中也都有差异。如果仅仅是因为团队成员没有在 planning meeting 上打扑克就认定这不是 Scrum，那么未免愚蠢了些。反过来，某些看似烦人的「流程」却不可或缺，比如每天的 15 分钟 stand-up，如果我们明白它对交流方面的重要作用，就绝对不会认为它可以被省略。
举个实际的例子，在我们的团队里，我们强迫一周一个 Sprint。就我所知，即使在很多实施很成功的项目中，这种做法也是相当激进的。一开始我也不理解这一点，但实施了一段时间后，我开始认同这一条，因为一周的发布周期让我们没有机会把任务往后推，从而迫使我们尽快从瀑布模型中转移出来。这对一个有着悠久瀑布开发传统的团队来说非常重要，但对别的团队来说，就不一定了。
经验二：正确定位队伍中的 Scrum Master。
为什么单独提 Scrum Master？如果只是看书本和参加培训，我相信多数人都会同意我的观点，即 Scrum Master 或许是整个开发过程中作用最不清楚的角色：不参与需求分析、不参与代码开发、甚至不参与任何人事问题，只有一句「去除阻碍」这种含糊的表述。但是，当我真正当起这个 Scrum Master 之后，才发现这个角色承担的职责非常具体。比如：
确保流程执行正确。进入 Scrum 之后，很多团队仍然会以各种方式走老路，比如有意无意地拉长 Sprint 周期，并以此区别计划周、开发周和测试周，实际上是把原来三个月的瀑布开发周期变成了两到四个星期的瀑布周期；又比如以开发时间有限为理由把自动测试开发任务缩减为手工测试。好的 Scrum Master 应该有能力发现并制止这种情况。——顺便说一句，相信我，不要以为两个星期的瀑布周期是个可行的开发计划，我们不可能完成测试任务的。
制止官僚主义流程。典型的例子就是一个又一个的 spec/plan review 和 sign-off 邮件；又比如非要区分所谓 Unit Test、BVT 和 Functional Test：或许对一个图形界面程序来说这两者区别极大，可对于函数库则几乎没有原则差别。合格的 Scrum Master 应该制止这样的倾向。——不过我也得说，这一条我现在做得很差，还需要改进。
构建交叉知识结构。整个团队的知识模型应该是各有专长但互有交叉的，而传统开发的一个很重要的问题是知识结构不平衡，比如测试的只管测试，开发的只管开发。这种模式对于发布时间长的大团队来说也许能接受，但对人手短缺又要求快速发布的小团队则是致命的。好的 Scrum Master 应当能够对团队的决策具备影响力，确保不会让某个任务陷入「只有一个人知道细节」的情况。——这一条在习惯了传统瀑布开发模型的团队中往往是最大的阻碍，需要时间改善。
但正因为上面的理解，我基本上不同意 Scrum Alliance 的教科书里关于 Scrum Master 的大多数表述。首先，Scrum Master 必须承担一部分开发任务，因为没有介入一线开发，很难想象 Scrum Master 会真正理解团队的「痛点」。其次，Scrum Master 需要关注团队的每一个人，不然队伍可能由于所谓「自组织」的原则而隐藏一些问题，比如某个人过于专精某一项而忽略了和其它成员的交流。当然，也有些部门的 Scrum Master 只负责写报告和推事情。这不是我共事过的任何一位 Scrum Master 的做法，而且我也可以很自信地说，这种 Scrum Master 在我们公司是生存不下去的。
Scrum Master，你是肩负着人类使命的人啊！
最后，贴两句最近刚学到的话：
50% percent of our decisions are wrong. Fail fast, learn fast. （我们作出的决定中， 50% 都是错误的。早早失败，早早学习。）
No matter what you want to do, choose what is good for your team.（无论你选择做什么，选择对你的团队有利的事）
先声明，说上面两句话的哥们本人在我们队伍里不算很受欢迎，但这两句我很喜欢。在我眼里，这两句话指出了 Scrum 的所有实质。
共勉之。
Scrum 是众多敏捷开发方法中的一种，它既是方法论，也包括了一系列预定义的角色、一系列的流程，以及一系列的实践经验。那么践行Scrum 到底是应该坚持以理论为准绳，还是从实际角度出发，有所舍弃和调整？一个可运行的 Scrum 流程的主要步骤是怎样的？
首先聊聊敏捷开发的价值观
对于敏捷开发来讲，有人说是流程、是方法论是工具，但对于我来讲它更是一种精神，它并没有局限在流程、方法、工具上。敏捷软件开发的目的就是解决需求中的变化和中的不可控因素。
当时提出敏捷开发的这个人或者这个群体，提出来的是敏捷开发的四个价值观：第一，个体的互动要高于流程和工具；第二，可工作的软件要高于详尽的文档；第三，客户的合作高于合同谈判；第四，响应变化高于遵循计划。这四点价值观是最能体现敏捷开发的核心的东西，其精髓就是拥抱变化，而不是控制变化。
了解Scrum 是什么很重要
Scrum 是什么？它既是方法论，也包括了一系列预定义的角色、一系列的流程，以及一系列的实践经验，包括需要的文档。我提出的一个观点是，对于我有用的就做，对于产品、项目没有用的就不做，但是Scrum 实际上不是这样的。你想做到Scrum 有些东西是必须要做的。所以我也希望大家能够自己批判性、灵活用它，而不是死板用它。
Scrum的主要角色
Scrum 主要定义了三个角色：Scrum Master，Product Owner，Development Team 。
Scrum Master 不是Project Manager， 他的主要的工作是要保证这个团队执行 Scrum 的顺畅。Product Owner 是真正对产品负责的人。如果我们是做产品研发的话，产品经理就是Product Owner。如果我们是做项目开发，客户就是Product Owner，这也体现了我们刚刚提到，我们并不是和客户去谈判，而是真正把客户放在我们的这种流程中，真正与他合作。第三种 Development Team 就是干活儿的。
所以 在Scrum 里面没有管理者的概念。另外，Scrum 里面实际上所有的真正为最终产出的软件付出的，都叫Development Team。这个地方也体现了一个Scrum 的观点，就是它希望能够打造Cross-Functional Team，即在这个团队中的所有人可以做所有的事情，每个人都是Development Team。
Scrum的开发流程
Step1. 需要一个 Vision
真正Scrum 的流程是什么样子的？首先，我们需要有一个Vision ，就是我们所做的产品或者所做项目的愿景。这个需要所有Team Members，包括Product Owner 一起确定，然后大家朝着同样的目标前进。
Step2. 维护Backlog
Vision 出现后，Product Owner 会维护一个Scrum 中我们提到的第一个文档，即 Backlog。它可以理解成我们从产品当中，从各个角度收集的需求， Product Owner 要做的事情就是维护Product Backlog，并且将Backlog 一条一条的按照优先级排好顺序。Product Owner 是唯一有权利维护这个列表的人。
这个时候合理利用工具，就能免去写文档的的这一步，可以直接将需求通过任务的方式收集，每个需求就是一条任务，Product Owner 可以给任务打标签来标示优先级。
Step3. 拆分Sprint
随后我们会针对这个Scrum 把它拆分成一个个的Sprint ，就是开发周期。然后将 Backlog 里面的项目添加到Sprint 中去，成为Sprint Backlog。每一个Sprint 开始的时候，需要进行一个Sprint Plan。
Step4. 运行Sprint Plan
Sprint Plan 就是整个团队一起，通过Backlog 从优先级最高的这个item 开始挑，挑出Product
Owner 对Backlog 进行介绍。紧接着的是，大家将Backlog 拆分成单个的Task，每一个成员在每一天的工作当中领Task，完成Task。
由此可见，在完美的Scrum 里面，是没有任务指派一说的。每个成员会根据任务、完成度，去及时更新任务的状态。为了让大家了解整个项目的进度，Scrum会引入白板（在墙上或者在板子上钉好多的小纸条，让大家明确项目进度和任务完成情况）。
说到这个，我可以向大家推荐一个工具：Worktile。这个工作可以在Worktile 的看板视图上做，看板视图非常像真正的白板。通常情况下，在 Scrum 里的白板列表只有三列：TO DO、IN PROGRESS，以及 DOWN。这个在Worktile 里面就十分简单，你可以打标签、分配人、设置截止时间、在任务上进行评论，并且任务可以直接在列表间拖拽，从而推进流程的进展。并且这一切都是实时的，所有人都能看到。
Step5. Daily Scrum
在Scrum run 起来之后，还有一件事情是Daily Scrum 。在 Daily Scrum 中，每个成员只需三件事情：我今天做了什么，明天要做什么，有什么是我搞不定的。Daily Scrum 一般来说会控制在15分钟之内，而且所有的成员必须要站着开会。
Step6. Sprint Rview
当Scrum 结束后，我们会产出一个产出物。这个产出物在Scrum 里面，可以是一个可以运行的软件，也可以是一个可展示的功能。之所以这么说是因为有一个Sprint Rview 的阶段，我们需要通过Demo 在Product Owner 以及其他的Stake Holders 面前，现场演示你做好的东西（而不是给大家讲你做了什么）。
Step7. Retrospective
在Sprint Review 结束之后就是Retrospective。我们整个团队的人都要坐下来聊一聊，我们的Sprint 做得好不好，有哪些地方需要修改。
敏捷实际上就是一种理念，然后基于这个理念提供了一些方法和实践，在我眼里它意味着持续改进。所谓持续改进就是在产品设计上的持续改进，包括那我们尽量快速的迭代。我们每一个 Scrum 的Sprint 都不会太长，保证我们的每一个Scrum 都能提供给客户一个可运行的版本，能够快速得到客户的反馈。同时在产品区改进中，架构设计也会持续的改进。我们的设计并不是上了之后就把所有的东西都想好，而是基于我们产品的不断改进，在架构上持续的改进。敏捷本来就是持续改进，改进敏捷的流程，并用敏捷开发的精神改变我们自己的开发流程。
【科普】Scrum——从橄榄球争球到敏捷开发
对敏捷开发Scrum稍有了解的都知道Scrum来源于橄榄球，但你知道为何要以这项球类运动的术语来命名这个敏捷开发方法论吗？
Scrum 一词源于英式橄榄球运动，是指双方球员对阵争球。双方前锋肩靠肩站成一横排，面对面躬身，肩膀互相抵在一起，形成一个通道。犯规队的球员低手将球抛入通道，此时通道两边的球员们互相抗挤，争取踢球给本方前锋。
比赛分为两支队伍，每个队伍上场的球员为11名。整个队伍中的球员分为进攻、防守和特别三种职能，三者各有优势又互相配合。进攻队员身手敏捷，凭借速度变化和身形穿透对方防线；防守队员身形强壮，阻挡对方球员的进攻；特别队员较为灵活，进可攻退可守，随时可充当前面二者的替补。
与橄榄球比赛对应，在Scrum组织中没有传统组织所强调的岗位、上下级关系、汇报等元素，每个人只有“一起赢得比赛”的目标，而且每个人的工作会有较大的重合覆盖度，角色可因势而变，提高效率的同时，有效避免传统组织可能存在的推诿和不作为。
英式橄榄球比赛中，球是被禁止向前传的：规则并不限制球员将球往前踢，但当踢球员踢球时，他的队友必须在球的后方。那么为了让球有方向地运动起来，球员必须将球往后传。如此显而易见的矛盾凸显了团队合作的重要性，同时创造了绝佳的纪律，因为这不是光靠一名球员就能成功胜利的比赛。球员们必须团队合作，才能带球向前冲过敌队的阵线，赢得最后的胜利。
在Scrum的工作方式下，团队化繁为简，只有三个角色，分别是产品负责人(PO)、Scrum Master和开发团队。Scrum中的产品负责人，就像橄榄球队的四分卫，对产品的方向负责，对产品的Why和What负责。Scrum Master，是一个团队的教练，关注人和人的互动质量，并减少外部干扰对团队工作影响。Scrum中的团队成员就是一支橄榄球队，大家共享时空、闭环决策。
此外，橄榄球赛还有一些特殊规则：与美式橄榄球不同，英式橄榄球无需佩戴护具，这使得比赛随时可以开展并更容易推广普及；比赛时间较短，上下场各7分钟；对不持球的球员不可以冲撞和阻挡；有意外或所谓的暴行时，裁判会判犯规，中断比赛来进行Scrum。
读到这里是不是若有所思？没错，Scrum开发模式并不只是简单地借用了英式橄榄球的术语，许多精神也与之一脉相承，二者的许多元素都可一一对应。
Scrum的乘风破浪开发产品与橄榄球披荆斩棘赢得比赛有着一脉相承的精神与灵魂，橄榄球是深受全世界球员喜爱的运动，那么Scrum是如何借势乘风破浪“C位出道”成为目前软件开发主流模式的呢？
1986年 ，竹内弘高和野中郁次郎在《哈佛商业评论》上发表《新新产品开发游戏》的文章，首次提出将Scrum应用于产品开发，文章指出传统的接力式开发模式已不能满足日益激烈的市场竞争，开发模式需转向团队整体前进的橄榄球式。
1993年 ，进入Easel公司后，Scrum的创始人Jeff Sutherland借鉴日本精益理念和《新新产品开发游戏》中的知识管理策略，在效率底下的部门中使用了新方法及工具，此时的实践就成了之后系统性Scrum中的各种元素。Jeff Sutherland拥有空军飞行员经历带来的观察、导向、决定、行动四大要素，攻读生物统计学博士学位时又吸收了生物学生物组织系统和进化论适者生存的理念，在实践中取其精华，形成Scrum的定义。
1995年 ，Jeff Sutherland和另一位创始人Ken Schwaber规范化Scrum框架，并在OOPSLA 95上公开发布。
2001年 ，敏捷宣言及原则发布、敏捷联盟成立，Scrum是其中一种敏捷方法。Ken Schwaber和Mike Beedle推出第一本Scrum书籍《Scrum敏捷软件开发》。
2002年 ，Ken Schwaber 和Mike Cohn共同创办了Scrum联盟。
至今，根据《2020敏捷状态调查报告》，总共有76%的组织采用Scrum，Scrum已成为当之无愧的“C位”开发模式。
[Scrum敏捷开发之] Sprint开发过程详解
首先，讲解下Sprint开发过程的一些原则：
当仔细思考这些原则的时候，将会看到Agile宣言渗透其中。接下来详细讲解每一原则。
请注意，这些技术中有许多是从精益方法中借来的，特别是WIP的看板。这是因为一旦故事计划好了，团队就应该像一台运转良好的机器一样运转。因此，持续改进和减少浪费的目标在此也绝对适用。
然而，Scrum与众不同且保持敏捷的一个关键方面是，产品负责人在团队中，他们可以增量地接受工作。另外，Sprint Backlog对所有人完全透明地显示了团队在Sprint结束前必须完成的工作，开发团队可以根据Sprint的需求来管理他们的时间。这些故事结合在一起形成了一个有意义的、可交付的产品增量。
正是基于这些原因，敏捷为开发团队提供了可持续性、目的性、掌控性和自主性，而不是纯粹的精益方法。这些要素已被证明是最能激励知识型员工团队的。
敏捷开发方式有哪些
敏捷开发包括一系列的方法，主流的有如下七种：
XP
XP（极限编程）的思想源自 Kent Beck和Ward Cunningham在软件项目中的合作经历。XP注重的核心是沟通、简明、反馈和勇气。因为知道计划永远赶不上变化，XP无需开发人员在软件开始初期做 出很多的文档。XP提倡测试先行，为了将以后出现bug的几率降到最低。
SCRUM
SCRUM是一种迭代的增量化过程，用于产品开发或工作管理。它是一种可以集合各种开发实践的经验化过程框架。SCRUM中发布产品的重要性高于一切。
该方法由Ken Schwaber和 Jeff Sutherland 提出，旨在寻求充分发挥面向对象和构件技术的开发方法，是对迭代式面向对象方法的改进。
Crystal Methods
Crystal Methods（水晶方法族）由Alistair Cockburn在20实际90年代末提出。之所以是个系列，是因为他相信不同类型的项目需要不同的方法。虽然水晶系列不如XP那样的产出效率，但会有更多的人能够接受并遵循它。
FDD
FDD （Feature-Driven Development，特性驱动开发）由Peter Coad、Jeff de Luca 、Eric Lefebvre共同开发，是一套针对中小型软件开发项目的开发模式。此外，FDD是一个模型驱动的快速迭代开发过程，它强调的是简化、实用、 易于被开发团队接受，适用于需求经常变动的项目。
ASD
ASD（Adaptive Software Development，自适应软件开发）由Jim Highsmith在1999年正式提出。ASD强调开发方法的适应性（Adaptive），这一思想来源于复杂系统的混沌理论。ASD不象其他方法那样 有很多具体的实践做法，它更侧重为ASD的重要性提供最根本的基础，并从更高的组织和管理层次来阐述开发方法为什么要具备适应性。
DSDM
DSDM（动态系统开发方法）是众多敏捷开发方法中的一种，它倡导以业务为核心，快速而有效地进行系统开发。实践证明DSDM是成功的敏捷开发方法之一。在英国，由于其在各种规模的软件组织中的成功，它已成为应用最为广泛的快速应用开发方法。
DSDM不但遵循了敏捷方法的原理，而且也适合那些成熟的传统开发方法有坚实基础的软件组织。
轻量型RUP
RUP其实是个过程的框架，它可以包容许多不同类型的过程， Craig Larman 极力主张以敏捷型方式来使用RUP。他的观点是:目前如此众多的努力以推进敏捷型方法，只不过是在接受能被视为RUP 的主流OO开发方法而已。
请阐述Scrum敏捷开发模型的8个步骤
1、我们首先需要确定一个Product Backlog（按优先顺序排列的一个产品需求列表），这个是由ProductOwner 负责的；
2、Scrum Team根据Product Backlog列表，做工作量的预估和安排；
3、有了ProductBacklog列表，我们需要通过 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的产品需求中；