标签：
前言
BB-Talk 是什么？
BB-Talk 是由Worktile 特别推出的线上分享活动，聚焦互联网时代更高效的工作流，横跨TMT、电商、律师、教育等各行业，覆盖研发、产品、设计、市场、运营、HR、行政等各职业。
每期邀请一位相关领域的大牛嘉宾，通过微信群内的语音、文字、图片等形式，分享干货、自在交流。
本文为6月14日BB-Talk 第一期嘉宾分享与互动提问的总结。
徐子岩，Worktile 首席科学家，软件架构师，连续5届微软MVP，著有《实战Windows Azure》。
Scrum 是众多敏捷开发方法中的一种，它既是方法论，也包括了一系列预定义的角色、一系列的流程，以及一系列的实践经验。那么践行Scrum 到底是应该坚持以理论为准绳，还是从实际角度出发，有所舍弃和调整？一个可运行的 Scrum 流程的主要步骤是怎样的？在这个过程中，工具应该扮演什么角色？Worktile 怎样做到了让原本的Scrum 效率提升50%？这些，在徐子岩近一个小时的分享中都有着重提到，帮助大家快速地梳理出了Scrum 的关键性要素。
我是Worktile 的徐子岩，Worktile 是为互联网时代的企业打造的协作办公平台，支持企业内部沟通、电话会议、任务管理、日程安排、企业网盘和办公应用，连接企业内外部一切服务。而作为一个效率平台，为用户带来便利是Worktile 最基本的属性，同时作为一个研发型的企业，我们在研发方面有深厚的积累和经验。近期，Worktile 从我们超过30万的使用企业中找到30支研发团队、与之深度沟通，重装打造了从研发流程管理到工作效率评估的一站式研发解决方案 。其中就包含了我今天要与大家聊的关于“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 是唯一有权利维护这个列表的人。
在Worktile 中，其实就免去了写文档的的这一步，可以直接将需求通过任务的方式收集，每个需求就是一条任务，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分钟之内，而且所有的成员必须要站着开会。
在Worktile 里面，工作台就可以对自己的个人任务进行集中的汇总展示，可以清晰的看到自己最近完成的任务以及接下来需要完成的工作。
Step6. Sprint Rview
当Scrum 结束后，我们会产出一个产出物。这个产出物在Scrum 里面，可以是一个可以运行的软件，也可以是一个可展示的功能。之所以这么说是因为有一个Sprint Rview 的阶段，我们需要通过Demo 在Product Owner 以及其他的Stake Holders 面前，现场演示你做好的东西（而不是给大家讲你做了什么）。
Step7. Retrospective
在Sprint Review 结束之后就是Retrospective。我们整个团队的人都要坐下来聊一聊，我们的Sprint 做得好不好，有哪些地方需要修改。
上面是对Scrum 的流程做的概要介绍，我们可以审视其中的一些环节：Backlog 阶段需求的收集和优先级排序、Sprint Plan 阶段任务的拆分、领取和进度跟踪、Daily Scrum 的统计……这些环节其实都需要一些工具的辅助，甚至可以说，整个Scrum 流程都可以通过工具的辅助来更好的运行。
依据Worktile 本身看板管理的特性和任务驱动的方式，可以很好的将一些进度和概要信息展示出来：每个需求可以直接创建一个任务，任务标签可以标示优先级，看板上的列表直接就能展示进度和阶段，也能很好地实现整体进度和个人进度的统计。并且在服务器监控和代码共享等具体的研发问题上，Worktile 也通过接入对应的监控服务和代码托管平台（比如github），得以一站式的解决。通过对比以前的研发进度和使用Worktile 做研发管理之后的迭代速度来看，整体的研发效率提升50%是很容易做到的。
在和一些研发企业做过深入交流并总结我们自己使用Worktile 做研发管理的经验之后，我们整理出了一套使用Worktile 做研发管理的解决方案，涵盖了需求管理、敏捷开发、bug 管理、代码共享、部署运维、研发周报和效率评估。其中贯穿了敏捷的思想和Scrum 的一些精髓，并且根据研发过程中的实际情况，做了针对性的调整，对于希望梳理研发管理体系或者实施Scrum 的团队有着非常好的借鉴意义。
有需要的同学，可以点击了解>>
通过上面的介绍，可以看到通过Scrum 这种方式能够把一个真正大的软件，拆分成小段，每一个成员都对工作非常清楚，所有的数据都是经过大家充分讨论、达成共识的。而且每一个任务，都是成员通过优先级，自己去领的。在Cross-Functional 的工作团队中，每一个人的工作能力、技能都是一样的，任何人领任何的任务，都能达成一致的效果。
但是理想跟现实之间永远是存在差距的，今天我们讲的都是理论状态下的Scrum 的样子。真正执行起来之后，会出现各种各样的问题。你会发现有的时候这个东西是不可能实现的。那么就面临的是说你们这种团队，或者说我们的这种研发团队究竟是死板的去追着Scrum 的原则来做呢？还是说我们自己也敏捷一把，把Scrum 也敏捷掉。
敏捷实际上就是一种理念，然后基于这个理念提供了一些方法和实践，在我眼里它意味着持续改进。所谓持续改进就是在产品设计上的持续改进，包括那我们尽量快速的迭代。我们每一个 Scrum 的Sprint 都不会太长，保证我们的每一个Scrum 都能提供给客户一个可运行的版本，能够快速得到客户的反馈。同时在产品区改进中，架构设计也会持续的改进。我们的设计并不是上了之后就把所有的东西都想好，而是基于我们产品的不断改进，在架构上持续的改进。敏捷本来就是持续改进，改进敏捷的流程，并用敏捷开发的精神改变我们自己的开发流程。
最后，我个人理解的敏捷开发的精髓，就是我们永远只做对产品和项目有用的事情 。
1.你们之前做到过Scrum 吗？@小悠
徐大神：开始做会很别扭，等做了四到五个Sprint 之后就会有一种节奏感和默契感。Scrum 对于团队来说重要的是找到节奏感，并且做的好的团队一定不会加班。
（小蜗语录：用了 Worktile 不加班哦）
2.不能演示的Task，如何 Review？@Nemo 前联想PM
徐大神：除了task 还有很多可Review 的东西，比如文档，一定要Review 成果性的东西。
3.产品老觉得我们不愿意做他们的需求，抵制情绪强烈，怎么破？@Rex.M AZT PM
徐大神：很好的例子，把产品拉进Team，因为不同的部门产品、测试、开发都有不同的事情和进度，都不愿意被打乱计划。而Scrum 里没有部门之分，大家都在一个 Develop Team 里面，更透明的方式就能够更好的沟通。
（小蜗语录：用Worktile 协作，更透明，无缝沟通）
4.如何让团队成员更主动去做事，如何在应用项目中推行敏捷开发？有时很艰难，格格不入。@王小?? 中科软 程序员
徐大神：预设成员都是积极主动能做好工作，这是前提条件，其次要重视管理的艺术，对于成员的保护和激励。有的项目不适合做敏捷开发就不要勉强。可能有的项目更适合使用瀑布式流程，找到项目的对的方式去做也是敏捷的精髓之一。
5.如何让水平高低不同的团队整体提高协作水平，从而提高产品质量？@高杉 CBEC 产品运维
徐大神：确实一开始做的很痛苦，做了几个Sprint 就会好很多，大家看到这种开发模式的好处的时候，在不爽的地方对Sprint 改进，不断演进，让大家喜欢上这件事。让团队成员自己去领自己想要的任务，提倡成员去领感兴趣、想要做、想要挑战的那部分工作，同时让工作更透明化。
6.测试用例有专人负责写吗？@我在睡觉 openrec.tv
徐大神：在之前的项目中有个要求是不允许手动测试，只能自动化测试，有测试去写自动化测试代码。每个人都有分工和专长，在Scrum 里面也会有一定分工。
7.测试人员在敏捷团队中是什么样的角色？如何能更融入？@王晴 开目 开发
徐大神：尽量让测试人员也进入开发，进入自动化测试的范畴内，如果测试愿意，也可以Take 一部分开发的工作，这都是可以的。
8.目前团队还是以职能分工，所以不同部门之间的矛盾和分歧怎么解决？@Rex.M AZT PM
徐大神：推进敏捷开发需要的是管理层的支持，部门间有了分歧需要管理层切实去协调和协助，可以选择把重要的人加进Scrum Team 里，他感同身受的时候也会承受一部分压力，不同部门的 Leader 互相了解对方才能更好地配合。
9.Product item 拆成 Task 的力度如何控制？用Worktile 如何实现比较方便？@仕星 中医药大数据
徐大神：Task 尽量在一天内完成，一个 Product item 必须要在一个 Sprint 内完成，否则搞的太大就失去敏捷开发的意义了。
10.技术团队管理的问题，如何处理团队内任务负荷不均以及由此造成的矛盾和冲突？@凡
徐大神：在任务是被强制指派可能出现这种情况。如果是Scrum ，Cross functional ，至少做到一个模块两三个人都能 Take。而后者，如果有人没法做自己想做的东西可能出现，Scrum 提倡自己去Take 自己想要的任务，一般来说就不会有不满了。
11.任务由开发人员完成后是否需要其他人来审核任务完成度？@我在睡觉 openrec.tv
徐大神：在Scrum 里是没有的，启动之后，整个team组确定 DOD ，怎么判断一个任务算完成了，是整个 Dev Team确定的，做这个功能的人符合要求，就可以他认为完成了这部分工作。而最终能不能Release 出去还是在Sprint Review 时由Product Owner 看 Demo 来决定是不是可以Release，如果不可以，需要再新开一个Work item，重新改模块。
标签：
原文地址：http://blog.csdn.net/u013695026/article/details/51729095
