敏捷用户体验设计的指导思想有两个：敏捷思想（Agile）和以用户为中心的思想（UCD：User Centered Design）。本文谈其中之一——Agile。

敏捷，《敏捷宣言》，《敏捷宣言》背后的原则

敏捷，不是一套具体的方法，更不是某种工具，而更像是一种思想，或者别用“思想”这么伟大的词——敏捷是一种思路/思维方式。我目前的理解，敏捷就是要小步快跑，及时用验证后的事实取代先前的假设。在实际的操作中，就是要根据项目的进展情况及时调整原有目标和计划，所做的工作要及时验证，工作成果要点滴地积累。我极力推捧《敏捷宣言》的头一条：“人”以及“人与人的互动”胜于“过程”和“工具”。很中国很大白话地说，就是：人要是太傻弱、或者人与人的配合不合拍，谈其他的一切思想、方法、工具都是白扯，当然包括谈敏捷。

谈敏捷不提《敏捷宣言》就像去东北没见过翠花的酸菜一样。咱先上翠花的酸菜：《敏捷宣言》及其原则。

在此，我试图对《敏捷宣言》作些解读：

◆方法套路要灵活——方法和工具是死的，人是活的，人要是太“面”或者协作不好，再强大的方法和工具都是白扯；

◆文档的编制要创新——上百页的项目报告没人乐意写，更没几个人乐意读。好在大家现在用结绳记事的人不多，要不得用多少绳子打多少扣啊？干的就是软件的活，却还用很原始的文字描述，难道这又是中国万恶的教育制度惹的祸？咱不是为人师表的灵魂工程师，咱就是弄点“软的(soft)东西(ware)”，所以只有软件能跑起来，才能算有建设性。码文字？不是咱的长项！

◆重新看待“合同”——这一条可能是针对非自用软件的生产的。咱没接过对外的服务合同，所以也没太多切身的体会。但俺意会一下，就是做人要厚道，不要太斤斤计较，最终把软件做好了，你好我好大家好，到时候再论功行赏，皆大欢喜。

◆弄清项目管理中的“计划”——“计划赶不上变化”。要是计划一点都不会变的话，人在执行计划过程中的自主能动性、创造性就体现不出来，计划也就是没必要由人来完成了。我们应该拥抱变化，积极应对变化，而不应死板地遵循预先的计划。那计划还有什么意义呢？我觉得计划是理清工作思路的作用，也就是要“抬头看路”。响应变化就是“低头拉车”了。

敏捷宣言背后遵循的原则：

1.产品设计开发过程中最重要的是：通过及早并频繁地交付有价值的软件来赢得客户的满意。

2.要欢迎改变需求，即使是在开发的后期。敏捷过程中的“变”，是为了让客户保持竞争优势。

3.交付要频繁，交付的软件要可运行。交付周期从数周到数月不等，但间隔的时间要尽量短。

4.在整个项目过程中，开发人员必须每天都与业务人员一起工作。

5.项目组所选的人要积极。然后，给予他们工作所需要的环境、支持和信任。

6.面对面交谈是开发团队内部和开发团队间传递信息最有效率和效果的方法。

7.可运行的软件是衡量进度的首要指标。

8.敏捷过程提倡可持续的开发。出资人、开发者和用户应始终保持稳定的步调（迭代周期）。

9.对技术的精益求精以及对设计的不断完善，将会提高敏捷性。

10.尽量去掉不必要做的工作——这就是“简洁”的艺术。

11.最佳的架构、需求和设计产生于自组织的团队。

12.团队要定期反思“如何能变得更有效率”，然后对自己的行为进行相应的优化和调整。

敏捷软件开发过程生命周期：产品→版本计划→迭代→用户故事

酸菜上完了，大家先品着。

咱先从软件产品设计的最基本套路谈起。软件设计，主要是这三斧子：设计规划→技术实现→测试评估，测试评估完了再修改设计重新规划，如此反复。

“设计规划”和“测试评估”工作一般由产品团队负责，具体的人员有：业务分析员、需求分析师、交互设计师、视觉设计师等。“技术实现”工作一般由技术团队负责，相关的人员包括：技术开发人员、界面制作人员等。

用户故事

看过了产品设计的基本套路后，再看看设计的基本单元——用户故事（user story）。用户故事就是以用户的语言对产品功能（feature）所作的描述。关于用户故事，应注意以下几点：

◆每个用户故事，只描述一个功能（feature）

◆用户故事，用的是用户的语言，体现了“以用户为中心”的思想

◆用户故事是产品设计的上下文背景

◆用户故事，是用来做出开发计划的，每个用户故事的开发周期不要太长，建议不超过1周或10天（属经验性估计，仅供参考，您别跟我较真，别问我为什么不是1周零一天或11天等等…….。一个用户故事是最小的开发单元，所以开发一个用户故事的时长最好是您能掌控的最小开发周期，所以给出了1周或10天的建议。）

◆接上一点。“能掌控”，就意味着每个用户故事都可以在“事前”被准确地估量出来，“事后”被准确地衡量。

用户故事由3部分组成：用户（user）、任务（task）以及用户执行该任务所要达到的目标（goal）。通常的格式如下：

作为

例如：

关于用户故事的更多讨论，在以后的内容中还会继续。

迭代开发

迭代就是以“用户故事”为单位的功能细化过程。每个迭代都有明确的起止日期。每个迭代的时间跨度大概是2~3周，当然，您可以定的稍长或稍长点，例如1周或一个月。（又是很招打的、貌似砖家般的、数值化的建议！！！）因为人们很难对1个月之后的事情做出详细而合理的计划，人们一般情况下可“掌控”的也就是2~3周内的事情，对1周内的事情会掌控的更自信点。

各位还记得赵本山的那句经典台词“你多大鞋我就多大脚”吗？敏捷开发中的迭代，就有点这感觉：你给我多长时间，我就干多少活；而不是你给定已知数量的活，然后我不停地估算时间，推延工期。每个迭代周期内要完成多少工作（几个用户故事），是由业务人员、开发人员、测试人员在做迭代计划时共商定的。确定迭代计划之后，开发人员就按照业务人员之前选定的功能（features）来开发。在每个迭代的后期，测试人员就会开始评估/测试依据用户故事所开发好的功能。在评估/测试时不但要对每个功能进行单独的测试，还应该对已实现的功能进行综合测试，以确保各功能间的配合默契。

当迭代预定的时间到期后，该迭代就宣告结束，未完成的功能将会被移到下一迭代中考虑。当然，在计划下一迭代时不但要考虑上一迭代“遗留”下的功能，更要考虑如何避免对工作量（即用户故事）估计时产生的误差。考虑迭代后的敏捷模型，就变成了下图的样子：

增量版本计划

“可掌控”的迭代周期都很短（1~4周），这样就能在软件产品开发的过程中，比较实时地测试开发工作的质量、评估产品当前的状态，并依此及时调整功能及其优先级。在这么短的时间内，我们所开发实现的产品功能可能还不够完善，无法供最终的用户使用。那么我们要等软件产品的所有功能都开发完毕后再交付给用户使用吗？我们需要考虑两方面的问题：一、所有的功能都开发完，我们的软件产品是不是需要很长时间才可以交付，用户、市场是不是有这样的耐心；二、即使用户、市场等外部环境允许我们花很多时间来开发软件，那“所有”的功能意味着什么？——意味着不可能完成！一来没有人能确定“所有”的功能，再者，已确定的功能也会随着时间的推移而有所改变，这样下去，我们的软件产品将永远都不可能交付使用。比较可行的办法是，为我们的产品确定大体的版本计划，我们的产品就可以在原有版本的基础上，每次增量地多发布一点新功能。

“软件产品的各版本要实现什么功能，每一版本要为用户、市场提供什么不同的价值”这些问题都会在版本计划会议上讨论清楚。确定版本计划的依据就是产品功能的重要程度以及实现这些功能所需的时间。第一个版本需要支持用户的所有必要活动，因此所提供的功能也是最必要最重要的。以后的版本，则会在不延误市场战机的情况下，确定对用户来说比较有价值的“版本升级”。（一定不是简单的功能堆砌，而是对用户来说有价值的工具更新换代。）

有了对各版本的计划后，我们就基本可以确定具体的每个版本需要多少次迭代来完成。Alistair Cockburn给出的经验值是：每个版本大概需要1~6个迭代。

小结

“小步快跑，及时反馈”，这样就能将我们的一系列从大到小的计划一步步落到实处。通过我们对产品的持续规划，就可以确定一个软件产品发展的大概版本计划；每个具体的版本内，我们又可以通过几个迭代来开发完成；每个迭代周期内，我们工作时用到的最小设计单元就是以用户为中心所确定的用户故事。这样，我们就将宏观的、抽象的产品规划一环套一环地落实到了具体的设计单元。“产品→版本计划→迭代→用户故事”的过程，就是由抽象到具体的敏捷软件开发过程。敏捷软件开发过程的生命周期如下图所示：

敏捷过程的时间规划如下：

This entry was posted on 星期日, 07月 5th, 2009 at 12:08 and is filed under Agile, 指导思想. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.