敏捷开发之scrum

如今敏捷开发是愈来愈火了，人人都在谈敏捷，人人都在学习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开发？

一、咱们首先须要肯定一个Product Backlog（按优先顺序排列的一个产品需求列表），这个是由Product Owner 负责的；

二、Scrum Team根据Product Backlog列表，作工做量的预估和安排；

三、有了Product Backlog列表，咱们须要经过 Sprint Planning Meeting（Sprint计划会议） 来从中挑选出一个Story做为本次迭代完成的目标，这个目标的时间周期是1~4个星期，而后把这个Story进行细化，造成一个Sprint Backlog；

四、Sprint Backlog是由Scrum Team去完成的，每一个成员根据Sprint Backlog再细化成更小的任务（细到每一个任务的工做量在2天内能完成）；

五、在Scrum Team完成计划会议上选出的Sprint Backlog过程当中，须要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每一个人都必须发言，而且要向全部成员当面汇报你昨天完成了什么，而且向全部成员承诺你今天要完成什么，同时遇到不能解决的问题也能够提出，每一个人回答完成后，要走到黑板前更新本身的 Sprint burn down（Sprint燃尽图）；

六、作到每日集成，也就是天天都要有一个能够成功编译、而且能够演示的版本；不少人可能尚未用过自动化的每日集成，其实TFS就有这个功能，它能够支持每次有成员进行签入操做的时候，在服务器上自动获取最新版本，而后在服务器中编译，若是经过则立刻再执行单元测试代码，若是也所有经过，则将该版本发布，这时一次正式的签入操做才保存到TFS中，中间有任何失败，都会用邮件通知项目管理人员；

七、当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，咱们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每个Scrum Team的成员都要向他们演示本身完成的软件产品（这个会议很是重要，必定不能取消）；

八、最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每一个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；

 

 

下面是运用Scrum开发流程中的一些场景图：

上图是一个 Product Backlog 的示例。

 

上图就是每日的站立会议了，参会人员能够随意姿式站立，任务看板要保证让每一个人看到，当每一个人发言完后，要走到任务版前更新本身的燃尽图。

任务看版包含 未完成、正在作、已完成 的工做状态，假设你今天把一个未完成的工做已经完成，那么你要把小卡片从未完成区域贴到已完成区域。

 

每一个人的工做进度和完成状况都是公开的，若是有一我的的工做任务在某一个位置放了好几天，你们都能发现他的工做进度出现了什么问题（成员人数最好是5~7个，这样每人可使用一种专用颜色的标签纸，一眼就能够从任务版看出谁的工做进度快，谁的工做进度慢）

 

 

 上图可不是扑克牌，它是计划纸牌，它的做用是防止项目在开发过程当中，被某些人所领导。

怎么用的呢？好比A程序员开发一个功能，须要5个小时，B程序员认为只须要半小时，那他们各自取相应的牌，藏在手中，最后摊牌，若是时间差距很大，那么A和B就能够讨论A为何要5个小时...

 

敏捷开发的4句宣言

个体与交互 赛过 过程与工具

能够工做的软件 赛过 面面俱到的文挡

客户协做 赛过 合同谈判

响应变化 赛过 遵循计划

 

 

 

经验一：整个团队必须理解 Scrum 的目的和限制。
若是管理团队把 Scrum 看成一种新的管理流程，那么这个理解绝对是错误的，并且有害。要正确理解 Scrum 的实施原则，须要从理解其设计目的开始。

 

我所理解的 Scrum 的目的在于两点：

1. 适应变化。Scrum 的一个基本假设，就是外部需求模糊而难以理解。Scrum 对此的理念是：让客户直接看到半成品，他们才知道本身要什么。不少 Scrum 的原则都是围绕如何解决这个问题的：好比每一个 Sprint 结束时由 Product Owner 为客户进行展现，又好比任务细化通常不超过一个 Sprint。理解了这一点，才会理解为何 Scrum 彷佛总在变化，由于需求总在变化。
2. 快速迭代。Scrum 的另外一个基本假设，是团队生存在一个快速变化且充满竞争的世界。若是本身一年半才能发布一个新版本，而竞争对手半年就能发布，那么几年以内，咱们就会被对手甩得远远的。Scrum 对此的理念是：发布即 Milestone（里程碑），宁肯每次发布二十个功能发布五次，也不要在内部搞五个 Milestone 而后一口气发布一百个功能。理解了这一点，才会理解为何 Scrum 会认为发布时砍功能是一种正常状况而非一种失败。

要实施 Scrum，整个团队至少必须取得共识，即以上两点是不能商量的。流程必须为目的服务。若是队伍相信增长前期沟通才是让需求清晰起来的最好方法，或者相信发布的功能必须是大批量一次性，那么请使用瀑布开发模式。

相应地，咱们必须明白 Scrum 不能作什么。个人理解可能耸人听闻，还是两点：

1. 由于发布周期缩短，团队没有能力保证做出的每个决定都正确，不少开销都必须花在试错上；
2. 快速发布实际上致使 Scrum 团队的抗风险能力弱于瀑布模型团队，由于一我的的离职或病假均可能对单一功能的进度形成影响，不利于短时间频繁发布。

Scrum 对此的解答是：不要试图不犯错误，而是保证小的错误能被尽快发现从而不会酿成大错。因此 Scrum 过程当中总会有些不肯定性，或者功能不合需求而返工，或者忽然缺了人手致使一些单个功能必须延期完成。若是非要事先肯定发布周期并且还得保证不准功能裁剪，请出门左转找 CMM 认证：它能够把任务精确到每一个对话框上该用什么字体。前期计划精确到这个粒度，什么均可以在掌控之中。但问题是，咱们必须用更长的发布周期来换。

理解了上面的内容，咱们实施时就不会对某些形式性的东西过于纠结，好比 Burn down chart，好比 Scrum 扑克。需知形式服务于目的，而形式未必适用于每个团队，正如瀑布模型在每个团队中也都有差别。若是仅仅是由于团队成员没有在 planning meeting 上打扑克就认定这不是 Scrum，那么未免愚蠢了些。反过来，某些看似烦人的「流程」却不可或缺，好比天天的 15 分钟 stand-up，若是咱们明白它对交流方面的重要做用，就绝对不会认为它能够被省略。

举个实际的例子，在咱们的团队里，咱们强迫一周一个 Sprint。就我所知，即便在不少实施很成功的项目中，这种作法也是至关激进的。一开始我也不理解这一点，但实施了一段时间后，我开始认同这一条，由于一周的发布周期让咱们没有机会把任务日后推，从而迫使咱们尽快从瀑布模型中转移出来。这对一个有着悠久瀑布开发传统的团队来讲很是重要，但对别的团队来讲，就不必定了。

经验二：正肯定位队伍中的 Scrum Master。
为何单独提 Scrum Master？若是只是看书本和参加培训，我相信多数人都会赞成个人观点，即 Scrum Master 或许是整个开发过程当中做用最不清楚的角色：不参与需求分析、不参与代码开发、甚至不参与任何人事问题，只有一句「去除阻碍」这种含糊的表述。可是，当我真正当起这个 Scrum Master 以后，才发现这个角色承担的职责很是具体。好比：

1. 确保流程执行正确。进入 Scrum 以后，不少团队仍然会以各类方式走老路，好比有意无心地拉长 Sprint 周期，并以此区别计划周、开发周和测试周，其实是把原来三个月的瀑布开发周期变成了两到四个星期的瀑布周期；又好比以开发时间有限为理由把自动测试开发任务缩减为手工测试。好的 Scrum Master 应该有能力发现并制止这种状况。——顺便说一句，相信我，不要觉得两个星期的瀑布周期是个可行的开发计划，咱们不可能完成测试任务的。
2. 制止官僚主义流程。典型的例子就是一个又一个的 spec/plan review 和 sign-off 邮件；又好比非要区分所谓 Unit Test、BVT 和 Functional Test：或许对一个图形界面程序来讲这二者区别极大，可对于函数库则几乎没有原则差异。合格的 Scrum Master 应该制止这样的倾向。——不过我也得说，这一条我如今作得不好，还须要改进。
3. 构建交叉知识结构。整个团队的知识模型应该是各有专长但互有交叉的，而传统开发的一个很重要的问题是知识结构不平衡，好比测试的只管测试，开发的只管开发。这种模式对于发布时间长的大团队来讲也许能接受，但对人手短缺又要求快速发布的小团队则是致命的。好的 Scrum Master 应当可以对团队的决策具有影响力，确保不会让某个任务陷入「只有一我的知道细节」的状况。——这一条在习惯了传统瀑布开发模型的团队中每每是最大的阻碍，须要时间改善。

但正由于上面的理解，我基本上不一样意 Scrum Alliance 的教科书里关于 Scrum Master 的大多数表述。首先，Scrum Master 必须承担一部分开发任务，由于没有介入一线开发，很难想象 Scrum Master 会真正理解团队的「痛点」。其次，Scrum Master 须要关注团队的每个人，否则队伍可能因为所谓「自组织」的原则而隐藏一些问题，好比某我的过于专精某一项而忽略了和其它成员的交流。固然，也有些部门的 Scrum Master 只负责写报告和推事情。这不是我共事过的任何一位 Scrum Master 的作法，并且我也能够很自信地说，这种 Scrum Master 在咱们公司是生存不下去的。

Scrum Master，你是肩负着人类使命的人啊！嗯！（握拳）

最后，贴两句最近刚学到的话：

1. 50% percent of our decisions are wrong. Fail fast, learn fast. （咱们做出的决定中， 50% 都是错误的。早早失败，早早学习。）
2. No matter what you want to do, choose what is good for your team.（不管你选择作什么，选择对你的团队有利的事）

先声明，说上面两句话的哥们本人在咱们队伍里不算很受欢迎，但这两句我很喜欢。在我眼里，这两句话指出了 Scrum 的全部实质。

-----------------------------------------------------------------------------------------------

咱们公司的开发团队，实践Scrum的效果很是好。在项目开始以前，咱们在内部作了一个 Scrum 的科普，很是适合这个问题，我稍加修改发在这里，确定能帮到你们。

 

1、角色分配和价值观

咱们先来看看，一个团队实践 Scrum 的角色分配▼

 

Scrum 中的角色结构很是扁平，有三种角色：

一、PO：Product Owner，产品负责人，肯定「你们要作什么」。互联网公司的 PO 通常由相关的产品经理担任；若是是为客户作项目，PO 通常就是客户负责人。

二、Scrum Master：Scrum的推进者，掌控大节奏的人。

三、Team：通常由多个 developer 组成，开发的主力。

 

三种角色有各自的责任，但三者间并无上司和下属的关系。这正是 Scrum 区别于传统开发流程的精华：

一、传统的开发流程，是由领导拍板的中央集权制；

二、Scurm 是人人平等的民主制，每一个人的能力都被信任，更加自主，能发挥出更高的效率。

 

Scrum 的价值观▼

 

 

2、三大神器

 

Production Backlog、Sprint Backlog 和燃尽图是三大神器。下面一一介绍。

 

Backlog 是 Scrum中的一个专用名词，意思是待办工做事项的集合。

 

1. Product Backlog (产品待办事项列表)是量化的用户需求，条目化地表达实际须要开发的需求。

2. Sprint Backlog（任务列表）是一次迭代中须要完成的任务，也是开发过程用得最多的Backlog，很是细化。

 

二者区别见下图▼

 

 

3. 什么是燃尽图？

 

咱们天天累加全部任务的剩余时间，将其标注在图表上。用蓝色的表示计划走向，红色线则是实际走向，两条线共同组成了燃尽图。

好比下图中的燃尽图，一开始表明实际走向的红线高于计划蓝线，说明开发初始，任务完成慢，可能遇到了困难。

 

 

3、Scrum 的四个会议

 

1. Sprint 计划会

 

Sprint 计划会就是你们坐下来，PO 向你们介绍排好序的产品待办事项（Production Backlog），而后你们共同思考决定如何推动计划，梳理出 Sprint Backlog 来完成后续的工做。

简单点说，这是一个你们理解「须要作什么」，而后讨论「怎么完成」，并造成待办事项列表的会议。

 

2. 每日站会 Daily Scrum

 

你们在一块儿，自发地汇报三点：

a：从昨天Daily Scrum到这一刻，我完成了什么工做？

b：从这一刻到明天的Daily Scrum，我计划完成什么工做？

c：是否有什么困难阻碍了个人进展？

 

3. Sprint 评审会（Sprint Review）

 

在 Sprint 结束后，你们一块儿评审本次 Sprint 的产出。每一个人均可以自由发表见解，协助产品负责人对将来工做作出最终决定。并根据实际状况，适度调整产品待办事项列表（Product Backlog）。

 

4. Sprint回顾会（Sprint Retrospective）

 

在一次Sprint结束后，你们聚在一块儿开这个会，回顾一下团队在流程和沟通等方面的成效。你们一块儿讨论，哪里完成得好，哪里还需改进？

 

 

以上四种会议，都是你们集思共享的快速会议，注意控制好每次会议的时长。

 

4、用Teambition 打造小而美的 Scrum 团队

 

传统的 Scrum，会用白板和 Excel 等工具。但正如前面所说，Scrum 不拘泥于形式，是探索更高效率的实践，因此有很多团队开始使用协做工具，在这方面咱们选了 Teambition。

 

使用协做工具来实践 Scrum，最直观的感觉就是，对 Backlog 的管理和会议活动管理很是方便，能更好地实现团队协做、需求到研发的信息关联与共享。好比 Teambition 中的「任务」看板功能，把全部任务及进程都「平铺」开来显示，实现了便捷的项目流程化管理；「分享」功能，你们在其中共享工做信息、总结知识经验 ；「文档」至关于该项目的共享协做网盘，你们能随时访问、更新共享资料；「群聊」则更像是该项目的微信群聊，支持项目成员随时沟通想法，而且自动保留每一条消息。别再用微信沟通工做，让工做的沟通发生在工做的平台上。

 

除了团队的沟通与共享，协做工具在对 Backlog 上的管理也很是方便。

 

一、用 Teambition 管理 Product Backlog

 

二、用 Teambition 管理 Sprint Backlog ▼

 

三、不一样 Backlog 间的联动，从 Product Backlog中提取需求到 Sprint Backlog▼

 

 

四、关于实践 Scrum，前面介绍了四种会议，用协做工具线上开会也很是方便，这里以 Daliy Scrum 为例：每日立会能够经过在 TB 项目的日程中设置，Scrum的团队成员都添加为参与者，将站会的日程设为每一个工做日重复，而且提早15分钟提醒你们▼

 

 

五、开 Sprint 评审和回顾会议时，能够将会议记录在线记录在分享中，并和日程关联起来，方便你们查阅▼

 

 

 

以上是咱们实践 Scrum 的一些心得，经过共享与协做，在开发过程当中提升了效率，这应该也是 Scrum 现在这么受欢迎的缘由。以为回答有帮助，欢迎点赞支持~