如何利用 KANBAN

让 SCRUM 更完美 -

趋势科技看板经验分享

趋势科技 David Ko

david_ko@trend.com.tw

1

商鞅变法

2

我是谁?

• 趋势科技, 台湾部门, 品质经理

• 台湾敏捷技术社群发起人之一• “Scrum Community in Taiwan”

• “Agile Community in Taiwan”

• 博客: http://kojenchieh.pixnet.net/blog

3

趋势科技 (Trend Micro)

• 前三大防病毒软件公司

• 着重于云端, 企业, 和个人等资安产品

• 2008 年开始推行敏捷, 目前约有七成使用 Scrum

4

主题: 如何利用 Kanban 让 Scrum 更完美

• 项目背景和早期的开发流程

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

• 如何以 Kanban 来进行渐进式改革• 流程中的坏味道

• 持续改进的方式

• Q & A

5

产品背景:沙盒分析平台 (Sandbox)

• 新发展的重点产品

• 市面上已有杀手级产品

• 老板的重点就是快,快,快

6

组织背景

专业分工 不同性质工作

7

产品经理

项目经理

测试人员

开发经理 质量经理

开发人员

设计人员

售前支持团队

维护团队

开发团队

(9) (11)

(1)

多版本, 多国语言, 多项目

• 多版本• 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

8

早期的开发流程

• 以 Scrum 为主的开发方式

• 为期 2 周的 sprint

• 发行周期: 1.5 M -> 2 M -> 4 M

9

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

10

多项目, 多种不同性质工作

• 多个项目同时进行

• 无法评估 bug 要花多少时间修复

• 重要性和实时性不同

11

任务版上的信息不足

• 一直停在 “处理中” 不动

• 直到最后几天才移到 “做完”

12

待办事项 处理中 做完需求

人数太多不易使用

• 每日立会要开很久

• 任务版太复杂

13

Retrospective 的效果不彰

• 相同问题在短时间内重复被提出

• 问题没有被探究到底

14

以 Kanban 来进行渐进式改革

• 非软件开发方法

• 变革管理的方法

• 需搭配其他软件开发方法

15

5 个核心实务• 可视化你的工作流程

• 限制同时工作数量

• 管理工作流程

• 为流程订定明确的方针

• 一同合作来改进

16

分析(3) 设计(3) 做完需求 开发(4) 测试(2)

将工作可视化

17

测试人员的任务版

• 测试: 测试个案开立, 检视, 环境准备, 执行, 验证修复结果

• 自动化

• 效能和侦测率调整

• 事件导向: To Do -> In Prog -> Done

18

开发人员的任务版

• 以开发为主

• Backlog -> Do -> Check -> Done

19

项目阶层的任务版

• 提供整体进度的概观

• 显示各个功能目前在那个阶段

20

Scrum of Scrum 每日立会

21

测试人员10:30 AM

Feature team

5:15 PM

专案阶层5:30 PM

Feature team

5:00 PM

目视管理找出坏味道

• 厘清状态

• 以持续改进方式排除多任务

• 确保流程顺畅度

22

坏味道 1: 有不需要或是少列的步骤

• 有些步骤不需要或是没有被列出来

• 要不断调整去呈现现况

23

坏味道 2: 工作流程过度一般化

• 发现很多概念性验证的工作同时在进行

• 重新建构工作流程

24

目视管理找出坏味道

• 厘清状态

• 以持续改进方式排除多任务

• 确保流程顺畅度

25

曾试图利用 WIP limit 解决问题

• 很难归纳公式• 多种类型工作, 多个项目

• WIP limit 只是提醒, 重点是厘清和解决问题

26

利用 Improvement Kata 持续改善

27

2. 理解目前的状态

1. 了解愿景方向

3. 想要达到的下一步的目标

4. 利用PDCA 达到下一步目标

http://hakanforss.wordpress.com/tag/toyota-kata/

坏味道 3: 同时处理不同性质的事情

28

工作流程广告牌 +

工作时间分布

收集信息

专人专职

确认资源

避免开发与维护并行

处理并行状况

29

• 收集信息• 记录处理概念性验证的时间

• 专人专职• 处理开发和维护不同人负责

• 确认有足够资源• 纪录 cycle time 以评断处理速度

坏味道 4: 台面下的多任务

• 老手的困境• 很多人问他问题

• 或是只有他能处理

• 解决方法• 师徒制搭档编程

• 限制最多能处理多少事

30

目视管理找出坏味道

• 厘清状态

• 以持续改进方式排除多任务

• 确保流程顺畅度

31

坏味道 5: 有些步骤做太快

32

很快就完成 或是直接跳过

制定政策

33

设计做完的条件1. 设计需要检视2. 验收测试个案要开立

整合完毕的条件1. 验收测试个案要通过2. 程序代码要检视过

专职架构师 (architect)

• 无法落实• 自顾不暇

• 没空专心检视

• 指派专职架构师• 严格把关

• 经验传承

34

坏味道 6: 有些步骤拖太久

35

不知花多长时间 错误不断被找到

处理修太久又错太多的状况

36

• 先处理既有的错误• 评估和保留修复时间

• 可视化错误处理的状态• 将 bug 贴在开发人员任务板上面

• 由架构师专职检视• 避免修复后带来更多错误

坏味道 7: 有些步骤一直重复发生

• 测试文件来来回回修改很多次

37

利用系统思考来洞察全貌

38

开发人员太忙

要测试多少不明确

设计常变动

需求不明确

测试规格交付延迟

Load

不均衡

请假没有交接

解法整理: 如何补强 Scrum

问题 解法

多项目, 多种不同性质工作 多个工作流程

任务版上的信息不足 详尽的工作流程

人数太多不易使用 Scrum of Scrum

Retrospective 的效果不彰 Improvement Kata

Fishbone + 5 Whys

39

解法整理: 如何观察坏味道

• 有不需要或是少列的步骤

• 工作流程过度一般化• 同时处理不同性质的事情

• 台面下的多任务

• 有些步骤做太快• 有些步骤拖太久• 有些步骤一直重复发生

40

使用 Kanban 后带来的变化

41

凡事可视化

找寻和处理坏味道

形成改善的文化

结论

• 好工具不该只有一种

• 利用痛点来渐进式演化

• 记住! 问题永远在现场

• 善用坏味道

42

有行动才会不一样

43

谢谢

44