敏捷研发二三事
RSG(Regional Scrum Gathering)这两天在上海召开，看了下朋友圈里的分享主题，颇有感触。敏捷研发走过这么多年，很多地方依然是李逵与李鬼并存，很多时候过多地谈论术而忽视了道的本源，于是便想窥一下敏捷的前世今生，为自己作下梳理和总结。
敏捷宣言是怎么回事
2001年2月11-13日，包括Kent Beck、Martin Fowler、Robert C. Martin在内的17人在一起思维碰撞产生了敏捷宣言。 在那个时候，敏捷研发及其相关的方法论包括XP、Scrum等都属于软件工程的边缘地带，人们关注的更多的是流程、计划和文档。
2001年软件发布的周期往往长达1年至数年（一些通信设备软件直到2007年的时候1年才发布一个版本更新）。而现在很多公司一周甚至一天发布几个版本，如facebook的web端在2016年之前每天发布3个版本，之后更是演进到准持续发布的阶段，而它的移动端现在也达到一周一个版本的发布频率。
敏捷软件开发宣言
英文版 我们一直在实践中探寻更好的软件开发方法， 身体力行的同时也帮助他人。由此我们建立了如下价值观：
- 个体和互动 高于 流程和工具
- 工作的软件 高于 详尽的文档
- 客户合作 高于 合同谈判
- 响应变化 高于 遵循计划
也就是说，尽管右项有其价值， 我们更重视左项的价值。
思想与实践
敏捷研发的本质是拥抱变化，快速地响应客户需求，无论采用何种模型，我们的最终目的都是要快速、准确、高质量地满足客户需求。
常见的实施方法有Scrum和看板等。
Scrum
1986年，竹内弘高和野中郁次郎提出了这个方法。1991年，DeGrace和Stahl在《Wicked Problems, Righteous Solutions》一书中将这种方法称为scrum。 Scrum是一个英式橄榄球术语，有团队整体前进的意思。
Scrum中的角色定义
有一个很形象的故事来描述scrum中的角色定义：
一天，一头猪和一只鸡在路上散步。鸡对猪说：“嗨，我们合伙开一家餐馆怎么样？”猪回头看了一下鸡说：“好主意，那你准备给餐馆起什么名字呢？”鸡想了想说：“叫‘火腿和鸡蛋’怎么样？”“那可不行”，猪说：“我把自己全搭进去了，而你只是参与而已。”
按照猪和鸡这两种参与特点，可以把角色分为两类：
- Scrum Team
一个scrum team是自组织的，通常的规模在5-8人，一般不会少于4人，也不会多于10人，团队中包含完成一个需求所需要的各种角色，如研发、测试、运维等，他们作为一个整体前进。
- Scrum Master
scrum master的作用是促进scrum流程的顺利完成，减少scrum团队遇到的各种干扰，保证sprint的顺利完成，通常建议scrum master不属于某一个scrum team
- Product Owner
产品负责人，通常是客户需求的代表，负责编写用户故事，安排优先级
这些是全搭进去的
- User
用户，软件的具体使用者，软件开发出来的目标群体
- Stake Holder
影响项目成功的人，如公司股东、客户、提供商等
- Manager
维护组织架构，为团队提供环境支持，通常一个manager会同时负责几个scrum team
这些只是参与而已
Sprint
一个scrum的研发单元称为一个sprint（冲刺），时间为1~4周，在一个sprint的开始会计划出这个sprint需要交付的目标，在sprint的结束的时候会对sprint作评审和回顾，包括交付目标和工作方式方法。
每日站会
scrum最为人所知的就是每日站会。所谓每日站会，是指：
- 每天的固定时间
- 在固定地点
- scrum team的所有成员参与
- 欢迎其他人参与，但只有“猪”可以发言
- 所有人保持站立
- 时间不超过15分钟
- 每个人回答三个问题：
- 昨天我做了什么
- 今天打算做什么
- 完成目标有什么障碍
Scrum的常见工具
- Product Backlog
产品的需求订单，按照优先级从高到低排列，粒度较粗，包含粗略的估计，单位有时为小时，也有用故事点（story point）的，用story point的做法一般是以一个过往的需求作为参考，假设完成那个需求需要1个story point，以相对的方式来估计需求。
- Sprint Backlog
一个Sprint（1~4周）的任务订单，同样按照优先级从高到低排列，粒度细得多，包含较精确的估计，任务需要拆分得足够细，通常1个人在1~2天内可以完成。
- Burn down chart
燃尽图，用来显示一个sprint未完成任务的情况
Scrum实践的常见问题
- 团队成员能力差异较大，且不经常轮换任务
- 传统的Manager在这个模式下定位模糊，容易成为障碍
- 项目经理出身的PO过多干预scrum team的具体工作
需要注意的是：
scrum实践中scrum team是自组织的，包括计划、评审和回顾，都是team自身完成的，不需要也不应该有其他人来主导这些事情（像PO，Manager可以参与）。
一个完整的scrum框架见下图：
看板
看板实践来自于丰田汽车，之后被应用到软件研发领域。 相对于Scrum的各种角色定义和实践会议，看板要简单不少。想直观的感受下看板，可以在TAPD上创建一个看板试一下，同时可以尝试将披萨游戏用看板的方式画出来。
看板的特点是：
- 从现在开始
- 渐进式地改变
- 尊重当前的流程、任务、职责和职位
- 奖励每一项改进
通常看板的实践包括：
- 将整个流程可视化
通过将整个流程以可视化的方式呈现出来，便于发现流程的问题以进行改进Kanban board example.jpg
- 限制在制品（WIP）
简单来说就是减少库存，WIP越多，说明流程越不顺畅，一个完美的系统是做到零库存
- 明确每个阶段间的转移标准
比如In Test => Done，必须有明确的标准 一个较完整的看板示例见下图：
做我们产品发布后的第一批用户
上图是facebook的准持续的“push-from-master”系统。 功能提交，经过自动化测试系统，会被自动合并入master，master上的变更会被自动部署到内部员工系统上，而后是2%的生产环境，再是100%的生产环境。
这里可以看到facebook的web系统使用者从先到后是这样的：
- 自动化测试
- 内部员工
- 2%外部用户
- 100%外部用户
有一句话叫“eat your dog food”，经常使用我们自己开发出来的系统，才能更好地了解它，发现它存在的问题，进而更好地改进它。包括以功能测试的形式或系统测试的形式去经常性地使用它。
人、习惯和工具：缺一不可
敏捷研发比传统的瀑布研发对人有更高的要求，它要求人的技能的多元化，要求团队的混合组成，要求团队的自组织能力。 同时它要求团队培养一个固定的步调来交付产品。 实践上工具有很重要的地位，无论是为了提高测试效率而引入的测试自动化框架，还是看板可视化面板，还是持续交付平台，都需要工具团队付出相当的努力才能完成。 这方面google和facebook堪称业内表率，他们把工具研发摆在相当重要的位置，从SDN等网络基础设施，到全链路监控平台，到测试工具如webdriver，无处不见工具团队的身影。