如何利用 KANBAN
让 SCRUM 更完美 -
趋势科技看板经验分享
趋势科技 David Ko
[email protected]
1
我是谁?
• 趋势科技, 台湾部门, 品质经理
• 台湾敏捷技术社群发起人之一• “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)
测试人员的任务版
• 测试: 测试个案开立, 检视, 环境准备, 执行, 验证修复结果
• 自动化
• 效能和侦测率调整
• 事件导向: 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