敏捷实践之用户故事编写
敏捷实践之用户故事编写
任志强 Roger
2019年01月
序 言
敏捷开发近些年在国内软件公司中越来越流行起来，越来越多的公司开始采用敏捷方法并投入精力去研究推广敏捷方法，因此也造就了国内一批又一批敏捷实践者和爱好者，我想当初Kent Beck等敏捷宣言的创始人也未必预见今天敏捷遍地开花的景象吧。
本人从2011年开始在IBM开始接触敏捷开发到后来做Scrum Master到现在的做敏捷教练，在敏捷的学习和实践中受益匪浅。我欣赏甚至是崇拜精益思想和敏捷方法，也特别希望能总结一些想法和心得来记录在这敏捷之路上遇到的困难和问题，从而分享给那些已经或者正准备踏上敏捷之路的朋友们用于个人学习、研究和欣赏，以及非商业或盈利性用途，为在敏捷之路的个人和群体贡献一份力量。
系列文字主要内容来自于个人敏捷转型实践、书箱文献和日常系列活动心得等的提炼总结和创作。此系列文字内容推荐有基本敏捷常识及有一定Scrum理论基础的朋友们阅读，并按实际场景进行参考。如内容涉及版权或原创作者有不同见解之处，敬请及时告知，乐于接受并给予修正。
目录
1 什么是用户故事
维基百科上是这样定义用户故事的：“在软件开发和产品管理中，一个用户故事是一个非正式的，自然语言描述的一个或多个软件系统功能”，而Mike Cohn在《用户故事与敏捷方法》书中这样写到：“用户故事描述了对用户、系统或软件购买者有价值的功能。”相比之下我个人更愿意使用后者的定义，用户故事的主题是一句主动语态场景描述，包括三个要素：
l 角色：谁要使用这个功能。
l 功能：需要完成什么样的功能。
l 价值：为什么需要这个功能，这个功能带来什么样的价值。
2 用户故事价值
无论你的团队用的是哪种敏捷框架和方法，用户故事都将会是最核心的、不可或缺的组成部分，因为用户故事是从使用者的角度出发对产品功能和商业价值的描述，是完成迭代目标以及产品交付的基石。
用户故事对用户有价值？还是对客户有价值？亦或是对开发团队有价值？首先我们要区分用户和客户的区别，用户是产品的最终使用者，客户是出钱购买产品的人，当然这两者可以是同一个人或组织。我曾经做过一个项目，一个银行客户出资开发了一套信用卡服务的App，最终的用户自然是银行的信用卡客户，该App后台需要记录用户的操作习惯来优化系统的设计，这个用户故事由一位开发者张三独立完成，那我认为这个用户故事对购买者银行是有一定价值的，而对最终用户来说并没有任何价值产生，所以我认同的观点是用户故事对用户或者客户有价值。
我们再来说一下开发者张三，他是个初级工程师通过刚刚提到的用户故事的开发，积极主动与客户多次进行业务上的交流，在技术和金融业务知识上都有了很大的提升，还收到了客户方的表扬信，而后他在团队和部门的影响力也今非昔比，我认为这个用户故事也成就了张三的个人价值，目前没有哪位大师或组织提及用户故事对开发团队有价值，但我个人观点认为用户故事某种程度上说也可以成就开发团队的能力和价值。
3 如何编写用户故事
3.1 用户故事模板
最流行的用户故事通常按以这样的格式来表达：
英文：As a <Role>, I want to <Activity>, so that <Business Value>.
中文：作为一个<角色>, 我想要<功能>, 以便于实现<商业价值>。
就这一种模板吗？不是的，还有如下其他多种格式：
l In order to <receive benefit> as a <role>, I can <goal/desire>
l As a <role>, I can <goal/desire>, so that <why>
l As <who> <when> <where>, I <want> because <why>
l As <persona>, I can <what?> so that <why?>
以上四种格式是维基百科上推荐的，但在实际的软件开发工作中，不一定所有需求都按照以上模板来编写，尤其是一些对客户或用户没有直接价值的需求您完全可以自己定义，不要被上述模板限制住。
3.2 搜集用户故事
3.2.1 领域知识
每做一个项目我都有很大收获，技术提高是一方面，更多的是业务。所以我一直对团队说，我们做一个项目如果把自己从技术专家变成业务领域专家那么你就成功了，你就是T型人才。很多时候，技术不是难点也不是障碍，而是业务知识，我们学习业务知识是为了更好的了解用户需求，业务知识考验一个人的思维方式和短时间学习的能力，将业务弄清楚再用技术手段将其实现就是开发团队的价值，也是用户故事本身承载的、客户最关注的商业价值。
3.2.2 用户访谈
与传统开发模型（如瀑布模型）的需求调研工作方法类似，搜集用户故事的方法可以使用用户访谈，因为敏捷宣言提倡的就是沟通、与客户合作，如果有可能访谈产品的使用者是最理想的选择，多和客户和用户沟通可以获取他们的真实想法和诉求，与客户和用户打成一片，是达成最终交付目标及客户满意度最有效的途径。
3.3 编写用户故事
3.3.1 优秀故事特征
几乎所有敏捷书籍和资料都会提到由Bill Wake提出的INVEST用户故事编写准则，INVEST是取自六个英文单词的首写字母，也是一个优秀用户故事应该具备的六个特征：
l 独立的（Independent）
尽量避免故事间的相互依赖。在对故事排列优先级或者使用故事做计划时，故事间的相互依赖会导致工作量估算变得更加困难。通常可以通过两种方法来降低依赖性：1.将相互依赖的故事合并成一个大的、独立的故事；2.换一种方式去拆分用户故事。
l 可讨论的（Negotiable）
用户故事是功能的简短描述，细节将在客户团队和开发团队的讨论中产生。用户故事的作用是提醒开发团队和客户进行对话，它并不是具体的需求本身。
l 有价值的（Valuable）
用户故事应该很清晰地体现对用户或客户的价值，最好的做法是让客户编写故事。
l 可评估的（Estimable）
开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：1.开发人员缺少领域知识；2.开发人员缺少技术知识；3.故事太大了。
l 短小的（Small）
一个好的故事在工作量上要尽量小（个人建议大于等于1人天小于等于5个理想天），如果用户故事越大，在安排计划，工作量估算等方面的风险就会越大。
l 可测试（Testable）
故事必须是可测试的。成功通过测试可以证明开发人员正确地实现了故事。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。
好的故事可能具备上述六个特征，但是绝对不是每个故事都必须具备，我举个例子说明一下我在IBM经历过的案例。我们整个Program注意并不是Project在全球有100人左右，有6个Scrum团队协同完成一个大型C/S（客户端/服务器）监控类产品，有多个中心服务器程序和数十个客户端代理程序，总而言之我们没有一个独立的、可测试的用户故事，都需要基于其他团队协同完成开发和测试。
3.3.2 用户角色识别
通常任何软件产品最终都是给用户（人或者系统）使用的，所以一般在编写用户故事时按照用户角色来分析产品的功能和特性是大多数项目采取的方法。个人经验是在访谈时先从“谁”有可能用到该产品（那些公开网络无用户权限控制的类型除外），他们都是哪个部门什么职位目的是什么，有没有特殊权限的用户，尽可能多的将所有角色都识别出来，而后根据用户角色的行为和特征归类、整合这些角色。
3.3.3 谁负责编写
《用户故事和敏捷方法》一书中的观点是，要保证每个故事对客户或用户的价值最好的办法是让客户来编写故事，我认为这种观点是比较理想化的。用户故事的编写看似简单，真正掌握写出合格的用户故事并非易事，要求客户有一定的领域知识和能力才行，客户又出钱又出力帮我们做他们不擅长的事情（不排除有些客户有能力并且愿意做），他们会愿意吗？我过去近10年的敏捷项目包括国内的和欧美的客户没有一个是愿意承担这部分工作的。
在实际的项目执行中，PO即产品负责人来编写用户故事的情况较为常见，这个也很容易理解，PO本身就是负责产品规划和交付的，是开发团队和客户之间的桥梁纽带，他既是客户方的代言人，也是开发团队的外交官。
3.3.4 用户故事地图
绘制用户故事地图是有Jeff Patton(2009)提出的方法，以用户为中心将用户行为分解为工作流，通俗地讲就是将用户的活动按照业务操作顺序列出来，再将大的活动分解为任务或者子任务。如下图：
图3.1 用户故事地图示例
用户故事地图结合了用户为中心的设计和故事分解，可以展现出用户的工作流，目的是识别所有用户故事避免遗漏，所以我个人建议用户故事地图可以不去过度关心优先级，而是聚焦于全面“生产”故事。当然用户故事地图在很多项目中可以用于做发布计划，从而可视化的规划整个产品的发布情况。
4 实践中的常见问题
4.1 问题1：用户故事写成了需求规格书。
观点：用户故事与需求规格说明书不同，没有大量的文字叙述，也不是与客户达成的合同或者契约，敏捷方法中的用户故事是需求场景化的简单描述，是价值交付的载体。
4.2 问题2：用户故事细节太多。
观点：我经历的敏捷项目中用户故事的细节是开发团队和客户“讨论”出来的，正因如此用户故事才有“可讨论”的特点，这些细节最终被确认后将以用户故事接受标准（Acceptance Criteria）或测试用例的形式被记录。这也遵循了Ron Jeffries(2001)的3C原则，卡片（Card）、对话（Conversation）和 确认（ Confirmation），“卡片”是用户需求的简洁描述，需求细节在与客户的“对话”中获得，并在“确认”部分记录。
4.3 问题3：所有需求都是用户故事吗？
观点：有些需求并不是用户故事，在实际项目过程中有一些需求无法以用户故事通用的格式话语言描述，例如我经历一个项目要求我们给出接口设计规范和调用方法，这个用户故事就与系统功能无关，但又确实是个非常耗时的工作，所以我把它也建了一个故事类型但描述并没有按照用户故事的格式来写。
因此，我觉得需求未必非得以用户故事的形式体现，也不要把所有需求都框死在用户故事的固定表述里面，因为需求不一定是功能需求还有性能需求、非功能的需求等等，用灵活的方式来写用户故事也无可厚非吧。
4.4 问题4：知识获取工作要写成用户故事吗？
观点：很多时候开发人员完成一个用户故事需要用到未曾使用过的技术时，首先他无法估算故事的工作量，其次他需要一定时间去做研究，这种情况下我的建议是先建立一个叫做探针（Spike）的工作项（如果你用的项目管理系统没有这个工作项，可以用故事类型去跟踪但是标题Tag就是Spike），在XP中提出的探针（Spike）的意思就是调研或验证类的工作项。
知识获取类的工作我个人强烈建议把他Highlight出来，因为知识获取会比较耗时且存在风险较大需要跟踪管理，另一方便这方面的工作往往会阻塞某些用户故事的实现，因此要特殊关注。
4.5 问题5：测试工作可以编写用户故事吗？
观点：我曾经在IBM做过一个内部项目，我给测试人员针对每个用户故事建立了一个对应的用户故事包括设计测试用例和执行测试用例，后来美国的PO很委婉的质疑我说他认为用户故事是体现交付功能的，而测试工作仅是一个验证交付的质量保证手段不建议用独立的用户故事去跟踪。后来我们达成一致在用户故事下建立测试的任务（Task），将测试用例放到接受标准（Acceptance Criteria）中去。
- 点赞
- 收藏
- 关注作者
评论（0）