《用户故事与敏捷方法》的原文摘录(共 28 条)

  • 第1章 概览 什么是用户故事 用户故事描述了对用户、系统或软件购买者有价值的功能。其包括: 1.一份书面的故事描述,用来做计划和作为提示。 2.有关故事的对话,用于具体化故事细节。 3.测试,用于表达和编档故事细节且可用于确定故事何时完成。 使用故事的过程是怎么样的? 编写用户故事的过程最好从考虑系统的用户类别开始。 应由客户团队而不是开发人员来编写用户故事,尽量不要出现技术术语。 排列优先级时需要考虑下面几点: 1.大部分用户和客户对特定特性的渴望程度。 2.小部分重要用户和客户对特定特性的渴望程度。 3.故事之间的互补或依赖关系。 规划发布和迭代 在许多故事的优先级上,开发人员可能与客户团队意见相左。他们可能基于技术风险或由于某个故事是其他故事的互补故事,而建议改变故事的优先级。客户端团队应该倾听他们的观点,但是随后排列故事优先级时,应该坚持客户组织利益最大化的原则。 小结 故事卡是故事的可见部分,但客户团队和开发人员关于故事的对话更重要。 客户团队包括那些确保软件符合潜在用户需求的人,可以包括测试人员、产品经理、实际用户和交互设计师。 (查看原文)
    LEON 2012-02-22 17:41:55
    —— 引自章节:第1章 概览
  • 第7章 优秀用户故事准则 从目标故事开始 切蛋糕 技术人员习惯将大故事按照技术路线分割,这种做法的缺陷是,没有一个故事是单独对用户很有用的。而应该保证每个小故事都提供某种程度的完整的功能。 编写封闭的故事 一个封闭的故事是指那种随着一个有意义的目标的实现而结束的故事,能让用户使用后觉得她完成了某个任务。 卡片约束 对于任何必须要遵守而不需要直接实现的故事,在其故事卡上标注“约束”(constraint) 比如 系统必须支持最大50个并发用户的峰值。 尽管约束卡不需要做估算,也不会像普通卡那样被安排到迭代中,但可以有验收测试。 根据实现时间来确定故事规模 不要过早涉及用户界面 有些需求并不是故事 如果需要,可以放心使用用户故事以外的其他形式来表达某些需求。例如,用户界面参考通常是以有很多截图的文档来描述的;通过文档来定义重要系统间的接口等。 在故事里包括用户角色 如果项目团队已经识别出用户角色,那么在编写故事时就要使用它们。比如用“求职者”来代替“用户”会更准确些。 一种将角色融入故事的模板:我作为(角色),想要(功能),以此(商业价值) 只为一个用户编写 当故事只为单一用户编写时,故事的可读性是最强的。 以主动语态编写 要写成“求职者可以发布简历”,而不是“简历可以被求职者发布” 由客户编写 向故事卡编号说“不” 给故事卡编号会增加无谓的流程,并导致我们去抽象的讨论需要形象化的功能。 不要忘记意图 故事卡的主要目的是用来提醒开发人员和客户团队对功能进行讨论的。既然仅仅是一个提醒,就要保持它的简洁性。加入必要的细节,以便联想到继续对话的切入点,但不要加入太多细节并以此取代对话。 (查看原文)
    LEON 2012-02-22 17:44:14
    —— 引自章节:第7章 优秀用户故事准则
  • 第8章 估算用户故事 故事点 可以用户理想日作为故事点的单位:相较于用连续时间估算,它更简单;相较于用完全模糊单位,它可使我们的估算拥有更好的依据。 以团队估算 客户和产品经理可以参加,但他不能提出他个人的估算或者在听到自己不赞成的估算时发表意见。 估算 Wideband Delphi方法,与采用迭代方式进行开发软件的极限编程类似。 目的是要为故事得到一个统一的估算值。这个迭代过程很少超过3轮。 三角测量 帮助团队验证他们没有逐渐改变一个故事点含义的有效方法,不过可以不是特别精确。 使用故事点 我们用“速率”(velocity)来代表一个团队在一轮迭代中完成(或期望完成)的故事点数。因此,务必保证每次迭代的故事点的度量是一致的。 如果用结对编程呢? 团队用不用结对编程,对故事点估算并没有影响。团队可以采用理想结对日或理想个人日来估算故事点,区别会表现在速率值上。 一些提醒 一个故事(可能是一个史诗故事)分解成一些小故事后,这些小故事估算的总和不需要与开始那个故事或史诗故事的估算相等。 类似地,一个故事分解成一些任务。这些任务估算的总和不需要与故事的估算相等。 开发人员职责 1.负责用一个方式定义故事点,并且对团队可用和相关的。努力保证这个定义的一致性。 2.负责给出诚实的估算。不屈服于诱惑或压力而给出低的估算。 3.负责以团队估算。 4.负责估算应与其他估算一致。即所有2点的故事都应该差不多。 客户职责 负责参加估算会议,但是你的任务是回答问题并澄清故事细节。你不必参与故事估算。 (查看原文)
    LEON 2012-02-22 17:44:25
    —— 引自章节:第8章 估算用户故事
  • 第10章 迭代计划 迭代计划概览 1.讨论故事。 2.从故事中分解出任务。 3.开发人员承担每个任务的职责。 4.讨论过所有故事,并且接受所有任务后,开发人员单独估计他们承担的任务,以确保他们不会做出过于乐观的承诺。 讨论故事 过分地深入每个故事的细节会让会议变得冗长、低效,因为会议中不是每个人都需要聆听所有故事的所有细节。 分解任务 1. 尽管故事的确可以小到作为工作单位,但将他们分解出更小的任务,一般更符合项目协作的需要。 2. 故事是对用户或客户有价值的功能的描述,它们并不是开发人员的待办事项。分解任务有助于发现那些可能会被遗忘的任务。 3. 一个故事点任务分解其实是即时设计中的一次短脉冲,而这些短脉冲的集合取代了瀑布过程的前期设计阶段。 准则 如果故事的某个任务特别难于估算,就把那个任务从故事中的其余任务中分离出来。 如果有些任务可以很容易安排给多名开发人员共同完成,就分割它们。 若有必要让用户了解故事某一部分的完成情况,可以把那部分拿出来作为一个任务。 承担职责 一旦确定故事的所有任务,就需要有团队成员自愿执行每个任务。 即使采用结对编程,每个任务通常也最好只关联一个人的名字。此人将承担完成任务的责任,包括从客户那里获取信息、寻找结对者等。 迭代过程中可以根据对项目细节的理解改变任务承担者,团队要有一种“同舟共济”的心态。 估算并确认 每个开发人员估算自己承担的任务,并将总和累加看是否可以在一个迭代中完成。 小结 迭代计划是发布计划的进一步计划,但只有在迭代即将开始时才开始做迭代计划。 开发人员职责 负责参加迭代计划会议。 负责帮助把所有故事划分为任务,而不只是自己想做的故事。 负责为认领的任务承担责任。 负责确保承担适当工作量的工作。 在整轮迭代中,负责监控自己剩余的工作,同时也要监控队友剩余的工作。如果很快就能完成自己的工作,就有责任帮助队友承担部分工作... (查看原文)
    LEON 2012-02-22 17:45:17
    —— 引自章节:第10章 迭代计划
  • 第2章 编写故事 独立的 尽量避免故事间的相互依赖。 可讨论的 故事是可以讨论的,它们不是签署好的合同或者软件必须实现的需求。故事卡是功能的简短描述,细节将在客户团队和开发团队的讨论中产生。难点在于掌握如何恰如其分地包括必要的细节。 如果我们把故事卡用于提醒开发人员和客户进行关于需求的讨论,那么故事卡应包含以下信息: 1.一两句短语,用来提醒开发人员和客户进行对话。 2.一些注释,用以表明在对话中亟待解决的问题。 如果是纸质卡片,则测试可以被标注在卡片背面。 对用户或客户有价值的 应当避免那些只对开发人员有价值的故事,例如: 所有的数据库连接要通过一个连接池。 所有的错误处理和记录应在一系列公共类中完成。 下面是这两个故事更好的版本: 这个应用软件,最多50位用户能使用一个6用户的数据库许可。 所有的错误应以统一的方式呈现给用户并做记录。 同样,应当避免在故事中出现用户界面和技术方面的定义。 可估计的 一般有以下3个原因会导致故事不可估计: 1.开发人员缺少领域知识:需要和写故事的人一起讨论,没必要理解故事的所有细节,但是至少需要对故事有个大概的了解。 2.开发人员缺少 技术知识:可以让一个或多个开发人员去实施极限编程(XP)中所谓的探针实验(spike)。探针实验本身需要限定一个最大时间量(称为时间箱,timebox),用这个作为探针实验的估计。如此,一个不可估的故事就变成了两个故事:一个快速的探针故事(用来获取足够的信息)和一个故事(真正实现功能)。一般而言,会将这两个故事顺次放到两个迭代中。 3.故事太大:分解成更小的故事。 小的 史诗故事通常分为以下两种: 复合故事(compound story):由多个小的故事组成。 复杂故事(complex story):本身就很大且不容易分解的故事。一般采用探针实验。 对于太小的故事,不值得去写故事和评估,则可以将其合并到需要... (查看原文)
    LEON 2012-02-22 17:42:28
    —— 引自章节:第2章 编写故事
  • 第3章 用户角色建模 用户角色 用户角色(User Role)是一组属性的集合,这些属性刻画了一群人的特征以及这群人与系统可能的交互。 角色建模的步骤 通过头脑风暴,列出初始的用户角色集合 理想情况是项目启动时,把团队所有成员聚集在一起进行角色建模。每个人先在卡片上写下角色名称和自己的名字,然后把它们贴在白板上。放上新的角色卡片后,作者只说出新角色的名字,不做其他任何事情。无需对卡片进行讨论,也不要对角色进行评估。不需要让大家轮流给出新的角色。想到一个角色,就把它写到卡片上,直到很难再想到新的角色。一般不会超过15分钟。 对角色进行头脑风暴时,要坚持“已确认的角色代表的是单一用户”的原则。例如,公司作为一个整体是没法使用软件的,而应为公司的某种人。 整理最初的角色集合 移动卡片的位置,以表明角色之间的关系:对于有重叠的角色,根据重叠度的多少部分重叠或完全重叠。 一般而言,不需要也不建议建立系统角色,除非加入这个非人物的系统角色非常有助于思考系统。 整合角色 由卡片作者描述一下他们的角色名究竟代表什么,简短讨论后判断这些角色是否相同。 同时应丢弃那些对系统成功不太重要的角色卡。最后分类排列角色,以此展示角色之间的关系。 提炼角色 角色特征是关于同属于这一类的用户的事实或有用信息。例如: 1.用户使用软件的频率 2.用户在相关领域的知识水平 3.用户使用计算机和软件的总体水平 4.用户对当前正在开发的软件的熟悉程度 5.用户使用该软件的总体目标。有些用户注重使用的便捷性,有些关注丰富的用户体验,等等。 除了这些特征,应该考虑正在开发的软件,是否有一些对描述其用户有帮助的特征。 可以将特征注释在角色卡片上,并将卡片挂在团队的公共区域。 例子: 用户角色:内部招聘者 不是很擅长使用电脑,但是使用网络相当娴熟。不经常使用该软件,但每... (查看原文)
    LEON 2012-02-22 17:42:51
    —— 引自章节:第3章 用户角色建模
  • 第4章 搜集故事 引出和捕捉是不合用的 够用就行,不是吗? 即使无法为一个项目一次编写出所有的故事,我们还是应该在早期尝试编写我们可以编写的故事,尤其是那些容易被发现的故事(是否尽快实现是排优先级时的事),即便许多故事还只能停留在笼统的阶段,但大家至少应该展望未来一段时间的发布(3至6个月时间)。 方法 1.用户访谈 (1)访谈成功的关键之一是选择正确的受访者:访问真实用户和担任不同角色的用户。 (2)开放式问题和背景无关问题:要想获得用户的本质需求,最好的技巧是提问。 不好的版本1:你们想在浏览器上运行新的应用程序吗? 不好的版本2:你不会愿意为了让软件在浏览器里运行,而牺牲性能和丰富的用户体验,对吗? 好一点的版本:你想我们新的应用程序在浏览器里运行,而不是本地窗口程序吗?即使这意味着性能会有所减弱,总体上用户体验会差一些,交互也会少一些。 更开放的版本:未来让我们下一代产品运行在浏览器里,你愿意舍弃什么? (3)最好从背景无关的问题开始提问,这样就有可能从用户那里获得更多样化的回答。如果从非常具体的问题开始,则很可能漏掉很多问题。 2.问卷调查 适合于庞大的用户群,需要了解某些很具体的问题时。 鉴于单项沟通的既有特点和时间滞后,我不建议在捕捞故事时使用问卷调查。 3.观察 观察用户实际使用软件的情况,这个方法非常不错。但这种机会很少,除非是为内部开发。因此,如果有这种机会,千万不要错过。 4.故事编写工作坊 故事编写工作坊是开发人员、用户、产品客户和其他对编写故事有帮助的人共同参加的会议。建议在每次计划会议开始前举办故事编写工作坊,只编写尽可能多的故事,不排优先级。 首先确定从哪种用户角色开始,然后把简单的原型(开始可能只是一个空的方框)画在白板上,。随着参与者对用户在使用软件过程中可能要做的事情进行头脑风暴,不断地构建原型,并画出软件内部高层之间的交互。无需确定实际... (查看原文)
    LEON 2012-02-22 17:43:14
    —— 引自章节:第4章 搜集故事
  • 第5章 与用户代理合作 用户的经理 如果用户的经理不是软件的实际用户并干预产品功能的开发,首先不要得罪该用户经理,在部分围绕她的同时,想办法接触终端用户。 开发经理 让开发经理担任用户代理,是最坏的选择之一,除非你们开发的软件就是给开发经理用的。 销售人员 让销售人员充当用户代理是危险的,这会让大家对正在开发的产品没有一个全面的蓝图。然而,销售人员是非常好的中转站,应该让他们通过电话或销售拜访把你介绍给客户。 领域专家 领域专家很适合做用户代理,但要避免最终开发出来的软件仅仅针对那些与领域专家有类似水平的用户。 市场营销团队 他们可能更关注软件特性的数量而不是质量。他们可以为相关故事的优先级提供高层次的指导意 见,但他们往往不具备很好的洞察力,无法给提供故事的具体细节。 以前的用户 应谨慎考虑她的目标和动机是否与实际用户的完全一致。 客户 客户是那些做出购买决定的人,如果他们能与软件的最终用户做密切地交流,那么他们能成为非常好的用户代理。如果客户自己也是用户,那就是完美的组合。 培训师和技术支持 你的系统最终将只成为一个易于培训或只是使得技术支持工作变得较为容易,而不是功能最大化服务于最终用户。 业务分析师或系统分析师 不错的用户代理,唯一缺点是遇到问题喜欢空想,偶尔会在项目前期花太多时间做产品计划。 与用户代理合作时,做些什么? 能接触到用户但访问受限时:最好可以申请由部分用户组成一个用户顾问团队。 实在不能接触到用户时:必须求助于用户代理;如果有竞争产品,也可以用其做一些故事的来源。 可以自己来吗? 要避免陷入误区:我知道用户的想法,所以不需要或可以忽略产品的用户代理。 设立客户团队 1.邀请真是用户加入; 2.在客户团队中确定一位“项目负责人”(一般为产品经理); 3.确定项目成功必须的关键因素。 小结 开发人员职责 1.负责帮助组织机构为项目物色合适的客户... (查看原文)
    LEON 2012-02-22 17:43:32
    —— 引自章节:第5章 与用户代理合作
  • 第6章 用户故事验收测试 验收测试可以记录客户提出的一些假设,也提供了确认故事是否被完整实现的基本原则。 在写代码之前写测试 考虑每个故事,然后问类似下面的一些问题: 1.关于这个故事,程序员还需要知道什么? 2.对怎么实现这个故事,我的想法是什么? 3.有没有一些特殊情况会使这个故事有不一样的行为? 4.这个故事在什么情况会出错? 客户定义测试 客户可以和程序员与测试人员合作创建测试,但不要完全依赖程序员与测试人员,客户至少应该详细的指出一些测试,用以验证故事的实现是正确的。 测试是过程的一部分 一般情况下,产品经理和测试人员共同负责列出详细的测试。产品经理带来驱动项目的公司目标的知识;测试人员则带来怀疑的心态。 多少测试才算多? 只要这些测试还在继续为故事增加价值和使它更加清晰,客户就应该继续写测试。同时,一个优秀的开发团队会为很多详细的用例写单元测试。 集成测试框架 客户在每轮迭代时都执行以往迭代的所有测试时非常重要的,且递增的测试工作量要求开发团队应该自动化部分或全部验收测试。 集成测试框架 http://fit.c2.com 自动化验收测试工具:http://fitnesse.org 测试类型 在敏捷项目中,测试的目的是发现并消除缺陷,所以没有必要追求100%的代码覆盖率或测试所有的边界条件。我们运用我们的直觉、知识和过去的经验来指导测试。 开发人员职责 1.若团队觉得有需要,则负责实现自动化验收测试。 2.开始开发一个新的故事时,负责考虑更多的验收测试。 3.负责为代码作单元测试,使验收测试就不必顾及故事的每个细节。 客户职责 1.负责编写验收测试。 2.负责执行验收测试。 (查看原文)
    LEON 2012-02-22 17:43:45
    —— 引自章节:第6章 用户故事验收测试
  • 第9章 发布计划 以产品的开发路线图开始规划发布通常很有帮助,路线图展示未来几个新发布中关注的重点。这个产品的开发路线图毫无疑问会不断改变——这是我们所期望的,因为这些改变表明我们更加了解自己的产品、它的市场以及我们开发产品的能力。 我们想在什么时候发布 理想情况下,开发人员和客户可以谈一个日期范围,而不是一个具体日期。 希望在发布中包含哪些功能? 莫斯科(MoSCoW)规则: 必须有(Must have):系统的基本功能。 应该有(Should have):很重要但短期内有替代解决方法的功能。 可以有(Could have):如果没时间就可以在发布中不予考虑到功能。 这次不会有(Won’t have this time):客户期望拥有但同时承认需要在后续发布中实现的功能。 排列故事优先级 开发团队可以根据开发需要先排出故事的优先级: 1. 故事不能如期完成的风险 2. 推迟实现一个故事时对其他故事的影响 然后开始估算故事点,用户再结合故事点并结合以下3方面给出最终的优先级: 1. 故事对于官方用户或客户的重要性 2. 故事对于少部分重要用户或客户端重要性 3. 故事与其他故事的内聚性(例如,故事“缩小”会因为故事“放大”是高优先级而也变为高优先级) 混合优先级 如果用户在确定一下故事的优先级时遇到问题,则可以尝试分割这个故事。 高风险故事 在高风险故事和高价值故事之间,敏捷方法支持先做后者。 根据架构需要安排优先级 选择迭代长度 如果不确定迭代长度,请选择短迭代。短迭代使项目进度更加透明,虽然每轮迭代会有少许额外开销,但使用长迭代更容易犯错。 项目开发期间,尽量坚持固定的迭代长度。 从故事点到预计工期 总故事点 / 团队的速率 = 需要的迭代次数 初始速率 1.使用历史值 2.执行一轮初始迭代,使用那轮迭代的速率 3.猜测 猜测速率 如果故事点是一个理想工作日,... (查看原文)
    LEON 2012-02-22 17:45:00
    —— 引自章节:第9章 发布计划
  • 第11章 测量并监控速率 测量速率 不能将部分完成的故事也计算在速率中。用集中全部力量完成一个故事的方法会提高团队的意识:大家一起先完成一些故事比所有故事都只能完成一部分更有价值。 计算速率是用迭代开始前分配的故事点数,而不是迭代完成后这个故事实际用的点数。实际点数可以作为下次迭代时速率估算的调整参考。 计划速率和实际速率 为每轮迭代画出计划速率和实际速率的折线图。 迭代燃尽图 既可以从中了解到用已完成的故事点表示的进展,也可以从中了解到对发布剩余的计划故事点数的改变。 迭代中的燃尽图 最好是在完成任务时或者在每天结束时更新白板。应鼓励大家尽量准确地估算。让程序员觉得增加剩余时间估算和减少估算是一样正常的。 每日燃尽图反映的是剩余工作量,而不是在一个故事或任务上所花费的工作量。可能跟踪花费小时数有些好的理由(如比较实际和计划的时间以提高估算准确度,或监测每个星期所花的生产时间)。然而这些好处远远不能抵消记录花费时间所带来的负面作用(如开发人员会觉得被管得很严,很死,以及这些数字并不准确)。 一个很有效的方法是把本章中所有的图做得很大并且放在大家都可以看见的地方,比如墙壁或大的白板上。 小结 完成一个任务或故事所花费的实际小时数对当次的速率没有影响。 每日燃尽图在迭代中十分有用,它展示了迭代中每天剩余的小时数。 设计及检测一个平均每个故事点出现的缺陷数目的图表可以帮助我们发现团队速率的提高是不是以牺牲质量为代价。 开发人员职责 尽量在完成一个故事后再去做下一个故事。我们更希望看到少量已完成的故事,而不是较多未完成的故事。 经理或者极限编程项目中的追踪者,应知道怎样以及在什么时候画本章中的这些图。 客户职责 知道团队的速率 知道实际速率和计划速率的差别和是否需要调整计划。 为发布添加或删除故事,以确保团队在种种限制条件下尽量多实现项目目标。 (查看原文)
    LEON 2012-02-22 17:45:36
    —— 引自章节:第11章 测量并监控速率
  • 用户故事描述了对用户、系统或软件购买者有价值的功能。用户故事由以下三方面组成: (查看原文)
    Lirio 2017-09-19 22:31:44
    —— 引自第4页
  • 一份书面的故事描述,用来做计划和作为提示; (查看原文)
    Lirio 2017-09-19 22:31:44
    —— 引自第4页
  • 有关故事的对话,用于具体化故事细节; (查看原文)
    Lirio 2017-09-19 22:31:44
    —— 引自第4页
  • 测试,用于表达和编档故事细节且可用于确定故事何时完成。 (查看原文)
    Lirio 2017-09-19 22:31:44
    —— 引自第4页
  • 用户可以在网站上发布简历。 (查看原文)
    Lirio 2017-09-19 22:31:44
    —— 引自第4页
  • 1. 通过头脑风暴,列出初始的用户角色集合 (查看原文)
    Lirio 2017-09-21 18:36:42
    —— 引自第28页
  • 2. 整理最初的角色集合 (查看原文)
    Lirio 2017-09-21 18:36:42
    —— 引自第28页
  • 3. 整合角色 (查看原文)
    Lirio 2017-09-21 18:36:42
    —— 引自第28页
  • 4. 提炼角色 (查看原文)
    Lirio 2017-09-21 18:36:42
    —— 引自第28页
<前页 1 2 后页>