用户故事

敏捷项目测试策略文档模板 　　在一个敏捷工作环境种，我们的研发工作以冲刺期和高度迭代的形式展开。每一个迭代周期都关注少数的需求或者用户故事，所以在文档在敏捷项目种的数量和内容方面都倾向于轻量化。 　　对于测试计划这样的文档也是如此，不过我们也确实需要为敏捷团队去提供一个概要的敏捷测试策略，以供指导。 　　敏捷测试策略文档是为了给团队提供一个最佳的测试实践和一些形式的测试体系。记住，敏捷并不意味着没有体系。 　　下面我们来看一个敏捷测试策略文档，看看我们都应该包含些什么内容。 1.　　 一份测试策略中通常都会对于更宽泛的商业目的和目标做出任务说明。 　　 一个典型的任务说明可以是： 　　“通过快速反馈和缺陷预防，持续的交付可工作的，满足用户需求的软件，而不仅仅是缺陷发现” 　　细化以后： 　　“● 在定义完需求的接收条件/测试之后，代码才能进行编写。 　　 ● 接收测试不通过，一个需求就不能被判断为完成。” 　　在敏捷项目中，通常还会包含关于质量保证的提示： 　　● 质量保证是系统和可靠的保证产品满足用户需求的一系列活动。 　　● 在SCRUM（敏捷）中，质量保证是所有人的责任，而不单单是测试人员。在我们开发新产品的过程中，我们通过质量保证活动来确保正确的质量。　 　 2.　　 测试级别 　　 2.1　　单元测试 　　WHY : 确保代码被正确开发 　　WHO : 开发工程师

用户故事 用户故事描述了对用户、系统或软件购买者有价值的功能。 用户故事应该具备以下特点： 1) 独立的：应该避免故事间的项目依赖。在对故事排列优先级时，或者做计划时，故事间的相互依赖会导致问题。 2) 可讨论的：故事不是签署好的合同，故事是功能的阶段描述，它提供了适量的信息给开发人员和客户团队，提醒他们在以后进行关于需求的对话。它并不是需求本身，因而不需要包含所有细节。 3) 对用户或客户有价值的：每个故事必须对用户有价值，因此应该避免那些只对开发人员有价值的故事，例如技术和实现细节，用户界面等。保证每个故事对客户又加重的最好方法是让客户来便携故事。 4) 可估计的：对于开发人员来时，应该能够估算故事的大小。如果故事太大而无法进行估算，则需要分解成更小的故事。但有时也需要史诗故事作为占位符或提示。 5) 小的：故事的大小很关键，故事太大或太小，都无助于制定计划。史诗故事在执行前，需要分成更小的故事。合适的故事大小取决于团队，它的容量及所使用的技术。 6) 可测试的：故事必须是可测试的，成功通过测试可以证明开发人员正确地实现了故事。如果故事不能被测试，开发人员将无法知道什么时候才算完成了代码。 用户故事的优点有： 1）强调对话交流而不是书面沟通： 使用用户故事的目的并不是让我们事无巨细的记录下想要的特征，而是提醒开发人员在将来需要与客户进行沟通与交谈。相较于追求完美的需求文档

1. 什么是用户故事？ 用户故事描述了对用户或客户有价值的功能。用户故事由以下三方面组成（3C）： 一份书面的故事描述，用来做计划和作为提示（Card）。 有关故事的对话，用于具体化故事细节（Conversation）。 测试，用于表达和编档故事细节且可用于确定故事何时完成（Confirmation）。 可以用故事卡来记录用户故事，在故事卡的正面记录故事的简短描述，背面则记录测试要点。 2. 什么是优秀的用户故事？ 优秀的用户故事应该具备以下6个特点（INVEST）： 独立的（Independent）。 可讨论的（Negotiable）。 对用户或客户有价值的（Valuable to users or customers）。 可估计的（Estimatable）。 小的（Small）。 可测试的（Testable）。 3. 为什么使用用户故事？ 使用用户故事能够带来下面好处： 用户故事强调口头沟通。可以提供迅速的反馈周期，能够促成对需求的充分理解。 用户故事更容易被人理解。 用户故事的大小适合做计划。 用户故事适合于迭代开发。可以很容易的从一个史诗故事入手，并在需要的时候将其分解成多个小故事。 用户故事鼓励延迟细节。可以很快的写出大量用户故事，迅速的开展工作。 用户故事鼓励随机应变的设计。团队能迅速的在高层及低层细节思考间切换。 用户故事鼓励参与性设计。 用户故事有利于传播隐性知识。

3 月，跳不动了？>>> 故事点 是敏捷项目管理和开发中的一种抽象的度量单位，用于估计实现一个或多个用户故事的复杂度，它是对工作量的一种描述方式。一个故事点就是一个数字，透过这个数字告诉整个团队用户故事的复杂度。复杂度包括功能的难易程度、风险和花多大的功夫。 故事点（story point）和预估时间（estimated）不一样，故事点是一种相对的估计，它并不能和类似“人/天”这样的单位画等号，因为每个人完成同样复杂度的工作所需的时间是不同的。我们举个例子说明一下： 假设T团队有A、B、C三位员工，A君的能力是B君的2倍，B君的能力是C君的2倍（能力是不能这样对比的，这里只是方便说明问题），T团队约定10天为一个迭代，现在他们想计划一下未来的工作。如果按照预估时间的方式，一个用户故事B君觉得需要1天，A君觉得0.5天就可以，C君觉得需要2天，那么他们最终定多少呢？ 这里可能出现两种结果： 第一种结果，A君说这个我来做，写0.5天吧！如果按照这个方式，那么整个计划会议就演变成分工会议，A君挑若干的用户故事，自己进行估时，B君和C君也是如此，当每个人的总估时都逼近10天的时候，那么这个迭代的目标就确定了。这是很多团队实际采用的方式，看起来好像没问题，但是久而久之，这种方式的弊端就会显现出来。 自己干自己的，不关心全局的进展。既然每个人自己的工作内容都已经确定

第一次冲刺 　　团队开展了第二次会议，商讨了项目需求，确定用户需求，以及确定了每个人应该完成的任务。 用户故事 　　作为一名长大学子，小黄特别希望能够在手机上查到自己的成绩、课表、校园卡信息，能够充值网费和热水卡费，想提高自己的成绩或者快要期末考的时候要复习能够找到自习室去学习，空闲时间想找人打球或者跑步，刚来学校向找自己的老乡带自己熟悉学校，想知道平时学校发生的大小事。 顶层用例图： 活动图： 完成情况 　　1、完成了用户故事的编写。 　　2、画出了用例图和活动图。 　　3、完成了登录和注册窗口的代码编写。 个人任务 　　画出用例图和活动图，顺利完成任务。 收获和体会 　　团队例会有利于我们更快捷的开发，更有利于我们团队的交流，每个人提出自己的想法，尽快的完成任务，学习到了很多新知识，下次还要继续努力。 来源： https://www.cnblogs.com/liyao123/p/7757816.html

无论作为产品用户还是管理咨询顾问，都非常非常喜欢微信。自认感情比较克制属于“高冷”挂，但从很多方面都太佩服太崇拜张小龙了（新书里微信也会是最喜欢的案例之一，真的不只是一个产品而已，很多方面都太牛了）。不知道大家是否有注意到，在疫情爆发后，微信的响应大概最快速也相对最到位的了，看一看立马有了“疫情专区”（不知道官方名称是什么，以下暂以此代称），对于了解疫情整体数据和最新动态都很有帮助，真是觉得太棒了。 之前了解到微信也是使用敏捷开发，最近也在筹备ASM实战课程和Scrum咨询服务产品，奇葩开个脑洞用Scrum YY一下看一看“疫情专区”开发过程，也通过这种方式简单科普一下敏捷开发基本理念与价值以及Scrum的流程实践吧。 本文包括4部分： 敏捷开发基本理念与价值 敏捷开发实践方法 Scrum的3个角色与5个活动 如何通过Scrum实现微信看一看“疫情专区” 敏捷开发基本理念与价值 敏捷开发根源于适应性项目管理和精益开发，相较于传统基于“预测+规划+控制”的瀑布式开发方式，能够适应需求变化的风险，及时理解与响应客户需求，通过周期迭代交付可工作的增量产品的方式，增强项目管理灵活性与可预测性，并基于团队责任制的工作理念运行，借鉴精益管理理念与优秀实践，流程效能高，能够显著优化开发成本，提升产品质量与竞争力、客户满意度、团队及干系人满意度。 就像微信看一看的“疫情专区”

在远古时代，文字没有出现之前。知识的传承靠口口相传，不管隔了多少代，其准确性很高。文字出现后，我们大脑中的这种技能反而逐步衰退。于是各种软件、各种方法充斥着我们，左右着我们。各位是否也有相同的想法？试想一下，上节课我们讲了什么？每次应允别人的承诺，我们转过头就忘记？比如忘记约会，忘记洗车、忘记写日报？ “要想知道栗子的味道，你得咬一口”这个真理朴实，正确。当用户提出一款软件时，我们不要只想着从技术的角度，认为用户不专业，他的需求是错误的。如果他专业，就没我们啥事了。用户大脑中的需求是离散的，不可控的，这时，就需要我们放下成见，彼此真诚相对，让用户参与进来，通过各种方法，一条条梳理，直至双方的理解是一直的。 其作用：1.我们弄懂了用户为何会这样想。2.用户通过亲身参与，头脑中的需求逐渐变成技术可理解的。“求同去异”是一个很难的过程，需要双方彼此做出改变，很难.....，往往难得事情才是最重要的，要不怎么会有“战胜困难”的伟大，痛苦成就了欢乐。 软件的最大价值只有在用户认可，使用才算真的有价值。“再牛逼的算法，再严谨的逻辑”不符合用户实际需求，都是白费力气。“当顾客很饥饿时，他只需要的立马填报肚子的食物，而不是需要几天或者几个月才能做好的满汉全席”。 扯远了，回归正题。因用户对软件领域不专业，脑中对需求没有一个正确的定论。就需要我们专业人士，运用特殊的方法，梳理用户真正的意图。

【 本文内容摘抄自网络 】 ① 在软件开发生命周期中，会遇到两个瓶颈。 第一，是在需求阶段和开发阶段之间，针对不断变化的需求，对软件开发者提出了高要求，所以出现了敏捷开发方法论，强调适应需求、快速迭代、持续交付。 第二、是在开发阶段和构建部署阶段之间，大量完成的开发任务可能阻塞在部署阶段，影响交付，于是有了DevOps。 ② 软件需求包括3个不同的层次―― 业务需求【 表示组织或客户高层次的目标 】、 用户需求【 描述的是用户的目标，或用户要求系统必须能完成的任务 】、 功能需求【 规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求 】。 除此之外，每个系统还有各种非功能需求。 ③MVP模式，暂不理解。 ④用户故事：从用户角度描述用户渴望得到的功能 INVEST Independent（独立性） 可以被单独地开发、测试甚至交付。 有些故事之间会有自然的顺序依赖，但每个部分仍具备单独交付价值。 有些无价值的依赖，我们需要寻找和消除依赖（通常是和其他依赖的故事结合起来取交集，形成一个新的用户故事）。 Negotiable（可协商） 允许、且需要经过协商。 Valuable（有价值） 用户故事必须向用户、客户或产品干系人提供一定的价值。 Estimable（可估算） 可估算的用户故事能够提取任何隐藏的假定和欠缺的验收标准，并且澄清团队对用户故事的共同理解。

概述 敏捷方法论有一个共同的特点，那就是都将矛头指向了“文档”，它们认为传统的软件工程方法文档量太“重”了，称为“重量级”方法，而相应的敏捷方法则是“轻量级”方法。正是因为“轻量级”感觉没有什么力量，不但不能够有效体现灵活性，反而显得是不解决问题的方法论似的。因此，就有了一次划时代的会议，创建了敏捷联盟。 在敏捷方法论领域中，比较知名的、有影响力的，是拥有与 Microsoft 的操作系统相同缩写语——XP的极限编程（eXtreme Programming）。极限编程方法论可以说是敏捷联盟中最鲜艳的一面旗帜，也是被研究、尝试、应用、赞扬、批判最多的一种方法论，也是相对来说最成熟的一种。 这一被誉为“黑客文化”的方法论的雏形最初形成于1996—1999年间，Kent Beck、Ward Cunninggham、Ron Jeffrey 在开发 C3 项目（Chrysler Comprehensive Compensation）的实践中总结出了 XP 的基本元素。在此之后，Kent Beck 和他的一些好朋友们一起在实践中完善提高，终于形成了极限编程方法论。 解析极限编程 那么什么是 XP 呢？XP 是一种轻量（敏捷）、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。与其他方法论相比，其最大的不同在于： 在更短的周期内，更早地提供具体、持续的反馈信息。 在迭代的进行计划编制

个人PSP 计划 *估计这个任务需要多长时间：估计需要三天的时间完成这个项目。 开发 *需求分析： 用户故事：作为一个观众，我希望了解没场比赛的比分，以便了解比赛的情况。 从分析用户故事可以知道完成这个程序需要完成选择队伍和查看比赛记录的功能。 任务：作为观众需要知道每场比赛的队伍、第几局、及比赛结果； 生成设计文档: 代码规范：无 具体设计： private void label2_Click(object sender, EventArgs e) { textBox2.Text = "记分板：" + textBox1.Text + ":" + textBox1.Text + textBox1.Text; } private void button3_Click(object sender, EventArgs e) { textBox1.Text = ""; textBox2.Text = ""; button2.Enabled = false; } private void textBox2_TextChanged(object sender, EventArgs e) { if (textBox1.Text != "") { button2.Enabled = true; } else { button2.Enabled = false; } } private void