中国国有银行敏捷开发点总结V2.pptx

敏捷开发试点工作汇报 试点团队：电子商务开发团队 试点项目小组：善融商务个人商城手机客户端小组 试 点 牵 头 人汇 报 人：Allen Zhang 张 明 中国**银行股份有限公司 Page  2 中国**银行股份有限公司 Page  3 中国**银行股份有限公司 主站组 营销平台组 手机客户端组 购物中心小组 商户中心小组 商户中心小组 （7人） 购物中心小组 Page  4 中国**银行股份有限公司 优先级、情景化、子任务化 可视化监测开发进展状态和健康度 沟通、互动、协作 跨部门、跨职能、提升协调力 小步、快跑、不贪多、只求快 尽早发现小问题、杜绝大问题 注*Scrum：一种敏捷的项目管理方式。敏捷开发主要有两个流派，一个是Scrum，一个是XP。Scrum偏重于过程，XP偏重于实践。Scrum是橄榄球的一个专业术语，表示“争球”的动作，比喻团队在开发一个项目时，大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它。 XP：极限编程(eXtreme Programming)。 Page  5 中国**银行股份有限公司 注*Scrum Master是负责一个team按照Scrum方式运行的角色。职责包括更新backlog, 主持plan meeting, 主持stand up meeting, 主持retrospective meeting, 提交team velocity, burn up chart, burn down chart. Page  6 中国**银行股份有限公司 遗留缺陷 需求变更 中国**银行股份有限公司 Page  7 选择能在2~3周之内完成的用户故事量作为本次迭代的目标，小步快跑 充分估计所选用户故事的需求变更风险性和技术风险（历史经验预估） 产品的实施周期以上线周期为准，平均为一个半月，大步慢跑 应对跨周期或者紧急功能版本时相对被动忙乱，消耗较多人力和精力 可测试功能点在上线前若干天阶跃式发布，开发测试人员并行性差 明确了解该敏捷团队的消化能力和抗风险能力（历史经验预估） 使用看板、子任务卡片和每日站立会议让每天的进展情况可视化 每晚检入代码，构建并在SIT发布集成了新用户故事的可测试版本 每天都保障开发人员和测试人员的并行流水线式作业，提高效率 测试人员进行测试和开发人员修正缺陷的压力平均分布，不随上线临近而阶跃上升 测试人员进行测试和开发人员修正缺陷的压力随上线临近而阶跃上升 小步、快跑、不贪多、只求快 用功能点来分解需求，不够情景化 需求分解的粒度较粗，完成周期较长 开发的多个中间过程无法直观体现和把控 将具体的产品需求分解为用户故事（2天/人的粒度） 对每一个分解后的需求（用户故事）进行工作量评估 明确区分出技术性故事和非技术性故事 将用户故事（场景任务）划分为若干子任务 Page  8 中国**银行股份有限公司 Page  9 根据最佳敏捷实践Scrum方法论进行工作项划分 中国**银行股份有限公司 Page  10 Scrum工作项展示 中国**银行股份有限公司 Page  11 中国**银行股份有限公司 Scrum工作项展示 任务卡状态迁移 优先级（颜色） 接地气 待分配、阻塞中 进行中、待测试 测试中、完成 紧急 正常 宽松 抬头可见、可视化 形象直观、易更改 Page  12 中国**银行股份有限公司 Scrum工作项展示 Page  13 中国**银行股份有限公司 Scrum工作项展示 Page  14 中国**银行股份有限公司 在上线后经用户使用再形成优化需求，而非在上线前的会议中提出 测试完以后直接上线验证功能，上线之后再总结本次上线过程，非所有成员参会 下个周期的开发内容在下个周期开始之后才确定而非当前周期结束时确定 回顾总结本次迭代周期内的开发过程，进行反思并改进 会议中评审本次迭代出来的产品，形成最终的产品 分析本次迭代产品中仍存在的缺陷，并列为下个迭代周期的用户故事 在每个迭代周期的最后一天的下午举行迭代回顾和计划会议 由SrcrumMaster主持，敏捷小组所有人员参会 中国**银行股份有限公司 Page  15 Page  16 IBM敏捷工具RTC功能展示(更加直观、自动化、协同化) 中国**银行股份有限公司 中国**银行股份有限公司 用户故事 故事点数 工时数 测试用例数 缺陷数 11个 20点 171小时 36个 13个 迭代周期一(2周) 用户故事 故事点数 工时数 测试用例数 缺陷数 20个 85点 290小时 82个 16个 迭代周期二(3周) 由 10 点/周 提升到 28.3 点/周 由 64% 提升到了 80% 由 1.82 点/故事 提升到 4.25 点/故事 两迭代周期对比 提升原因：团队磨