STORY方法.ppt

软件公司敏捷项目STORY课程胶片 目录 STORY的定义 一个用户STORY描述了一个对客户有价值的、简单的、端到端的功能点。 STORY可以理解成能独立交付，能够感知的最小需求。 Story是什么？ Story描述了对于系统或软件的客户或用户有价值的功能片段 Story由三个方面组成 一个书面的Story简短描述，用来做计划并在开发过程中起到提醒的作用 针对Story描述进行的交流，用来澄清Story的细节 记录和传递细节的测试信息，用来确定Story是否开发完成 沟通之道 基于我们手头能够掌握的信息来做决策，并且加快决策的频度。 与其在项目开始的时候就做出巨细无遗的完美决策，不如我们把做决策的时机分散在整个项目开发周期中。 为了做到这一点，我们必须确保我们有方法在适合的时间，获取到尽可能及时准确的信息。 STORY的特征 为什么Story应该是相互独立的 尽可能的避免在Story之间引入依赖关系，因为 依赖关系会导致优先级和计划的问题 Story之间的依赖还会使估计工作更加困难 复杂系统的依赖关系不可避免 独立性的引申意义：好的Story划分应该使开发人员在安排计划的时候，可以更加灵活，方便地进行调整 独立的 – 举例 假设 下面是“无线路由猫” 的一组关于带宽控制的Story： 用户可以根据IP地址来限制对应上网终端的带宽 用户可以根据MAC地址来限制对应上网终端的带宽 用户可以根据局域网端口来限制对应上网终端的带宽 假设开发人员估计支持带宽控制类型（随便哪种）需要5天的工作量，然后第二和第三种各1天，哪个Story应该是5天完成的呢？ 很难估计这种内容性依赖Story —— 先后次序相关 形成独立的Story的方法 要防止这种类型的依赖性，可以采用下面两种方法： 1. 将相互依赖的Story组合成一个更大的但是相互独立的Story 组合成一个大的Story“用户可以限制上网终端的带宽” ，开发时间小于迭代周期 2. 用以功能增强的方式拆分这些相互依赖的Story 如果组合的Story超出了一个迭代周期，以功能增强的方式更合适 用户可以根据IP地址来限制对应上网终端的带宽 用户可以根据其他方式（MAC/局域网端口）来限制对应上网终端的带宽 或者：根据不同顺序给出两个估计值 形成独立的Story的方法 – 临时解耦 对于相对比较松散的数据依赖，可以采用临时解耦的方式来暂时解除依赖 临时解耦：对于共享数据的不同Story，以临时的数据配置和读取接口来临时解除Story之间数据的依赖关系。 注意：当这些Story都完成后，需要去除临时接口，并更新相关测试 以少量附加工作量来换取更大灵活性 原则：Story卡上的文字是为了沟通交流而存在 右边描述是合适的，用于讨论足够了 开发Story时，开发人员知道当初做出的决策是可以根据IP，MAC和局域网端口来限制带宽，但是还有个遗留问题，需要进一步和客户交流 Story卡上的注释可以帮助开发人员和客户从以前交流的基础上继续交流 反例 过早的确定细节会妨碍交流! 简单描述-从抽象到具体-抽象思考更重要! 高层抽象时，细节只是干扰 问题：思维惯性 -这么细的需求不需要讨论了！ 引入不合理的假设： 登录用户名必须为admin的话，那还需要用户名做什么呢，只需要一个进行密码验证就可以了。 或者是否允许多个用户账号登录？ 回归本源：Story是支持交流的工具 Story的内容应该包括： 少量的简洁的语句用作关键内容的提示 关于需要在交流中解决的问题的注释 细节-测试信息 Story卡的背面的测试点 临时记录（白板，笔记，IT工具，Wiki） 小结 理想情况下，Story之间应该相互独立。有时候这是不可能的（特别是大型复杂系统），但是从其引申意义来说，好的Story划分应该使开发人员在安排计划的时候，可以更加灵活，方便地进行调整 Story的细节是通过客户和开发人员之间的沟通得到的 Story对于客户或用户的价值应该是清楚的。达到这个目的最好的方式是客户来编写这些Story Story可以包含一些关键点的注释，但是太多细节会反而会导致Story的意图变得模糊，并且会在开发人员和客户沟通的时候造成没必要进行沟通的印象 针对Story的验收测试点是对Story进行注释的最好方式之一 太大的Story不利于迭代计划和工作分配，混合和复杂的Story可以拆分为多个更小的Story 太小的Story可能会降低效率，所以多个微小的Story可以合并为一个更大的Story Story必须是可测试的 Story不能包打天下 你需要采用不同于Story的方式来表达某些需求 用户界面指导原则经常用包含了大量屏幕截图的文档方式进行描述 重要的系统之间的接口说明 如果你发现系统某方面