阳陆育 大型软件产品的敏捷案例分享

1,541 views

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,541
On SlideShare
0
From Embeds
0
Number of Embeds
57
Actions
Shares
0
Downloads
25
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

阳陆育 大型软件产品的敏捷案例分享

  1. 1. 大型软件产品的敏捷案例分享 易保网络技术有限公司 财产险产品线总监 阳陆育 (Luyu.Ouyang@gmail.com)
  2. 2. Scrum概述 拆分您的团队 一个简单的框架分割您的产品 一个庞大的团队花费很长时间一次交付很多内容 多个跨职能的小团队分多个小迭代持续的交付增量的可用功能, 交付过程中持续的集成、持续的改善商 对过程进行持续的业 分割您的时间 检视与调整价 2010/01/01 2010/04/01值 根据商业价值 排列优先级 2
  3. 3. 大纲(contents)n 分割及组织团队n 分割及编排计划n 立即开始并持续改进n 逐步克服长期挑战 3
  4. 4. 案例实录:Team Structure 4
  5. 5. 案例实录:Workplace Arrangement • 把团队组织在一个开放 空间中 • 尽可能在多放置白板 • 调转座椅就能开会 5
  6. 6. 案例实录:Engineering Infrastructure 6
  7. 7. 分享1:跨职能团队+特性团队n 跨职能团队: n 完成一项功能的设计,开发和测试的过程不需要进行文档化的握手过程 n 极大的减少了沟通和传递中的噪音和偏差,并且大大降低了沟通成本 n 群体决策成为可能,使得集体的智慧(Wisdom of the crowds)得以发挥 n 给了每个成员更大的技术视野n 特性团队: n 同一团队关注在同一功能模块,在同一时间段大家联合做同一个功能 n 成员间通过帮、传、带使领域知识不只是积累在文档中,而且积累在团队中,使得每个人 都不是不可替代的。n 是否一定要由Senior成员构成的团队才能发挥Scrum的作用?: n 不一定。更多的Senior的成员能提升团队的效率,但是团队的最终效率是由团 队成员的配合度来决定。 n Scrum方法中大家高度协作,每个人的主动性被激发起来后,能很好的提升团 队的整体作战能力,Junior成员也能很快的从Senior成员那边学到很多东西。 n 由于同一个团队关注的是相近的功能,采用PP的方法,能很好的促进学习, 并能极大的营造团队的学习气氛。 7
  8. 8. 分享2:做好开发服务是发挥作用的关键n 工程基础设施专人专职: q 专人负责开发测试环境的维护,持续集成体系的构建和看护 q 使得每个开发团队不需要分心于基础设施n PO及用户故事团队全程参与,随叫随到: q 对需求的澄清随时可以进行 q 需求人员在开发过程中即参与需求的验证和纠正n 专职教练: q 旁观者清,需要一个看得清楚,并一直思考的人来持续的发现问题并促进集体思考 q 专职教练能很好的帮助团队对抗团队惯性(或者叫“组织重力”) 8
  9. 9. 大纲(contents)n 分割及组织团队n 分割及编排计划n 立即开始并持续改进n 逐步克服长期挑战 9
  10. 10. 案例实录:Release Planningn Body text 10
  11. 11. 案例实录:Arrangement around the National Holiday Monda Tuesd Wedn Thurs Friday Saturd Sunda y ay esday day ay y • 严格的保证10个工作日 14 15 16 17 18 19 20 的Sprint长度,节假日 Release Release Sprint 5 plan plan Planning 不例外 21 22 23 24 25 26 27 • 如果一个Sprint不能在 固定时长内结束,在中 28 29 30 1 2 3 4 Sprint 5 Doc 间要进行内容的调整, Review review 但是不能延长时间 & Sprint 6 pre- planning • Scrum执行成功的关键 5 6 7 8 9 10 11 是帮助团队找到固定的 Sprint 6 节奏感 Planning 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Sprint 6 Review 11
  12. 12. 案例实录:Scope Control Authority for Internal Authority for Internal External External Control Control Change ChangeChange requests would come from:Change requests would come from: Request Request 1, Project manager as 1, Project manager as level 1 authority Handling Handling level 1 authority• End users in Sprint review and after• End users in Sprint review and after 2, Project Steering Board Following the Following the 2, Project Steering Boardreview atreview at as level 2 authority agreement agreement as level 2 authority made per made per • Disagreement with solution and • Disagreement with solution and 3, eBaoTech GS sub 3, eBaoTech GS sub project with project with design design committee as final committee as final co-developer co-developer • Advise more features to product • Advise more features to product judgement judgement•eBaoTech BA and PDM in implementation•eBaoTech BA and PDM in implementationwhenwhen • More user stories are found to • More user stories are found to ensure business integrity ensure business integrity Change Adopting Change Adopting • New solutions are identified with • New solutions are identified with Urgent cases are Urgent cases are 20%+ efforts variation 20%+ efforts variation handled immediately handled immediately•eBaoTech Business Units when higher•eBaoTech Business Units when higher and the impacts will be and the impacts will bevalue features are identifiedvalue features are identified fixed afterwards; fixed afterwards; Normal cases are Normal cases are handled before each handled before each sub-release sub-release 12
  13. 13. 分享3:基于”客户价值“的计划n 编排目标,而非编排任务: q 先把每一个Subrelease和每一个Sprint的业务目标定下来,根据业务目标来分解用 户故事。 q 永远先做优先级高的事情,优先级低的事情由用户故事团队持续的与客户协商。n 及早开始,逐步清晰,及时调整: q 让用户故事的细化与开发并行起来,尽早开始开发,为开发工作腾出更多的时间 q 使用Sprint0来解决大的方案和技术风险 q 在每个Sprint中预留10%~20%的时间准备下一个Sprintn 不断调整,不停检视: q 每个Subrelease结束前一个Sprint重新进行Release planning,进行大的变更管理 q 每个Sprint review结束后,调整Product backlog的内容及优先级 13
  14. 14. 大纲(contents)n 分割及组织团队n 分割及编排计划n 立即开始并持续改进n 逐步克服长期挑战 14
  15. 15. 案例实录:Burndown of a team in sprint 1 • 猜猜这个Sprint中发生了什么事情 • 分析一下早期的Sprint为什么会是这样 15
  16. 16. 案例实录:Burndown of a team in sprint 5 • 猜猜这个Sprint中发生了什么事情 • 分析一下有了一些新的尝试后的Sprint为什么会是这样 16
  17. 17. 案例实录:Burndown of a team in sprint 8 • 猜猜这个Sprint中发生了什么事情 • 分析一下一个理想的Sprint的执行状况应该是什么样子 17
  18. 18. 案例实录: Define the DOD Aspect Definition of Done OwnerCode complete 100% CQ status as "reviewed" MasterDeliver to integrated Testing environment Demo feature in Testing environment Master (not defined yet, we will defineUnit testing at local (by Java or by other method) Master no late than sprint 5) Master ofAutomated code check/review Enforced at code check-in engineeringTest cases in TD More than 0 in QA report Master assignedFunctional testing cases 100% pass at Dev 100% in QA report Master assigned environmentTesting regressed at integrated Testing environment 100% in QA report Master assigned Product OwnerProduct owner acceptance testing passed 100% demo scenario covered Representat ive 100% validated against theBasic quality criteria passed Master assigned standard from Andrew 20% cases automated (as a starting point, we will Master ofAutomation testing increase the ratio a bit by a testing bit) 18
  19. 19. 分享4:改进,改进,再改进n 定义清晰的DOD: q DOD是一种Commitment,而不是一种监管手段 q Owner of DOD的使命是让团队理解,而不是强迫团队执行 q 质量来自于团队意识,而不是来自于测试n 让团队自学习: q Sprint不是微型的瀑布,让团队成员自己打配合 q 尽量多的PP q 允许团队犯错误,帮助团队分析原因n 稳定然后再提高: q Scrum不会加快开发速度,团队配合效率的提高才能提高速度 q 假设一个Velocity然后不断的较正 q 尽量确保团队稳定 19
  20. 20. 大纲(contents)n 分割及组织团队n 分割及编排计划n 立即开始并持续改进n 逐步克服长期挑战 20
  21. 21. 逐步克服长期挑战n 技术债务 q 慢慢的补齐欠缺的单元测试及自动化 q 定期的组织重构活动 q 每个Sprint的review中加入defect review and summarizen 协调敏捷的方法与PMO监管 q 争取公司管理层的认同 q 将用户故事测算转化成传统PMP的测算值 q 鼓励PMO参与Sprint reviewn 打造高效的团队 q 团队发展的三个层次:forming, storming, performing q 给团队适中的压力 q 组织长效的培训计划,鼓励学习与分享 q 保持团队稳定 21
  22. 22. n Thanks! 22

×