敏捷开发的实战经验介绍(2)

　　当Scrum团队不大的时候，可以依靠主观感觉来评估执行力。有道云笔记团队在初创的一年内，对sprint的完成情况是没有量化的评估的。

　　Scrum教材对执行力的量化评估用的是故事点和速率。由于团队成员实际上都是有道云笔记的用户，能够直观理解产品经理提出的需求。因此我们省去了用户故事，由产品经理提产品需求，而团队把需求分解成任务。经过一段时间的探索，我们定义了几个量化指标，其中最重要的是完成度，我们用这个指标来衡量团队的执行力：

　　完成度=1-计划内未完成任务的剩余时间/计划内任务评估时间

　　(完成度的数值在80~90%之间比较好。过高的完成度说明sprint计划过于保守。)

　　有些管理者会怀疑完成度的准确性：第一是，团队是否会把计划内任务的评估时间评估得过长，使得完成度看起来高?事实上根据我们的经验，团队对计划内任务的评估往往是偏乐观的;第二是，计划内未完成任务的剩余时间是如何出来的?这个是由团队在sprint末尾评估出来的，因为这时技术设计多已完成，这个时间是比较准确的。我们也曾尝试过燃尽图，发现并不如完成度来得直观。

　　另外，我们还定义了两个指标来作为辅助参考。一个是评估准确度(计划内任务评估时间/实际使用时间)，一个是计划合理度(计划内任务使用时间/计划外任务使用时间)。这两个指标的历史数值可以让我们更加了解团队执行的情况。

　　5、高效的sprint计划会的要素：预先梳理需求、合适的任务粒度、随机认领任务、运营调研任务、任务评估。

　　Scrum开发中，最重要的会议是sprint计划会。但是在这之前，产品经理和研发工程师可以预先梳理一下需求，以保证sprint计划会可以更加高效和准确。我们尝试过多种方式来预先梳理需求：发邮件、产品与研发面对面沟通、开需求梳理会。哪种方式更好，目前还没有定论。

　　Sprint计划会主要讨论几件事情：将需求分解成任务、评估每个任务的工作量、分配任务。每件事情都有各自的技巧。

　　首先，任务分解的粒度应该如何?Scrum开发一般认为任务分解得越细越好，但是在实际操作中我们发现如果分得太细的话是有问题的。比如说，认领任务、记录每个任务的工时和完成情况，都会带来时间消耗。我们经过较长时间的实践，发现0.5至3天一个任务是一个合适的粒度范围。

　　如何评估工作量和分配任务这两个事情是关联的，不同的人做同一个任务，往往时间会相差很大。所以这时候有一个艰难的选择，是让大家做自己熟悉擅长的事情，还是随机认领任务以达到团队人员对所有模块都很熟悉的状态。一个短期见效，另一个长期可发展。

　　有道云笔记PC平台的Scrum团队经历了一个从前者转向后者的过程。在开始很长一段时期里，Scrum团队把自己PC客户端按模块进行拆分，每个模块由一位研发工程师负责，工作量的评估也以这个人判断为准。这个办法帮助团队快速开发了PC的第一个版本和后续几个小版本。但是慢慢的，这种做法的瓶颈就出现了。之前的模块划分随着项目发展变得有些过时，有的模块出现了瓶颈。在最近的几个sprint里，PC平台的Scrum团队已经开始随机认领任务的方式。

　　此外，在实际研发工程中，往往会有一些由于团队没有相关的经验而比较不确定的事情。对于这样的事情，我们会先安排一个调研任务，并且将这个任务尽量安排在sprint的早期，并且凭借经验会在计划会上留出后续实际开发的时间。如果调研任务确定这个事情的复杂度可控，我们会在后续的sprint会议上根据调研成果分解出详细的任务，另一方面，如果这个事情的复杂度太大，那么我们会把完不成的内容放到下个sprint。

　　任务评估的办法，或者用纸笔写下后同时公布或者用估算扑克，两者本质上没有区别。当有较大分歧时经过讨论后再次评估，次数不宜过多，一般1-2次就好，不超过3次。如果讨论不清楚，Scrum Master不妨先定一个时间，让会议进行下去。后面实际开发过程中会越来越清楚。敏捷开发本来就是渐进的过程。

　　6、流水化安排开发环节与测试环节。

　　如何安排测试与开发，是从项目一开始我们就反复思考和尝试的问题。经过一段时间的实践，我们目前采用流水化的方式来安排开发环节与测试环节。具体来说，就是在开发sprint结束后再开始测试这个sprint的产出版本;而在开发的sprint内，开发团队解决上一个sprint的产出版本测试出的bug。虽然这意味着开发团队要在测试环节还未开始之时(Sprint计划会上)，就要估计并预留出上个sprint产出版本的bug修改时间，但在实际操作中，开发团队能够通过历史数据做出比较准确的估计。因此这种方式的效果是良好的。

　　7、版本发布基本按照sprint周期。

　　我们通常在一个或者多个sprint之后(在测试环节之后)发布版本。具体选取几个sprint往往会参考一些市场情况的考虑，比如说将一个做了较多重构的sprint与一个做了较多新功能开发的sprint打包作为一个新版本发布出来。我们基本上不会为某个大版本打乱我们的sprint周期。

　　8、Scrum需要配备合适的工程实践，例如单元测试、代码审核、持续集成、项目管理工具。

　　我们要求研发工程师必须要写单元测试和相互审核代码。测试驱动开发和结对编程目前还有许多争议，我们也不建议贸然尝试。在实践中，我们采用了简化版本，对可以写单元测试的模块都要求测试覆盖，并且通过测试覆盖率来量化单元测试的力度。此外我们将研发工程师两两结对，相互检查对方的代码，只有经过检查的代码才能最终提交。

　　此外，我们对代码进行了持续集成。每天凌晨持续集成系统会自动下载前一天的代码，进行编译和部署。Web端会直接部署到Web测试服务器，而客户端(PC、iPhone、iPad、Android)会自动拷贝到一个内部服务器上。测试人员或者感兴趣的人每一天一上班就可以用到最新的版本。

　　关于Scrum的任务管理，我们采用过不同的项目管理工具，包括白板、开源软件等等。总的来说，工具只是简化了一些统计，Scrum最重要的还是敏捷开发本身的思想。

原文转自：http://tech.sina.com.cn/i/csj/2013-01-22/18528003613.shtml