敏捷用户体验设计指导思想之一敏捷思想

敏捷用户体验设计指导思想之一敏捷思想

2010-03-18 来源：

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

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

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

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

“人”以及“人与人的互动”Individuals and interactions 胜于

over

“过程”和”工具”

processes and tools

可运行的软件Working software 胜于

over

面面俱到的文档

comprehensive documentation

客户合作Customer collaboration 胜于

over

合同谈判

over contract negotiation

响应变化Responding to change 胜于

over

遵循计划

over following a plan

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

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

◆文档的编制要创新——上百页的项目报告没人乐意写，更没几个人乐意读。好在大家现在用结绳记事的人不多，要不得用多少绳子打多少扣啊？干的就是软件的活，却还用很原始的文字描述，难道这又是中国万恶的教育制度惹的祸？咱不是为人师表的灵魂工程师，咱就是弄点“软的(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）。通常的格式如下：

作为

作为 [某种类型的用户]

我想 [执行某某任务]

这样，我就能 [达成某某目标]

例如：

作为“直奔主题”的购物者

我想在店内找到CD的位置

这样，我就能快速买下它，然后马上离开；我好继续回到自己的生活轨迹中，爱干嘛干嘛了。

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

迭代开发

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

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