敏捷需求人.pptxVIP

敏捷需求人 王春光 wangcg@ 课程目标 提纲 需求现状 搭建需求人能力模型 理解敏捷需求开发的思想 课程总结 需求现状_1 除了需求分析和编码之外，瀑布过程中的每一个步骤都是浪费！ 需求现状_2 需求现状_3 错误需求缺陷的放大过程 “需求人”的能力模型 腿：技术理解能力，架起需求与开发的桥梁；方案创新能力，不创新需求，走创新解决方案之路； 心：沟通能力，是做好需求的核心能力； 脑：业务分析能力，引导产品实现业务价值，去伪存真。是需求工作的重中之重； 手：需求管理能力，在有限的条件下交付出有价值的需求子集； 敏捷需求开发_1 敏捷软件开发宣言 个体和互动 高于流程和工具工作的软件 高于详尽的文档客户合作 高于合同谈判响应变化 高于遵循计划 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。 欣然面对需求变化，即使在开发后期也一样。 为了客户的竞争优势，敏捷过程掌控变化。 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。 业务人员和开发人员必须相互合作，项目中的每一天都不例外。 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。 可工作的软件是进度的首要度量标准。敏捷过程倡导可持续开发。 以简洁为本，它是极力减少不必要工作量的艺术。 最好的架构、需求和设计出自自组织团队。 团队定期地反思如何能提高成效，并依此调整自身的举止表现。 敏捷需求开发_2 敏捷宣言遵循的原则 敏捷需求参与者 角色及职责 传统的需求参与 敏捷的需求参与 用户/客户 需求的提供者 需求演进的参与者 用户的主要参与方式 陈述 遵循游戏规则的积极的交互参与 BA 需求的定义者 需求的组织者 BA的主要参与方式 前期的调查获取和整理成文档 参与全周期的迭代与演进 开发 需求的接受者和实现者 场景拟合者与改进者 开发的主要参与方式 被传导需求并使之功能化 完成完整的业务场景实现 测试 功能测试者 场景测试者（需求测试者） 测试的主要参与方式 找出软件的显性的bug 找出不满足需求逻辑和不能拟合场景的缺陷 敏捷需求分析的特征对比 角度 传统需求分析 敏捷需求分析 需求分析时机 更多地集中在项目早期 近乎均匀地贯穿于项目的整个生命周期 需求划分单位 基于功能分解，划分模块或子系统，一个模块或子系统的颗粒度通常较大 基于能否独立业务价值，切割成一个个用户故事，一个故事有时会跨越传统的模块或子系统边界；用户故事是小粒度的，可测试的，可见的，并且是有价值 需求细化过程 一步到位，可供开发人员设计开发 逐步细化，仅就下一个迭代需要实现的部分进行详细分析 需求文档要求 正式文档，往往有明确的格式要求。既作为设计开发人员必须严格遵守的规约，也作为向客户提交的必备产出物之一。难维护，难验证（跟踪），很多产出物最终难以被阅读。 非正式文档。仅仅是辅助开发团队与客户沟通，不作为规约，也不作为必备产出物。更多强调通过自动化功能测试用例来跟踪系统需求。（对于组织过程资产管理要求，可以在此基础上形成可阅读可理解的轻型文档）。 需求文档同步 项目中后期一般都处于不同步状态 即时的同步 需求传递过程 单向的陈述与记录，文档传导（线性的传递，误导放大，缓慢） 聚议，共同参与，业务场景与用户故事，及时的非正式沟通 应对需求变更 有严格的控制流程，视变更为风险 视变更为必然或预期中的事情 总结 敏捷过程是一种结合管理理念与工程方法的最佳实践，它关注人的价值，倡导客户合作与响应变化，是持续过程改进的最有效途径之一。 敏捷过程意味着全过程的敏捷，而不仅仅只是片面理解只局限于开发环节。 敏捷需求分析构成了方法体系的重要因素，它以沟通、迭代、响应变化、独立业务价值导出的可见的用例等特征，贯穿于产品全生命周期。