Post on 08-May-2015
description
敏捷需求分析和管理 用户故事方法
© ThoughtWorks 2009
钱安川 �
ThougtWorks高级咨询师、敏捷教练、资深讲师、Team leader、Developer
Beijing-open-party组织者&主持人
Email: qiananchuan@gmail.com
Blog: http://qac.blogbus.com
© ThoughtWorks 2008
软件开发的秘密�
除了需求分析和编码之外, 瀑布过程中的每一个步骤都是浪费。──Mary poppendieck
© ThoughtWorks 2008
软件需求面临最大的问题是什么?�
交流问题!�
需求从哪里来?�
© ThoughtWorks 2009
市场� 客户�
需求的获取�产品研发 - 市场部门�
谁是产品的用户�
产品的目标是什么�
产品的竞争对手分析�
投资回报分析�
产品用户角色建模和交互设计�
产品界面原型�
⋯⋯�
项目开发 - 客户�
谁是项目的用户�
项目的业务目标�
项目的投资回报分析�
客户当前的过程�
客户未来的过程�
⋯⋯�
© ThoughtWorks 2009
软件行业40年多来,需求分析技术已经
很成熟了,但是。。�
© ThoughtWorks 2008
需求文档驱动的过程不堪重负�
© ThoughtWorks 2009
Business IT
End user
敏捷需求分析和管理过程�
© ThoughtWorks 2009
项目启动�
第一次发布� 第二次发布� 第三次发布�
需 求 分 析 和 管 理�
时间
迭代
敏捷需求管理贯串项目始终:�
• 初始阶段 – 识别需求,仅供估算项目规模使用,“快速启动”;�• 发布计划阶段 – 高风险的需求进行可行性分析⋯⋯�• 迭代计划阶段 - 需求细化⋯⋯�• 迭代实施阶段 - 反复验证需求并确认需求被实现⋯⋯�• 每个迭代 - 纳入新需求,重新审视需求列表及优先级,调整计划⋯⋯�
项目启动阶段�
目标和交付物� 项目愿景和动机� 快速产出可以开始开发的需求列表� 确立可视化项目原型� 了解技术风险� 估算项目成本� 制定发布和迭代计划�
轻量的,可视的文档�
© ThoughtWorks 2009
我觉得我们已经达成一致了�
啊?
哦!
现在我们达成一致了!�
财务模型�
项目启动阶段交付物� 业务流程� 架构原型�
界面原型�
功能分解图�
需求如何表述?�
© ThoughtWorks 2009
用户故事卡片�
© ThoughtWorks 2009
#102 注册用户
作为 用户�
我想要 我的用户资料被系统记录下来�
以便 我能享受到个性化的待遇�
H 2
估算 优先级
用户故事的3C原则�
Card �用户故事卡片本身代表了需求的存在�
Conversation�用户故事所代表的一段对话和交流�
Confirmation�用户故事的确定性�
© ThoughtWorks 2009
用户故事XYZ表述�
X:用户角色�作为 。。。�
Y:目标系统提供的行为或功能�我希望 。。。�
Z:实现的业务价值或目标�以便于 。。。�
© ThoughtWorks 2009
角色流程(Role-Process)方法�
© ThoughtWorks 2009
输入查某本书的条件�
执行查询� 浏览查询结果�
是否查到?�
加入购物车�
是
否
结算�是否继续购买?�
角色流程(Role-Process)方法�
© ThoughtWorks 2009
输入查某本书的条件�
执行查询� 浏览查询结果�
是否查到?�
加入购物车�
否
查看购物车�是否继续购买?�
1
2 3
是
否
用户故事�
1. 作为用户,我希望能够通过书名和作者名查找书籍,以便我能快速的购买我想要的书�
2. 作为用户,我希望能够把我感兴趣的书籍加入购物车,以便我能够批量购买�
3. 作为用户,我希望能够查看我目前购物车内的书,以便我做出购买决定�
© ThoughtWorks 2009
INVEST原则�
Independent 可以独立开发�
Negotiable 可以协商�
Valuable 有价值�
Estimable 大小可评估�
Sized appropriately 合适粒度�
Testable 可测试验证�
© ThoughtWorks 2009
需求的分解�
© ThoughtWorks 2009
开发任务�
用户故事�
特性�
模块�
产品� 电子商务系统�
电子商务模块�
购物车�
添加到购物车�
查看购物车�
更改数目�
计算总额�
在线支付�
产品列表�
财务账务模块�
User Story的逐步细化�识别需求阶段: 仅供项目规模估计使用�
发布计划阶段: 高风险需求细化以便更好理解�
迭代计划阶段: 需求细化和明确到可在一个迭代中实现�
迭代实施阶段: 从业务角度如何判别需求已经完整实现�
© ThoughtWorks 2008
非功能性需求�
Accessibility 可用性�
Archiving 归档�
Auditability 可审计性�
Authentication 安全认证�
Authorization 授权�
Localization 本地化�
⋯⋯�
© ThoughtWorks 2009
验收条件 (Acceptance Criteria)�
如何验收用户故事?如何确定Story已经被开发完成?如何进行估算?�
验收条件� 具体属性� 功能性验收条件� Happy Path/Sad Path方法�
非功能性验收条件�
© ThoughtWorks 2009
需求如何管理?�
© ThoughtWorks 2009
用户故事生命周期�
© ThoughtWorks 2009
• 业务分析师细化功能需求�• 与客户讨论、验证业务目标是否满足�• 与开发团队讨论、实现可行性�
• 业务分析师与质量分析师一起验收测试�• 向客户演示,客户验收�即使满足了之前与客户商定的方案,但验证时如果业务目标没被满�
足,就要重新与客户讨论、分析直到满足业务目标,该需求才算完成�
• 业务分析师随时回答开发人员的疑问�• 需要时再向客户澄清、确认�• 开发完成后,业务分析师做第一手测试�
等待分析�
第X�迭代�
迭代过程中,分析师怎么做?�
正在分析�
正在开发�
正在测试�
正在验收�
验收完成�
可视化管理�
来自于精益生产的看板管理(Kanban Management system)�
目的是为了增强管理的透明性,鼓励每个人都去发现问题和解决问题,而不是等待别人来做�
© ThoughtWorks 2009
需求管理的可视化�
© ThoughtWorks 2009
Mingle中的Story Wall�
© ThoughtWorks 2009
敏捷需求分析师必读�
《User Stories Applied: For Agile Software Development》by Mike Cohn
《金字塔原理:思考、表达和解决问题的逻辑》(麦肯锡40年经典培训教材)
© ThoughtWorks 2008
谢谢�
© ThoughtWorks 2009