阅读笔记04

阅读笔记04--用户故事与敏捷方法

第1章：概览

故事卡包含对用户或者客户有价值的功能的简短描述。客户团队包括那些确保软件符合潜在用户需求的人，可以包括测试人员、产品经理、实际用户和交互设计师。验收测试用于验证实现的故事是否开发成符合客户团队的设想。用户故事是很有意义的，因为它们强调口头交流，你和开发人员都可以理解，可以用于进行迭代计划，在迭代开发过程中能很好地工作，而且因为它们鼓励推迟细节。

 

第2章：编写故事

理想情况下，故事之间是独立的。有时很难做到这一点，但我们要尽量实现这一目标。故事之间的交付顺序应该是无关的，可以任意拿一个故事来实现。故事细节由用户和开发人员讨论得出。故事应该很清晰地体现对用户或客户的价值。最好的做法是让客户编写故事。故事可以注释一些细节，但是过多的细节会使故事难以理解，也可能给人一种开发人员和客户无需交谈的错觉。给故事加上注释的最好方法是给它编写测试用例。

 

第3章：用户角色建模

大部分项目小组只考虑单一的用户类型。这会导致软件忽略原本需要的一些用户类型。为了避免从单一用户的角度编写所有故事，要识别与软件交互的不同用户角色。通过对每个用户角色定义相关特征，可以更清楚地看到不同角色间的不同点。对于有些用户角色而言，用代表人物来描述会很有帮助。虚构人物是假想出来的用户角色代表。他们有名字，有照片，还有足够的相关细节，因为对项目成员来说，很真实。对于有些应用程序，极端人物可能有助于搜集原本被遗漏的故事。

 

第4章：搜集故事

拖网捕鱼的比喻是非常有用的：它说明了需求有不同的大小，需求会随着时间的推移变化，需要一些技巧来发现需求。即使敏捷流程支持需求的后期涌现，依然需要对预期的发布进行展望并开始写下容易发现的故事。我们可以通过用户访谈、观察用户、问卷调查和举办故事编写工作坊来发现用户故事。使用多种方法比过度使用一种方法更能获得好的效果。通过开放式、与背景无关的提问更容易获

得有用的答案，例如，“告诉我你想怎么搜索工作？”就胜于“你要通过职位名称来搜索工作吗？

 

第5章：与用户代理合作

在本章中，我们学习了不同类型的用户代理，讨论了编写用户故事时，为什么用户代理不如实际用户理想。除非用户的经理也是用户，否则她就不是合适的用户代理。开发经理会试图担任用户代理，因为他们已经参与到项目每天的细节中。然而，开发经理大多不是正在开发的软件的用户，所以他们不是理想的用户代理。在产品公司里，客户经常来自市场团队。来自市场团队的人经常是不错的用户代理，但他们通常关注于软件的功能数目，而不是其质量，这点必须要克服。与很多不同的客户(而这些客户同时也是用户)联系的销售人员可以是很好的开发项目客户。