*
淘宝广告技术部开发流程和Scrum实践
苏宁(铁枪)
课程纲要
一. 引入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并不是从项目初期就开始的
项目进行到一半的时候开始引入Scrum
涉及到的角色增多，团队配合增多
架构、PE甚至客服的直接反馈
跨团队合作，跨地域合作
复杂Scrum慢慢开始
“中断”增多
项目临时需求
客户反馈Bug
其他意外导致Scrum中断
技术驱动项目增加，如何与产品项目进行配合
系统重构
性能优化
各种角色在项目中的作用
要了解我们的Scrum，首先要先了解我们的开发流程，要了解我们的开发流程，首先要清晰我们的项目角色
产品
架构师
TL/PM/Scrum Master
开发
测试
PE
各种角色在项目中的作用
产品经理
收集产品需求及改进意见
编写需求文档
产品上线验收
架构师
收集需求对现有系统的改动
出台系统调整方案
业务流程整理
系统整体设计
掌握系统改造成本
各种角色在项目中的作用
TL/PM/Scrum Master
组织Sprint
跟踪项目开发进度
沟通协调
测试
了解需求，了解改进点
测试用例
模块测试/集成测试/系统联调
TDD
各种角色在项目中的作用
开发
模块设计
代码开发/Review
单元测试
内部集成测试
Bug修复
上线手册
各种角色在项目中的作用
运维
了解业务需求
了解系统瓶颈
熟悉模块接口和数据接口
故障应对措施
流量增长模型
实际上线操作
新的开发流程
课程纲要
一. 引入Scrum的过程
二. 我们现在的开发流程
三. 我们如何使用Scrum
四. 应对危机的策略与工具
Scrum过程
目标
一切不以上线为目的的开发都是耍流氓
明确宣讲目标
团队配置
开发测试比例2：1
尝试结对编程
Scrum过程
计划会/需求沟通会
需求点回顾/罗列
需求实现思路讲解
任务分解
每日晨会 – 三个经典问题
昨天的进展
今天的计划
可预见到的风险或问题
Scrum过程
Sprint总结回顾
头脑风暴、集思广益
成功
不足
改进方案: 改进点和时间
Scrum过程
任务分解WBS
Scrum过程
工时预估
课程纲要
一. 引入Scrum的过程
二. 我们现在的开发流程
三. 我们如何使用Scrum
四. 应对危机的策略与工具
Scrum策略与工具
和开发坐在一起
产品：产品需求能提前快速沟通
架构：更细致的了解实现
测试：和开发配合更密切
运维：关注实现方式，提出合理上线建议
案例一
开发团队经常性的接触跨团队项目，在Scrum实施过程中变数较大，产品需求变化，算法模型变化，设计方案变化等等，导致开发修改提交代码过于频繁，测试团队面临众多测试版本不得不安排排期，PE团队在短时间内面临众多版本的上线，风险大，故障多。
Scrum策略与工具 之 倒三角理论
案例二
由于业务规则复杂，系统模块众多，往往开发提交了一个改动需求后，测试团队面临着修改变动的测试环境(甚至重新搭建测试环境)，编写测试脚本，准备测试数据等等众多步骤的准备工作，在多方(甚至项目经理)的压迫下，不得不以牺牲测试质量，压缩测试工期来“完成测试任务”，系统上线后风险高，各方人员疲惫。
Scrum策略与工具 之 倒三角理论
这些挑战是正三角么？
案例一
产品
开发
测试
上线
风险随着项目的推进而增加，麻烦也越来越多，解决的成本也越来越高
Scrum策略与工具 之 倒三角理论
案例二
前期准备
测试环境
测试完成
测试压力随着时间越来越大，所有人员的心理越来越急躁，测试质量下降
这些挑战是正三角么？
Scrum策略与工具 之 倒三角理论
是一种风险提示模型，也是一种规避风险的指导工具
保证Scrum结果可持续并有效
横向切割维度代表随时间的增长、跨团队的流程、有条理的步骤
纵向向下代表风险增加，危机严重，解决成本增加
纵向向上表示大局观的增加，主动性的增加
Scrum策略与工具 之 倒三角理论
阶段一
阶段二
阶段三
随着时间的增长或者项目的推进，一些不被重视的风险会慢慢的被拖延或者挤压到下游，造成当项目验收时，被扩大的风险才被重视，这时很有可能为时已晚。
一个Scrum能解决的问题不要带到下一个Scrum。
Scrum策略与工具 之 倒三角理论
阶段一
阶段二
阶段三
解决的办法就是要在早期发现并定义风险，在执行的过程中，所有流程都参照上游解决风险的办法去解决在本阶段的部分风险，当到达最后的流程时，绝大部分风险已经在项目过程中消耗掉。
Scrum策略与工具 之 倒三角理论
道理很简单，难的是发现总结并去解决问题
风险危机增加
更多的主动性规避风险
Scrum策略与工具 之 倒三角理论
如何解决危机？
案例一
我们的风险(危机)是上线频繁，叠加严重
按照倒三角的思考方式，产品或者算法团队在提出需求是要真正的“深思熟虑”，是否有可以整合的需求？是否所有的需求都有预期的性价比？
架构设计阶段，我们的架构师是否能看的足够远，看的足够深，我们的系统模块之间是否关系合理，是否能适应未来需求的变化。
系统开发阶段，我们的工程师是否能提供可重用的代码，是否可以编写更加灵活的模块，是否可以将不同的功能在代码阶段做以整合。
我们的测试工程师是否真的理解了我们这次上线是为了解决什么问题？测试环境可以直接使用并重用么？测试用例足够了么？
上线阶段，我们的PE是否做好了足够的准备，有了得心应手的工具？我们的安装包是否合理？出现危机是否有了应对之策(所有重大上线项目都有回滚说明么？虽然我们不愿看到回滚这两个字)
Scrum策略与工具 之 倒三角理论
如何解决危机？
产品：合理整合需求
架构开发：合理设计系统，重用开发
测试：测试用例充足，环境清晰
上线：充分准备，做好后备计划
Scrum策略与工具 之 倒三角理论
如何解决危机？
案例二
我们的风险(危机)是系统复杂，测试压力大
我们的开发工程师是否真的体谅测试mm们的辛苦，我们的代码真正自测过吗？我们是否过于自信或者自大？我们设计的系统真的是灵活易用么？
测试阶段，测试的同学真的了解产品需求么？为什么会有这次测试？系统修改了哪些地方？
我们的测试用例准备充足么？我们的测试环境可以重用么？我们有测试数据么？
我们有足够灵活的自动化测试机制么？
Scrum策略与工具 之 倒三角理论
如何解决危机？
开发：清晰的测试提交单，充分的单元测试
测试：了解产品需求，理解系统设计
测试用例充足，测试环境清晰
重复工作请交给自动化测试处理
Scrum策略与工具 之 倒三角理论
如何解决危机？
倒立看世界，同样我们也要倒立着看待风险，将各种风险和麻烦扼杀在项目初期。
前期(上游)准备的越成功，后期(下游)进展的越顺利，Scrum的目标越容易达成。
多为他人考虑，上下游互为客户，换位思考
倒三角更多的是一种自我驱动的思考工具
Scrum策略与工具 之 倒三角理论
Scrum策略与工具
Sprint工具
Excel
SharePoint + Project
Xplanner
mindmap
Q & A
