中国国有银行敏捷开发试点总结V2知识讲稿课件

1、敏捷开发试点工作汇报试点团队：电子商务开发团队试点项目小组：善融商务个人商城手机客户端小组试 点 牵 头 人&汇 报 人：Allen Zhang 张 明中国*银行股份有限公司Page 2本次敏捷试点的心得和收获4敏捷试点引入的六个最佳实践（对比）2敏捷推广的未来展望5中国*银行股份有限公司敏捷试点项目的规模和层级1敏捷试点采用的平台支撑IBM RTC3Page 4中国*银行股份有限公司敏捷试点引入的六个最佳实践2优先级、情景化、子任务化可视化监测开发进展状态和健康度沟通、互动、协作跨部门、跨职能、提升协调力小步、快跑、不贪多、只求快尽早发现小问题、杜绝大问题计划会议&回顾会议&站立会议统一团队

2、持续集成迭代化开发燃尽图&燃耗图&故事墙用户故事Scrum*注*Scrum：一种敏捷的项目管理方式。敏捷开发主要有两个流派，一个是Scrum，一个是XP。Scrum偏重于过程，XP偏重于实践。Scrum是橄榄球的一个专业术语，表示“争球”的动作，比喻团队在开发一个项目时，大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它。 XP：极限编程(eXtreme Programming)。Page 5中国*银行股份有限公司敏捷试点引入的六个最佳实践：统一团队2客户端开发人员（宝润-全职）服务器端开发人员（宝润-全职）客户端开发人员（宝润-全职）ScrumMaster*敏捷教练（广开张明-全职）

3、服务器端开发人员（宝润-全职）产品经理（宝润-兼职）测试人员（银行业务部-兼职）轻文档、重沟通：最大幅度减少被过度写作的需求文档和设计文档，用面对面交流完成信息传递自管理、自组织：管理和决策不再由管理层单独掌握，而是整个团队商议决定。每个成员都对质量、时间、成本、风险负责跨团队、跨职能：消除分工灰色地带、淡化目标不一致、减少部门间“打架”位问题；敏捷咨询顾问（IBM-全职）注*Scrum Master是负责一个team按照Scrum方式运行的角色。职责包括更新backlog, 主持plan meeting, 主持stand up meeting, 主持retrospective meeting

4、, 提交team velocity, burn up chart, burn down chart.统一团队Page 6中国*银行股份有限公司其他相关部门人员统一团队（敏捷团队）产品需求根据业务优先级选择实施模块细化（2天以内）最终产品看板管理每日站立会议持续集成并行测试实施周期:23周 (历史经验预估)总结与改进会议迭代（冲刺）发布合并流敏捷试点引入的六个最佳实践：迭代化开发2遗留缺陷需求变更中国*银行股份有限公司Page 7选择能在23周之内完成的用户故事量作为本次迭代的目标，小步快跑敏捷模式瀑布模式充分估计所选用户故事的需求变更风险性和技术风险（历史经验预估）产品的实施周期以上线周期为准

5、，平均为一个半月，大步慢跑应对跨周期或者紧急功能版本时相对被动忙乱，消耗较多人力和精力新旧对比可测试功能点在上线前若干天阶跃式发布，开发测试人员并行性差明确了解该敏捷团队的消化能力和抗风险能力（历史经验预估）使用看板、子任务卡片和每日站立会议让每天的进展情况可视化每晚检入代码，构建并在SIT发布集成了新用户故事的可测试版本每天都保障开发人员和测试人员的并行流水线式作业，提高效率测试人员进行测试和开发人员修正缺陷的压力平均分布，不随上线临近而阶跃上升测试人员进行测试和开发人员修正缺陷的压力随上线临近而阶跃上升敏捷试点引入的6个最佳实践:迭代化开发2实施周期:23周(历史经验预估)持续集成并行测试

6、看板管理每日站立会议小步、快跑、不贪多、只求快用功能点来分解需求，不够情景化需求分解的粒度较粗，完成周期较长开发的多个中间过程无法直观体现和把控将具体的产品需求分解为用户故事（2天/人的粒度）对每一个分解后的需求（用户故事）进行工作量评估明确区分出技术性故事和非技术性故事将用户故事（场景任务）划分为若干子任务Page 8中国*银行股份有限公司敏捷模式瀑布模式新旧对比产品需求Story设计、情景化用户故事（2天以内）具体化开发过程子任务敏捷试点引入的6个最佳实践:用户故事2Page 9根据最佳敏捷实践Scrum方法论进行工作项划分用户需求Word文档UI设计样本（静态图片）UI原型（动态可交互迁

7、移页面）需求来源方口述用户故事需求描述验收条件规 模用户价值所属应用所属模块用户特性子任务客户端界面开发（2H）设计相应库表（1H）服务器端代码开发（4H）客服端与服务器端联调（3H）编写测试用例（3H）执行测试（2H）修正缺陷（3H）中国*银行股份有限公司敏捷试点引入的6个最佳实践:用户故事2Page 10Scrum工作项展示用户故事中国*银行股份有限公司Step 4场景化地描述需求内容估计用户价值和规模明确验收条件子任务化Step 3Step 2Step 1敏捷试点引入的6个最佳实践:用户故事2Page 11任务板（故事墙）中国*银行股份有限公司Scrum工作项展示敏捷试点引入的6个最佳实

8、践:任务板（故事墙）2任务板（故事墙）任务卡状态迁移待分配、阻塞中进行中、待测试测试中、完成优先级（颜色）紧急正常宽松接地气抬头可见、可视化形象直观、易更改Page 12中国*银行股份有限公司Scrum工作项展示敏捷试点引入的六个最佳实践:燃尽图2燃尽图（基于故事点）燃尽图（基于工时）优点4可视化项目进度与消化情况诊断健康暴露瓶颈促进风险预估团队定性优点 3优点 2优点 1燃耗图（基于工时）Page 13中国*银行股份有限公司Scrum工作项展示敏捷试点引入的六个最佳实践:燃尽图2优点4可视化项目进度与消化情况诊断健康暴露瓶颈促进风险预估团队定性优点 3优点 2优点 1Page 14中国*银行

9、股份有限公司每日站立会议Step 4昨天做了什么？今天要做什么？有什么困难需要协助？更新迭代状态更新任务板Step 3Step 2Step 1敏捷试点引入的6个最佳实践:站立会议2在上线后经用户使用再形成优化需求，而非在上线前的会议中提出测试完以后直接上线验证功能，上线之后再总结本次上线过程，非所有成员参会下个周期的开发内容在下个周期开始之后才确定而非当前周期结束时确定回顾总结本次迭代周期内的开发过程，进行反思并改进会议中评审本次迭代出来的产品，形成最终的产品分析本次迭代产品中仍存在的缺陷，并列为下个迭代周期的用户故事在每个迭代周期的最后一天的下午举行迭代回顾和计划会议由SrcrumMaste

10、r主持，敏捷小组所有人员参会中国*银行股份有限公司Page 15敏捷模式瀑布模式新旧对比本迭代最终产品迭代回顾和计划会议下个迭代计划(改良)敏捷试点引入的6个最佳实践:计划与回顾会议2Page 16IBM敏捷工具RTC功能展示(更加直观、自动化、协同化)中国*银行股份有限公司敏捷试点采用的平台支撑IBM RTC3用户故事任务板燃耗图燃尽图中国*银行股份有限公司本次敏捷试点的收获和总结：试点数据4用户故事故事点数工时数测试用例数缺陷数11个20点171小时36个13个迭代周期一(2周)用户故事故事点数工时数测试用例数缺陷数20个85点290小时82个16个迭代周期二(3周)由 10 点/周 提升

11、到 28.3 点/周故事消化能力故事消化速率测试通过率由 64% 提升到了 80%由 1.82 点/故事 提升到 4.25 点/故事两迭代周期对比提升原因：团队磨合到位、流程更熟练、抵触感降低、RTC更上手、协同参与度增大中国建设银行股份有限公司本次敏捷试点的收获和总结：试点数据4得出最优迭代周期长度3周周期中段最高效二周三周亚健康迭代健康迭代得出试点敏捷团队类型Late-Learner型传统团队敏捷团队Early-Learner：开始有一个顶峰，然后是平缓的衰退。团队认识到早期探寻的重要性，然后高效工作以实现目标。（理想实践）Fakey-Fakey：表面完美而已。软件项目过于复杂以致于难以界

12、定直观的目标。这种燃尽图来自于充满了命令与控制的环境，在这种环境下，开放的交流变得难以进行。（失败实践）Middle-Learner：要比late-learner更加成熟。燃尽图中段会有一个顶峰出现。团队在Sprint的中期会探寻出大多数的任务与复杂性。(良好实践)Late-Learner：燃尽图末段会有一个顶峰出现。通常出现在沟通高效且正在学习Scrum的团队中。(普通实践)SCRUMPage 19中国*银行股份有限公司本次敏捷试点的收获和总结：心得4该去向何方？遇到障碍！迈出了第一步！教练很牛很高大上！怎样才能摆脱困境？组员们可以默契高效地合作了！领导指派的IBM敏捷教练来了！教练迭代会议

13、耐心讲解示范看不到希望！手把手教会我使用强大的敏捷工具RTC帮我们建立合理有效的分工敏捷小组快速成长！教练每日严格要求感谢领导关怀和教练的指导，我们会继续努力在敏捷开发领域做优秀的CCB开拓者 ！在敏捷领域，我们会继续努力读书学习！最初按照敏捷的方法很痛苦很累，但是熬过这段时间就会从中大大获益敏捷对成员的能力要求较高，同样对成员的能力提升也快开发过程中必须遵循敏捷的原则，但具体的活动可以灵活控制最重要的是理解并接受敏捷的思想敏捷的确可以提高工作效率和产品质量，值得尝试推广中国*银行股份有限公司本次敏捷试点的收获和总结：不足之处4亟待提升之处2WIFI连入SIT测试环境的前期准备不充分3测试用例

14、与开发人员共享过晚降低了测试通过率4每日站立会议对子任务实际消耗工时更新不及时，略影响了燃尽图的准确性和真实性5持续集成仍为手工操作，未实现自动化和一体化合作公司人员变动略频繁1问：RTC与建行用于配置管理的ClearCase可以进行协同工作么？答：可以，RTC可以与CC集成，在RTC的工作项中，可以直接连接到一个CC的Activity，将源代码追踪能力做得更好。问：RTC与建行用于缺陷管理的ClearQuest可以进行数据同步么？答：可以，RTC可以与CQ无缝集成，把缺陷提到CQ中。当然在RTC中也提供管理缺陷的能力，直接提交一个Defect类型的缺陷即可。问：RTC与建行用于管理需求的FLPM可以进行数据同步么？答：当前FLPM只能通过使用RTC对应工