敏捷原则

1.我们最重要的任务是通过尽早和持续交付有价值的软件来满足客户。

2.即使在开发的后期也欢迎需求的更改。敏捷过程利用更改来为客户获得竞争优势。

3.频繁交付可用软件，从几周到几个月，优先考虑较短的时间段。

4.业务人员和开发人员在整个项目创作期间每天都必须一起工作。

5.围绕积极的个体构建项目。为他们提供环境并支持他们的需求，相信他们能够完成工作。

6.在开发团队中传达信息的最有效方法是面对面的交谈。

7.可用软件是进展的主要度量。

8.敏捷过程提倡可持续开发。项目方、开发人员和用户应该长期保持步调一致。

9.对卓越技术和优秀设计的持续追求能够改进敏捷性。

10.简洁性不可或缺，它是减少工作量的艺术。

11.最好的架构、需求和设计源自于自我组织的团队。

12.团队定期总结更为高效的手段，然后相应也

调整自身的行为。

敏捷UX

“用户体验包括最终用户与公司、公司的服务及其产品交互的所有方面。出色用户体验的第一个要求是满足客户的实际需求，而不是带来繁文缛节以及干扰。接下来是简洁性，它能使拥有和使用该产品成为客户的快乐。为了在公司提供的产品中实现高质量的用户体验，必须将多种不同的服务无缝合并，这些服务包括工程、市场、图形化和工业设计以及界面设计。”

UX不仅考虑客户使用应用程序执行任务的能力，还要考虑他们在什么地方使用它、为什么使用它，他们可能需要进行的其他工作和需要的工具。这个术语还包含了最终用户用该产品执行任务所产生的满意度、挫败感、舒适性和信任度。例如，如果你设计一个用于商业旅游者的应用，并且考虑使用音频和视频命令，就必须意识到这一应用将会常常用在有着大量背景噪声的忙碌机场中，这些地方可能难以听到声音，系统也很难处理音频命令。这会导致令人沮丧的用户体验，即使用户几经努力后完成了任务、产品的设计非常吸引人也于事无补。从过程的角度上看，UX也指为最终产品做出贡献的活动——调查、设计和可用性测试。

将UX融入到敏捷环境中

预先进行设计工作以避免UX成为开发瓶颈，为代码实现准备好设计，防止在几个冲刺之后，设计出现麻烦并且需要返工。

如果团队的一部分在波士顿，另一部分在上海，还有一部分在旧金山，那么使用Wiki页面或者共享文档来获得共同认识就是合理的，因为面对面的交流很有限。国际化团队通常很欣赏在电话会议之前查看某种屏幕截图或者草图的做法，这为他们提供了吸收信息、形成自己的问题的机会。这对于任何远程协作都是最佳的做法，因为它可以使电话会议更加高

如果团队的一部分在波士顿，另一部分在上海，还有一部分在旧金山，那么使用Wiki页面或者共享文档来获得共同认识就是合理的，因为面对面的交流很有限。国际化团队通常很欣赏在电话会议之前查看某种屏幕截图或者草图的做法，这为他们提供了吸收信息、形成自己的问题的机会。这对于任何远程协作都是最佳的做法，因为它可以使电话会议更加高效。直接沟通永远是最有效的方式，通常比最具交互性的原型都更为有效。如果团队全都处于同一位置，所有功能区都支持该项目，但是有文档方面的要求，就应该被看作是一个危险的信号。

原型可以说明屏幕交互，而不是屏幕截图或者草图中捕捉到的平面设计。可以对交互的说明提供清晰的认识，消除了静态图片常常需要的解读。

每周或者每两周进行一次用户反馈，如果你所处的条件不允许这么做，另一个选择是确定关键的里程碑，在这些日期附近进行可用性测试。

用户调查

1.设计调查在发行期间完成，用于验证设计和产品总体方向的正确性。在设计周期中征求和使用用户反馈更容易适应敏捷的节奏。

2.较长期的调查用于确定用户需求、定义角色，而且可能包含其他更花费时间和精力的工作。

UX团队转移到敏捷环境是一个设计问题——收集你的调查结果、理解你的用户、提出最好的解决方案并且进行迭代，直到获得正确的结果。

召开每日会议可以保持团队的健康，养成相互交流的习惯，并且提高团队成员行动的透明度。

每日站立会议、计划会议、回顾会议和每日燃尽图评估。站里立会议一般是15分钟。团队成员往往抱怨每日站立会议和计划会议，但是这两种活动最终能够带来巨大的价值，因此很少被放弃。在调整之前先经历整个过程的另一个原因是这样的过程可能更精确、更有效果。你可能没有必要取消每日站立会议，而是精简它们，使某些功能区可以派出一名代表参会，这对于跨越多个项目的团队来说更加重要。要解决一个问题，你必须真正了解这个问题的含义以及解决问题的原因，这样才能得到正确的解决方案。

沟通

不管人们身处何处，能将团队成员头脑中的想法传达给团队的其余成员都是重要的。同样重要的是，信息不仅要传达出去，还要经过其他人的处理，并随之发生健康的交流。正如那些活动和仪式一样，不是为了对话而对话，而是真正地交流想法和思路。

敏捷团队可能特别容易迷失于工作的细节，而忘记他们的任务是如何组成整体的。

培训

UX团队应该一起参加培训活动，或者让整个项目团队都参与这类活动。一起阅读博客文章并进行讨论、建立读书俱乐部、分享出色网站的链接。

LinkedIn的敏捷体验设计组。对于拥有LinkedIn账户的读者，可以参与Anders Ramsay管理的这个组，这是参与或者聆听有关敏捷（特别聚焦于设计）的交流的极佳途径。

·www.agileproductdesign.com这是Jeff Patton的网站，也是敏捷相关信息的“金矿”，其中的重点是在过程中加入以用户为中心的设计。这个网站上有他的博客，一些演讲的存档、他的文章的链接、他所提供的培训说明，以及他将要参与的活动的安排。这个网站非常全面，是对敏捷感兴趣并想学习更多相关知识的设计人员和调查人员最好的资源之一。对这个网站怎么赞美都不为过，如果只想到一个网站上学习敏捷方法，就应该去这个网站。

UXMatters.com。它实际上就是一份在线杂志，有关于UX的出色文章。

任何敏捷项目的成功高度依赖于频繁的讨论和团队协作。

UX应该制作什么作为交付物?

敏捷方法提议消除传统的可交付成果，代之以可用于测试和客户迭代的快速原型，并使之成为与开发团队共享的工件。这与随意丢给其他功能区的旧式规格说明文档形成鲜明的对比。这种方法以更加互动的方法表达设计意图，更接近于真正的实现。如果你的情况允许，我强烈建议你这么做。大量事实说明，创建可交付物还会在敏捷项目的各个功能区之间建立不必要的边界。