1. 1
如何利用 KANBAN
让 SCRUM 更完美 趋势科技看板经验分享
趋势科技 David Ko
david_ko@trend.com.tw

2. 2
商鞅变法

3. 3
我是谁?
• 趋势科技, 台湾部门, 品质经理
• 台湾敏捷技术社群发起人之一
• “Scrum Community in Taiwan”
• “Agile Community in Taiwan”
• 博客: http://kojenchieh.pixnet.net/blog

4. 4
趋势科技 (Trend Micro)
• 前三大防病毒软件公司
• 着重于云端, 企业, 和个人等资安产品
• 2008 年开始推行敏捷, 目前约有七成使用 Scrum

5. 5
主题: 如何利用 Kanban 让 Scrum 更完美
• 项目背景和早期的开发流程
• 项目实施 Scrum 后所遭遇的问题
• 如何以 Kanban 来进行渐进式改革
• 流程中的坏味道
• 持续改进的方式
• Q&A

6. 6
产品背景:沙盒分析平台 (Sandbox)
• 新发展的重点产品
• 市面上已有杀手级产品
• 老板的重点就是快,快,快

7. 7
组织背景
专业分工
产品经理
开发经理
不同性质工作
开发
团队
项目经理
质量经理
开发人员
测试人员
(9)
(11)
设计人员
(1)
维护
团队
售前支
持团队

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
早期的开发流程
• 以 Scrum 为主的开发方式
• 为期 2 周的 sprint
• 发行周期: 1.5 M -> 2 M -> 4 M

10. 10
项目实施 Scrum 后所遭遇的问题

11. 11
多项目, 多种不同性质工作
• 多个项目同时进行
• 无法评估 bug 要花多少时间修复
• 重要性和实时性不同

12. 12
任务版上的信息不足
• 一直停在 “处理中” 不动
• 直到最后几天才移到 “做完”
需求
待办事项
处理中
做完

13. 13
人数太多不易使用
• 每日立会要开很久
• 任务版太复杂

14. 14
Retrospective 的效果不彰
• 相同问题在短时间内重复被提出
• 问题没有被探究到底

15. 15
以 Kanban 来进行渐进式改革
• 非软件开发方法
• 变革管理的方法
• 需搭配其他软件开发方法

16. 16
5 个核心实务
• 可视化你的工作流程
• 限制同时工作数量
• 管理工作流程
• 为流程订定明确的方针
• 一同合作来改进
需求
分析(3) 设计(3)
开发(4) 测试(2) 做完

17. 17
将工作可视化

18. 18
测试人员的任务版
• 测试: 测试个案开立, 检视, 环境准备, 执行, 验证修复结果
• 自动化
• 效能和侦测率调整
• 事件导向: To Do -> In Prog -> Done

19. 19
开发人员的任务版
• 以开发为主
• Backlog -> Do -> Check -> Done

20. 20
项目阶层的任务版
• 提供整体进度的概观
• 显示各个功能目前在那个阶段

21. 21
Scrum of Scrum 每日立会
专案阶层
5:30 PM
Feature team
5:15 PM
测试人员
10:30 AM
Feature team
5:00 PM

22. 22
目视管理 找出坏味道
• 厘清状态
• 以持续改进方式
排除多任务
• 确保流程顺畅度

23. 23
坏味道 1: 有不需要或是少列的步骤
• 有些步骤不需要或是没有被列出来
• 要不断调整去呈现现况

24. 24
坏味道 2: 工作流程过度一般化
• 发现很多概念性验证的工作同时在进行
• 重新建构工作流程

25. 25
目视管理 找出坏味道
• 厘清状态
• 以持续改进方式
排除多任务
• 确保流程顺畅度

26. 26
曾试图利用 WIP limit 解决问题
• 很难归纳公式
• 多种类型工作, 多个项目
• WIP limit 只是提醒, 重点是厘清和解决问题

27. 27
利用 Improvement Kata 持续改善
1. 了解愿景方向
3. 想要达到的
下一步的目标
4. 利用PDCA
达到下一步目标
2. 理解目前
的状态
http://hakanforss.wordpress.com/tag/toyota-kata/

28. 28
坏味道 3: 同时处理不同性质的事情
避免开发与维护并行
收集
信息
工作流程广告牌 +
工作时间分布
专人
专职
确认
资源

29. 29
处理并行状况
• 收集信息
• 记录处理概念性验证的时间
• 专人专职
• 处理开发和维护不同人负责
• 确认有足够资源
• 纪录 cycle time 以评断处理速度

30. 30
坏味道 4: 台面下的多任务
• 老手的困境
• 很多人问他问题
• 或是只有他能处理
• 解决方法
• 师徒制搭档编程
• 限制最多能处理多少事

31. 31
目视管理 找出坏味道
• 厘清状态
• 以持续改进方式
排除多任务
• 确保流程顺畅度

32. 32
坏味道 5: 有些步骤做太快
很快就完成
或是直接跳过

33. 33
制定政策
设计做完的条件
1. 设计需要检视
2. 验收测试个案要开立
整合完毕的条件
1. 验收测试个案要通过
2. 程序代码要检视过

34. 34
专职架构师 (architect)
• 无法落实
• 自顾不暇
• 没空专心检视
• 指派专职架构师
• 严格把关
• 经验传承

35. 35
坏味道 6: 有些步骤拖太久
不知花多长时间
错误不断被找到

36. 36
处理修太久又错太多的状况
• 先处理既有的错误
• 评估和保留修复时间
• 可视化错误处理的状态
• 将 bug 贴在开发人员任务板上面
• 由架构师专职检视
• 避免修复后带来更多错误

37. 37
坏味道 7: 有些步骤一直重复发生
• 测试文件来来回回修改很多次

38. 38
利用系统思考来洞察全貌
需求不明确
设计
常变动
要测试多少
不明确
测试规格
交付延迟
Load
不均衡
开发人员太忙
请假没
有交接

39. 39
解法整理: 如何补强 Scrum
问题
多项目, 多种不同性质工作
任务版上的信息不足
解法
多个工作流程
详尽的工作流程
人数太多不易使用
Retrospective 的效果不彰
Scrum of Scrum
Improvement Kata
Fishbone + 5 Whys

40. 40
解法整理: 如何观察坏味道
• 有不需要或是少列的步
• 有些步骤做太快
骤
• 工作流程过度一般化
• 同时处理不同性质的事
情
• 台面下的多任务
• 有些步骤拖太久
• 有些步骤一直重复发生

41. 41
使用 Kanban 后带来的变化
凡事可视化
找寻和处理坏味道
形成改善的文化

42. 42
结论
• 好工具不该只有一种
• 利用痛点来渐进式演化
• 记住! 问题永远在现场
• 善用坏味道

43. 43
有行动才会不一样

44. 44
谢谢