敏捷开发需求管理实践.pptVIP

敏捷开发需求管理实践黄河敏捷案例

故事估算用户故事故事地图优先级技巧故事交付

用户故事01

什么是用户故事

UserStory是用户需求的简化表达，用一两句话表达出完整的想法。它只要求写下最有价值不能被忘记的东西，而这些内容足够帮助估算工作量以及与客户、Devteam沟通。虽说是简化表达，但要求展示出该需求的角色、功能、价值，相当于一个简化的用户场景，避免不自觉地从自我出发，以为其他人想的都跟自己一样，你认为的就是别人认为的—同理心。Userstory

3CCardConversation交流Confirmation确认格式Asa[auserrole],角色Iwantto[accomplisharesult],功能Sothat[Icangetsomebusinessvalue].价值例子：作为一个直播手机用户，我想要在主播共享屏幕的时候，能听到主播的声音以便接收到完整的信息Userstory你们不用管为什么这样做，和你们说也不懂，只要实现好就可以了

Independent独立Negotiable可协商Valued有价值Estimable可度量/评估SizedAppropriately大小适中Testable可测试INVEST

渐进明细当前迭代US的粒度与工作量都相差不多粒度足够细，以至于可以省略设计环节UserStory粒度EpicThemeThemeUserstoryUserstoryUserstoryUserstoryTaskTaskTaskTaskTaskTaskTaskTaskTaskTaskTaskTaskMonthsWeeksDaysHoursBiggerthanareleaseBiggerthanaSprintSprintreadyTasks

作为一个驾驶员，我希望手机导航能进行语音播报，以便我更方便地使用导航作为一个驾驶员，我希望手机导航能进行语音播报，以便我在驾驶的过程中更安全地使用手机导航作为一个路痴（远行）的驾驶员，我希望手机导航能用语音播放方向指示，以便更安全地通过手机导航了解下一步行驶方向举例

如何编写验收准则

从聚焦做什么到如何做作用：确认理解需求、设计、识别依赖、估算准确ATDD的前提格式：Given:[apre-condition]前提，假定When:[userinputs]输入Then:[usergetsexpectedresults]输出注意：AC是团队写的，确保理解需求AC可以直接作为验收用例团队做出承诺前写验收准则

验收准则容易疏忽的问题：功能的负面场景用户故事对其他功能的影响用户体验问题性能问题功能系统不能和不应该做的事验收准则

举例AC1：Given：基于web的登录界面When：我输入正确的用户名/密码Then：我可以登录并且进入系统AC2：Given：基于web的登录界面When：我输入错误的用户名/密码Then：我会收到弹出信息“错误的用户名或密码，请重试”AC3：Given：基于web的登录界面When：当我选择“记住我”Then：我下次登录的时候就不需要再次输入用户名和密码AC4：Given：一个移动设备登录界面When：我输入错误用户名/密码超过3次Then：锁定用户，并提示请1小时后重试Userstory：作为一个web用户，我想要在登录时做认证，以便我可以安全的访问系统

用户故事在什么时候确定？谁来写更合适？验收准则在什么时候确定？谁来写更合适？思考

故事估算02

估算原理

AbsoluteEstimationVS.RelativeEstimation绝对值估算VS.相对值估算估算是永远不会准确的，更推荐相对估算Just-In-Timeplanning只估算当前迭代的终极目标是不做估算！注意：估算的是功能，而不是任务！工作量！=时间只有已完成的工作才能用于度量进展估算原理

休假开会任务切换处理邮件修改当前发布的bug为当前的发布提供支持……工作量！=时间

故事点是用于表达用户故事大小的度量单位。定义用户故事的大小并没有固定的公式，更确切地说，对故事点的估算需要综合开发该功能所需的工作量、开发工作的复杂性以及蕴藏的风险等方面。故事点是相对的A项目故事点≠B项目故事点当我们使用故事点进行估算时，会给每个对象分配一个点值，我们分配的原始估算值本身并不重要，重要的是点值的相对大小。使用故事点估算

敏捷团队里面强调我们是一个整体；多个值会增加一次发布进行计划所需的工作量。例如：一个用户故事，需要程序员4人天，测试人员2人天，产品负责人3人天，那么该用户故事应该是9个理想人天，而非分开的每个角色一个估算值。如果分开会大大增加一次发布进行计划所需的工作量，跟踪不同角色的速度和剩余工