网站大量收购独家精品文档,联系QQ:2885784924

敏捷开发过程概览.docx

  1. 1、本文档共19页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
Scrum敏捷开发过程实战 产品级,大团队的敏捷实战方法 需求结构化 需求描述 版本规划 迭代计划 日常活动 团队建设 与传统灌输理念的培训不同,此实战培训中不只包含“按客户价值进行优先级排序”“利用自组织团队发挥主观能动性”等含糊的指导性思想,更在每个阶段均介绍一种或多种直接可以使用的方法来完成落地。 按照实际项目的开发顺序,培训分为三个环节,其主要内容如下: 需求结构化与需求描述(主要受众为产品负责人Product Owner、团队骨干) 将产品愿景转换为可实现的业务需求; 将高层业务需求分解为具备层级结构的需求树; 编写用户故事,面向用户使用场景而非产品功能描述单条需求; 版本规划与迭代计划(主要受众为产品负责人、Scrum Master,团队骨干) 在宏观层面上,确认整个产品中所有子系统的优先级,并将其顺序计划到版本和迭代中; 在微观层面上,利用Scrum计划会估算每个迭代中任务的工作量; 日常活动与团队建设(主要受众为Scrum Master,团队成员) 日常活动中,利用每日立会、故事板、看板跟进开发进度; 团队建设中,利用自组织团队、松结对编程等方法建立师徒制度,在实际工作中培养队员; 在大型、跨职能团队研发时的团队结构与工作方式 附:敏捷设计与工程实践(仅出现于3天培训中,主要受众为团队成员及技术管理者) 如果从用户故事经过简单设计得到代码结构 如何利用用户故事来产生、管理测试用例 如何利用用户故事来管理变更、缺陷和客户反馈 课程将围绕每个小组实际工作中各自产品或项目的自身需求展开,通过对其进行结构化、用户故事化、用户建模、模拟计划会估算、设定验收标准等,从而演练Scrum各个环节所需的技能。知识及案例讲解约占70%,实际练习约占30%。 注:本大纲中以一个易于理解的电子商务系统的研发为例,实际应用时可应用于银行、电信、政府、电子商务、互联网社区娱乐、仪器仪表等各种主流行业。 ×××××××××××××××××××××××××第一天×××××××××××××××××××××××××××××× 概述 本阶段培训通过简短介绍,让学员大致了解敏捷开发的历史及其尝试解决的问题。 敏捷开发尝试解决的问题 Scrum及其历史 产品负责人 Product Owner 产品负责人团队 产品负责人的职责 现场演练:分组并推选Product Owner 第一阶段:需求结构化与需求描述 本阶段培训旨在从头到尾打通需求,即从感性的产品愿景分解到可供开发的具体需求条目。 传统敏捷开发使用“条目化”的方法来表达需求。但具体分解和描述需求的方法停留在“每个故事交付一个客户价值”“从客户价值角度描述需求”等非常含糊、难以落地的层面上。这导致分析所得的需求个体差别很大,难以作为大型、长期产品研发的正式工程文档。 本课程引入了QUML作为分界用户故事的基础,通过三层需求完成从产品愿景到可开发任务的分解: *配图中的三层分解流程见下文分步描述。 三层需求分别为业务愿景(左上图),业务操作(左下图中的方框,即史诗故事),业务数据(右侧三张图中的椭圆,即用户故事)。 这就解决了传统敏捷开发中存在的以下问题: 最初的产品愿景与割裂的用户故事之间缺少必然联系 大量用户故事之间缺少清晰的结构 用户故事颗粒度大小不一 此外,这种体系下建立起来的“用户故事树”(需求树)还能: 直接分配到开发任务中 直接生成代码结构 直接用于结构化管理变更、增强、重构、缺陷等 直接与测试用例匹配 而为一人年的工作量进行这种需求分析,只需要1小时左右。 第一步:业务愿景——利用“角色-业务图”来支撑产品愿景 愿景(Vision)是用户对产品的核心期望。 培训中使用“角色-业务图”(简称RB图)来表达和落实愿景。 比如在配图中:“购物子系统”核心愿景是“建立一种有保障的网上购物方式”;图中使用“确认收货-转账”的第三方监管业务实现。这样软件开发人员就能得到确切的技术方案,而不是面对描述非常虚的愿景;而技术方案实现后,又能支撑愿景。 有了愿景,产品就不会简单停留在“能用”的状态,而是要积极增加可以实现愿景的功能。 现场演练与指导:建立角色业务图(20分钟) 案例分享:RB图详细规则与最佳实践 第二步:业务数据——利用“实体-关系图”发掘业务数据 此内容将客户愿景转化为“对某些的业务数据的操作”,从而逐渐进入开发人员可理解的范畴;同时业务数据还是早期功能点估算的核心元素。 具体分析工具是实体-关系图(简称ER图),而业务数据对应其中的实体(图中方框)。 实体-关系图(教学过程中进行了简化)中分析了实体及其依赖关系,通过适当定义,不但可以保障不会遗漏实体,甚至能直接协助进行早期估算和部分设计工作。 重要!在敏捷开发中,我们将业务数据作为史诗故事进行开发。 比如在配图中,所有实体(5个矩形)均

文档评论(0)

希望之星 + 关注
实名认证
内容提供者

我是一名原创力文库的爱好者!从事自由职业!

1亿VIP精品文档

相关文档