敏捷开发，洋媳妇儿在中国，为何总当不了家？

敏捷开发模式起源于上世纪90年代末，从国外引入中国企业，是个不折不扣的“洋媳妇儿”。每每有企业期望将她融入自己的研发体系之中委以重任，却总碰上无穷无尽的问题。究竟哪里有错？天旦为什么能成功？很多人问，但这是第一次，天旦将敏捷开发的成功经验整理成文。

远不算悠久却已经开始被遗忘的计算机历史上，最初的程序员竟然是一位颜值与智慧并存的女性——Ada Lovelace，意识到计算机的巨大潜力、开启计算机科学的首位程序员。而当程序员这一工种成为前景广阔的职业后，「大男孩们」很快蜂拥而来，把女性排挤出去，甚至大言不惭地说出「女性从生理上不适合做代码开发工作」这种性别歧视语言。

但是，时代在不断变化。随着信息技术深入地融入人们的生活并深刻地改变了生活的形态，用户对于软件的需求也在不断变化。以商业软件为例，过去充分调研用户需求进行定制开发的软件项目，以年为单位规划漫长的开发周期，为用户量身定做的交付产品冠以「解决方案」之名。这种模式下，不到瀑布流的最后一关“测试部署”，无法见到开发成果，可到了测试阶段才发现早期的设计失误怎么办？一年后用户的需求翻了篇又该如何是好？无法成倍增长的研发团队面对无穷无尽的错误修复与用户需求变化；依靠按时交付保证收入来源的企业，面临单个项目就面临过高的成本与风险。

- 瀑布式开发流程 -

因此，天旦在成立之初就选择了另一条道路——企业级软件产品之路。天旦通过持续发掘和探索产品需求，创造满足普遍市场需求的通用性软件产品、而非定制化或抄近路的投机取巧，灵活应对市场变动而迭代进化，循序渐进地持续升级实现功能演进和性能提升。这条路为天旦研发团队带来了高标准、严要求的巨大挑战：过去按部就班的瀑布式开发流程让产品交付周期无比冗长而迟缓，但企业级软件产品的通用稳定遇上频繁的需求变化，如果再把研发工程师当作螺丝钉标准化运转就无法实现产品高效迭代工作的量与质。于是，敏捷开发的理念与模式在天旦选择企业级软件产品之路的伊始就开始萌芽。

相比「顺流而下」的瀑布模型，敏捷开发是截然不同的软件产品开发方式——集中全力优先实现能满足80%用户需求的两成核心功能，然后根据市场情况随时灵活调整开发计划和迭代路线。敏捷开发是80/20原则在软件生产领域的深刻贯彻。

- 敏捷开发与瀑布式开发的本质区别 -

敏捷开发起源于上世纪90年代，当其理念在天旦研发团队萌生之时，国内投身敏捷开发实践的企业并不多，成功者更是寥寥。就连在国外，Google公开表示研究应用敏捷开发方法的公开报道也要到2008年Forbes《Google's 'Agility'》一文。

起初，天旦的研发工程师们不得不靠自己去翻阅外文材料，循序渐进摸索尝试。敏捷开发的具体方法和框架很多，经过比较，研发工程师们最终选择了Scrum这个框架，原因有三点：

- Scrum原则 -

按照Scrum，研发团队重新调整部门组织架构，将过去瀑布模型下的岗位划分打散，以任务为单位组建了多个小规模但五脏俱全的开发分队，每个分队中同时包含代码编写工程师、测试工程师、代码审阅工程师等成员，使得每一个小分队都是一个可以独立完成整个开发流程的精锐队伍——是的，Scrum这种军事气息浓厚的架构发明人之一Jeff Sutherland正是一名毕业于西点军校、参加过越战的战斗机飞行员。

在天旦，小分队的名字透露了研发工程师们纳言外表之下的丰富个性：

Python语言的标志是蛇，所以Python小分队取了不同蛇的拉丁学名；Java语言的标志是咖啡，自然给了小分队各种咖啡命名的启发；C++小分队像《名侦探柯南》里的黑衣人组织一样用不同的酒来命名；而小分队们负责的项目代号则使用了高斯、玻尔等数学家的名字，纪念作为计算机科学基础的数学科学。

这种小型的精锐开发小分队以结果为导向，按照任务需要组建，开发任务交付后就会解散、重新按照新的任务进行编组。在不断变化的组织中，有三种角色是不变的：

用一句话说，Product Owner决定「做什么」，Scrum Master保障「做得顺」，而具体任务的哪些部分由谁以什么方式完成，是担任Development Team角色的成员们自己认领、自行决定的。

在多年后的今天，包括腾讯这样的国内互联网巨头也已经在实践敏捷开发，但是众多软件公司在实践时失败的概率十有八九，最后还是不得不回退到过去的职责编制。很多公司主管在接触到三种角色后就犯嘀咕：团队里没有人监督大家干活，不会偷懒撂挑子吗？

在天旦的实践中，通过三大支柱避免这一情况、保障任务的顺利完成：

瀑布模式下产品开发周期很长，所以研发部门往往以季度甚至年为单位进行规划和总结；而在Scrum的敏捷开发框架中，一切任务以一个最小周期Sprint（冲刺）为单位，一般为两周到一个月；假如某一任务预计无法在单个Sprint内完成，必须进行拆分，变成多个单Sprint子任务。Sprint是Scrum的核心，是分装任务的「时间盒」，在Sprint结束后，小分队必须交付出任务要求的产品或成果，然后启动下一个Sprint。

造成产品经理和研发工程师矛盾的一大原因，就是产品经理提出的不断调整的需求，使得研发工程师的投入打水漂。在Scrum中，一个Sprint要做的任务，在提前两周的周期性会议上就已经确定，而在Sprint执行中，Scrum Master会阻止任何干扰执行的因素（包括产品经理），因此开发小分队可以心无旁骛地完成自己的工作。

在Sprint执行期间，研发小分队每天一早都会举行简短站会，作为任务进度确定的「定期检查」。小分队的看板上清晰地展示了积压任务、执行状态、完成数量以及该Sprint的燃尽图，分队成员对彼此的工作量和产出状态一目了然。而在多年实践后，纸质看板变成了显示在大屏幕上的工作流软件，通过专业的项目管理工具更高效、更直观地呈现了任务状态，并且方便小分队进行统筹和成员个体安排。

随着天旦研发工程师们对Scrum的实践逐渐熟练和深入，工程师们开始引入各种方法来提高任务的完成效率：像通过自动化的任务系统，开发完成的代码提交后会自动触发代码审查，不需要工程师手动提请；自主研发的集成测试工具Mercury，线上提交代码之后马上可以进行测试，测试用时减少了一半；早在2014年，工程师们就开始在docker上进行每日构建测试，保证产品稳扎稳打的高品质研发……这些通过自动化提高效率的尝试是非常有价值的成功经验，以后会专门撰文分享。

很多友商羡慕天旦能够做到这些突破，当然也羡慕促成这一切成功的敏捷开发实践。也曾有天旦的某股份制商业银行用户领导亲自来到天旦办公室参观解惑，“为什么敏捷开发在天旦活得有声有色，而在我们组织内却不那么顺利？”

天旦研发总监William Cai曾表达：“在人们印象中，研发人员整天与代码为伍活在自己的世界里，好像刻板、无聊、不善交流。在天旦，研发部门的每一位成员都拥有强大的能量，我们尊重每位研发工程师的个体价值，给予团队创新的空间。我们认为，在产品中凝结的代码之美，不仅是隐藏在「优化了○性能……修复了○BUG……实现了○新功能」的只字片语之下，更是集结在另一种语言中的智慧之美。我们尊重、欣赏，并鼓励大家创造这种美。”

没错，这就是敏捷开发在天旦能够成功生根发芽的关键所在——理解技术的价值和工程师的力量。而这种独特的企业文化也与天旦创始人大部分是技术派出身息息相关。天旦从创立之时就贯彻自下而上的自治式组织架构，给了工程师们发挥主动性、实现自身信念的自由和空间。「企业级软件产品公司」这个定位并非一句空洞的口号，而是贯彻在天旦每一个角落、每一个人身上落于实践的目标。所以，天旦才有了不断学习成长、创造行业顶尖产品的顶尖产品团队；才有了紧跟产品规划、使命必达、按时交付的强大研发战斗力，才有了天旦一系列深受用户喜爱、被广大客户选择的优秀产品。

尊重工程师的个体价值、尊重他们的个人实现，也就要将他们看作是拥有无限可能和成长潜力的「人」。与其他企业给机器质量与产量贴标签式的Px评级不同，天旦对工程师的评价系统是对工程师们在不同方向和不同技术上的工作能力平级——就像角色扮演游戏的技能树一样，技术评级直观展现了工程师们的各项「属性点」，也成为他们自我成长、不断变强的方向指引。「目标是全栈制霸」，对吧。

吸引了全球亿万老少观众、创造了巨大票房的漫威宇宙中，超级英雄们集结成伍，组成了足以弑神的「复仇者联盟」。他们被粉丝喜爱不仅仅是因为拥有强大的力量，还因为他们和每个人一样，也有自己的挣扎和苦痛，同时也有拼上一切去守护的珍贵之物。你期待敏捷开发能像复联一样发挥出1+1＞2的力量，却甩出索科维亚协议想让研发工程师们惟命是从，结局会不会好看你自己知道。