淘宝广告技术部开发流程和Scrum实践

1

淘宝广告技术部开发流程和Scrum 实践

苏宁 ( 铁枪 ) 2010.8.21

课程纲要

• 一 . 引入 Scrum 的过程

• 二 . 我们现在的开发流程

• 三 . 我们如何使用 Scrum• 四 . 应对危机的策略与工具

引入 Scrum 的过程

• 第一个 Sprint– 2006 年

– 淘宝广告技术部前身 :• Yahoo! 中国 P4P 竞价团队

– 梅坚 ( 花名三多 ) 从加拿大引进

– 项目团队 : ContentMatch iMatch– Excel 文件模板工具

引入 Scrum 的过程 (Backlog)

引入 Scrum 的过程 (Burndown)

引入 Scrum 的过程

早期开发流程

简单 Scrum 的特点

• 涉及到的团队和角色较少– 产品、开发、测试

• 开发过程简单， Scrum 过程清晰

• Scrum 过程干扰因素少，不容易被打断– Scrum 周期短，见效快

• 小项目 / 功能 Review 少， Scrum 过程精简

课程纲要



• 三 . 我们如何使用 Scrum• 四 . 应对危机的策略与工具

复杂 Scrum 慢慢开始

• 随着业务增加，产品功能快速增加– 产品功能越来越多，系统越来越复杂

– 有时进行迭代的模块千头万绪

• 有些 Scrum 并不是从项目初期就开始的– 项目进行到一半的时候开始引入 Scrum

• 涉及到的角色增多，团队配合增多– 架构、 PE 甚至客服的直接反馈

– 跨团队合作，跨地域合作

复杂 Scrum 慢慢开始

• “中断”增多– 项目临时需求

– 客户反馈 Bug

– 其他意外导致 Scrum 中断

• 技术驱动项目增加，如何与产品项目进行配合– 系统重构

– 性能优化

各种角色在项目中的作用

• 要了解我们的 Scrum ，首先要先了解我们的开发流程，要了解我们的开发流程，首先要清晰我们的项目角色– 产品

– 架构师

– TL/PM/Scrum Master– 开发

– 测试

– PE


• 产品经理收集产品需求及改进意见

编写需求文档

产品上线验收

• 架构师收集需求对现有系统的改动

出台系统调整方案

业务流程整理

系统整体设计

掌握系统改造成本


• TL/PM/Scrum Master组织 Sprint跟踪项目开发进度

沟通协调

• 测试了解需求，了解改进点

测试用例

模块测试 / 集成测试 / 系统联调

TDD


• 开发模块设计

代码开发 /Review单元测试

内部集成测试

Bug 修复

上线手册


• 运维了解业务需求

了解系统瓶颈

熟悉模块接口和数据接口

故障应对措施

流量增长模型

实际上线操作

新的开发流程

课程纲要



• 三 . 我们如何使用 Scrum

• 四 . 应对危机的策略与工具

Scrum 过程

• 目标一切不以上线为目的的开发都是耍流氓

明确宣讲目标

• 团队配置开发测试比例 2： 1尝试结对编程

Scrum 过程

• 计划会 / 需求沟通会需求点回顾 /罗列需求实现思路讲解

任务分解

• 每日晨会 – 三个经典问题昨天的进展

今天的计划

可预见到的风险或问题

Scrum 过程

• Sprint总结回顾头脑风暴、集思广益

成功

不足

改进方案 : 改进点和时间

Scrum 过程

• 任务分解 WBS

Example.jpeg

Scrum 过程

• 工时预估

课程纲要



• 三 . 我们如何使用 Scrum

• 四 . 应对危机的策略与工具

Scrum 策略与工具

• 和开发坐在一起产品：产品需求能提前快速沟通

架构：更细致的了解实现

测试：和开发配合更密切

运维：关注实现方式，提出合理上线建议

• 案例一– 开发团队经常性的接触跨团队项目，在

Scrum 实施过程中变数较大，产品需求变化，算法模型变化，设计方案变化等等，导致开发修改提交代码过于频繁，测试团队面临众多测试版本不得不安排排期， PE 团队在短时间内面临众多版本的上线，风险大，故障多。

Scrum 策略与工具之倒三角理论

• 案例二–由于业务规则复杂，系统模块众多，往往开发提交了一个改动需求后，测试团队面临着修改变动的测试环境 ( 甚至重新搭建测试环境 ) ，编写测试脚本，准备测试数据等等众多步骤的准备工作，在多方 ( 甚至项目经理 ) 的压迫下，不得不以牺牲测试质量，压缩测试工期来“完成测试任务”，系统上线后风险高，各方人员疲惫。


这些挑战是正三角么？

• 案例一

产品

开发

测试

上线

• 风险随着项目的推进而增加，麻烦也越来越多，解决的成本也越来越高


• 案例二

前期准备

测试环境

测试完成

•测试压力随着时间越来越大，所有人员的心理越来越急躁，测试质量下降

这些挑战是正三角么？


• 是一种风险提示模型，也是一种规避风险的指导工具

• 保证 Scrum结果可持续并有效

• 横向切割维度代表随时间的增长、跨团队的流程、有条理的步骤

• 纵向向下代表风险增加，危机严重，解决成本增加

• 纵向向上表示大局观的增加，主动性的增加


阶段一

阶段二

阶段三

随着时间的增长或者项目的推进，一些不被重视的风险会慢慢的被拖延或者挤压到下游，造成当项目验收时，被扩大的风险才被重视，这时很有可能为时已晚。一个 Scrum 能解决的问题不要带到下一个Scrum。


阶段一

阶段二

阶段三

解决的办法就是要在早期发现并定义风险，在执行的过程中，所有流程都参照上游解决风险的办法去解决在本阶段的部分风险，当到达最后的流程时，绝大部分风险已经在项目过程中消耗掉。


• 道理很简单，难的是发现总结并去解决问题

风险危机增加

更多的主动性规避风险


如何解决危机？• 案例一

• 我们的风险 ( 危机 ) 是上线频繁，叠加严重– 按照倒三角的思考方式，产品或者算法团队在提出需求是要真正

的“深思熟虑”，是否有可以整合的需求？是否所有的需求都有预期的性价比？

– 架构设计阶段，我们的架构师是否能看的足够远，看的足够深，我们的系统模块之间是否关系合理，是否能适应未来需求的变化。

– 系统开发阶段，我们的工程师是否能提供可重用的代码，是否可以编写更加灵活的模块，是否可以将不同的功能在代码阶段做以整合。

– 我们的测试工程师是否真的理解了我们这次上线是为了解决什么问题？测试环境可以直接使用并重用么？测试用例足够了么？

– 上线阶段，我们的 PE 是否做好了足够的准备，有了得心应手的工具？我们的安装包是否合理？出现危机是否有了应对之策 (所有重大上线项目都有回滚说明么？虽然我们不愿看到回滚这两个字 )


如何解决危机？

产品：合理整合需求

架构开发：合理设计系统，重用开发

测试：测试用例充足，环境清晰

上线：充分准备，做好后备计划



• 案例二

• 我们的风险 ( 危机 ) 是系统复杂，测试压力大– 我们的开发工程师是否真的体谅测试 mm 们的辛苦，我们的代码真正自测过吗？我们是否过于自信或者自大？我们设计的系统真的是灵活易用么？

– 测试阶段，测试的同学真的了解产品需求么？为什么会有这次测试？系统修改了哪些地方？

– 我们的测试用例准备充足么？我们的测试环境可以重用么？我们有测试数据么？

– 我们有足够灵活的自动化测试机制么？



开发：清晰的测试提交单，充分

的单元测试

测试：了解产品需求，理解系统设计

测试用例充足，测试环境清晰

重复工作请交给自动化测试处理



• 倒立看世界，同样我们也要倒立着看待风险，将各种风险和麻烦扼杀在项目初期。

• 前期 ( 上游 )准备的越成功，后期 (下游 ) 进展的越顺利， Scrum 的目标越容易达成。

• 多为他人考虑，上下游互为客户，换位思考

• 倒三角更多的是一种自我驱动的思考工具


Scrum 策略与工具

• Sprint 工具ExcelSharePoint + ProjectXplannermindmap

淘宝广告技术部开发流程和Scrum实践

Technology

Transcript of 淘宝广告技术部开发流程和Scrum实践