QCon shanghai2013-davidko-如何利用 kanban让 scrum 更完美

1,340 views

Published on

0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,340
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
39
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

QCon shanghai2013-davidko-如何利用 kanban让 scrum 更完美

  1. 1. 1 如何利用 KANBAN 让 SCRUM 更完美 趋势科技看板经验分享 趋势科技 David Ko david_ko@trend.com.tw
  2. 2. 2 商鞅变法
  3. 3. 3 我是谁? • 趋势科技, 台湾部门, 品质经理 • 台湾敏捷技术社群发起人之一 • “Scrum Community in Taiwan” • “Agile Community in Taiwan” • 博客: http://kojenchieh.pixnet.net/blog
  4. 4. 4 趋势科技 (Trend Micro) • 前三大防病毒软件公司 • 着重于云端, 企业, 和个人等资安产品 • 2008 年开始推行敏捷, 目前约有七成使用 Scrum
  5. 5. 5 主题: 如何利用 Kanban 让 Scrum 更完美 • 项目背景和早期的开发流程 • 项目实施 Scrum 后所遭遇的问题 • 如何以 Kanban 来进行渐进式改革 • 流程中的坏味道 • 持续改进的方式 • Q&A
  6. 6. 6 产品背景:沙盒分析平台 (Sandbox) • 新发展的重点产品 • 市面上已有杀手级产品 • 老板的重点就是快,快,快
  7. 7. 7 组织背景 专业分工 产品经理 开发经理 不同性质工作 开发 团队 项目经理 质量经理 开发人员 测试人员 (9) (11) 设计人员 (1) 维护 团队 售前支 持团队
  8. 8. 8 多版本, 多国语言, 多项目 • 多版本 • 2012: 2.9 -> 2.91 -> 2.92 -> 2.95 • 2013: 3.0 Beta 1 -> 3.0 Beta 2 -> 3.0 -> 3.0 SP1 • 多语言 • 多项目 • 2012: DDA • 2013: DDA/CTIS/DDTI
  9. 9. 9 早期的开发流程 • 以 Scrum 为主的开发方式 • 为期 2 周的 sprint • 发行周期: 1.5 M -> 2 M -> 4 M
  10. 10. 10 项目实施 Scrum 后所遭遇的问题
  11. 11. 11 多项目, 多种不同性质工作 • 多个项目同时进行 • 无法评估 bug 要花多少时间修复 • 重要性和实时性不同
  12. 12. 12 任务版上的信息不足 • 一直停在 “处理中” 不动 • 直到最后几天才移到 “做完” 需求 待办事项 处理中 做完
  13. 13. 13 人数太多不易使用 • 每日立会要开很久 • 任务版太复杂
  14. 14. 14 Retrospective 的效果不彰 • 相同问题在短时间内重复被提出 • 问题没有被探究到底
  15. 15. 15 以 Kanban 来进行渐进式改革 • 非软件开发方法 • 变革管理的方法 • 需搭配其他软件开发方法
  16. 16. 16 5 个核心实务 • 可视化你的工作流程 • 限制同时工作数量 • 管理工作流程 • 为流程订定明确的方针 • 一同合作来改进 需求 分析(3) 设计(3) 开发(4) 测试(2) 做完
  17. 17. 17 将工作可视化
  18. 18. 18 测试人员的任务版 • 测试: 测试个案开立, 检视, 环境准备, 执行, 验证修复结果 • 自动化 • 效能和侦测率调整 • 事件导向: To Do -> In Prog -> Done
  19. 19. 19 开发人员的任务版 • 以开发为主 • Backlog -> Do -> Check -> Done
  20. 20. 20 项目阶层的任务版 • 提供整体进度的概观 • 显示各个功能目前在那个阶段
  21. 21. 21 Scrum of Scrum 每日立会 专案阶层 5:30 PM Feature team 5:15 PM 测试人员 10:30 AM Feature team 5:00 PM
  22. 22. 22 目视管理 找出坏味道 • 厘清状态 • 以持续改进方式 排除多任务 • 确保流程顺畅度
  23. 23. 23 坏味道 1: 有不需要或是少列的步骤 • 有些步骤不需要或是没有被列出来 • 要不断调整去呈现现况
  24. 24. 24 坏味道 2: 工作流程过度一般化 • 发现很多概念性验证的工作同时在进行 • 重新建构工作流程
  25. 25. 25 目视管理 找出坏味道 • 厘清状态 • 以持续改进方式 排除多任务 • 确保流程顺畅度
  26. 26. 26 曾试图利用 WIP limit 解决问题 • 很难归纳公式 • 多种类型工作, 多个项目 • WIP limit 只是提醒, 重点是厘清和解决问题
  27. 27. 27 利用 Improvement Kata 持续改善 1. 了解愿景方向 3. 想要达到的 下一步的目标 4. 利用PDCA 达到下一步目标 2. 理解目前 的状态 http://hakanforss.wordpress.com/tag/toyota-kata/
  28. 28. 28 坏味道 3: 同时处理不同性质的事情 避免开发与维护并行 收集 信息 工作流程广告牌 + 工作时间分布 专人 专职 确认 资源
  29. 29. 29 处理并行状况 • 收集信息 • 记录处理概念性验证的时间 • 专人专职 • 处理开发和维护不同人负责 • 确认有足够资源 • 纪录 cycle time 以评断处理速度
  30. 30. 30 坏味道 4: 台面下的多任务 • 老手的困境 • 很多人问他问题 • 或是只有他能处理 • 解决方法 • 师徒制搭档编程 • 限制最多能处理多少事
  31. 31. 31 目视管理 找出坏味道 • 厘清状态 • 以持续改进方式 排除多任务 • 确保流程顺畅度
  32. 32. 32 坏味道 5: 有些步骤做太快 很快就完成 或是直接跳过
  33. 33. 33 制定政策 设计做完的条件 1. 设计需要检视 2. 验收测试个案要开立 整合完毕的条件 1. 验收测试个案要通过 2. 程序代码要检视过
  34. 34. 34 专职架构师 (architect) • 无法落实 • 自顾不暇 • 没空专心检视 • 指派专职架构师 • 严格把关 • 经验传承
  35. 35. 35 坏味道 6: 有些步骤拖太久 不知花多长时间 错误不断被找到
  36. 36. 36 处理修太久又错太多的状况 • 先处理既有的错误 • 评估和保留修复时间 • 可视化错误处理的状态 • 将 bug 贴在开发人员任务板上面 • 由架构师专职检视 • 避免修复后带来更多错误
  37. 37. 37 坏味道 7: 有些步骤一直重复发生 • 测试文件来来回回修改很多次
  38. 38. 38 利用系统思考来洞察全貌 需求不明确 设计 常变动 要测试多少 不明确 测试规格 交付延迟 Load 不均衡 开发人员太忙 请假没 有交接
  39. 39. 39 解法整理: 如何补强 Scrum 问题 多项目, 多种不同性质工作 任务版上的信息不足 解法 多个工作流程 详尽的工作流程 人数太多不易使用 Retrospective 的效果不彰 Scrum of Scrum Improvement Kata Fishbone + 5 Whys
  40. 40. 40 解法整理: 如何观察坏味道 • 有不需要或是少列的步 • 有些步骤做太快 骤 • 工作流程过度一般化 • 同时处理不同性质的事 情 • 台面下的多任务 • 有些步骤拖太久 • 有些步骤一直重复发生
  41. 41. 41 使用 Kanban 后带来的变化 凡事可视化 找寻和处理坏味道 形成改善的文化
  42. 42. 42 结论 • 好工具不该只有一种 • 利用痛点来渐进式演化 • 记住! 问题永远在现场 • 善用坏味道
  43. 43. 43 有行动才会不一样
  44. 44. 44 谢谢

×