Scrum实施指南-V0.1.docx

《Scrum实施指南-V0.1.docx》由会员分享，可在线阅读，更多相关《Scrum实施指南-V0.1.docx（9页珍藏版）》请在第一文库网上搜索。

1、Scrum实施指南编制：项目管理中心审核：批准：1 .总则31. 1.目的32. 2.适用范围32 .准入标准33 .输入项34 .角色与职责35 .敏捷过程55.1 发布Release计划55. 2分析55. 3构建55. 3.1 冲刺计戈ij会议(SprintPlanning Meeting) 65. 3. 2 每日站会 (Daily Stand-Up) 65. 3. 3 冲刺演示 (Sprint Review) 75. 3. 4 冲刺回顾会(Sprint Retrospective) 75.4 Release集成测试与发布75 . 5生产部署86 .输出项87 .准出标准81.总则1.1

2、. 目的本文描述了在敏捷项目管理过程中的各项过程及流程，公司内部敏捷项目可参照本制度根据项目需要进行裁剪，实施项目敏捷管理。1.2. 适用范品本管理过程适用于公司内部信息类应用敏捷Scrum框架的项目o2 .准入标准已获取研发需求。3 .输入项 需求，期望 产品待办列表 每个Release或Sprint的验收标准4.角色与职责角色职责产品负责人Product Owner(PO) 提供路线图和愿景，协调和优先处理来自客户或业务方的需求，并进行排序.把控产品需求，组织召开需求评审会，明确需求 在计划会议上将需求完整地传达给开发团队 对产品待办列表的用户故事进行排序，最好地实现目标 在冲刺迭代开始时

3、从产品代办事项中选出优先级高的进入冲刺待办列表 在冲刺计划会上对冲刺待办列表的用户故事及如何验收讲解清楚，并在评审会议负责验收 确保产品待办列表对所有人可见、透明、清晰，并且显示Scrum敏捷教练Scrum Master研发团队Team团队的下一步工作 确保开发团队对产品待办列表项有足够的理解 想改变某项的优先级必须先经过产品负责人 为保证产品负责人的工作顺利进行，组织中的所有人员都必须尊重他的决定。产品负责人所作的决定通过产品待办列表的内容和排序来表达。 维护冲刺列表sprint backlog 帮助团队利用看板对每日工作进行监控，促使团队每天报告和更新用户故事的状态 与团队成员一起在整个开

4、发过程中识别问题与风险，并且与团队成员共同商讨解决 确保每日站立会召开以评审sprint状态 编辑或评审每周状态报告 促进与团队和产品所有者的冲刺评审会议，以评审sprint中构建的功能 帮助移除开发团队工作中的障碍 引导和检查开发进度；约束不规范的行为 帮助团队成长，提交开发效率 激励团队了解项目的方向，目的和重要性 分析需求并与P0进行确认 建立设计文档 构建功能 执行评审活动 执行测试工作 参加四个会议。在冲刺计划会议上承诺在本次冲刺要开发的用户故事，每天站立会上更新开发进度，在评审会议上给产品负责人P0演示承诺的用户故事，配合敏捷教练SM完成回顾会议。 遵循所有架构标准，以保持质量，并

5、最大限度地减少技术债务每个冲刺Sprint交付潜在可发布并且“完成”的产品增量5. 敏捷过程5. 1发布Release计划发布计划使用相同的预先计划过程进行更深入的迭代，但对于已批准的工作，它将以更细粒度的级别进行迭代。计划采用的是高层级功能集，并在与客户确认需求的同时，使用对史诗和高层级故事的假设将其分解。然后将明确的工作范围划分为预定的版本，并分配给交付团队。发布计划通常范围在3-6个月，并且是2-4周的迭代过程。当业务方/领导层/利益相关方团队希望根据收集到的想法和需求来生成一个生产版本时，产品负责人将基于此创建产品/发布待办项列表以及发布日程表，并获得业务方/领导层/利益相关方的批准。

6、产品/发布待办项列表按以下三点：紧急，重要性和难度进行优先级排序。5.2 分析分析阶段强调对批准的项目进行澄清，提供定稿的用户故事和详细设计方案。它也标志着状态报告的开始。在分析阶段，BA需要将Epics和高层级用户故事，分解为“待开发”的用户故事。并将这些添加到待办项中以供稍后在sprint中使用。此活动包括与产品负责人会面，并根据需要与技术专家合作，以编写详细的用户故事和准确的验收标准。创建初稿故事后，产品负责人或相关干系人需要对故事进行评审，以确保功能被正确表述。“待开发”的用户故事应该具备： 需求描述清楚 任何测试人员都明确验收标准 排到一个迭代的日程上 已由P0或相关干系人评审 已由

7、架构师或技术负责人评审(可裁剪)5.3 构建此阶段是敏捷Scrum的基本流程，可在2周的开发冲刺(Sprint)中选择要开发的用户故事，开发代码进行评审，执行测试并报告状态。基于业务逻辑和UI原型，每个开发团队都会准备自己的开发冲刺待办列表(Sprint Backlog)。开发冲刺待办列表中的每一项需要估算到1-32人时(不超过32)。可以基于分析迭代中编写的测试计划来准备测试用例。在冲刺末期，开发冲刺待办列表中的每一项的测试结果都需要验证，并且是已完成。每个冲刺结束的时候需要进行”演示(Demo)”会议。每个冲刺(Sprint)通常持续2-4周。通过下面的子章节描述构建阶段的四个代表仪式：5

8、. 3. 1 冲刺计划会议(Sprint Planning Meeting)团队参加冲刺计划会议来评估和估算用户故事。在这个会上，可以进行详细的估算,并且可以识别并讨论将要开发的用户故事。冲刺计划会议在每个冲刺开始时进行，目的是评审当前冲刺的用户故事列表，确定当前冲刺的容量或资源可用性，并为开发和测试分配用户故事。 产品负责人P0必须参加 每个团队成员都必须参加 会议结果要记录在冲刺待办项列表 整个团队要在会议过程中对决议达成一致 P0决定/认可用户故事的优先级排序 每个用户故事都应该估算 会议控制在2-4小时5.3.2 每日站会(Daily Stand-Up)为了保持冲刺的快节奏，团队要每天

9、召开站立会，并覆盖以下内容： 昨天的进展 项目的阻碍/困难 今天的目标 站立会要简明扼要，重点关注项目的阻碍/困难。在这个会上，开发负责人/敏捷教练(Scrum Master)要确定需要他们协助解决的关键团队需求 每天召开或每周几次(要固定频率) 敏捷教练和团队成员必须参加 建议相同时间和地点 站会不超过15分钟5.33冲刺演示(Sprint Review)在每个冲刺sprint结束时，团队要进行演示，来展现在当前冲刺期间完成的功能。当某个特定的用户故事完成后，也可以安排在冲刺期间进行演示。根据项目的情况可以向内部产品方，或高层领导，或客户方进行演示。 在每个冲刺结束时或特定用户故事结束时进行

10、 重点看“完成了什么” 对照查看冲刺计划 仅演示已完成的内容 所有相关干系人都可以选择参加 要接收演示的反馈5.3.4 冲刺回顾会(Sprint Retrospective)召开冲刺回顾会旨在评估项目绩效并识别改进机会。该会议要限定讨论范围并由团队成员来引导，保证每个人都参与进来。会议上主要是讨论后续的冲刺中要继续保持的活动，要停止的活动以及为提高整体项目绩效而需要关注的活动。 在每个冲刺结束时进行 重点看“完成的怎么样” 检查并使之适应开发流程 项目团队讨论哪些方面做得好及哪些方面可以改善 敏捷教练和团队成员必须参加。产品负责人可以选择参加 每个人都要发言 只有收到会邀的人才能参加5. 4

11、Release集成测试与发布该阶段涉及从构建到生产运行的过渡，各个冲刺已完成功能的集成测试，确认最终的缺陷及发布清单，与相关干系人协调完成项目的交付。包含但不限于以下活动： 进行功能测试，回归测试 识别缺陷提交给开发人员修复并再次验证 验证非功能性需求是否满足 验证功能性符合预期满足需求 与相关干系人协调解决缺陷 准备最终的发布清单 确保环境等已配置5. 5生产部署该阶段完成代码上生产环境的最后移交部署。包含但不限于以下活动: 识别生产环境的缺陷并判断影响（高/中/低） 根据需要支持生产环境的相关活动 创建并排序由于修复缺陷引发的代码变更等用户故事 用户故事要由产品负责人决定优先级 完成其他所需的文档工作6. 输出项 产品待办列表 冲刺待办列表 冲刺回顾会议纪要 燃尽图 冲刺看板/白板7. 准出标准项目所有资料都已归档