敏捷设计和敏捷开发 - UCD大社区

详解互联网产品开发中的“快”字诀

admin — 2012-04-11 10:40:23

当今互联网的发展，已不是大鱼吃小鱼的时代，而是快鱼吃慢鱼的时代。互联网产品的制胜原则就是一个字——“快”。在各种形态的产品研发中，我们始终贯彻如一的价值观之一就是“快”，我们应该如何来理解和诠释“快”？又会从哪些方面来执行贯彻这个原则呢？

一、快速迭代，快做快发

互联网产品不同于传统软件开发，我们面对的是上亿用户这样一个庞大的使用群体，他们是谁，有什么喜好，有何种习惯，会怎样使用我们的产品，是否喜欢我们的产品……这些情况我们并不能准确地知道。因此，互联网产品的需求，并不能通过几个月的用户调研、市场调查、产品规划就能弄清楚，何况互联网的用户群体本身也处于飞速的动态发展之中。

那么，这种情况下如何发展我们的产品？如何对各种可能的产品特性做选择？用户将是最好的指南针，任何产品推出时肯定不会是完美的，完美是一种动态的过程，所以要迅速让产品去感应用户需求，从而一刻不停地升级进化，推陈出新，这才是保持领先的唯一方式。在这个领域，产品永远是Beta版，可能每几天一个版本，快速地去升级，不断地倾听论坛、用户的反馈，不断地调整修改，然后决定你后面的方向。

所以，“快速迭代”是我们对产品的基本要求，能否做得足够快已成为衡量一款产品研发是否成熟的标准之一。以“QQ农牧场”为例，目前每周平均会发布20个版本，之所以能做到如此高的产品发布节奏，是由于我们一直坚持在做两件事情。

1. 以稳定迭代，小步快跑

虽然，我们追求快速发布，但更需要一个稳定的研发节奏来便保证团队的效率和产品的质量。如何能既快又稳，QQ农牧场采用了一种有特色的敏捷迭代开发模式，我们称之为“极速模型”。

图1 QQ农牧场的“极速模型”

QQ农牧场的研发团队，由多个角色组成，包括：项目经理、产品、UE设计、前台开发、后台开发、测试、运维。以一周为一个固定的迭代开发周期，这一周时间包括了团队一次完整的各个角色的研发协作过程：迭代前有特性规划、迭代后有回顾，其中迭代过程也会包括迭代规划、开发、测试、发布等过程。但与Scrum敏捷迭代最大的不同是：并非在迭代结束时进行交付，而是能够在一次迭代中完成多次交付和发布过程。

此种方式看似简单，但其实对团队的综合研发能力是一个巨大的挑战。其中主要挑战来自以下几个方面。

1) 特性需要能裂解成很细小的可交付的子特性，通常不超过2天的开发工作量。

2) 迭代前，特性规划、沟通确认、界面交互及视觉设计这些工作均需提前安排完成。

3) 迭代计划及评估过程，还必须考虑到特性/子特性之间的耦合关系以及开发人力的耦合关系，合理地作出计划安排，保证开发过程的顺利进行，降低风险。

4) 要求团队成员工作咬合能力高，自运转能力高，需要长期默契配合。前台开发、后台开发、测试人员都能够高效率地沟通，顺畅地协作。

2. 以特性为中心，随做随发

特性，是用户能够感知和使用的、对用户真实有意义的功能单元。所以，仅仅追求发布版本数量是没有意义的，每次发布至少能够给用户带来感知或使用的功能。

因此，我们产品研发的所有活动，都是以特性为中心开展的。一种比较通常的方式是规划一批特性，然后经过一个开发阶段进入测试，集中测试回归后完成发布。但在“QQ农牧场”，从特性规划、计划、开发、测试、发布都是以特性为单位来驱动的。也就是说当完成了一个特性的开发后，即刻转入测试、完成测试后即刻发布。在一个迭代周期内，会有很多不同的特性独立并行于从开发到发布的过程。

当然了，能够做到这样的程度，还依必须赖于产品技术架构、测试自动化、运维发布自动化能力做支撑。但首先，“以特性为中心、随做随发”的核心思想，是产品、技术、项目管理、运维的指导原则，它让产品的整个研发配套能力建设围绕这这个中心来持续开展。

二、反馈及时，响应快速

做到产品的快速发布只是第一步，其根本目的就是让用户尽快能用到新功能，尽快得到用户反馈信息，以便及时地对产品开发做调整。所以，一个产品团队能否能够快速获取用户反馈、是否真正重视反馈并及时作出响应非常重要。经历了12年互联网的摸爬滚打，我们非常重视来自用户的反馈意见，不断改进产品，积累了丰富的交付经验。

1. 建设用户反馈渠道

首先，要解决如何搜集用户反馈的问题，满足不同用户习惯，提供多种方式的反馈渠道，让反馈及时得到。用户可以通过不同的渠道对使用的产品进行问题反馈，提出意见和建议。

2. 重视反馈，快速响应

用户反馈、意见和建议就像一座矿山，为产品的发展提供了宝藏，但产品团队是否真正认识到它们的价值，是否能够快速地挖掘这些宝藏，却并不是一件容易的事情。

以QQMail为例，为了确保对来自用户反馈的快速响应，在腾讯流传着一个1000/100/10的故事。

1) 每人每月必须回复1000条论坛用户帖子。

2) 每人每月必须查阅100篇与QQMail相关的网络评论文章。

3) 每人每月必须处理10个用户反馈意见。

3. 注重数据运营，有数据才有真相

无论事前经过多么细致的调研、多么缜密的规划，对于产品经理来说，一个新特性的发布，仍然是一个提心吊胆的经历：特性被用户的接受程度如何，用户将如何使用，新特性给产品带来了怎样的拉动或抑制，哪些特性可能存在交互、易用性、稳定性等问题。要想回答这些问题都很困难。

数据运营，就是用产品运营数据说话，通过对运营数据的分析，为产品发展提供客观的决策依据。通过运营数据的分析，能够在短时间内获得对某个产品特性的准确评价，进而快速地指导产品下一步的发展。

图2是一个产品93天内用户注册成功率的连续运营数据的例子。

图2 连续运营数据分析示例

从图2可以看出，7月12日前注册成功率稳定维持在20~30%之间。7月12日对注册页面交互流程进行了优化并对外发布，之后2周的数据观察表明新的交互设计起到了预期的作用，注册成功率提升到了40%~60%，即使在7月17日、24日两天有定向向某省所有上线QQ用户发布消息时，其注册成功率也在40%左右浮动2个百分点。通过运营数据分析，能够快速地判断特性目标是否达到，进而指导下一步的行动。

三、快需要创新、需要实力

我们希望产品迭代得更快，但有了这个理念就一定能够快起来吗？快不只是一种产品理念，更是一种技术实力，遵循着这个核心价值观，需要技术上的创新思维，让技术能力来支撑我们的快。

以QQ宠物为例，通过技术架构创新成功地提升了客户端产品的发布速度和更新频率。如果采用传统客户端方式的话，一次版本的全量升级需要6个月的时间，新架构下一次全量升级仅需1天。架构从以下几方面提升了快的能力。

1.客户端Web化技术：像B/S系统一样的开发方式和发布周期

有人会问：客户端的产品发布能快得起来吗？确实很困难，但必须做到，因为这就是互联网产品的基本要求，我们能做到让客户端像Web一样敏捷吗？答案是肯定的，我们的客户端微内核懒加载架构，将客户端Web化技术做到了像Web一样开发客户端产品。

整个架构由客户端的微内核、插件版本控制服务器和资源下载服务器构成，如图3所示。

图3 QQ宠物的技术架构

微内核简要介绍如下。

1) 整个客户端改造成为一个微内核插件平台，只有一个插件加载器、插件版本控制组件、资源下载组件。

2) 插件加载器，负责加载插件。

3) 插件版本控制组件，负责询问版本服务器获取加载的版本。

4) 资源下载组件，负责下载插件资源。

客户端的简要启动运行流程如下：

1) 获取版本：内核启动后，询问版本控制服务器，获取需要加载的版本。

2) 下载相应版本的XML配置。

3) 加载器解析XML配置。

4) 开始第一个插件加载逻辑。

5) 下载第一个插件的资源。

6) 加载第一个插件。

7) 继续加载子节点插件。

微内核懒加载架构与Web架构的比较如表1所示。

表1 微内核懒加载架构与Web架构的比较

	懒加载架构	Web架构
加载器	懒加载微内核	TT、QQBrowser、IE、Chrome、FireFox等浏览器
描述语言	XML	HTML
加载对象	插件	图片、视频、Flash等

2. 微内核、插件化体系结构：特性即插即用，产品灵活稳定

基于微内核懒加载架构的业务开发就变得非常简单、异常灵活。整个产品大大小小的特性，都被拆解成一个个功能组件，组件之间被强行解耦，减少依赖独立运行，这大大降低了依赖性在联调、测试、系统集成方面带来的工作难度，减少了时间，提升了效率。更重要的是，每个组件都可以被独立下载，在客户端加载运行，这也就意味着发布风险的降低、效率的提升。

图4 微内核、插件化体系结构

3. 面向特性的竖向架构：以特性为开发粒度，提升开发效率

传统的产品技术架构多为横向的分层结构，而每一层又习惯于分配不同的人来负责。这直接带来的一个问题是，我们以特性为粒度进行开发、联调、测试时会因为人员耦合、层耦合带来复杂性、引入风险。

图5 传统的横向分层产品技术架构

举个例子，比如开发一个login页面登录功能，可能需要Web前台工程师开发页面、Web后台工程师开发CGI、Server后台工程开发用户鉴权接口、数据库工程师做数据库表结构开发。那么这样一个简单的login功能，在联调、测试、发布方面就会牵扯很多的人力协作，而又因为每一层都需要改动代码，可能对这一层的其他功能代码造成影响。试问这样的方式能快得起来吗？

QQ宠物的新架构则以特性为中心，采用竖向的架构来解决这个问题，每个特性一个组件，一个人负责开发，每个组件必须包括UI、逻辑、协议的代码实现。

图6 竖向产品技术架构

这样的方式，使得面向特性的开发模式得以强制化，从而提升了效率，加快了节奏。

四、快需要手段

想快容易——做快难，除了产品、运营、技术上的能力，产品研发过程上需要有必要的手段保证整个研发快起来。

1. Scrum敏捷开发：发扬光大

敏捷为快而生，快速响应变化，这正是互联网产品的发展需要。我们早在2005年就引入了敏捷开发，目前已经将Scrum结合我们自身的产品、文化、团队特点形成了自己的敏捷研发管理框架。经过自下而上的发展和腾讯人积极的探索和沉淀，逐步形成了“经典迭代”、“极速”、“大象”、“运营”这四个比较有特色的敏捷研发管理模式。

我们在敏捷的推广、实施方面，已经有一套以运营为理念的推广模式，把敏捷当作产品来运营，形成了“管理”、“工程”两条线，在多个维度推行敏捷。

图7 腾讯的Scrum敏捷开发

2. CI：持续集成，快速体验

CI在产品开发、测试阶段提升自动化效率方面非常有效。目前我们CI的发展水平还参差不齐，但从起初的自动编译已逐步加入了静态代码检测、单元测试、自动化部署等更多内容，开始为更多的研发团队所青睐。

作为加快产品的发布的能力，CI在以下几个方面作用明显。

1) 自动编译输出报告，维护代码可运行，及时暴露风险，降低集成成本。

2) Dailybuild日构建系统，让产品经理、测试人员可以尽早进行体验和测试。

3) 作为一个自动化系统，利用静态代码检查、单元测试报告等手段为团队提供报告，促进编码质量不断得到重视，降低缺陷解决成本、缩短解决时间。

3. 灰度发布：提升发布的频率，降低发布风险

在互联网行业，灰度发布已经成为最重要的发布控制手段。有时我们希望通过向小部分用户开发新功能，让他们先来体验新功能、新特性。通过用户反馈、数据运营的手段及早获得反馈，及时改进。以此方式，既可以降低发布风险，也可以提升发布频率，加快发布节奏。

总结

快是一种追求、一种习惯，更是一种能力，这种能力需要产品、技术、运营、研发管理多方面的支撑才能够快得起来。这样的快，就像是中国的高铁，在高速的行驶中还必须让你感到安全、舒适、服务、便利。

作者简介：

王晶，腾讯R&D项目总监、敏捷教练。从事通讯、互联网开发、项目及研发管理多年，目前负责腾讯多个业务线重要产品的项目管理工作，探索并推行适合腾讯的敏捷研发及项目管理。

敏捷企鹅的创新功夫

admin — 2012-04-11 10:23:29

2011年6月24~25日，敏捷实践者的盛会Scrum Gathering大会在上海召开，此次盛会云集了传统行业和互联网行业的众多知名企业，如百度、支付宝、SAP、爱立信……来自于腾讯的嘉宾们也带来了腾讯6年敏捷实践的精华——创新的敏捷实践，结合着腾讯实际业务，故事性的展现了各项实践的由来和价值。

腾讯公司敏捷教练&高级项目经理艾永亮在本次活动中分享了腾讯在敏捷探索中的六项独特的实践：

本文将回顾一下其中最为吸引人的关于如何做到极速开发的几项实践。

2009年最火的游戏QQ农场，一周最多发布23个版本，它为什么需要如此之快的开发速度呢？由于农场玩法非常简单，必须要持续推出新的玩法，新的作物，才能让用户被长期吸引在这里，因此2周已经太慢了，必须要更快的速度才能满足用户。

那么它如何做到的呢？

创新实践：自运转团队

早期的农场项目，大家的压力都非常大，为了能提高效率，项目经理希望每个角色都能全力以赴的提升自己的效率，于是自己承担起来大量沟通和推进的工作，那个时候的感觉是大家都在被PM推着走，一旦PM休假，项目基本没有什么产出，当时去了以后，发现问题很严重，觉得团队的主动性必须被调动起来才行，但是大家都已经习惯了了现有的工作方式，短期内很难到达自组织团队。更加思考和一段时间的尝试，我找到一个中间阶段“准自组织团队”，我们管它叫“自运转团队”。

自运转团队，是将需求开发过程详细划分成开发的各环节，并明确每个环节的负责人，由该负责人来驱动上下游的负责人，而不再由项目经理来连接各个环节，再配合上高效的项目协助工具平台，实现开发过程自运转。这时项目经理则由指挥者变成服务者，观察环节之间产生的瓶颈，并及时采取措施扫除障碍。

借此团队的主动性和合作性明显提升，一次女生节活动，早上提出想法，下午6点就上线了。

如果再能配合上一些其他实践，例如任务墙和版本墙（两种创新的故事墙），以及多种团队建设方法，团队的整体效率以及默契程度会有进一步的提升。

创新实践：发布汽车

过于频繁的发布会打破团队节奏，有效的发布管理是必不可少的，根据业务特点，我们通常会采用三种发布模式，我们管它叫“发布汽车”。

班车模式：像班车一样，固定周期进行，比如每两周发布一次，这周比较适合特性规划比较好的产品，比如QQ客户端基本每个月都会发布一个版本。

的士模式：与QQ客户端不同，QQ Server作为一个平台，它的需求来源非常多，因此它采用多线并行的方式，根据需求来源分成十多个子项目，根据每个子项目如果想要发布，就像打的一样随叫随发布。他的好处是快，但是协调发布的成本是比较高的，比作班车花钱要多。

警车模式：顾名思义可以不按法规来开车，因此对于一下特别紧急的需求或运营事件，必须采用警车这种模式，紧急发布，但这样做成本更高，会把交通秩序搞乱，开发节奏打破。

创新实践：灰度发布

腾讯很早就提出灰度发布的概念，简单说就是，将一项业务不是一下发布给所有用户，而是分批分期的发布，目的有两个方面，一是减轻服务器压力，二是期间可以在小范围收集到用户的反馈，如果业务出现问题，不会让大范围用户受到影响。

随着经验的累计，我们有了许多种灰度策略和方法，灰度也有了更多的应用，甚至引入到了测试环境，即选择一些热心用户，将功能首先发布给他们，通过他们的使用，来帮助我们进行一些现网测试，这使得一些难于模拟的测试场景变得简单，测试人员的压力大大降低；更重要的用户是最好的测试人员，测试结果更加真实；同时他们也享受到了优先体验的特权，可谓一举三得。

关于作者

艾永亮，腾讯公司敏捷教练&高级项目经理，曾参与QQ农牧场，Qzone商城，SOSO，无线应用、网络游戏等业务的项目管理与教练工作。曾任著名敏捷咨询公司ThoughtWorks资深敏捷顾问。有兴趣交流者请联系：艾永亮的微博

敏捷开发思想谈（二）

song — 2012-01-28 13:35:38

敏捷开发思想谈（一） http://ucdchina.com/snap/11431

版本持续统一的意志

为什么需要版本

验证乐趣

我们的设计在我们的脑海里，很可能和在别人脑海里得到的认识是不一样的。

或许大家都能有幸得到统一的认识，但是做出来实际体验的时候又不一定能够符合我们的预期。

就算符合了我们的预期，也许我们玩的时候会发现一些新的点子可以很容易的加入到游戏，并且大幅度的提高游戏性。

所以，多个迭代版本的目的，首先就是为了：验证我们的功能是否符合我们的设计预期。因为:

l 没有实际玩到之前，永远不要相信自己的设计是OK的。

我想强调的是，这里的设计预期不仅仅涉及到我们的功能，事实上作为游戏开发，功能开发永远只占其中的一小部分，还有大部分的时间我们需要用来调整，优化，修改，以达到我们的真实预期。

换一种说法，这里的预期除了功能以外，还有我们对它的感受，也就是这个功能到底好不好玩。而我们关注的重点，也是在好不好玩上。如果只是关注于功能是否完善，那么我们的版本就还离成品有一大段路要走。

所以迭代版本应该是计划功能均可玩，并且没有会阻止我们体验所有需要体验内容的BUG的游戏版本。它是我们评判一切的依据，因为一切功能，一切资源，一切玩法，在进入版本可以被我们体验之前，都存在不确定性，只有最后经过版本的体验，这一切的不确定性才能消除。

持续集成

其次，敏捷开发的要求是快速迭代。但是这里的快速迭代其实远比大家想象的还要快速。或许大家觉得正确的快速迭代就是每一个周期，或2周，或一个月就需要一个版本出来。迭代速度比起传统开发确实快了许多，版本也多了许多。但是事实上的快速迭代远比一个周期要短的多。理想的快速迭代，应该是：

l 每个功能，每个改动完成之后都有一个版本能够立即对功能进行验证，进行体验。

让我们对游戏的改变把握得更直接和高效。让大部分对游戏方向的修正都发生在开发当中而不仅仅发生在周期的开头或者末尾。原因就如我所说，每一个功能从完成，到有乐趣，都需要有一个打磨的过程。在打磨之前，很有可能这个功能根本没有乐趣。所以实际上，我们一周要开发一个功能，很可能我们前4天就需要把功能开发完毕，周四出一个版本进行体验。然后周五针对周四的反馈进行一些BUG修正和反馈修改。之后乐趣才出的来。

是的，如果是理想情况的话，每一个功能无论大小都应该是这样的一个流程。哪怕是一个只有半天开发周期的功能，我们在3个小时开发后也需要出一个版本对功能进行验证，并提出反馈改进（如果有的话）。之后优化到大家觉得这个功能合格或者有存在的价值之后，我们才会继续下一个功能。

这样的过程当然过于理想化，每一个功能我们都可以几乎无限的优化下去。所以我们也需要对优化的程度进行取舍。这样取舍的标准还是最终会基于我们开发者自己的个人能力和标准上。更重要的是，我们需要建立每一个功能和变动都需要一个版本进行验证的意识。进而才能追求我们的版本质量和效率。

冲刺的艺术

效率

敏捷开发绝对不是牺牲效率追求品质的开发模式。

相反，在每一个迭代当中：

l 效率才是需要追求的第一位。

唯有在尽可能快地发布版本之后，我们才能根据版本的反馈，进行修正。进而得到更好的版本质量。大部分时候，我们需要的仅仅是以最快的速度得到我们需要的原型。验证我们的设计。为此我们需要尽可能的追求效率。

那么，如何得到我们需要的效率？

范围

首先，永远不要做多余的事情。一旦目标明确，那么我们的目标就是所有我们要做的，在目标范围内的质量优化，必要的代码改善，必要的体验优化，都是可以做的。但是离开了我们目标范围的事情，一件都不要做。

这里的范围，则是一个度量。而这个度量的划分，则又一次，需要依据我们这些人来判断。它需要我们深刻的理解到，我们制定这些目标的意义，我们要实现的究竟是什么，我们应该优化到什么程度？

我们有多少时间，那么我们就只能设计到什么程度，做到什么程度。而更多的次要的需求，我们有时间再考虑，更多的兼容性想法我们可以想，前提是我们这个版本还有时间。我们需要画一条基准线，在有限的时间里，我们能做多少内容，该做哪些内容？一切行动都需要以我们的目标为准则。当然，我们还需要考虑量产和下个阶段的准备工作等等（然则，这些其实如果规划的好，应该可以算作这个周期内的目标之一）。但这些都需要服从于当前版本的开发。全力开发我们需要的内容。

因此我们需要避免过度设计，过度开发，以及过度优化。我们需要将效率作为我们开发的准则。

人员

永远只涉及必要的人。为什么我们要进行小组化开发？因为人员牵扯一旦扩大，唯一的结果就是效率降低。各种意见难以统一，管理变得困难，计划难以统筹，任务分配变得困难等等。所以最佳的小组规模应该在7人前后。

仅仅如此么？当然不是，我们不但要确定小组规模并且将小组开发与外界的干扰屏蔽开。我们还要确定我们项目开发的流程中，每一个步骤所要参与的人员，哪些是真正必须的，哪些是不必参加的。确定人员的职责范围，首先他们需要专心于负责的部分，之后才涉及力所能及的部分。

在这里，需要解释的一点就是，敏捷开发并不是所有的决定和步骤都要大家来参与，以增进组员责任心和归属感的。为了最大化效率，我们永远只让必要的人来做必要的事情。比如故事分解为任务，只需要小组成员，和相应的主程主美主策。比如故事本身的优先级划分，只需要核心组成员（更加通常的情况是只有PO）参与即可，小组成员没有必要参与。再来，版本体验会，我们需要的是真正的指导性的意见和重要的人的声音，如果需要专门组织一个会来听小组成员对版本的反馈，我觉得那小组成员平时就不知道是干什么去了。我们需要在组织每一场会议的时候都考虑到，是不是每一个到会议的人都是必须到的，因为我们找他来开会的时间，都本来应该是他开发和工作的时间，而那才是我们的重点。

高效会议

最后，我们需要有一个清醒的认识，过多的会议永远都是高效率的开发的大敌。一个会议10个人，一小时，意味着我们会损失10个人时的工作时间。而实际上一周的工作中，我们一个人时都是损失不起的。当然，这并不是意味着我们不要开会。而是我们需要意识到我们的会议究竟是否有必要，如果有，那么会议效率是否足够？我们是否有足够的会议准备和计划，能够保证我们会议的效率？还有我们是否有相应的会议章程，会议时限？这些都是我们需要考虑的，用以高效化会议，减少时间浪费的重要方法。

所以，当我们思考效率的时候，不妨真的来看看我们现在的开发，分析一下一周的工作中，究竟开发的时间有多少？其他的时间又有多少。看看到底是什么在影响着我们的开发，是否有方法，或者措施，能减弱这些影响。最终进一步加快我们的开发？

开发的脉络

交流

非正式沟通

交流，在敏捷开发中，是永远都谈不够的东西。也是永远会存在问题的地方。在敏捷开发中，我们会重视交流而轻文档。原因？只是因为交流永远比文档更高效。

并非我们就此放弃文档，文档最终会变成记录我们讨论交流结果的工具，便于未来查阅。高效的原因是，在交流的过程中，我们就可以共同修正分歧，修正个人的错误，并且将信息传达给对方。当然，一切都还仅仅是基础的东西。

进一步的是，究竟如何能让我们的交流高效？首先，必须明确一点，会议并非是高效率交流的良好方式。更好的交流，应该更多来自于更频繁的，更多的非正式的沟通。把所有人拉到一起，强迫他们发言，或者收听，并非能很好的传递信息或者进行讨论。而鼓励他们进行自发的讨论、交流、在每天，在所有的闲暇，都可以进行一些思想，一些想法的发散、讨论。这才是最好的情况。

我们当然也可以就此进行推动。更多的不是人为的设置一些刚性讨论需求，而是制造一种推崇各自讨论的氛围。

邮件

其次，是我们交流的方法。我们有没有真正考虑过，哪些内容我们应该放到正规会议上进行宣讲？哪些内容我们只需要发一封邮件，并收集回信的反馈？哪些内容，我们只需要找到相关的人，非正式地谈论一下就可以得到解决？这些分类一旦清晰，能够为我们的团队节约多少时间？

从另一方面来说，有多少内容我们甚至连邮件都没有发出，完全变成了个人的地下行为？在这里，我想强调一下关于邮件的作用，在原来的公司，我们被要求尽量少使用邮件，因为某个时期，员工们甚至把所有需要面谈的内容都用邮件来代替了。距离5米的两个人甚至一周几百封邮件却没有一次谈话。

而在现在的环境中，邮件却变得相对冷落，很多应该有邮件作为记录，或者应该由邮件发出的内容都借由其他的方式或者没有以任何方式发出。比如现在很多的策划文档，每一次更新，只有一定几率会有邮件通知到大家。比如会议纪要，当然这都还是表现的比较好了。再比如不太重要的设计文档，这些都可以借由邮件发送来让需要知道的人了解，并且相比专门的宣讲会，节约很多的时间。大家只需要看完之后，把反馈意见用邮件发回就可以了。所以，我们可以考虑是否完善我们对于邮件的使用？更重要的是，是否我们可以进一步提高我们对于邮件使用的意识？我相信，这会是一个很漫长的过程，但是必然能够极大提高我们办公的效率。

其实终究，还是我们考虑问题的方式，我们是否能够意识到我们现在的交流方面的不足，是否能够开始改进？这将是我们是否能够继续成长的关键。

项目的基石

人

谈到人，其实就是谈到整个流程和过程中最关键的地方，最关键的元素，也是决定一切事情成败的根本。无论多好的制度，流程，如果没有相应的，合格的人来执行，也只会是失败的结局。那么，在敏捷开发中，或者说在游戏业的敏捷开发中，我们需要什么样的人，我们需要什么样的素质和要求，才能更好的运作这个模式，更好的做，并且做出更好的游戏呢？

迭代的意识

首先，是改进的意识。永远记住，没有完美的东西。我们需要保持清醒的认识，认识到我们的项目；我们的流程；我们的文档；我们的游戏等等，都还有可以改进的地方，都还有很多可以改进的地方。改进是没有终点的，我们需要能够找到这些可以改进的地方，我们还需要可以找到改进的方法，并且切实的推行下去。这样，我们才能在一次次迭代中，得到更好的项目，更好的版本，更好的团队，等等。意识到我们有问题，我们才能够改正这些问题。从某种意义上来说，其实这也是迭代的意识。

效率的意识

其次，我们需要效率的意识，我们要明白，最终，我们是在开发商品。我们是在进行商业运作，所以效率是我们需要真正关心的。而效率的重点并不是每天在公司里花了超过8小时，而是我们的时间是否都真正被有效利用起来了。我们是不是真的在需要的时间内，给出了需要的成品。是否这些成品能够合格。每天做的事情是否有意义，是否能够给予我们的工作和项目帮助？我们是否能够抓住我们工作的重点？而不是浪费在无关痛痒的地方。我们需要考虑我们的工作是否是向着目标前进的，是否足够，是否有效率。要做到效率，我们就需要首先明确我们的目标，其次清醒的意识到我们在做的事情，最后再反省是否有无效或者被浪费的地方。是否我们能做的都做了，是否我们把不需要做的也做了？

理解游戏

再次，我们需要有对游戏的把握。毕竟，我们做的是游戏，如果做的人都不知道什么是游戏，那么如何能保证我们做出来的游戏能被人喜爱？甚至，我们如何能保证我们做出来的游戏，是游戏，而不仅仅是一个选择播放的技能地图预览器？所以，首先，我们大家都需要了解游戏，了解什么是游戏，游戏包含了什么；游戏性是什么；核心玩法是什么；主要模式是什么；画面表现是什么；音效是什么；故事是什么，它们是如何结合的，是如何组合成一个游戏的。不同的游戏类型里，这些要素又以什么比例组合，哪一个更加重要。这些都是游戏开发者所需要了解的基本。进而，开发者才能明白，我们现在的游戏已经有了哪些元素，还差哪些元素，已经有的元素是否足够，是否还有所欠缺。这时，合格的游戏开发者们，才有能力说出，我们的开发方向在哪里，应该补充什么元素，有什么欠缺的地方。这样，我们才有能力，做出一个至少完整的游戏。

开发者的野心

进一步，我们如果还有野心，并非只是做一个完整的，良好的游戏，我们还想要有创新，想要做一款让人眼前一亮的游戏。那么我们就不只要了解什么是游戏，我们还需要对游戏有自己的理解和想法，我们需要有自己对这个游戏的未来的想象，并且时常将之拿出来讨论，碰撞，最后留下那些可行的，优秀的方案来实现。我们每个人都需要对我们的游戏有所希望，并且这些希望都是需要时常在我们的大脑里酝酿的。这才是游戏开发最有趣的地方，我们总是可以实现我们脑海中大胆的想法，我们总是可以把我们有趣的意见，点子说出来，如果能够得到大家的赞同，就可以实现到游戏里去。做游戏应该是有趣的，而不是每天重复枯燥无聊的劳动。所以，我们需要思考，并且说出我们的想法。

快乐地制造快乐

用心制造快乐，是不够的，还需快乐地制造快乐。让我们并不仅仅是麻木的工作着，而是真的有趣的去做有趣的事。这才是做游戏的本意，这才是大部分人最早加入游戏公司制作游戏的本意。如果我们做的东西连我们自己都无法说服自己，“那是有趣的。”那做出来的真的能有趣么？我们在做游戏，之后才是工作。如果整个游戏，都没有一点自己的心思在里面，那我们就真的只是在勤劳的上下班了。

而且也只有相互间的思想，想法在碰撞，才会做出有意思的游戏。游戏的设计并不仅仅是策划的事情，游戏的需求也不仅仅是由策划提出。只有大家每个人都可以针对游戏的缺陷，乐趣，玩法能有自己的见解，每天争的面红耳赤，那才是真正做好游戏的取胜之道。在游戏性的讨论上，根本没有策划美术程序之分。

对游戏工业化开发的把握

最后，我们还需要有对游戏开发的把握，对整体的把握。我们是否知道我们现在处于游戏开发的哪个阶段？这个阶段应该重视那些东西？应该注意那些东西？这个阶段我们应该完成那些东西？对于这些我们是否有清醒的认识，清醒的计划？

我们是否有对我们项目的整体规划？知道我们现在要做什么，知道我们下一步还要做什么，这才能让我们明白我们现在做的是否有意义，是否有效率，是否正确。我们的目的，绝对不是过GR1，2,3,4,5.这一点大家应该明白，我们始终都是在做游戏，如果我们的方法正确，计划正确，那么这些评审对我们产生不了任何影响，那么既然我们每次都需要针对这些评审改变我们的流程计划，那么是不是也意味着我们本身的计划也存在一些问题？这个问题大家也许可以思考一下。不要让问题找到我们，而是我们去寻找问题。

故事WHY ME? WHY STORY?

为什么要使用故事？

我们为什么要使用故事？要理解这个问题，首先要理解故事的作用。那么故事的作用是什么？

消除理解误差。

早期软件开发的需求方往往不懂任何技术，开发者的功能清单却往往难以让需求方有直观的对最后成品的认识。比如，或许一个功能描述是，“战斗场景分为5层可以根据摄像机的移动而相对运动”，但对于非专业人士来说，他们可能无法理解这样的描述意味着什么。于是故事开始发挥了它的作用：以一种大家都认可的方式让所有人对我们要做的功能目标有清楚的认识。

所以：

l 只要能够让全体人充分意识到我们功能开发的目标以及内容，那么它就是一个很好的故事。

对我们来说，这样的共识需要在策划，美术，程序等人员之间达成，所以我们的故事也需要以一种大家都能理解的方式来表达。而更重要的，不是故事的方式，而是确实所有人都能够完全理解。具体怎么写，其实真的怎么写方便都可以。

整体统筹估计和管理。

由于故事是从系统和结构的层面，以一定的高度来描述我们整个项目的框架功能，所以我们可以以较快的速度全面了解我们的功能点，而对于这些功能点，我们还可以进一步快速的给出粗略的估算。进而得出整个项目的大概工期或者每个迭代我们可以完成的故事数量。这里的估算往往是由不准确慢慢到准确的。

l 每一个周期，每一个项目的历史数据都可以让我们之后的估计更加精确。

而且这样划分的工作，可以更好的交付给不同的小组完成。小组内部进一步自行组织计划，使得我们的管理工作可以分散到小组，降低管理难度。

创意管理

本质上，游戏就是已有的同类游戏的完整功能点，加上我们独特的创意。完备的前者能让我们的游戏成为一款合格的游戏，而后者的加入则让我们的游戏变得独特。引入故事后，我们可以总是在一个层面，对功能开发和创意尝试的投入进行平衡，相互以取舍。我们可以总是以功能和创意的价值来判断真正对我们有价值的开发顺序。

故事在讲什么？

什么是故事?

首先，故事本质上依然是功能点，依然是从需求中抽取出的一个个系统功能。只是以一种所有人都能理解的形式进行描述。所以，为了能够让所有人能够理解，故事仅仅只从实现功能的目的来描述这个功能：

l 故事是对功能的目的的描述

同时，故事是在讲述这个功能究竟是发挥什么样的作用。所以它本身价值只是简单描述和给予一定参考。

l 它不是，不能也不需要详细的描述这个功能的所有细节和玩家对此的感受。

因为前者有相应的策划文档，后者难以文档化以标准衡量。

所以，当我们要验收某个故事的时候，并不是我们比照着一个个故事，来体验游戏。看一个个故事是否在游戏中完整的实现了。

正确的故事验收，应该是在这个故事在组内达成统一之，所有人就应该知道要做成什么样子之后。将单个功能的验收在周期内

就实时完成。而在最后版本发布之时，对功能进行检验，检测这个功能的最终效果是好还是坏。

我们的目的不只是要看是不是功能A,B,C,D已经完成了，我们应该再深入一步：

l 关注于功能是否得到了很好的效果，符合了我们的预期

l 在游戏开发中，则是，是否有了乐趣

l 是否有其他想法，能够让这个游戏更有趣

因为仅仅是功能的集合，并不能成为合格的游戏。

因此，我们也需要改变我们对于设计目的的定义：

l 我们的目的并非仅仅是完成某个功能，而是功能能否达到我们需要的乐趣。

带着这样的思路，我们才能真正的在版本回顾的时候，给予能够指导我们开发方向的反馈，而非仅仅是针对我们功能开发的完整与否，发表意见。

作为核心组成员，或者，作为整个游戏项目的一员：

l 我们不应该仅仅关心于完成情况，各种细小的错误。我们应该看得更远，思考的更远，给予我们的开发真正能提升最终质量的帮助。

最后，故事包含对它大小的估计，我们可以使用这个估计来对将来的工作和计划进行评估；对它本身价值的估计，让我们在选择他们时可以参考。简单的来说，就是另一些附加的功能。

用好你的武器

如何使用故事

故事的来源

第一，从已有的游戏设计文档或者框架中抽取的，比如，我们已经知道我们要做的是一个回合制战斗的游戏，那么我们就可以抽取出，基础战斗指令，回合制战斗流程之类的故事。

第二，新出现的创意性质的内容，比如，今天我突然想到在回合制战斗中加入行动顺序条或许是个很有趣的点子，我告诉大家，大家也觉得这个东西很好，于是我把它加入到清单中。

第三，当我玩到某个游戏的版本的时候，发现，某个功能给我的反馈不是很好，或者我觉得可以如何改进，能够让这功能变得更好，那么也可以放进到故事清单中。

故事的使用

首先，我们有一个用来维护故事的列表，术语叫做产品订单，里面罗列了所有我们已经完成或者没有完成，重要的或者不重要的故事。我们可以在里面清楚的看到：

l 故事的描述

l 故事点（大小）

l 优先级（价值）

l 当前状态

于是，在每个迭代开始的时候，我们都将故事从大到小排列起来，依据上个版本我们能完成的故事量（以故事点来衡量）来选取我们这个版本需要完成的故事内容。

故事选取完成后，下一步，则是让整个小组对故事的内容达成统一。也可能只是统一目标，而某些细节在完成的过程中确定。这过程的形式，依然并不固定。

当大家对故事的内容都有所了解之后，我们可以开始对故事进行分解。得到相应的详细的任务。任务又成了计划，在对计划进行评估和检验之后，每个周期的工作内容就如此确定。

故事的作用就基本到此结束，剩下的内容是当单个故事完成的时候，对版本中功能进行体验，如果通过，则这个故事就此完成，最后进行归档之类的收尾工作。

当然，在故事的具体使用中还有一些细微操作，比如如果一个故事在一个周期中制作时发现比估计的大很多要放到两个周期来做才能完成。那么我们还需要对故事进行拆分之类的操作。这些细微操作还是需要在针对不同的情况进行不同的处理。

版本体验会

当我们一个周期的开发内容完成，每个版本功能都已经在周期内得到了验证，并且已经有了一定的优化。为什么我们还要有一个版本体验会呢？

首先，我们每个人负责的领域不同，我们有的人对于美术质量很关注，有的人对于代码质量很关注，有的人对于设计文档很关注。也许我们中的一些人参与了一些功能的开发，但是我们并不能对于这个周期的所有功能，所有的改动有所了解。就算对此有所了解，我们也许也不明白每一个功能的设计用意。最后，为了让所有人对最终结果达成统一的认识，我们需要一个正式的展示会议，向核心组或者高层进行我们这个阶段的成果展示。在展示我们的版本新增功能和内容的同时，核心组也会对这个版本的各个细节和内容进行考察和审核，确定这样的改变是否符合对于游戏性和乐趣的追求，是否符合我们对我们游戏的希望，这样的发展方向是否是正确的。

而在这样的会议中，最重要的是，我们需要得到来自各个方面的反馈。作为开发者，这可能本身就局限了我们对于我们的版本的认知和看法。我们对于我们的版本过于熟悉，有可能自动的忽略掉了一些很重要的问题，或者会错误的认为一些难以被接受的游戏性具有很大的乐趣。而这样的会议，则是指正我们类似问题的恰当时机。针对这些反馈，我们可以更好的修正我们的工作思路和计划。给予我们下一个阶段更好的目标。

所以，在这里，核心组需要给出的，更多，更重要的，还是对于我们游戏的方向性的，涉及到我们目前开发功能的游戏性和表现上的改进意见或者反馈和一些指导性的意见。因此，我们需要要求我们核心组本身更了解游戏，更明白游戏性，并且自己对于我们要开发什么样的游戏，有清醒的认识和思考。

周期总结会

自适应，自我优化的流程，需要有两个要素才能真正的进行自我改进。首先最重要的是其中的人要有对流程中的问题，需要优化的地方，甚至是对优化本身有清醒的认识和意愿。其次，就是这样的人推动的一个优化行动。而周期总结会，就是SCRUM中设立的一种针对流程自身优化而进行的一种行为。

项目总结是游戏业的一个普遍工作习惯，在每一个游戏项目结束的时候，会进行一次全项目级别的总结会议，对于整个项目过程当中，做的好，有典范价值的事物，或者在过程当中发生的有范例价值的问题，甚至是还没有解决的问题进行系统的总结和提炼。之后将之发表，可以成为团队，甚至其他团队将来工作时的依据和帮助。

而每一个周期一次的周期总结，则是将这一行为加快，频率加高，在项目进行中不断反复。以此达到更快速的寻找总结目前我们的优缺点，针对我们目前的缺点问题寻找解决的办法，并且开始行动。总的来说，就是以更快的频率不只是迭代我们的版本，将我们的版本改进的更好。同时也是迭代我们的行为，优化和让我们自己更加的进步。

其实设立一个这样的会议并不难，每一个周期我们都会有这样的总结会。而会议也总会有这样那样的缺陷和需要优化修改的结果。难的是我们需要切实的推行那些问题的修正措施，难的是我们需要能够直面我们的不足，并且将其提出。我们要能对或许难以开口的问题更直白。鲁迅先生有云，真正的猛士，敢于直面惨淡的死生。我们必须承认我们的工作都是不完善的，都是需要优化的。但是这些问题都不是阻止我们开始修正和改革的借口。敏捷开发的意义也就在于，知道一开始的我们不足以成功，甚至肯定会出现问题，会有失误。但是正是在一次次快速迭代中，我们快速的磨合，快速的修正，最后在一次次的改正与进步中，我们才会得到一个完善的团队，一个良好的流程以及一系列适合我们的方法。

这也才是周期开发的意义所在。所以，敏捷开发，并不是一个需要在一开始就有完全的准备的过程，并不是一个需要完整规划，好好考虑的过程。我们只需要有一定的东西可以开个头，哪怕还不算成熟，但是我们依然可以在接下来的过程中，对我们的目标愈发的清醒，越发的明确，并且我们本身也会越发的成熟，最终共同达到目标。

一开始，游戏功能不明确？没问题，我们可以先从知道一定会做的开始做，然后开始探讨我们最后要做的目标，再根据每一个迭代的版本反馈修正我们的目标。

一开始，我们开发团队磨合不够？没问题，我们可以先让他们从开发简单的底层功能做起，并且同时进行磨合，将磨合过程中需要解决的问题一一提出并改正，最终优化得到一个完善的团队。

一开始，我们的工具不够？没问题，我们可以先用最快的方式开发原型，同时分析原型制作的方式和需求，进行工具制作。并且在工具可以使用之后，再根据使用者的反馈和项目的进展进一步的优化和改进。

... ...

我们可以做的东西很多，而那些还没有做的，也同样不能成为我们开始做的障碍。

原文地址：http://djt.open.qq.com/portal.php?mod=view&aid=115

相关话题：敏捷设计和敏捷开发源地址：http://ucdchina.com/post/11432

敏捷开发思想谈（一）

song — 2012-01-28 13:27:52

敏捷的原则

敏捷开发其实并没有标准型的流程。SCRUM也只是众多衍生体中的一个。实际上就算是SCRUM的实际使用也情况千差万别。所以首先，请大家有这么个概念：
敏捷开发绝对不是一套一成不变的标准化流程。而更多的是一种自适应，自我优化的流程优化理念。

并没有一定的流程，而是需要大家有对任何自己觉得不对的，不正确的，效率低下的事情的警觉性，和将之提出来并进一步改正的行动力。其次，敏捷之于游戏开发，则更要体现人对游戏本身品质的把握，而非对各种文档的审核，这就是和传统软件开发区别最大的地方。所以，没有最好的流程，只要是合适并且能够持续优化的流程就是好的。

所以：

l 不一样的项目经理会有不一样的流程

l 一样的项目经理，不一样的团队，也会有不一样的流程

l 一样的项目经理，一样的团队，每隔一段时间，都还会有不一样的流程。

迭代想与得

为什么我们要迭代？

进行游戏开发，首先请大家对此铭记于心：

l 我们的设计不一定是我们真正想要的

l 文档内容在我们想象中和实际体验版本时的感受不相等

l 我们没法100%的思考到所有需要思考的角落

同样，要理解为什么要使用迭代，我们需要明白迭代开发从何而来。最初，软件开发行业中，一般都由需求方提需求，开发方拿到需求开始分析设计，一次性开发成型交付。随着行业的发展，软件复杂度的增大，需求变化的增加，大家发现一次成型的版本往往无法满足需求方的需要，于是返工。当这样的情况多了之后，返工就成了一种标准化的流程，系统化的返工其实就是我们所谓的迭代了。当然这是一种比较民间的解释，但是在游戏产业中，这也说明了：

l 迭代的目的是为了应付需求的变化。

这里的需求变化需要我们的额外注意：

l 游戏产业中的需求变化，并非只是指策划或需求方在中途站出来说自己的想法有变。更多的时候，是自己在进行游戏开发的过程中，出于对开发的游戏的认知的加深产生的需求设计的变化。一般来说游戏的需求来源于设计，但是我们的设计却往往并不是我们真实的需求。或者说，我们的设计往往不能满足我们真实的需求。

例如，我们需要一个激烈爽快的单体攻击技能，那么我们的设计可能会涉及到，这个技能的功能，伤害，消耗，动画播放等。这个设计还会涉及到表现：比如技能的动作如何，特效如何，播放速度如何，镜头如何。当我们看到这些设计，我们是否就能确定这些设计能够满足我们的需求？进一步，就算我们看到设计之后，认为能够满足了我们的需求了，但是否在游戏版本中我们实际体验的时候，实际效果能100%符合我们的预期？

当我们清醒地认识到：

l 无论我们在设计上花多少时间，我们都无法完全消除设计的实际效果和预期的差距。甚至在超过某种程度之后，我们花在设计上的时间将会形成浪费（这就是所谓的OVER-DESIGN）。

我们就应该开始考虑，什么时候设计应该停止，什么时候我们就应该开始先做，然后预留足够的时间，把那些可能出现的，和必然出现的问题，留给我们后续的迭代来发现和解决。而不是把这些问题试图在一开始全部解决掉，第一，不现实，第二，不科学。

旋转上升

什么是迭代

那么，迭代究竟是什么？

首先要申明一点是，其实我们现在谈论的迭代并不是纯粹的迭代，而是迭代加增量开发。纯粹的迭代是指没有新需求的加入，第一个版本实现的内容就已经完整，之后的版本只是之前内容的优化。而增量，则指下一个版本是在上一个版本基础上增加内容的开发形式。

那么，迭代加增量开发的意思就显而易见了，而我们需要的开发模式就是这种：

l 在不断以版本为基础的增量功能开发的基础上，不断对已经有的功能进行完善和优化。这就是狭义的迭代

进一步来讲，广义的迭代，则不仅限于我们的功能开发。而且还要对于我们本身的流程，工具，工作方式，方法，习惯等等所有可以改变，可以优化的地方进行优化，进行修改。最终的目的就是通过一个个版本迭代开发，不只功能品质在变好，团队效率，团队流程等各个方面都会变得越来越好。最终形成一个真的具有战斗力的团队。

周期总结会议，以及一系列的问题改正，优化提高事项，以及平时提倡的交流，对于变化的拥抱等等，都是为了这个目标而发生的。所以，

l 敏捷开发是一种精神，而不是一种固定的形式。我们需要有一切都是可以改变的心态和准备，并且真的可以着手去改变任何我们觉得有问题的东西，这样才能真正发挥敏捷迭代开发的优势。

陀螺的转动

如何迭代

迭代的漩涡

首先，我们抽象一下，以便大家能简单的明白迭代的形式。迭代就像是一个漩涡，从漩涡中心开始旋转，越转越大。而处于迭代最中心，所有的东西都围绕它来转动的那个核心，就是我们的产品订单（故事清单）。

而那条旋转的线，就是我们的版本。版本永远围绕着我们的故事清单来开发，（故事清单，抽取于我们的游戏的设计），版本总是由故事清单里寻找需要完成的功能，再将根据实际版本得到的反馈，并更新故事清单。于是功能清单的功能越发的有价值，而版本本身也会越来越有价值。

迭代的步骤

那么，我们的版本该如何围绕我们的功能清单来画这个漩涡？

首先，漩涡是一个环绕的圈，所以我们先确定圈的长度：

l 一个迭代的长度

在这段固定长度中，它其实是一条单向封闭线性的线段，有始有终。有始有终的过程才能被量化和计划。在线段开始时我们从产品清单中取得信息，在结尾会释放一个版本并向产品订单反馈信息。

再进一步深入：

在这线段的开头，我们要从产品订单中取得什么？故事。什么样的故事？价值（优先级）总和最大，且大小（故事点）不超过我们一个周期工作量的故事。仅仅如此么？当然不是，首先，有一个重要的概念：

l 系统

也许有几个故事隶属于同一个系统下，它们共同组成了这个系统，它们全部完成，或者至少关键部分完成。这个系统才是完整的。当系统不完整的时候，这些功能的乐趣根本无法体现。

那么，有可能当我们选择这个周期开发某个高价值功能时，没有开发相应的属于一个系统的其他低价值功能。于是周期末的版本我们发现，由于系统的不完整，这个功能乐趣甚微。如果对这种涉及系统的问题没有认识，那么我们很可能就会对这个高价值功能有错误的认识。（关于系统理论的知识，请参见WIKI系统学一词）

如何避免这个问题？这个时候人的作用就体现出来了。当然我们可以在故事列表上增加一列系统属性，提醒我们。但根本的方法还是一个或者多个对整个故事列表有着足够把握能力的人来进行掌控。

我们需要有人能够全面的了解设计意图，并且对我们的故事列表进行把关，对我们周期开始的需求选取进行主导。有一点大家应该明白，规则和标准都是人制定的，那么我们究竟是依靠标准和规则来更好的控制结果，还是依靠人本身？是完善更好的标准，还是培养出更能把握质量的人？

接下来，线段中的开发过程，本质上其实就是分析需求，制定计划，开始开发。或许会周期内分为更细小的周期进行迭代。但是这些小迭代其实依然是瀑布式开发，这点毫无疑问。区别只是在于，这样的小周期内，我们开发的思想和方针是以敏捷开发的思想为指导的，我们更注重版本，更注重交流，更注重结果。而不是预定义式的开发流程（pre-defined)。

在线段的结尾，一个周期结束了，我们需要做两件事情，第一是将我们体验版本之后的反馈，反馈回故事清单中。或许我们体验某个功能之后会觉得加上另一个功能会更好玩，于是我们提升这个功能的优先级。或许我们会觉得这个功能很无聊，于是我们把同类型的功能优先级都降低。再或者我们添加，甚至删除一些全新的故事（不推荐）。

迭代的节奏

在迭代中，我们还需要注意我们迭代的节奏，什么时候该松，什么时候该紧。什么时候我们允许大家的发散和更多的思考。什么时候我们应该专注于我们的目标并且忽略其他的一切以得到我们最终的版本。这些都是有所讲究的。

这节奏包括各个方面。那么究竟这样的节奏应该如何来走呢？

在一个迭代之内，我们的节奏应该是先松后紧。当然不是说迭代开始时我们的效率可以放缓。这里的先松，是指在一开始时我们可以有更多的想法和思路，更多的探讨和研究。本来我们的迭代工作就是从粗到细，从模糊到精确的进行。在迭代中，我们也如此一步步明确我们的工作。

一旦目标明确，那么迭代周期SPRINT的名称的含义就出来了：我们向着我们的目标冲刺而去。到了这个阶段，我们需要收缩我们的讨论和想象，一切以最后的版本和质量为前提。以尽可能快的速度来开发我们的功能，提高我们游戏的质量，得到我们需要的结果。至于具体的迭代方式，各有不同，我的方式大家可以参加之前发出的那个VISIO图表。某些细节接下来还会讲到。

企鹅快跑——腾讯敏捷历程揭秘

baiyuzhong — 2011-09-20 23:25:46

文/艾永亮

腾讯这只企鹅在13年的成长历程中，不断长大，但却并不笨拙，这其中的秘密就在于研修了敏捷方法！本文就将为您揭开其中不为人知的敏捷故事。

天生敏捷基因

企鹅出生在极速变化的互联网行业，出生之时便面临着四大挑战。

海量用户的需求：企鹅服务于数以亿计的互联网用户，在保证业务稳定的前提下，更要满足海量用户不断变化的需求，因此企鹅必须要竭尽全力快速实现一个个新需求，如果采用传统的开发方法，用户是无法接受的。

行业的迅速变化：互联网上新概念、新玩法、新应用层出不穷，一会儿SNS、一会儿团购、一会儿微博，一步落后步步落后。

竞争对手的压力：虽然很多人都觉得企鹅很可怕，但是行业变化如此之快，企鹅再大再强也不可能把所有产品做到第一，取舍之间就有可能被其他公司超越，毕竟迫于竞争对手的压力。

自身发展的需要：企鹅希望能为用户打造一站式在线生活，让用户更加方便地在网上冲浪，但要想实现这个目标其实很难，需要做的产品太多太多，要完善的功能点太多太多，而资源又太少太少，急需一种高效的方法来支撑产品开发。

幼年时的企鹅虽然遇到了这些问题，但那时候它还不知道有敏捷方法的存在，但好在有几项与生俱来的小聪明，借此支撑了几年的发展，后来证明这几项小聪明其实都有着敏捷的影子，我们管它叫草根敏捷基因。

拥抱变化：从不拒绝变化，只要对用户有价值的，即使推倒重来，也要作出最有价值的功能给用户。

重视反馈：为了能够听到亿万用户的声音，建立许多反馈渠道，例如QQ群、Qbar、客服、意见反馈、内部反馈、用户CE等，借此收集用户对现有功能的意见和新功能的期望，进而指导产品经理的工作。

快速发布：很早就建立完整发布平台，可以非常快地发布到全国各地的服务器上，这使得企鹅具备了产品快速上线，缺陷快速修复的能力，目的也是为用户提供更好的服务。

快速改进：建立很完善的用户数据统计分析平台，用于发现影响用户使用的瓶颈，发现用户操作的习惯、发现对用户最有价值的功能，从而有的放矢进行产品优化，提升用户体验。

敏捷历程

小聪明毕竟也只能支持几年，因为业务发展实在太快，必须系统学习一种有效的方法来来支撑进一步的发展需要，经过多方打听，企鹅重要发现了一项绝技敏捷方法，经过多方学习，开始在内部有条不紊地尝试起来。总体来说敏捷学习分为三重境界，下面我们来共同回忆一下这段学习经历，每个阶段都采用了“点、线、面”相结合的学习方法，我们也将按此思路为大家展现。

中规中矩

刚刚开始学习，企鹅并不急于随意发挥，因为它认为只有真正理解敏捷的精髓，才可以自由运用，因此老老实实、中规中矩地练习起敏捷方法来。

点（标杆小项目+敏捷教练）：我们在公司各个业务线选取了若干具有代表性的项目尝试敏捷。选取过程中主要遵循如下标准：

图1 敏捷实施流程图

团队有需求，有明确的问题

团队愿意接受敏捷教练

重点项目，资源用在刀刃上

教练能力可以帮到团队

团队规模适中（5~12人）

接下来我们的专业敏捷教练会下到团队通过如图1的步骤开展敏捷实施工作。

其中实施过程主要分四个迭代展开，着重在如图2的六个方面进行指导。

图2 敏捷实施指导图

线（提炼模型）：经过近两年的深入实践，结合自身项目特色，我们将企鹅的敏捷提炼出来两种模型。这两种模型成为企鹅实践敏捷的基本套路，从“线”的角度为相似项目提供更具操作性的指导。如图3和图4，精炼地展现了两种模型的特色与实践。

图3 极速模型

图4 迭代模型

面（培训+工具平台+敏捷研发奖）：“点”和“线”分别实现深入和升华，但是如何对更大范围的项目产生影响，必须通过“面”的手段广泛地传播敏捷思想和实践，为此我们也是通过三个方面开展。

首先是培训，我们结合多种敏捷方法、企鹅特色，开发出了多门敏捷相关课程，全方位地为公司员工进行培训，主要有一些系列课程，供大家参考。

表1 腾讯敏捷培训内部课程

其次，敏捷实践的固化与更加高效的运转需要强大的工具进行支撑。为此腾讯组建了一支团队专门开发了适合自身的敏捷产品开发平台Tencent Agile Product Development（TAPD）。它提供了敏捷产品开发全生命周期管理，包括产品管理、项目管理、发布、缺陷报表等。另外TAPD的强大之处还在于它内嵌了多项优秀的敏捷实践，如用户反馈、特性裂解、迭代计划、时间线、故事墙、燃烧图、发布计划等，并为不同业务类型提供多套整合解决方案，如Web应用、无线应用、游戏、桌面应用等。

最后，为了鼓励更多的项目积极尝试敏捷方法，我们通过“卓越敏捷研发奖”来鼓励积极实践并取得明显效果的项目。奖项评选主要从项目管理、迭代能力、CE（Customer Engagement）敏感度、团队经验分享等几个方面来衡量。截至日前，已经有15个团队获奖。

皆为我用

经过四年的苦心研修，可以说已经掌握敏捷方法的“形”，但是“神”还掌握得不够，于是开始新一轮的学习。希望借此让内部项目对敏捷的理解更进一步，达到融会贯通的程度。同样，腾讯也是从“点、线、面”三个方面来进行的。

点（部门级重点大项目+派驻项目经理）：要想融会贯通，必须从关注众多小项目转向关注部门级重大项目。因为这种项目由于规模较大，特别是常常涉及多个子项目协作，前一阶段的一些方法已经不太适用，急需寻求新的方法帮助此类项目提升效益和质量。

但是如何在此类项目中开展敏捷，其实谁都没有底，原先的教练已然不能轻松地指导项目了。为了更加深入了解项目，找到合适的解决方案，并有效推进方法的落地，采用了派驻项目经理的方式与项目团队合作。

通过这一阶段的实践，我们丰富了公司敏捷模型，增加一种“大象模型”，特别适用于部门级的大项目采用，详见图5。

图5 大象模型

线（TAM）：众多团队提出了敏捷指导需求，但是原来单对单的辅导效率太低，必须有一种方式可以让受益面更广，我们花了大约一年半的时间终于找到了一种非常有效的方法Tencent Agile Master（TAM）训练营。

对象：有意愿实施敏捷的团队骨干成员，特别是项目经理，因为项目经理能从全局角度推动团队采用各项敏捷实践。

方式：Training + Action + Coaching + Sharing。Training部分涉及六门课程《敏捷项目管理基础》、《敏捷需求管理》、《敏捷规划》、《敏捷实施跟进》、《敏捷团队建设》、《质量与持续改进》。全过程分为四个迭代进行，前三个迭代每次集中进行两门课程的授课，接着要求学员在各自项目中切实实践，每门课程中设定3～5项实践点，期间有专职的敏捷教练进行指导和答疑，之后再对实践效果进行评估，在下一迭代开始时，请学员分享各自实践心得，并进行深入的探讨。第四迭代将对总体实施效果进行评估，进而对学员实施TAM认证，并请CTO为其颁发证书和奖品。

TAM在广度和深度两条线同时有效加速了敏捷的推广，取得了非常好的效果，值得向大家推荐。

面（敏捷俱乐部）：这一阶段的“面”更侧重于公司内部敏捷经验的交流和传播，因此我们发起了“敏捷俱乐部”这一组织，由专人负责运营，通过“线上+线下”结合的方式实现“敏捷知识管理+分享交流”。

线上活动主要在公司内部知识管理平台KM上展开，通过KM的文章、讨论、活动、问答、资料、季刊等形式，使得敏捷相关知识得以推广和沉淀，截至发稿前，线上敏捷俱乐部已经有500多篇文章。

线下活动主要包括公司内外专家演讲、专题讨论会、Open Party、模拟场景训练等活动，让大家相互认识，交流经验，探究答案。每次活动之后请大家在线上总结收获，使得线上、线下紧密结合，互为促进。

自成一派

腾讯经过两年进一步的研习，敏捷运用已经达到了随心所欲的程度，不过它还不满意，希望进一步发展，于是开始了第三阶段，目前尚在进行中，目标是形成自己的敏捷流派，并将敏捷方法发扬光大。

点（公司级重大项目+大项目经理）：随着公司不断发展，越来越多的公司级项目涌现，必须从公司层面跨业务的开展，这对我们来说又是新的挑战，此时我们还是采用委派大项目经理的方式探索新的敏捷模式，这一工作目前还在进行中。我目前负责的一项涉及全公司的技术改进项目就是一个例子。

线（企鹅敏捷价值观）：基于三大模型，企鹅经历多年积累了产品价值观，我们希望能够将敏捷精神与公司本身精神相融合，形成企鹅特色的敏捷价值观。目前我们已经初步确定七大价值观：无快不破、海量之道、柔性可用、立体监控、灰度发布、产品微创新、体验文化，目前正在整理完善中。

面（开放共赢）：如今互联网迎来了开放大潮，敏捷方法也要开放，具体来说我们打算从内部和外部两个层面进行敏捷开放。内部开放是希望通过跨业务跨部门的轮岗实现内部敏捷方法和经验的实质性流动，并为大家提供更大的发展空间。外部开放是要走出去，将企鹅研修的心得回馈给业内，让所有公司能够共享敏捷实践成果，实现共赢。

结语

本文全局性地为大家展现了腾讯敏捷实践之路，以及未来的发展方向，实践证明敏捷是非常适合互联网开发的方法，但需要一些适应性调整，希望此文展现的一些具体实践能为正在尝试敏捷的公司提供一些借鉴。

作者艾永亮，腾讯公司敏捷教练&高级项目经理，曾参与QQ农牧场、Qzone商城、SOSO、无线应用、网络游戏等业务的项目管理与教练工作。有着多年敏捷实践和咨询经验。可通过腾讯微博（aland_ai）、新浪微博（alandai）与作者交流。

相关话题：敏捷设计和敏捷开发源地址：http://www.programmer.com.cn/8285/

忘记敏捷

baiyuzhong — 2011-09-18 22:42:43

瓦沙奇山下那段著名的敏捷宣言，至今已近十年。似乎在不经意之间，敏捷已经被视为 CMM 之后又一次软件开发领域的浪潮，不论业界报道或者坊间传闻，都不约而同地将敏捷视为一个时代的开始，与之同存的是那些未尝或浅尝敏捷者的各种质疑和争论。

当敏捷在介于自发与非自发中间演变成为一种近乎“革命”的运动，围绕在它身边的躁动就不曾停歇，对于细节的争执，对于方法的固执，让我们更多地为敏捷的未来忧心忡忡。我们担心的是，如果敏捷只被认为是实践和方法集合，那么必然有一天在它某次失效或者迫于压力无法延续的情况下，便会被开发团队自然而然地抛弃，他们要做的也只是耐心等待下一次所谓的“革命”。

这时往往被忽略的是第一个要问的问题——为何敏捷。作为从汽车产业精益制造理念衍生出来的敏捷，到底为何产生？敏捷的萌芽和发展与精益理念的传播过程有何共同之处？敏捷将如何发展？当敏捷风潮过后留下什么？只有当这些问题一一被深刻解答和理解，才能让敏捷实践忘记敏捷，真正的敏捷基因才会被持久留存。

精益启示

在这个充满隐喻的软件世界中，各种软件开发方法的思潮都来自于其他某个成熟行业成功经验的映射。理解敏捷的核心，应该从精益制造的灵魂开始。精益的萌芽发展变化在某种程度上契合并预测着敏捷的今生来世。

敏捷之前工业制造世界的基础都建立在“遵循计划”的模型上——在执行之前，需要完成的是计划，这个被设计的计划中规定了资源分配、详细工序、时间线、技能要求等，被认为如果按照计划严格地执行，便可达到预期的成功。那么，当计划在一个可预期的成功之上被设计时，理所当然遵循计划的结果便是这个可预期的成功。

基于这个模型，在 1908~1927 年的 19 年间，福特制造了T型车的神话——在福特设计的流水线上，生产计划被严格地执行，所有的产出物都达到“可预期的成功”。在这 19 年里，福特认为“无论你需要什么颜色的汽车，福特只有黑色”—— 拒绝任何改变，并坚持把计划中可预期的成功作为经营成功的唯一标准。因为市场需求的单一，以及价格的低廉，计划的成功执行与市场经营成功在某种意义上，画上了等号。

而福特T型车的迅速衰落正是在于，当市场需求最终占据了主动时、当企业生产和销售的天平慢慢倾向于销售一方时，计划中“可预期的成功”瞬间变得次要。原因很简单，企业的价值不以生产计划的完成为基础，取而代之的是销售计划的完成。换句话说，如果最终目标是“在一定时间线上用合理的成本生产出产品”，作为企业来说，这样的目标不足以成为企业价值的衡量基准，而真正体现企业价值的是“在一定时间内用合理的成本生产出产品，并让这些产品成功地被用户使用”。

当成功地让用户使用产品变得越来越有风险（用户的需求越来越趋于多样性和变化），使得传统制造工业的从业者无以适从——完成预测的生产计划可以通过内部的管理手段实现，但当生产计划无法完美契合用户需要时，传统生产方式的低效和浪费便暴露无遗。也许关张的不一定都是那些没有在“在一定时间内用合理的成本生产出产品”的企业，但那些没有“让这些产品成功地被用户使用”的企业一定关张。

这样的危机感使得更拥抱变化的精益制造理论得到了迅速发展——如果那些没有被用户使用的产品就是不产生价值的东西，那么更应该关注的不是生产计划的完成，而是生产线那头的东西是不是可以被市场买单。

精益的产生和发展完全契合着汽车消费市场的变革——越来越趋向于关注用户多变和多元的需求。换句话说，一个消费需求变化风险越大的消费市场，必然产生一种对“降低消费需求变化风险”越依赖的生产模式，这个生产模式就是精益。

敏捷非革命

相对汽车行业近 135 年的历史，软件产业仅仅经历了不到 50 年的时间。在软件产业初端将近一半的时间里，就像福特T型车流行的 20 世纪 20 年代，软件并没有足够庞大且多元化的消费市场，世界对于软件的应用多限于工业控制、数据分析、科学研究等领域，以及那些服务于并没有形成足够成熟消费市场的配套软件。“遵循计划”的瀑布式生产模式在很长一段时间里成为软件工程的准则——“在规定的时间和规定的资金投入内，完成规定软件规格的应用”。

接下来，随着个人电脑以及各种消费类电子和通信产品的普及，人类对于信息的需求上升到前所未有的高度。软件终究是连接使用者和信息的接口，当对于信息的需求不仅限于大型制造商、军方、科研人员，而突然趋向于成为普通消费者日常生活的必需品，对软件的需求必然呈现级数增长。于是，软件行业在过去 20 年里的发展趋势是“让更多的人享受到信息服务”，而曾经的高端专业软件市场正在慢慢被信息消费类软件所挤压。

可以这样理解，当一个市场的消费门槛越来越低时，这个市场越有可能变成买方市场，这个市场的消费者层次就越来越丰富，这个市场可能出现的需求变化就越来越频繁，预测这个市场需求变化的难度就越来越高。

这便可以解释为什么越来越多的软件从业者，开始体会到如同汽车普及化运动对汽车行业的影响类似的困惑——单单“在规定的时间和规定的资金投入内，完成规定软件规格的应用”已经不够，必须在后面加上一个“并让这些产品成功地被用户使用”。这种市场需求带来的内部驱动使得人们开始思考一种更加适应市场需求变化的生产模式，像大野耐一的天才创新一样，软件行业也开始像汽车行业一样开始向追逐最终消费者使用价值的方向发展，敏捷方法的诞生正是基于此。

一个行业的成熟，必然经历一个消费市场剧烈分化膨胀的阶段——随着工艺和技术的提高，以及生产成本的降低带来了消费门槛的降低和更多多元化需求，这必然使得涉足其中企业的核心竞争力完成从“按时按量按质生产”到“按时按量按质适应市场生产”的转变。在这个转变的背景之下，必然出现一种生产模式的转变，保证“按时按量按质生产”之外还能保证“这些产品成功地被用户使用”。

汽车消费市场变革发生在汽车行业发展 75 年后的 20 世纪中叶，丰田的精益制造模式成为适应汽车消费市场剧烈变革的主角——快速推向市场，迅速对市场变化作出调整，丰富汽车品种满足多元化需要的丰田在一段时间内成为汽车行业发展的标杆。

同样，在软件行业的发展经历 50 年之后，也开始迎来一次软件消费市场疯狂膨胀剧烈变化的阶段，这个行业的参与者，不得不到殚精竭虑于生产的产品是否能够真正适应市场的需求，把成功交付的标准改变成“在规定的时间和规定的资金投入内，完成规定软件规格的应用，并让这些产品成功地被用户使用”。

而传统的软件开发方法已经无法支持对快速变化的市场变化作出快速反应，换言之，传统的“计划+执行”的模式在当前的市场特质中行不通，在这样存在“巨大需求变化风险”的市场中，不可避免地需要一种能够降低这个风险的生产模式，这个生产模式，就是快速响应变化的敏捷开发方法（见图1）。

图1 汽车消费市场的变革产生了精益制造；软件消费市场的变革产生了敏捷开发

从这个意义上来说，敏捷本身并不是“革命”，真正发生巨大变革的是市场，敏捷只是被市场选中。实践敏捷是软件消费市场变革的结果，驱动敏捷背后的力量是市场。如果敏捷是市场变革背景一次必然的风潮，那么在风潮过后，如果这个市场依然充满变化且专注每一位消费者的价值，那么能够被市场所留存的必是这个充满变革的市场在一开始最需要的东西。

风潮过后

对敏捷的经典误读之一：从“敏捷”的字面出发，认为敏捷是一种快速和高效的开发方式，通过各种实践达到交付能力提升，使交付速度变快。事实上，“敏捷”真正的含义里，“灵活”远大于“高速”，或者说敏捷绝不是提升效率的方法，敏捷是降低变化风险的艺术，即是“拥抱变化”的艺术。换言之，敏捷的精髓在于“拥抱变化”，而正因为这个特质，才使得敏捷越来越被这个越来越充满变化风险的软件消费市场所需要。那么，应该如何理解敏捷的精髓？

灵活应对变化风险的实质在于当需求发生变化时，应对变化的成本最小，而这个成本的组成包括舍弃在这个需求上的已投成本、修改其他关联需求的修改成本和额外投入的新成本。我们不难看出，额外投入的新成本基本由需求本身决定，为固定成本，而舍弃的已投成本和关联的修改成本是可以通过某些手段降低的可变成本。这便是敏捷“拥抱变化”的两个核心之所在（见图2）。

图2 拥抱变化的实质

1. 在需求发生变化前，不在或者尽可能少地在这些发生变化的需求上投入任何工作量；

2. 当需要发生变化时，不在或者尽可能少地在可能影响的其他功能上产生任何工作量；

而敏捷几乎所有实践活动的实质都围绕在这两个核心上。让我们从敏捷中几个经典实践出发看它们是如何体现这两个核心的，它们是：用户故事、迭代交付、重构和持续集成。

1. 用户故事：将客户的需求拆分成不同的用户故事，每一个用户故事代表一个独立的业务价值，对于未来不确定的潜在特性（变化风险最大），用用户故事的方式占位（Placeholder），当需求发生变化时，尽量只影响其中的一个用户故事（最好的情况是之前预估过风险还未进入开发），而不影响其他用户故事的业务价值；

2. 迭代交付：将需求放在不同迭代进行交付，每个迭代都给予客户对下个迭代需求进行变化的机会，当需求变化真正产生变化时，还没有实质的开发工作量产生；

3. 重构：鼓励持续地对系统架构进行优化和重构，降低系统的耦合程度，让一个需求的变化不会或尽可能少的对现有的其他功能产生额外的工作量；

4. 持续集成：大量使用自动化测试和构建持续基础环境，让可能产生于每次提交的缺陷（对现有功能的影响）及时暴露，越早发现，越减少可能产生在被影响的其他功能上返工工作量。

市场的变革是敏捷方法风潮背后的推手，如果市场真正需要的是一种适应消费需求充满变化的生产模式，那么很有可能，敏捷作为一种方法论，有天也会被某种更新的理念替代。但是能够肯定的是，软件消费市场将会在更长的时间内趋向于满足日益多元化的消费群体充满变化的需求，因为敏捷“拥抱变化”的基因，这场市场的变革选择了敏捷，如同汽车消费市场选择了精益，那么当风潮有天退去时，“拥抱变化”的基因必然被留存，无论冠以敏捷之名或是其他。

同时应该指出的是，软件消费市场仍然存有部分消费需求变动较小的市场，包括稳定的工业自动控制、数据分析和科研研究等领域。在这一市场里，对于市场变化的风险控制成本较小，以敏捷所包含的“拥抱变化”的基因，并没有足够优势完全替代传统“计划+执行”的开发方式。因此，在可预见的未来，敏捷或任何一种可能出现的“拥抱变化”的开发方法会在一定时期内与传统开发方法共存。

不可否认，敏捷正在风行，绝大部分敏捷实践者的关注点自然都在敏捷本身，而我们往往陷于的误区是——因为它是敏捷的东西，所以我们要实践。那么，当敏捷风潮退去或者对敏捷的效果产生疑问，我们的反应往往会变成——敏捷已经不流行或者敏捷已经证明不适合我们，那么我们没有理由继续实践敏捷的东西。如果仅仅把敏捷当成一种风潮之下的流行物，最有可能发生的事情在于，现在如火如荼实践的敏捷方法的任何一种，都有可能突然在某天被团队所抛弃而不能延续。

图3 实践敏捷的根本不在于敏捷本身，而在于理解敏捷背后拥抱变化的基因

当我们深刻理解敏捷背后，“拥抱变化”被这个充满变化的市场所需要的基因，明白我们做的每一件事都是让我们在面对变化时从容不迫，让我们制造的产品能够满足更多消费者的需求，创造更加多元化的需求。而不是因为，某个深不可测的大师或是高屋建瓴的咨询师不遗余力地鼓吹敏捷的神奇。只有这样，我们的实践才能够真正为我们的交付产生实效性的价值，并能在更长的时间内坚持，哪怕有天没有人谈起敏捷，那个藏在敏捷最里面的基因一直可以留存。实践敏捷，请忘记敏捷（见图3）

相关话题：敏捷设计和敏捷开发源地址：http://www.programmer.com.cn/8240/

中国敏捷实践中的误区（三）误区和改进

baiyuzhong — 2011-09-18 23:28:26

三个主要误区

第一个是重视流程忽视人。敏捷宣言开明宗义指出“人和沟通胜过过程与工具”。但是仍然有很多企业试图通过创造一个完美的流程来实施敏捷。不可否认，合理的流程对于提高团队效率有一定的作用，但是企业真正要从敏捷改进中获益必须落实到人的改变上来。

第二个是重视管理轻视工程。很多团队将敏捷等同于开开站会、做做迭代、搞搞回顾。到头来，一切流于形式。敏捷说到底是对于软件工艺性的认识回归，那么持续集成、自动化测试、设计、重构这些手艺是绕不开的。不从这些根本的手艺上解决问题，各种眼花缭乱的沟通手段实际上徒然增加了团队的成本。
第三个是重视指标轻视过程。很多团队特别是从CMM型组织转向敏捷的团队，热衷于设计所谓的敏捷度量体系。度量应该是帮助团队增强信心和持续改进，指标不应成为目的。我们要关心的不只是站在哪里，更应关心我们将走向哪里。

要解决这些问题没有任何灵丹妙药，从来也不存在一个完美的、放诸四海而皆准的流程。我们在帮助各种企业进行敏捷流程改进的过程中，总结了几种改进模式，这里跟大家分享一下。

五种改进模式

跳跃：团队作为整体从一种实践直接切换到另一个实践方式上。

有些实践我们知道其目标，并且知道这种切换对团队的影响较小，或者不适于采用逐步推行的方案，我们就采用跳跃的方式。

例如，配置管理工具切换。某团队原来使用的配置管理工具是ClearCase，为了享受到SVN的原子提交、低成本分支等好处，我们往往采取跳跃的方式，即整个团队立刻从ClearCase切换到SVN上工作。这是因为配置管理的切换总的来说对于团队的工作方式影响比较可控，而且使用简单。

并行：团队中部分组织或个人使用原有实践，而另一部分切换到另一个实践方式。

有些实践知道其目标，但在整个团队推行可能会对工作方式造成较大影响，或者团队中的某些组织或个人不具备切换到新的实践方式上的条件，我们就采用并行的方式。

例如，项目组持续集成。团队中某个项目组具备较好的持续集成基础，另一些项目组基础较差。如果在整个团队推行持续集成，就可能对团队产生较大的冲击。而且持续集成的具体方案可能需要在一个项目组内试验。这时候，先在一个项目组做起来，然后推广到其他的项目组。
阶石：为了达到一个长远的目标，先实现一个较近的目标。

有些实践有长远的目标，但还看不清达成目标需要的路径，如果知道做某件事情一定有助于达成目标，可以先完成这件事情。例如，单元测试。有时候希望在某些团队中实施单元测试，但缺少合适的测试框架，那么在确定测试框架之前，实际上很难展开后面的工作。这时就可以先全力构建这个测试框架。称这种方式为阶石。

简化：为了达到一个长远的目标，先实现一个较为容易实现的目标，但是这个目标仍然能够给我们带来好处。

有些实践我们有一个长远的目标，但是对于这个长远的目标还不太清楚，或者要达成这个长远目标，要走的路还很长。如果有些做法可以给我们带来一些好处，虽然不如长期目标带来的好处那么大，我们仍然可以先做起来。

系统测试和低成本测试的拉通。系统测试和低成本测试拉通是个长期而艰巨的任务，比如可能需要良好的基础设施的配合。但是我们可以做一些简单的事情来获得相似的好处。

暂停：暂不实施某个实践。

有些实践，团队不具备实施条件，或者对团队的冲击较大，可选择暂不实施。例如TDD。实施TDD需要较高的条件。如果团队不具备这样的条件，贸然推行难度非常大，这个时候常常选择暂停。

上面的5个模式所在维度并不相同。比如，并行是从组织的维度考虑的，而阶石和简化是从目标维度考虑。另外，在不同范围内看，同样的实践也可能属于不同的模式，需注意模式的目的是为帮助参与者清晰把握问题本质，认识解决方案在时间和范围上的局限性。所以把实践与模式绑定的做法也不提倡。

相关话题：敏捷设计和敏捷开发源地址：http://www.programmer.com.cn/8098/

敏捷测试的方法和实践

朱少民 — 2011-09-18 23:37:04

文 / 朱少民

有一次，当开发人员完成当前Sprint 任务的代码之后，测试人员、开发人员和产品经理一起来浏览产品、从头到尾走一遍，产品经理发现了问题，认为需要对功能进行比较大的修改。这时开发人员估计需要两天时间才能完成代码，但测试人员反对这样做，我们本来只有5天测试时间，加上这次新做的功能比较多、开发代码质量不高，验收测试已经很紧张。如果再延迟两天，测试没法完成。产品经理说，你们不是在用敏捷测试方法，应该测得很快，三天应该能完成测试工作啊！

什么是敏捷测试呢？敏捷测试当然不能简单地理解为测得更快，绝对不是比以前用更少时间进行测试，也不是将测试的范围缩小了或将质量降低来减少测试任务。也有人说，只有敏捷开发，没有敏捷测试。下面我们将要讨论一下：

究竟什么是敏捷测试？
敏捷测试有哪些流程改进？
测试人员如何面对敏捷测试的挑战？
在敏捷测试中如何制定相应的自动化测试策略？

什么是敏捷测试

假如将过去传统的测试流程和方法硬塞入敏捷开发流程中，测试工作可能会事倍功半，测试人员可能会天天加班，而不能发挥应有的作用。敏捷测试应该是适应敏捷方法而采用的新的测试流程、方法和实践，对传统的测试流程有所剪裁，有不同的侧重，例如减少测试计划、测试用例设计等工作的比重，增加与产品设计人员、开发人员的交流和协作。在敏捷测试流程中，参与单元测试，关注持续迭代的新功能，针对这些新功能进行足够的验收测试，而对原有功能的回归测试则依赖于自动化测试。由于敏捷方法中迭代周期短，测试人员尽早开始测试，包括及时对需求、开发设计的评审，更重要的是能够及时、持续的对软件产品质量进行反馈。简单地说，敏捷测试就是持续地对软件质量问题进行及时地反馈，如图1所示。

图1 敏捷测试定义的形象描述

敏捷测试流程的优化

在敏捷方法中，需求变化比较快、产品开发周期很短，我们目前采用四周时间，也就是每个月发布一个新版本。开发周期短，功能不断累加，给软件测试带来很大的挑战，软件测试流程要做相应的调整。例如，我们原有的测试规范明确规定，首先要建立项目的主测试计划书，然后再建立每个功能任务的测试计划书，测试计划书有严格的模板，而且需要和产品经理、开发人员讨论，并和测试团队其他人员（包括测试经理）讨论，最终得到大家的认可和签字才能通过，仅测试计划经过“起草、评审和签发”一个完整的周期就需要一个月。在敏捷方法中，不再要求写几十页的测试计划书，而是在每个迭代周期，写出一页纸的测试计划，将测试要点（包括策略、特定方法、重点范围等）列出来就可以了。

在原有测试规范中，要求先用Excel写出测试用例，然后进行讨论、评审，评审通过以后再导入测试用例库（在线管理系统）中。在敏捷测试中，可能不需要测试用例，而是针对Use Case或User Story直接进行验证，并进行探索性测试。而节约出来的时间，用于开发原有功能的自动化测试脚本，为回归测试服务。自动化测试脚本将代替测试用例，成为软件组织的财富。原有测试规范还要求进行两轮回归测试，在敏捷测试中，只能进行一轮回归测试。综合这些考虑，敏捷测试的流程简单有效，如图2所示。

图2 敏捷测试流程简要图

在敏捷测试流程中，如前所述，测试是一个持续的质量反馈过程，测试中发现的问题要及时反馈给产品经理和开发人员，而且某些关键方面也要得到我们足够的关注，主要有：

测试人员不仅要全程参与需求、产品功能设计等讨论，而且要面对面地、充分地讨论（包括带语言、视频的即时通讯），仅仅通过邮件是不够的。
参与代码复审（Code Review），并适当辅助开发人员进行单元测试。
在流程中增加一个环节“产品走查（Product Walk-through）”——测试人员和产品经理、开发人员等在一起，从头到尾将新功能看一遍，可直观、快速地发现问题。

新功能的测试和回归测试策略

测试任务简单地可分为新功能测试和回归测试。在敏捷方法中，针对这两部分的测试建立相应的策略，以提高测试的效率，最大限度地降低质量风险。新功能测试的策略主要有：

不需要测试用例，直接基于用例和对需求的理解来完成新功能的验证。即使要写测试用例，只要保证各个功能点被覆盖，不要过于详细（大颗粒度）。
持续地进行验证，一旦某块新代码完成（Code Drop），就开始验证，而不是等到所有代码完成后才开始测试。这也包括参与到单元测试和集成测试中。
实施端到端（End-to-End）的测试，确保完整的业务流程的实现，同时，也容易发现业务逻辑不够清晰、不够合理等各方面的问题。
阅读代码来发现问题，可以和开发人员工作保持同步，消除测试周期的压力。
基于经验，可以实施更多的探索性测试、组合交互性（Interoperation）测试和用户场景(User Scenario)测试，更有效地发现埋藏较深的缺陷。

回归测试是敏捷测试中需要面对的难点。每次迭代都会增加新的功能，一个产品可能会经过十几次、甚至几十次迭代，回归测试范围在不断增大，而每次迭代周期没变，可能还是一个月。这样验收测试的时间非常有限，所以回归测试很大程度上依赖于自动化测试，因为很难将回归测试控制在非常有限的范围内。当然，还是有些办法可以帮助我们减少回归测试的范围，例如：

通过执行Code Diff 来了解代码变动的所有地方，再做代码关联分析，就可以明确知道要进行哪些地方的回归测试，回归测试范围会大大缩小。
基于风险和操作面分析来减少回归测试的范围，例如回归测试只是保证主要功能点没有问题，而忽视一些细节的问题。
持续测试的过程，只要有时间，就进行测试，包括开发人员、产品设计人员都参与到日常的试用和测试中来。

自动化测试策略

由于开发周期短，需求、设计等方面沟通也需要花费很多时间，没有足够时间开发自动化测试脚本，至少对新功能的测试很难实现自动化测试。这时候，就需要正确的策略来提高自动化测试的效益，如图3所示，并说明如下。

图3 自动化测试的策略

构建一个灵活的、开放的自动化测试框架，如基于关键字驱动的自动化框架，使测试脚本的开发简单易行，脚本维护也方便。
针对稳定的产品特性开发自动化测试脚本，也就是针对前期完成的已有功能开发自动化测试的脚本，而大部分新功能测试采用手工测试
集中精力在单元层次上实现自动化测试，主要由开发人员实施，测试人员提供单元测试框架，并辅助完成一些所需的基础工作。
在产品设计、编程时就很好地考虑了自动化测试的需求，使全面的、自动化的底层测试、接口测试成为可能，尽量避免用户界面（UI）的自动化测试。
良好的IT基础设施，包括自动化构建软件包、自动化版本验证（BVT）、自动化部署、覆盖率自动产生等。

敏捷测试工具

自动化测试依赖于测试工具，所幸的是，目前已有很多敏捷测试工具。由于篇幅所限，这里只是简单地列出一些常用的敏捷测试工具，不再深入讨论了。

单元测试工具：TestNG、xUnit家族（如JUnit、NUnit）、JMock、BizMock等。
功能测试自动化：ThoughtWorks Twist。
Web功能测试（frontend）：Selenium IDE/RC、WatiR、WatiN。
Web service测试工具（backend）：soapUI。
性能测试：JMeter+BadBoy。
验收测试框架：Fitnesse、Tellurium。
敏捷测试过程管理工具：微软的Visual Studio 2010，包括TFS 2010、Scrum模板（MS VS Scrum 1.0）、Test Manager 2010、Coded UI Test等。
业务智能（BI）应用的测试框架：Oraylis BI.Quality （+ NUnit）。
其他一些协作工具等，如TestLink、BugZilla、BugFree、Wiki等。

测试人员在敏捷方法中的价值

在敏捷方法中，开发人员的主导作用更明显，系统设计、编程实现、单元测试、重构等看似关键的一些任务都落在开发人员身上，测试人员容易被边缘化。那么，在敏捷方法中，测试人员的价值又如何体现呢？

在需求和功能设计讨论上，测试人员可以站在客户角度来阐述自己的观点，扮演“用户代表”角色，强调用户体验，真正体现测试人员和开发人员的互补作用。
测试人员不仅扮演“用户代表”角色，而且通过需求讨论、代码复审等各种活动及时地提供质量反馈，包括代码质量、接口一致性等，保证在产品构造的整个过程中质量受到足够的关注，以提高质量改进的持续性和可视性。
测试人员应积极参与单元测试，即使不参加单元测试，也应督促开发人员进行单元测试，确保单元测试达到80% 以上覆盖率，确保开发出具有良好可测试性的代码。
在敏捷方法中，往往将一个大的系统开发分解成多个小的子系统（模块或组件），集成测试和端到端（End-to-End）测试显得更为重要，测试人员在这些测试上能发挥更大的作用。
产品发布前，验收测试和回归测试依然不可缺少，这更是测试人员的用武之地。
一个迭代周期结束后，对缺陷根本原因进行分析、总结规律，帮助开发人员建立良好的习惯，预防缺陷，从根本上提高产品质量。

理想情况下，测试人员掌握设计模式、具有很好的编程能力，可以和开发人员进行角色互换，如在当前版本开发中担任测试人员角色，在下一个版本开发中则担任开发人员角色。这样双方对不同角色的工作有着更深刻的认识，消除沟通的障碍，开发的效率和质量会有进一步的提高。

总结

根据上面的讨论和我们的实践，最后针对敏捷测试进行一个简单的总结，就是：

敏捷测试就是持续测试、持续反馈，扮演“用户代表”角色，确保产品满足客户的需求。
敏捷功能测试 = 新特性的手工测试（Use Case验证和探索性测试） + 原有功能的自动化测试（回归测试）。
敏捷测试人员和开发人员的区别越来越小，理想情况下，敏捷方法中，测试人员和开发人员在不同的迭代周期可以互换。
敏捷测试流程依据不同的团队特点、不同产品的特点而不同，因地制宜，适合才是最好。

相关话题：敏捷设计和敏捷开发源地址：http://www.programmer.com.cn/8065/

我眼中的敏捷设计

Dicky Shu — 2011-09-20 21:59:37

2001年，许多公司的软件团队陷入不断增长的流程困境，为了解决这个问题，这个领域中最优秀的experts一起概括出了一些全新的价值观和原则，从而可以让软件开发团队具有快速工作、响应变化能力，他们自称为敏捷联盟。敏捷开发过程的方法很多，包括Scrum, eXtreme Programming, Feature Driven Development, Adaptive Software Development等等。目前，我所在的公司内部也有很多团队开始启用Scrum的开发流程，力图改变瀑布式开发模型的诸多弊端。作为Run了3年该流程的team，我们团队在不断学习和总结中得到了进步，我也希望可以从设计的角度来分享一些敏捷开发流程中快速迭代设计的心得。

Process 流程

这是一个高速变化的时代，无论是产品的更新还是技术的进化，同时变幻莫测的需求对传统软件开发模式造成了极大的冲击。当用户需求不断变化造成软件开发目标的不断更换，传统的设计方式会举步维艰，从而造成了软件的滞后，总是无法贴近用户的实时需求。快速迭代设计的特点是：先设计出稿，再不断改进。白鸦在 2011中国交互设计体验日上分享到：“怎么做都是错的。唯有迭代的速度，才能取胜。” 可见，快速迭代的要求，无论是对研发还是设计，都已迫在眉睫。

整个快速迭代设计流程分为5个阶段：

* Iteration-1

前期准备阶段，团队很容易就各类需求该放哪些进入Sprint backlog发生讨论，设计师主要参与PO(Product Owner)/PM组织的用户需求讨论，对需求优先级排序，解读一些用户潜在需求并转化成为产品功能需求，毕竟相比他们，设计师更加懂得产品细节。同时，设计师可以同步展开用户研究的工作，了解Persona的主要工作流和Goal。

* Iteration 0

与每个项目开始之前设定Sprint 0相同，Sprint里也有一个叫Iteration 0的阶段，包括设计开工之前的验证与出具设计方案。通过与开发团队的沟通来验证设计方向与设计方案的可行性，可以创建一些信息流图与内容结构，做好坚实的设计架构。同时，在用户需求被解读成为功能列表后，利用纸片、PPT、Balsamiq等工具创建快速原型，最好在这个阶段让研发团队介入，对设计原型进行评估。然后设计师根据快速原型，负责设计其实现方式，通常会有几个解决方案。在Scrum团队内部与开发测试人员反复讨论权衡后，选出最优方案。这个阶段设计师的交付物为交互线框图、低保真模型等简单设计文档。

* Iterations

设计不断迭代的阶段，因为我们假设改阶段用户需求已经确定，所以主要是基于设计方案的迭代，协同开发实现的进度，将设计不断修正至最优。正是这种快速的模式让设计师能在一个可以体验的原型上验证设计，从而改进设计。与流行的测试驱动开发（TDD）类似，我们也可以采用测试驱动设计（Test Driven Design,详见http://www.agiledata.org/essays/tdd.html）的方式。QA要对用户的背景和工作模式比较熟悉，协同设计师一起敲定User Story，撰写Real User Test Scenarios，并根据测试结果优化设计。设计师与开发团队成员一并进行Usability Testing，以便在早期消除可用性缺陷，减轻后期维护成本。

* Release

作为design release的阶段，前面的工作主要内容是确定功能的主要逻辑与工作流，这个时期，我们可以在优使性（Usability）上有所提升，做好Final Usability Testing，确认没太大疏漏，再将其发布出去。不同于QA的最终验收测试，这里的可用性测试需要从用户的角度去“使用”产品，不是去找功能的缺陷，而是从优使性方面看是否顺手，是否符合用户心智模型，是否高效完成用户目标。

* Production

设计发布过后，为了适应不断更新和快速迭代的需要，设计师在这个时期的工作重心从偏用研设计转移到偏运营维护的方面来，一方面收集一些用户反馈和wishlist，改进之前的不足；另外一方面为了产品的下一个迭代更新做好规划，方便产品的发展和扩充。

整个流程有两个迭代循环：
1.Requirements Iteration
这个迭代循环贯穿于整个敏捷设计流程。用户需求随着时间推移不断更新，整个设计流程的迭代。根据以用户为中心的设计思想，当用户的需求发生变化时，在设计流程中要及时响应，做出调整变化。
2.Solution Iteration
这个迭代循环主要指Iterations阶段，用户需求相对确定，设计方案的不断优化更新。当需求基本确定后，设计师需要配合开发团队不断优化设计思路，提供更优的设计解决方案。

特别需要注意的是，前面两个阶段（Iteration -1, Iteration 0），应该早于当前研发的Sprint N一个周期（Sprint N-1）进行。进入当前的Sprint工作周期，完成第一个迭代设计后，研发团队可以开始该部分内容的开发测试，与设计师不断互动推动迭代。在Sprint N的末期，设计师完成当前Sprint的基本设计工作后，开始收集前面Sprints release内容的反馈。团队不需要提前太多进行设计，要保持需求的最新update，主要依赖测试结果作为支撑，不断持续改进优化设计，以便每次迭代结束后产出物都最适合当前迭代的需求。

Rules 原则

快速迭代设计的一些原则：

* 验证可行性的必要

完美的敏捷思想是团队中的每个人都是全才，大家都可以design，coding，testing。不过这样的团队不多，全才的混合有时候更容易造成管理混乱，相反，专才的合理搭配能产生更好的效果。所以，如果你不会写代码，一定要在设计早期拉上开发人员，坐在一起慢慢探讨设计可行性，用代码验证原型之后，再确定方案。

* 测试用例验证设计的重要性

根据测试驱动设计的理念，设计师与QA协同合作，利用早期测试结果驱动设计更新，比设计师长期独自酝酿出的详细设计文档更有用。行不行，利用草图或者低保真原型让QA去测测看就知道。Scrum鼓励充分沟通与互动，这个时候QA的测试用例能发现很多设计缺陷和遗漏。TDD如下图所示：

* 注重团队设计

与瀑布模型的单打独斗不同，快速迭代设计更推崇团队设计，由设计师主导，把握设计框架，整个团队给出解决方案。一些design scenario和workflow的归纳，即使经验丰富的设计师，也不如团队智慧来的全面，当然，除非你是乔帮主，使用导演中心论的设计流程。另外，团队设计的好处还可以减轻设计师的负担与压力，一起承担产品兴亡的重任比一个人承担要安全可靠的多。

* 设计不多不少，恰好就行

兵贵神速，指的就是以快为王。特别是在快速迭代设计中，你不必在你的原型或草图中事无巨细的列出所有可能，完美的概念在这里是不适用的，甚至你不需要完成设计的整个部分，只要把关键模块讲清楚了，开发与测试理解了，就足够。想想那些精美的设计文档中无数看上去perfect的图片和排版，最后真的有人在乎吗？只要你在迭代开发流程中能于脑海中攫取所有细节并传递给团队，不要文档都可以。无需太具体，思考那些真正有价值的地方。

* 写好User Story

User Story是在Agile开发流程中从用户角度对系统的某个功能模块进行的简短描述，它包含了目标用户(不同角色)、功能需要（可以做什么）以及其创造的价值（实现目的）。它可以是：
1.一个用户需求
2.产品功能的描述
3.用来计划和追踪任务的工具
4.团队沟通的桥梁
通常我们把一个User Story按照以下格式写在即时贴上：

以第一个句型为例：
As a _ I would like _ so that _
作为（某个角色)，我希望可以（做什么），以达到（什么目的）
User Story照理应该是由PO写，不过有些团队（比如我们:D）是由设计师来完成，同时在即时贴上标注预估完成时间（我们团队采用了Story Point这样一种估算方法，这里不赘述）和优先级别，以便开发团队根据它们来形成Sprint Backlog。

* 任务量

不同的功能模块其工作量也不尽相同，我们可以按以下三种类型划分:
1. Large
一般来说每个User Story都需要在一个Sprint内完成，避免太大而跨越几个Sprint。如果出现太大的User Story导致一个Sprint塞不下，则需要将User Story分解，这个Sprint完成一部分，但是不release，只是demo给PO/PM，余下的在接下来的Sprint里完成。
2. Normal
按正常流程进行快速迭代设计。
3. Mini
JDI (Just Do It), 一些小功能的实现无需文档，任何沟通方式都可以用来传达你的设计思路，然后交由开发去实现。

* 关于文档

原本瀑布开发模式下设计师的唯一交付物Specification，在快速迭代设计中已经不是那么重要，因为快速变化的用户需求让设计节奏加速，不断更新维护Specification成本太高。用户是为你设计出的产品或者功能付款，而不是你的设计文档，所以传递设计思想才是主要目的，PPT、Visio等Wireframe或者email、meeting notes等记录都可以作为设计参照。
对于文档，我们一般遵循如下原则：
-尽可能在文档中简单的描述需求、分析结果、信息架构和设计细节，只要它们恰好满足PO的要求即可。
-如果该Scenario的逻辑足够复杂，那么请毫不犹豫的用文档详细的描述，以开发团队恰好能充分理解为宜。
-文档的简繁程度需要经过几个Sprint的迭代，才能找到最合适的level。

* 保持一直设计

设计对产品来说如此重要，特别是在敏捷开发流程中，没有一个专门的设计阶段(There is no design phase)，整个流程都伴随的设计。从前期纸片概念，白板框架，用户场景测试，到具体细节代码实现，终极用户测试，都离不开设计的跟随。这不再是那个只需要在早期完成设计就弃之不管的模式，他要求你每天都不停的参加讨论参入迭代参与设计。

Epilogue 后记

我们团队面对的是一款由公司早期元老打造的工程领域软件，它的用户基数庞大，它的地位曾经显赫。然而它的功能逐渐老化，模块架构也相对固化，开发团队很难对整个系统进行改动，因为整个软件架构已经固定，任何大的改动都是牵一发而动全身，不但会造成许多与改动处无关的环节出现问题，莫名其妙的regression defect也让QA措手不及。一些设计改进都必须得在之前设计的基础上进行调整，力求一致性，很难加入全新的交互模式和UI风格。同时，正是由于产品功能没有大幅度的更新，瀑布模式比较擅长的低风险复杂功能开发已经无法满足用户需求的小快灵。因此，我们目前所使用的敏捷设计流程尽管无法跟全新开发的产品一样自由，只是在大框架的制约下进行功能的迭代更新，但也取得了不错的效果，3年做下来完成了许多小功能的快速成功发布，提升了大家对于Scrum流程继续使用的信心，致力于建立一个持续的可改进的快速响应团队。本文所提及的流程并不适用所有情况，希望大家各取所需，保留对自己有价值的部分，摒弃不适合的。

参考：

http://www.agilemodeling.com/

http://blog.rexsong.com/?p=2365

设计师谈敏捷

fifisama — 2010-08-31 23:15:43

腾讯一直推广敏捷开发，也在强调敏捷开发，但你会发现，即便如此，还是会陷入以下情景

又臭又长的讨论会
好像人手永远不够
不切实际的想法
悬而不决的功能点
无穷尽的偏好设置
越来越多纠缠不清的细节
项目依然延期

我们如何构建一个更轻巧的开发流程，让我们更快更好的交付结果？作为一个设计师，如何成为敏捷的一分子？以下是一些心得方法，希望和大家分享

1 界面先行

作为设计师，最简单能让大家明白你的想法就是先把它画出来，不要用晦涩的语言和结构图，毕竟不是所有人都能把你的语言转化为图像。而且界面（视觉，交互）设计是相对轻量级的，修改起来也简单，成本也低。但修改程序就远不是那么回事了。保持界面先行可以让你非常灵活，至少在开始开发之前可以随意修改。

界面先行另一个最重要的原因就是，对于用户来讲，界面就是你的产品，界面可以帮助你从用户角度看待自己的产品，如何展现，如何操作，给人感觉怎么样，是不是易用。只有当你面对真正界面的时候才能回答这些问题，文档概要并不能帮你解决实际用户体验问题。

2 初期不需要太关注细节

虽然大家总说，成功来源于细节，当然，这非常对。但前期过分关注细节的同时也会令你止步不前。先把大框架确定下来，而不是一直纠结于

这条提示怎么写更合适？
文字字号用16还是14？
要不再往左挪1像素？
这里加个高光把
把2像素的描边变成1像素

你需要关注细节，但不是现在。所有事情都要从大到小的去做。先把他做出来，把该放的东西放上去，然后实际去用一下。

细节是你在使用的过程中才会慢慢显露出来，只有在使用中你才会发现哪些更值得关注。如果你有足够的时间，当然可以面面俱到，如果没有，请先把精力放在最重要的事情上。

3 不要纠结那些还没有成为问题的问题

“当我们的用户用了这个功能以后还想跟另一个功能配合使用怎么办？”

如果想快速推出版本，就先解决当下。不要花太多时间去考虑还没有成为麻烦的问题。别担心，你还有后续版本。

而且你就真那么确定用户想跟另一个功能配合使用么？如果不是，就先放一边，等问题真正浮出水面的时候再去快速解决。

4 帮助产品经理精简功能

好像大家都在弩着一股劲，比谁做的多。竞争对手的产品如果做了**，我们就要做***，他们有4个功能，我们就要做5个。如果不做，拿什么跟他们竞争？

这种方式是行不通的，因为你会发现，永远是赶超，永远没有自己领跑的那一天。怎么办？

做少

通过做少来打败他们

做的功能越多，功能间的交互就会越复杂，用户的学习成本就会越高。而我们的用户真的用的上那些高深的功能么？他们会不会已经被那些多如牛毛，但我们自以为高明的设置搞得疲惫不堪？试着少做一点，让自己的产品更加轻巧而更具备亲和力——没有人会喜欢使用显得自己很笨的软件。

5 功能间更少的牵扯

把一个功能点做的尽量独立，能保证需求改变时更为快速，更为灵活。

如果功能间的牵扯太多，就如同你身上沾满了蜘蛛丝，每做一点改变，其他的都要进行改变，从设计，到开发，到测试。当你发现改变的代价太大时，你就会放弃，然后依旧背负着带有缺陷的功能一路走下去。

为什么不开始就尽量少牵扯呢，这样更加来去自如

6 要有自己的主张

虽然交互设计通常都会处在不黑不白的阶段，因为没有绝对的对与错。但我们还是需要坚定自己的主张。也许果断的观点看起来目中无人，但总比那些“嗯……其实这样也成……”模棱两可要好的多。敏捷开发中需要的就是快速做决定，而不是唯唯诺诺和稀泥。

————————————————————————————————

也许并不是所有的项目都适合，毕竟初期不考虑细节必然要考虑后期更改的成本。但对于一个新产品，快速触达用户，让用户来使用，验证，反馈，得到的数据更加真实有效。根据这些反馈作出的调整总是比自己拍脑袋来的简单，更加符合用户需求。

敏捷，并不只是站立晨会，迭代总结，理论，文档，更需要的做的是，把它做出来。

评价敏捷

劲松 — 2009-09-08 18:10:26

原文作者：Sue McKinney
原文链接：Evaluating Agile
译者：劲松

评价敏捷

从成本和收益上分析是否要转向敏捷开发

高效地开发出有品质的软件对各个行业的企业都是至关重要的，对最终用户尤为重要。软件企业不再能忍受18个月的产品周期，它们正在寻求各种方式变得更加灵活和多变以适应不断变化的市场需求。

尽管我们需要一个高效的软件开发计划，但目前多数的开发项目仍然在进行中并且按传统的模式要求事先定义下所有的需求，同时这些需求在日后几乎不允许改变。问题是按这种方式多数客户都不能准确定义出它们的需求。夹杂着技术进步带来的变化，结果是令人气馁的。美国的一家研究公司Standish Group发现百分之九十的软件项目延期，百分之六十六的可以认为失败，以及百分之三十的完全报废。

敏捷开发是一个使公司能够更快速地提交软件产品的开发过程方法。它一个渐进的，协作的方法，其目标是有效及时地生产出高质量的软件。

在敏捷的初期，它适用于较小的范围和相对简单的商业应用项目。如今，局面已发生了显著变化。当公司想要把敏捷开发应用在更广泛的项目上，那么敏捷开发就需要处理当前软件开发组织所面临的大量业务、结构、和技术的复杂问题。

正确的分析出转向敏捷的代价，你必须权衡利弊，同时开了开发风险的减少。例如，实施敏捷方法需要改变工程师花费时间的方式和他们如何完成所有的软件开发活动。这里强调一些进行转换应该关注的要点。

个人和交互（针对流程和工具）
工作软件（针对全面文档）
客户的合作（针对合同谈判）
响应变化（针对遵循计划）

经理们必须考虑他们扮演的角色。多数敏捷精益开发经理使用更加放手的方式。他们让队员在特定的方向作先锋从而培育出成功转向敏捷精益开发的环境所需要的。

敏捷增加了团结的软件交付效率，从而转化为客户满意度和收益。效率可以消除在特定活动上的浪费，它可能也许不能对大的目标产生影响。但是，效率不会告诉你正在做的事情是否正确，或者告诉你正确的做事顺序。效率更重要的是它帮助你实现目标。

和其它重要的敏捷开发原则一样的一条是开发阶段的客户介入，如同前面提到过的，持续的团队协作。相关人员关于可工作代码的反馈和测试驱动开发对成功推出一个项目至关重要。相关人员包括业务相关者、软件使用人、客户支持、和其它企业IT部门人员，需要他们尽早的多多介入到敏捷项目整个开发周期中，积极参与建模和测试，有时甚至是参与开发。这一层次的介入使得他们能够看到软件开发的内部工作。这样促使开发人员关注于客户的优先级上而不是个人的优先级，这样可以提高产品的可用性。

这些敏捷开发指导方针为企业提供了一个基础，一个使企业知道如何快速响应并准备好应对需求变化的基础。例如使用Scrum（混战：一个敏捷开发借用橄榄球运动中的术语），一个每天举行的“混战”（也就是会议）邀请所有项目相关人员。每天开发人员回答三个问题：

从昨天到今天你完成了什么？
从今天到明天你打算做什么？
你遇到什么问题使你无法完成计划的目标？

这个每日例会要求每个人清楚说明他所做的事情，这样其它队员可以在转为灾难之前指出错误和不兼容。它也可以确保在紧急情况出现时有人可以作出及时补救。

敏捷开发常常被人批评为是过于随意的，这是不符合事实的。沟通交流和规则是敏捷开发的两个基本组成部分。敏捷最大的驱动原则是定期提交可工作的软件。提交周期越短，对规则的要求越高－例如，每次迭代都必须以可工作软件形式提供具体的可以度量的商业价值。

虽然关于敏捷是否过于随意和无纪律的争论还在继续，但有一个事实：人们对敏捷模式和精益开发的关注兴趣越来越强。仅仅在IBM一家，过去的两年中，敏捷项目的数量从5个增加到了200多个。

关于作者

休麦金尼是IBM的开发变革和整合副总裁。她目前在IBM软件部负责开发变革行动。她的主要工作重点是推动主流软件开发采用敏捷和精益原则。休还致力于分享IBM的经验，帮助大客户看到他们变革活动的机遇。

解读敏捷设计

Cennydd Bowles — 2009-02-25 22:05:15

原作者：Cennydd Bowles；译者：UCD翻译小组，Sophie；校审：Angela

原文链接：http://www.alistapart.com/articles/gettingrealaboutagiledesign

敏捷开发方式是不会被淘汰的。金融危机在过去几个月中终于爆发了；长期的要求和浮夸的前期文档不被接受的情况比以往更为普遍。软件必须从一开始就可见并且有价值。对很多设计师来说，他们对敏捷理论已非常熟悉（对此不太了解的，请参看文章最后的一些推荐阅读）。我们正在面临适应或是被淘汰的选择。好的方面是，敏捷理论仍然允许我们做那些我们认为有价值的事——研究，发展一个观点，测试并提高我们的设计——我们需要的只是新技巧。如果我们想在这越来越严峻的形式下与时俱进，现在是实践的时候了，证明设计可以适应。

渊源

时间，研究和构思有史以来都是设计师熟悉的领域，它们和我们与生俱来的想像和直觉相适应，并且使我们能够将模糊抽象的“品牌”和“用户行为”仔细结合起来然后转化成开发人员喜欢的：技术规范、站点地图、规划图和图表。

而另一方面，敏捷理论意在快速的交付软件和流畅地应对变化。这两种模式依靠的是微妙对立观念：见招拆招 vs 运筹帷幄，迁就变化 vs 先发制人。尽管有这些不同，许多敏捷宣言从根本上还是和设计师的思想体系相关的，交互在过程之上，合作在谈判之上，反馈，简洁。都正合我们的意思。

虽然设计师和开发者通过不同的视角观察世界，敏捷哲学从本质上是足够灵活能够支持这两种不同的方式和思想的。在敏捷的世界仍然有方法可以适应高品质的设计。

研究

鉴于敏捷理论认为“运作着的软件是评估进展的主要方式”，这使得详细研究的空间很小。虽然基于敏捷理论的项目能够在没有任何用户资源而（用直觉代替以用户为中心的设计）的情况下执行，但是输出总是少得可怜。就像手术也许是成功了，而病人却死了。

当团队成员和目标用户相似时，代入用户可以满足需求。设计师可以利用他们的经验工作，发现潜在的偏见并调解它。然而这种情况并不多见，大多数项目从研究中得到有益的东西，避免从错误的方向得到动力。 “零次迭代”作为一个争取时间的方式被接受，有些团队将这个方式扩展，在没有用户反馈交付的情况下增加了中期零次迭代。开发人员可以整理代码并规划下一步，设计师可以重审品牌、美感、体验这些贯穿整个站点的东西。

既然研究必须被轻量级，就不可避免会不精确。幸运的是，即使在每次迭代时进行一次到两次小型会议都可以满足需求。一个较好的方式是利用人际网（朋友的朋友，Twitter）并举行双重目的的会议：为未来的构想做研究，为已经完成的构想做可用性测试。如果不可能获得真实的用户，还是有挽救的机会。市场团队常常是拥有大量的人口数据的，服务器日志可以暴露搜索范围以及其他。这很鲁莽，但是甚至是这样的研究也可以帮助设计师弥补不足。

这种方式显然是不适合需要前期研究的缜密型研究团队。有些团队试图雇用项目之外的研究顾问，以便在需要的时候给予研究结论。然而，这样的结果有可能是混乱的，有用的细节也可能在沟通过程中丢失。因此，除了大型的项目，设计师最好能通过自己做研究获得重要深入的见解。

设计流程

敏捷的迭代是计划一个稳定的开发速率，但是设计师并不总能从这种中规中矩的工作流程中得到益处，因此摒弃计划对设计来说也是有价值的。准确性可以很灵活，一个大致的估计也可以帮助减少贸然的设计并且强化与开发同样关键的设计的重要性。

“最优方法”建议设计师应该研究迭代n+2，设计迭代n+1，支持迭代n，审核迭代n-1。这是个忠告但是无需照字面意思去做：一些构想的设计需要比这些时间线更久的时间。设计师应该用他们的直觉和经验提前找出潜在的复杂构想，获得更长的研究周期。这种做法和敏捷理论的规则有偏差，但是如果对项目有益就该鼓励。

愿景

缺少连贯是敏捷设计的一个普遍缺陷。这源于敏捷理论的模块化本质和某种程度上一个范围内的力量平衡。产品负责人，有时缺少觉察大局的策略。不加以制止的话，这会导致在战略上的突发奇想，提出不稳定需求，产品贴近的是公司幻想而不是客户现实。“地平线效应”能说明这个弊端的症状：潜在的问题在不断的迭代过程中被忽视，在项目完成之前，设计师不能确定解决方案是否完全产生了效果。

幸运的是，我们可以从其他领域借鉴。电影制片人以相似的方式运作，拍摄的顺序纯粹由逻辑决定。为了保证版本和叙事的连贯性他们聘请专家：导演和监制。在网络领域，设计师可以扮演相似的角色，但必须是自发自愿的。这意味着参与制作用户故事板，并试图引导产品所有者摆脱过度仓促的决定。

我们仍然没有很多时间探索明确的产品构想，但仍可以通过将用户故事组织成完整的用户流程并设计这一系列的用户故事来达到目的。随后我们可以将之作为一个整体进行审查和测试。这种做法可以表明很多用户的总体体验同时预警那些因“地平线效应”造成的陷阱。

交付物

敏捷设计的交付物是轻量的文件。很好——更多的时间用于思考和设计。基于这种倾向，静态的页面文件和线框图是行不通的。这些对于敏捷设计来说太僵化，尤其是在页面已经不是网络的基本组成部分的今天。我们更喜欢“在过程之上的交互”方法，从对话而不是固定的模板开始，使用具有真实交互过程的原型而不是静态的线框图。

用户体验设计师有许多交付物可以选择，低保真草图和纸质原型是分享设计思路和讨论观点的理想方式，然而这些方式在实际运用中却出乎意料的少见。通过快速而大量的手绘工作，用户体验设计师能够通过构建一个纸上的信息架构（包括元件，按钮，导航元素，下拉框等等）来复述他们的设计。

使用HTML制作原型或借助Axure和iRise这样的工具也是好的辅助。虽然需要一定的学习曲线，但它们都避免了草图的含糊（还有裁纸）。它们的灵活性足以应对修改的需求，它们的稳定性可以保证测试完整的用户流程。

视觉设计师仍然需要创造高质量的设计稿，所以终端产品设计也离不开Photoshop或者Fireworks。然而视觉设计师也应该与用户体验设计师一起参与早期原型交互设计。

应该尽早提出解决方案，尽管与某些观念是格格不入的，但这是敏捷理论的中心。为了节约时间，每一个内容类别只做一个实例——一个形式、一页研究结果等等，是明智的。通过足够的沟通，原型可以兼具说明的角色。

角色

我们知道现代组织体系是超链接形式的，但是在很多公司里设计仍然是单一决策的。为了迅速的迭代设计必须放弃完美：“90%正确”是敏捷的标准。这可能是违反常规的，但是不管怎么说，敏捷将时间线的重要性摆在精湛的技艺之上，并不是多大的损失。

然而，也有妥协过甚的时候。据Alan Cooper所言“不会有一大群人对你糟糕的产品翘首以盼。”最好的往往会打败最先进入市场的，而设计师天然的在质量管理、通过产品游说赞助商提供额外资源方面做的很好。

快速有时会诱使设计拘泥于模式化，借鉴其他有创造性的技巧可以有所帮助。设计师应该适应一个协作者的身份而不是一个独裁者。这不是指设计应该变得民主——专业的知识一如既往的必要——只是通过协同工作，设计师可以促进这种共同设计，并以此提高自身技能的信誉。这一方式还需要一种普遍认知：最好的敏捷设计师，产品经理，开发者和产品所有者都对彼此的原则有很好的理解。

未来

当许多设计师热衷于适应敏捷理论，少部分人认为这是一种让步。敏捷就理论来说是成功的：软件开发的最优方法。但是敏捷与Python、可用性测试或者microformats相比并不是最优方法。它只是一种工具：有时适用而有时不是。为此我们看到了后敏捷主义的出现，试图保留一部分敏捷思想而摒除那些不适应项目的部分。

不管怎么样，现在是将敏捷理论和设计团队就我们共同的未来达成一致的时候了。我们彼此需要，也需要从高高在上的象牙塔上下来。毕竟，我们有着共同的目标：为我们的客户和用户提供最好的结果。

推荐阅读

· The Agile Manifesto — an important starting point for anyone new to Agile.

· Agile software development on Wikipedia.

· Jeff Patton’s AgileProductDesign.com — contains a wealth of information on practical Agile design. See also SpoolCast: UX in an Agile Environment with Jeff Patton.

· Emily Chang and Max Kielser’s Agile Web Design Manifesto.

· Johanna Kollmann, Designing the User Experience in an Agile Context. Master’s dissertation (HCI and Ergonomics), UCL 2008.

引用

· Leisa Reichelt, Waterfall bad, Washing machine good [mp3] — presented at dConstruct 07.

· Jeff White & Jim Ungar, User Interface Design in an Agile Environment: Enter the Design Studio — presented at Interaction08.

· Alan Cooper’s The wisdom of experience — keynote at Agile 2008.

· Maria Guidice, Can’t we all just get along? Human-Centred Design meets Agile.

Finally, the IxDA and Agile Usability lists frequently discuss the issue of Agile design.

敏捷设计和敏捷开发 - UCD大社区

详解互联网产品开发中的“快”字诀

敏捷企鹅的创新功夫

敏捷开发思想谈（二）

敏捷开发思想谈（一）

企鹅快跑——腾讯敏捷历程揭秘

忘记敏捷

中国敏捷实践中的误区（三）误区和改进

敏捷测试的方法和实践

我眼中的敏捷设计

设计师谈敏捷

评价敏捷

评价敏捷

从成本和收益上分析是否要转向敏捷开发

关于作者

解读敏捷设计

渊 源

研 究

设计流程

愿 景

交付物

角 色

未 来

渊源

研究

愿景

角色

未来