现在敏捷开发是越来越火了，人人都在谈敏捷，人人都在学习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个小时...
那么什么是Product Backlog？什么是Sprint Backlog？
产品待开发项(Product Backlog)：根据初始需求分解出的任务列表，包括功能性的和非功能性的所有功能； 由Product Owner为Product Backlog中的任务确定优先级别；当开发团队开始做某个任务的时候，再精确定义和分解这个任务。
Product Backlog是产品所要具备的所有功能的总纲。当一个项目刚刚开始时，没人能够事先预见到所有的任务和需求，并为之做一个充分、详细而又包罗万象的计划。可行的方式是，先为一个项目写下所有它应该具备的显著特征和功能，数量不必很多，最好够让团队的第一个Sprint有活可干。随着Sprint的进行，生产出可发布的产品增量，客户对产品的直观认识也随之加深，他们可以据此建议更改或者添加产品Backlog中的任务。
在Sprint计划会议上，产品负责人人为产品Backlog中的任务确定优先级，并向Scrum团队描述这些任务。Scrum团队随后根据团队整体情况，确定他们能在这个即将到来的Sprint中完成哪些功能，并把它们挪到Sprint Backlog中去。
迭代计划会(Sprint Planning Meeting) ：在每个Sprint开始之前，需要召开Sprint计划会议，一般为4至8个小时。参加人员有产品责任人、Scrum Master、Scrum团队和其他感兴趣的人，比如管理层人员和客户代表。Product Owner从产品Backlog中挑选优先度高的任务，并与Scrum团队一起决定在这个Sprint中需要完成多少功能；Scrum团队将这些任务分解成小的功能模块； Scrum团队成员详细讨论如何能按需求完成这些功能模块，并估计完成每个功能模块所需的大概时间。
每日立会(Daily Stand-up Meeting)：既团队每日例会，条件允许的话，每天都应该在同样的时间和地点，所有成员站立着举行。由于是站立的状态开会，因此时间比较短，一般为15分钟左右。这个会议最好是在每天的早晨开，有利于团队成员们安排好当天的工作计划。只有团队成员可以在每日Scrum会议上发言，其他人员如果对项目进度有兴趣也可以参加，但只能旁听而不能发言。
会议由Scrum Master主持，Scrum团队的所有成员轮流回答上图中的三个问题，即：
- 昨天我完成了什么工作；
- 今天我打算做什么；
- 我遇到了什么障碍。
Sprint评审会(Review Meeting)：Sprint结束时召开；由开发团队展示这个Sprint中完成的功能；长度为两个小时左右；不需要PPT；一般是已完成的功能的Demo； 谁都可以参加：客户、管理层、Product Owner、其他开发人员等等。
在每个Sprint结束时，应该组织一个Sprint评审会议。Scrum开发团队将在会上展示他们在这个Sprint中所做的工作。一般采用向大家演示产品新功能的方式来展示。
相对来说，Sprint评审会议不必很正式。通常不需要用到PPT幻灯片，而且长度最好控制在两个小时之内。也就是说，不要让Sprint评审会议成为Scrum团队的负担，他们不必花太多时间来准备这个会议。
Sprint评审会议的参与者，可以包括所有对该产品感兴趣的人：产品责任人，Scrum团队，利益相关者，管理层人员，客户，甚至来自其他项目的开发人员等等。
在Sprint评审会议上，Scrum团队用Demo的形式展示产品的新功能之后，与会人员依据在Sprint计划会议上确定的本Sprint的目标来评审具备了这些新功能的产品。
首先，参与会议的人都能直观的看到Scrum团队的工作成果；其次，利益相关者们可以据此提出更切合实际的反馈意见；第三，为了完成Demo，团队会努力完成并发布那些功能，即使只是发布在测试环境下，也比没完成的好。如果不做Demo，也许不少功能会停留在“已完成99%”的阶段。相比较起来，在有Demo的情况下，也许“已完成”的功能数量会相对少一些，但它们是确确实实完成了的，否则，那些“99%”的貌似完成的功能势必还要拖到下个Sprint来解决。
假如有一个刚从传统的开发模式转而采用Scrum的团队，由于不习惯这种自我约束、自组织的方式，在Sprint中并没做多少工作，那么在会上演示的时候，他们会觉得很尴尬。没准老板看到他们花了这么多时间只做了这么少的工作而感到很生气。发生这种情况当然是大家都不想看到的，但良药苦口，在下一个Sprint中，这个团队肯定会吸取教训，他们会明白无论什么情况下都必须Demo，那么他们必然会很好的完成这个Sprint并演示给大家看。
在Scrum中有三种角色：产品负责人Product Owner，Scrum Master和Scrum团队，他们的职责分别是：
- 产品负责人(Product Owner)
- 确定产品的功能和完成时间；
- 对产品的收益负责；
- 根据市场需求确定产品功能的优先级；
- 在每个Sprint开始之前，可以修改功能需求和优先级；
- 有权决定接受或否决各Sprint的工作成果。
Scrum团队按照功能的优先级，将它们从高到低分配到各个Sprint中进行开发，这些被分配到一个Sprint中完成的功能就形成了Sprint Backlog。
在产品的整个开发过程中，Product Owner对于产品的需求可能会发生改变。他可以修改Product Backlog，增加某些功能需求、删除某些功能需求、修改优先级等等，但这些行为只能在各个Sprint之间进行。
- Scrum Master
- 负责监督整个Scrum项目进程，调整项目计划
- 确保开发团队成员的能力能够胜任产品的开发；
- 促进团队中不同角色的成员间充分交流和沟通，并负责为项目的进行扫除障碍；
- 保证开发团队不受外力的干扰和阻挠；
- 掌握产品开发进度，参与每日Scrum会议、Sprint计划会议和Sprint评审会议。
- Scrum Master最经常的情况就是由过去的项目组长(Team leader)来担当。
- 开发团队
一般由5-10个能全职工作的成员组成较为理想；团队成员横跨各个职能，通常包含开发，测试，文档设计人员等等。
这与我们传统的开发模式（瀑布模式）截然不同了。开发团队可以及时有效的交流，而不是像瀑布模式中受职位和文档的限制，使得出错率低，积极性高，从而提高了开发效率。
相信看了文章后大家一定对敏捷开发感兴趣了（不没有兴趣一定不是我写的不好，一定是你没仔细看没思考，重新review哈），最后广州微信小程序开发公司小编给大家推荐下主流的团队协作工具以实践验证是否有效，小编已经开始使用leangoo。
这款是几个推荐里小编觉得跟敏捷开发最贴合，也比较上手的，当然你都可以用试试再做决定， 其他的工具各有优势，有会有oa有的会有文档协作等等，小编更看重的是看板功能。以下是清单：
leangoo
推荐，看板功能强大，有游泳，有生成模版，功能比较强大，缺点是不太知名的公司，产品目前也是前期阶段还没有ios端。
Coding Enterprise
推荐，国内git类老大，git和相关管理工具做的已经比较成熟，市场占有率也高，我们使用了几年比较稳定，易用性也不错，付费版很强大，很多特性也能值回票价，不差钱的推荐。
Worktile
次推荐，免费版略弱的看板功能，优点是其他功能较多，并且有付费版。
Teambition
次推荐，免费版略弱的看板功能，优点是其他功能较多，并且有付费版。
Trello
次推荐，国外鼻祖，也有付费版，最近估值达到惊人的4.24亿美刀，潜力股还是泡沫？小编觉得路漫漫还是得抱大腿。
