1 / 22

企 业敏捷试点的价值及常见问题

企 业敏捷试点的价值及常见问题. 平安科技（深圳）有限公司 项目经理 仲向前. 摘要. 敏捷试点的背景. 某金融集团旗下全资子公司，为保险、银行、投资各业务系列提供 IT 基础架构、软件开发、测试及咨询服务，公司拥有 2000 多人的研发团队 鼓励多元化的开发管理模式，在“稳定运营”的基础上，积极实践“快速交付”，提升服务品质 对应业务处于快速发展期，业务需求交付压力较大，希望更好的响应变化、消除浪费、快速工作 团队首次接触敏捷，希望敏捷实践提升团队及个人的能力，迈向更专业的软件交付团队. 敏捷实施前后的变化. 需求. 交付. 持续集成. 看板. 需求.

darryl-burgess
Télécharger la présentation

企 业敏捷试点的价值及常见问题

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 企业敏捷试点的价值及常见问题 平安科技（深圳）有限公司 项目经理仲向前

  2. 摘要

  3. 敏捷试点的背景 • 某金融集团旗下全资子公司，为保险、银行、投资各业务系列提供IT基础架构、软件开发、测试及咨询服务，公司拥有2000多人的研发团队 • 鼓励多元化的开发管理模式，在“稳定运营”的基础上，积极实践“快速交付”，提升服务品质 • 对应业务处于快速发展期，业务需求交付压力较大，希望更好的响应变化、消除浪费、快速工作 • 团队首次接触敏捷，希望敏捷实践提升团队及个人的能力，迈向更专业的软件交付团队

  4. 敏捷实施前后的变化 需求 交付 持续集成 看板

  5. 需求 实施后 实施前 • 经历较长的需求收集及分析阶段 • 需求经SA与用户沟通、确定、细化和估算 • 评审通过后进入设计及开发阶段 • 需求变更控制严格 • PO增量提供需求概要（业务流程图、界面） • 需求被拆分为粒度合适的用户故事 • PO对用户故事排定优先级 • 迭代内用户故事开发完即进行测试 • 迭代结束PO对用户故事进行验收 • 产品Backlog具有很高动态性

  6. 给业务带来的价值 • 按优先级开发，专注交付最有价值软件 • 需求变化得到更快速的响应 不足 给IT带来的价值 • PO角色能对用户故事排定优先级，但还缺乏产品愿景规划能力 • 用户故事拆分能力不足 • 验收标准不明确 • 前期估算偏乐观 • 开发的内容更快得到业务的反馈 • 估算更能帮助计划和预测风险

  7. 交付 • 实施前 • 实施后 部署 集成测试

  8. 每个迭代的任务 架构、数据库设计 用户故事实现 单元测试 持续集成构建 XP、TDD技术实践 确定迭代backlog 用户故事串讲反串讲 验收条件 估算 领故事 自动化验收测试开发 手工测试 用户验收 回顾总结 发布准备 迭代计划 风险管理

  9. 给业务带来的价值 • 从IT获得更快的反馈 • 更频繁的交付，商业价值得到更快的满足 不足 给IT带来的价值 • 第1、2个迭代未完成所有用户故事 • 迭代结束缺陷未全部解决，软件质量达不到可发布的要求 • 测试驱动开发、重构、结对编程等技术实践应用较少 • 提升业务的信任 • 开发、测试的协调与合作的促进 • 自组织团队成长、责任感与主人翁精神的提升

  10. 持续集成 实施后 实施前 • 没有持续集成环境 • 快移交STG，开发人员代码才check in，开始系统集成测试 • 花费较多时间和成本修复集成测试的缺陷，甚至影响到移交STG、系统测试开始时间 • 搭建持续集成环境，代码短频率的check in，应用自动编译及部署 • 自动化运行的开发者、验收者测试案例不断检查原来正确运行的系统功能仍然是好的

  11. 持续集成 迭代开始即搭建项目的持续集成环境 优先开发系统主要流程上合适 的单元测试、验收者测试案例 根据迭代开发的用户故事补充必须的测试案例 团队关注对持续集成的重要性

  12. 给IT带来的价值 • 缺陷被发现的更早，减少修复成本 • 成为更专业的软件交付团队 给业务带来的价值 • 快速交付成为可能！ 不足 • 构建失败修复不及时 • 单元测试落后于程序开发 • 冗余代码对覆盖率的影响 • 项目结束后持续集成团队关注度下降

  13. 看板 实施后 实施前 • 更多通过邮件、word、ppt沟通需求、设计及测试 • 项目经理或开发负责人采用PROJECT、需求跟踪矩阵跟进项目进度 • 项目经理或开发负责人分解任务，分配给团队成员 • 团队成员不了解也不关注项目整体情况 • 尽可能以看板为沟通的主要工具，有必要的再留存为文档 • 迭代看板包括迭代所有要交付的用户故事，展现从分析、开发、测试、验收整个生命周期 • 所有团队成员按用户故事优先级在看板上主动领取任务 • 每日站会回顾完成情况、沟通存在问题，团队一起识别风险

  14. 迭代看板 讨论工具 电子backlog

  15. 给业务带来的价值 • 项目信息可视化，让业务更准确了解项目进展 • 提升沟通效率、节约沟通成本 不足 给IT带来的价值 • 用户故事的跟踪仅到迭代验收，没有包括集成测试及上线 • 反映需求变化及整体完成进度的燃烧图更新不及时 • 沟通方式的转变 • 方便识别开发过程中的瓶颈，并加以解决 • 让团队每个成员了解项目进展

  16. 项目内敏捷与传统模式对比 2/6-4/13 V1DEV 4/16-5/10 V1 ST/UAT 4/23-5/18 V2DEV 5/21-6/6 V2 ST/UAT 5/21-6/15 V3 DEV 6/18-6/27 V3 ST/UAT

  17. 项目内敏捷与传统模式对比 版本一 • 两周一个迭代，5个迭代后移交测试，三周半的系统及UAT测试、发布 • 每个迭代都有测试前置和验收 • 持续集成环境保持良好，有问题及时修复，自动化案例根据用户故事有选择的补充 • 不是一个人在战斗，团队协同交付 版本二 版本三 • 2个迭代（1个月）开发后移交测试，两周半系统及UAT测试、发布 • 每个迭代开发人员还是按照用户故事优先级开发，但专职测试人员投入在版本一系统测试，开发完成的用户故事不能及时测试，迭代内开发测试协同作用受到比较大的影响，用户故事无人测试和验收 • 持续集成环境团队关注降低，案例得不到维护，案例失败的修复时间增长 • 潜在可交付的软件迭代目标不能得到保证 • 开发一个人在玩 • 2个迭代（1个月）开发后移交测试，一周半系统及UAT测试、发布 • 与版本二类似，用户故事得不到及时测试和验收

  18. 版本一、二、三测试缺陷对比 • 版本一缺陷与开发人时占比0.08；开发修复缺陷人时与开发人时比值18% • 版本二缺陷与开发人时占比0.12；开发修复缺陷人时与开发人时比值28% • 版本三开发修复缺陷人时与开发人时比值29% • 迭代内测试前置使得一些缺陷在移交前就修复，迭代内的缺陷修复耗时较少 • 移交后修复缺陷人时减少，修复成本较低

  19. 版本一、二、三开发、测试人时、工期分析 • 版本一测试人时占总人时的比例约27% • 版本二测试人时占总人时的比例约35% • 版本三测试人时占总人时的比例约34% • 版本一迭代中测试前置，移交后系统/UAT测试周期较短 • 版本二、三移交前迭代内未测试，移交后系统/UAT测试周期较长 • 版本一开发、测试周期比7:3，版本二/三开发、测试周期比约6:4

  20. 团队对敏捷的感受

  21. 团队对敏捷的感受 • 交付与计划 • 以不影响产品的质量为前提，实现产品的最大价值为目标 • 快速响应用户的需求 • 持续交付 • 团队 • 敏捷的团队应该是主动、高效、有激情的团队 • 以人为本 • 开发与测试的融合 • 团队规则的重要性和执行力 • 激励胜过惩罚 • 技术实践 • 敏捷两大法宝：持续集成、自动化测试 • 照葫芦画瓢——尽管没能完全理解敏捷，依然按着它做事 • 完善故事、守护质量 • 持续集成和测试前置的重要性 • 敏捷项目适当增加测试人力投入 • 持续改进，摆脱“地心引力”

More Related