敏捷开发在传统银行的实践经验

前言

笔者09年的时候在Sybase工作，那时候公司就在内部开始推广极限编程XP（ExtremeProgramming），当时是第一次听说这个名词当时公司也做了一个敏捷培训，从培训中了解到了在当时硅谷XP已经大行其道，而且当时亚马逊、微软、IBM都已经实施了XP，Sybase美国总部也已经用XP在软件开发方面实施了一年多，反响都是很好的，XP其实和现在的Scrum、Kanban的核心思想其实是一样的，但是XP更倾向于软件开发，Scrum和Kanban更聚焦在项目管理的全流程。当时的Sybase美国总部那边很多项目都已经做到了敏捷需求管理、TDD、CI和小迭代发布版本，当时亲眼看到这样的全自动的持续集成和快速迭代版本发布还是很惊讶的，一对比当时国内的软件公司，简直就是天与地的差别，后来去了传统银行从事了6年开发也印证了当时的看法。后来所在的银行也顺应潮流实施了敏捷，后来还去了互联网公司也实施了敏捷，本篇文章就讲述下当年在传统银行实施敏捷开发和项目管理方面的一些感想和实践经验。因为全程参与了传统银行的IT项目的敏捷改造，并且传统银行的IT项目也比较有代表性，基本代表了目前主流的传统IT项目，改造的实施过程对于其它传统IT项目也有一定的参考性。

1.什么是Scrum

Scrum 是一个用于开发和维护复杂产品的框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周(互联网产品研发可以使用1周的Sprint)。在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint backlog。在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。 Scrum起源于软件开发项目，但它适用于任何复杂的或是创新性的项目。

scrum流程

SCRUM框架包括3个角色、3个工件、5个事件、5个价值

3个角色

产品负责人（Product Owner）
Scrum Master
开发团队

3个工件

产品Backlog
SprintBacklog
产品增量

5个事件

Sprint（Sprint本身是一个事件，包括了如下4个事件）
Sprint计划会议（Sprint Planning Meeting）
每日站会（Daily Scrum Meeting）
Sprint评审会议（Sprint Review Meeting）
Sprint回顾会议（Sprint Retrospective Meeting）

5个价值

承诺 – 愿意对目标做出承诺
专注– 把你的心思和能力都用到你承诺的工作上去
开放– Scrum 把项目中的一切开放给每个人看
尊重– 每个人都有他独特的背景和经验
勇气– 有勇气做出承诺，履行承诺，接受别人的尊重

这里我就不详细描述scrum的这些关键要素了，只是给大家罗列了下，相信看这篇文章的同学多少对敏捷还是有一定了解的，如果不了的同学可以网上搜搜就知道了。

2.传统银行IT项目管理流程

在传统银行工作了6年，对于传统银行的IT项目管理流程也是比较熟悉的，下面先说下传统IT项目的流程，基本都是这个套路：

传统IT项目一般的流程都是业务经理搜集了客户的需求，将这些客户的共性需求整理成了粗糙的项目需求条目‘
业务产品经理接收到这些零散的需求条目后，会将这些需求条目进行整理，整理成比较规范的PRD需求文档;
业务产品经理会将需求拿去进行需求评审；
需求评审通过后，科技部门的架构师会收到通过需求评审的需求，进行技术方案制定；
架构师制定好技术方案后，拉着各个关联产品进行方案评审；
在方案评审通过后，项目经理会制定项目计划，并制定项目预算表等等；
分别进行项目计划评审和项目预算评审；
这些项目类评审都做完后，项目经理会和相关产品一起进行项目排期；
制定好实施排期计划后，项目经理才会安排开发项目组进行项目开发工作；
开发项目组开发完成后，接下来会进入SIT测试，SIT测试完成后会进入UAT测试，UAT测试完成后会发布生产版本；
运维人员拿到生产版本后会在约定的批次投产时间进行投产工作；

这个流程看着每个评审写的都很简单，经历过传统项目评审的应该都知道，这个评审的过程一般是比较耗时的，虽然说整个流程中一般不会有什么实质性的阻拦或者问题，但是就是会在各个环节耽搁很多时间，导致一个需求要经过三个月左右才能真正进入开发阶段，最后投产还需要运维人员进行版本部署。可见这个流程全部走下来是非常艰难的，需要耗费非常多的时间用户才能看到我们的新功能，就算是比较小的需求基本也是要等到半年后才能与用户见面，那时候可能用户已经找到了替代方案或者根本不需要这个功能了。

3.敏捷迭代开发在互联网公司的应用

敏捷开发是这几年炒的非常热的一个概念，国内基本上是在2010年开始，在各个互联网公司开始普及敏捷开发，主流的敏捷开发模型就是Scrum、Kanban，Kanban和Scrum对比起来没有本质上的区别，也不用在意这两个的区别细点到底是什么，因为我待过的3家公司都实施过敏捷但是每家都是变种，都按照自己公司的情况和项目的情况进行过调整，没有一家是完全按照模型去实施的。

2016年的时候我所在的一家互联网电商公司内部也在推广敏捷，但是实施方式上和之前在传统银行实施的敏捷开发也有比较大的区别，下面我介绍下当年所在的互联网公司的敏捷是如何实施的。我们都知道敏捷开发的核心理念是拥抱变化，互联网项目的最大特点就是变化快，每个项目都是需要在很短的时间内完成，为了在互联网的世界存活下来只有快，要经快上线才能获得市场的认可，最近比较火的吃鸡游戏，腾讯游戏300人的团队采用3班倒的方式进行开发，人停代码不停，这让我想到了富士康。。。人停机器不停，倒班制居然出现在了互联网科技公司，这也从侧面说明了必须要快速、拥抱变化才能赢得胜利。

下表是我们迭代中几个关键的时间点：

	周一	周二	周四	周五
迭代1第一周	迭代计划会			下轮迭代预排期
迭代1第二周		下轮迭代排期, 提交本轮迭代测试版本		本轮迭代总结会
迭代2第一周			上轮迭代版本投产
迭代2第二周

下面按时间轴来说明下我们每轮迭代每天的工作，我们迭代是以两周为一个迭代，共计10个工作日，下面我就描述一个需求经过的全过程（迭代1-1表示迭代1第一天，迭代1-2表示迭代1第二天以此类推）

迭代1－1至迭代1-7:开发人员进行本轮迭代开发工作；

迭代1-5:PMO、产品经理、产品开发负责人召开下轮迭代预排期会，这个预排期主要是根据本轮开发的情况，评估下轮迭代可以排入迭代进行开发，这个时候开发负责人需要首先评估下轮迭代有几个人力可以使用，还需要参考产品经理当前接到的所有需求，进行评估哪些可以排入下轮迭代进行开发，这里的评估是非常考验开发负责人的经验，需要负责人对自己的手下足够了解，并且一般要预留20%－30%的人力作为储备，用于处理紧急需求和一些紧急的bug，互联网公司的紧急需求是非常多的，所以一定不要相信产品经理说需求就这么多了。。。

迭代1-7:迭代第二周周二是下轮迭代的正式排期，这个排期会有所有提需求的产品经理和开发负责人、测试负责人、所有PMO参加，这个会议每次参加都像菜市场一样，各种争吵，亲眼见到有产品妹子被开发负责人骂哭，每次的场景都是非常壮观的，现场也非常的混乱。大家互相讨价还价，你能做了还要看其它产品能不能做，这还是非常考验产品经理协调能力的，牛的产品经理基本都可以把其它产品经理的需求挡下去，让自己的需求排进开发计划；

迭代1-7:同时迭代第二周周二还有一个非常重要的任务就是提交SIT版本给测试团队，这个是迭代中非常重要的一个里程碑时间点，这个时间点如果不能按时提交测试版本，那么就意味着缩短了测试的时间，意味着产品测试可能不充分，上线后存在bug的风险就会提高；

迭代1-10:迭代第二周周五下午一般本轮迭代的开发任务和bug修改也都完成了，可以召开下本轮迭代的总结会，让大家把遇到的问题提出来，负责人后续可以去改进，来不断帮助大家提高开发效率；

迭代2-4:迭代2第一周的周四，是我们公司的版本发布日，当天晚上运维会进行版本部署和APP上架，公司已经实现了半自动的devops，3个人完成70多个系统的生产日常运维版本部署，当时觉得这方面做的还是很完善的，完全释放了运维人员的工作，同时也减少了人为出错的可能性；

整个迭代还是比较紧凑的，工作的节奏非常快，当时我作为门户移动端的负责人，每天都非常忙，被各种评审和组内日常管理牵制了太多精力，和各个产品协调也是一件非常累的事情。这个流程整个公司所有项目都是这么运作，所以总流程还是比较顺利的，但是各个产品的bug都是挺多的，后来我们在一起回顾bug多的原因的时候发现主要有以下几点：

需求变化比较频繁
缺少充分的回归测试
跨系统架构方案设计常常考虑不完善

这几个问题，也是在敏捷迭代中比较常见的问题，需求变化频繁这个问题，我相信在任何一家互联网公司都存在需求变化频繁的问题，这个问题用Scrum官方解释的解决办法就是将在迭代中提的需求放到product backlog中，排到下轮迭代中开发，但是在实际中，所有的产品经理都会要求就放在这个迭代完成，这就产生了需求和开发的矛盾，一般来说都是按照老板要求开发加班把需求完成，目前我是没找到太好的办法。

缺少充分的回归测试，这个问题对于国内大型互联网公司目前基本都没这个问题了，都已经实现了高自动化的CI，每完成一个功能代码提交到git后就会自动触发CI，完成静态代码复查、单元测试、版本构建、版本部署、功能自动化回归等功能。而且这些过程往往都在很短的时间完成，开发人员马上就可以知道自己提交的代码是否有问题，是否影响到了其它代码，这是非常好的一种体验。但是这个对于很多小公司来说是很难实现这样的自动化CI的，我们当时其实规模也不算小，但是在整个CI的搭建是完成了，并且完成了大部分的步骤，除了单元测试和功能自动化测试，其它都已经完成了，但是就是因为少了这两步，导致整个CI过程是不完整的，这个CI流程从运维人员角度看，可能是已经完成全部的自动化了，但是从开发人员和测试人员的角度来看，都缺少了关键的环节回归测试。单元测试是针对开发人员的回归测试，国内的程序员基本没几个有单元测试习惯，大部分都是写完代码，run一下自己用接口工具或者和功能测试人员一样点两下就完成了所谓的内部测试，之前在sybase的时候，发现老外的单元测试代码量是超过源码量的，当时不能理解为什么开发要写那么多的单测代码，后来看了他们的单测代码才知道，单测代码是针对代码逻辑分支都编写了不同的案例，所以源码写了一个if else就针对了至少两条unit test case，这样自然就比源码多了。目前国内的开发迭代任务都没有考虑单测的时间，都是满打满算开发新功能产能，所以产生了一个恶性循环，要让开发人员养成编写单测的习惯，一方面是要求开发人员提高意识和能力，另一方面也要求产品经理能够控制迭代需求的节奏。还有一块是功能自动化测试，这个对于目前国内的测试人员要求是有点高了，目前国内的大部分测试都还停留在手工测试阶段，一些大的互联网公司已经完成了高度自动化的功能测试，一旦有了单元测试和功能自动化测试的保驾护航，开发人员对于自己写的代码也比较有信心，代码也能做到每次提交后CI跑完就是可部署可执行的产品。

最后一个比较常见的问题就是跨系统架构设计考虑不完善，这个问题之前很多人都将这个问题的根因归类到敏捷开发没有做总体设计和详细设计导致了该问题，但个人觉得这不是主要原因，主要原因还是公司架构师的能力问题，如果一帮对自己系统都不是很了解的人做架构师，然后一群不懂的架构师坐在一起讨论架构方案，那出来的方案必定存在各种漏洞，所以解决这个问题最好的办法就是，各个产品的架构师最好不是空降，而是从自己的开发团队中选出对系统最熟悉的人去担任这个角色。

总的来说在互联网公司实施敏捷的感受还是很带感的，痛并快乐着。

4.传统银行使用敏捷遇到的问题和实践经验

上面大概介绍了下我当时在互联网公司实施敏捷的一些经验，下面再说下前几年在传统银行实施敏捷遇到的问题，这个可能对更多要试试敏捷的公司有参考价值，我们是在13年开始在行内开始敏捷试点的，当时也是找了敏捷咨询和敏捷教练来带我们实施敏捷转型，下面我就罗列下期间遇到的各种问题。

用户故事的拆解粒度问题

用户故事拆解的粒度这个问题其实是刚解除敏捷的时候绝大部分同学都会提的疑问，这个问题就好像是在问微服务，一个服务应该定义成多大？这个问题每个敏捷教练的答案可能都是不一样的，用户故事从我这些年拆分的经验来看，这个问题的回答可以简单总结为只要拆到团队一个开发人员平均可以在1-2天内完成的工作内容，这句话听起来简单，其实这对一个PO的要求是非常高的，需要PO对团队内每个开发人员的战斗力、当前工作负荷、需求的理解都要非常熟悉。因为用户故事的粒度这是一个很抽象的问题，很难用定量的指标进行描述，这里为了方便大家实践和执行所以定了1-2天工作量这样的指标，其实在真正实施过程中，只要PO不定义那种史诗故事直接放到sprint中就可以了。当你拆解故事多了以后就能找到那种感觉了，还是需要大家多实践，一开始可能似懂非懂，经过几个迭代就会渐渐找到拆分用户故事的感觉了。

用户故事工作量评估问题

用户故事工作量的评估是个比较耗时的过程，按照Scrum的敏捷过程规范来说应该是先定义一个基准故事，基准故事一般选择比较简单又具有代表性的故事，可以让每个组员一看就知道大概这个基准故事需要花费多久时间，这样就可以让组员了解用户故事和故事点之间的比例关系，例如我们定义了一个基准故事-修改用户信息（1个故事点），修改用户信息这个基准故事我们定义了一个故事点，这个故事很简单也很有代表性每个组员一看就知道这个任务大概需要花费多长时间才能开发完，所以再用这个故事和其他待评估的故事一对比，自己心里就知道这个待评估故事大概需要多少个故事点，这样就把每个人的评估基准给拉平了。如果按照传统敏捷教练教的故事评估方法，一定是组内每个人都对一个故事进行故事点评估，评估完了之后再一起拿出评估结果给大家看谁的评估故事点多了，谁评估少了，并让故事点评估最高和最低的同学说下评估理由，这样可以让所有人了解到每个人对这个故事的理解，评估低的同学可能是没考虑到这个故事一些深层的工作，评估高的同学可能会发现自己考虑复杂了，其他同学听了以后也会根据其他人的讨论重新进行评估，讨论过后需要每个人再重新评估，一直这样评估讨论评估讨论，直到评估结果大家都非常相近的时候，去掉最大值，最小值取平均值作为该故事的故事点。我印象很深刻，第一次在教练的带领下进行评估的时候，一个迭代的故事，我们一个组的人居然评估了一天。。。为什么评估那么长时间，一方面是大家第一次进行评估，还有一个主要的原因是大家评估的结果每次都有比较大的差异，当时教练的说法是第一次会比较慢，后面会越来越快，但是我这样做了好几个迭代后，发现虽然是比第一次快了很多，但是还是比较耗时的，尤其是团队中开发人员能力层次不齐的时候，这种状况出现的频率更高。因为我们团队当时大部分同学都是外包公司的程序员，人员初级、中级、高级都有，能力也相差比较大，评估的结果也相差比较大，所以后来我干脆不用教练教的那种方法了，我按照我对开发人员的了解，用专家评估法进行评估，虽然这样评估会有很大的片面性，也可能对需求考虑的不全面，但是这样能够极大的缩短评估时间，我评估好了之后，会让所有组员去看评估的结果是否有问题，让每个人也能够有个确认的过程。后来在互联网公司发现，组内人员的开发能力都比较强，大家评估的准确度也比较高，所以当时也对故事评估过程进行了修改，直接任务认领后，让每个开发人员自己进行评估，他们评估好后，我去复评估，这样可以解放PO的评估工作，但是也都有了工作量的确认过程。从两个团队的评估经验，我也体会到了敏捷中所有的过程和方法都是可以修改的，不要教条主义，一定要根据敏捷团队当前的实际情况来调整。

用户故事认领工作分配不合理问题

用户故事评估过后，按照标准的敏捷实施过程应该是，所有组员根据自己擅长的技能去认领故事的过程，一开始我也是按照这样的流程让大家自主去认领，但是发现总会存在一些不是特别主动的同学每次认领的任务都是比较少的，这就导致了组内每个人工作分配的不平均，长期下来就会导致其他正常工作的同学心理存在不平衡，会影响到团队的和谐。所以我后来的做法是在每次认领后会根据每个人领取的故事点情况，再进行一次平衡，由PO来主动调整，这样可以起到一个再平衡的作用，也能维持好团队的氛围。

迭代小组人员过多问题，导致每次晨会发言时间很长

我们一开始迭代小组内大约有8个人，除了PO还有7名同学，3名andorid开发、4名ios开发，其中一名ios开发兼SM。这样的人员配置开晨会的时候每个人说下自己的工作情况和问题就已经会花费比较多的时间了，基本上要20分钟才能搞完，后来随着项目组的逐渐庞大，人员也越来越多，最多的时候有22人，这么多人开晨会场景是非常壮观的，遇到几个比较大的问题，一个是人太多，Scrum看板前面站不了那么多人，基本上都是围了2-3排，后排的同学基本每次晨会都没有什么参与感，而且每次会议的时间都超过了半小时，浪费了大家很多时间，所以后来为了提高效率，我按照功能模块拆成了3组，每个组都分配了SM，分别由每个SM单独去组织晨会，每个组单独维护看板和燃尽图。每个组的开会时间都是岔开的，这样PO就可以去参加每个组的会议，了解到所有组的进展，并能能够在各组之间协调工作。

迭代文档缺失问题

原来我们的传统项目使用的工程模型是瀑布式的或者螺旋式，这些项目开发工程模型，基本每个阶段都是比较清晰的，需求分析、总体设计、详细设计、开发、sit、uat、投产，在项目计划中有明确的需求分析、总体设计、详细设计的开发时间节点，所以每个阶段的输入输出文档都是比较明确的，但是使用了Scrum后，会发现，其中很多环节表面上看都确实了，例如需求分析阶段、总体设计、详细设计好像都没有，好像是PO开完迭代计划会议，分好故事大家就开始进入迭代开发了，感觉少了很多分析设计的环节，这就导致了之前各个环节的文档，都统统不见了，没人写了。这个其实是对敏捷非常错误的理解，经过几轮迭代后，发现文档缺失的后果非常严重，引出了很多问题，当人员存在流动的时候，交接工作基本就是对着代码说，接手的人基本都是讲的时候一脸懵逼；查问题的时候也没法查看交易流程，只能看代码分析；在评审的时候因为没有问题，所以评审专家也没办法评估到底有没有问题。所以经过几个这样混沌的迭代后我们立马意识到存在的问题，需求分析文档，其实就是我们的用户故事，PO在编写用户故事的时候其实已经做了需求分析，并且将故事需要实施的内容进行了详细的描述，让开发人员看到故事就能够了解这个故事到底要实现什么功能，如果不理解，PO也可以联系PO继续讲解故事。总体设计文档，我们后来体现在了每个task的文档中，我们要求开发人员对每个task都要进行交易时序图、数据结构、接口的编写，这样就保证了每个task都是有总体设计的，去掉了原先总体设计文档中一些比较虚的内容，只保留了最有价值的内容。详细设计文档，详细设计文档我们在整个过程中用代码注释进行了替代，我们要求所有开发人员遵循公司的编码规范，变量、函数、类命名都有了规范，并且在每个关键步骤都编写注释，通过注释来替代原先的详细设计文档。经过这些改革，我们发现分析设计的精髓还是留下来了，同时也去掉了原先文档中一些比较繁琐没用的内容，做到了最简化。

迭代质量保证

Scrum有个比较关键的思想是每次迭代结束后，产品都是可发布的，可发布意味着什么，意味着产品的质量是经过严格考验的，我们原先瀑布式开发是有专门的sit、uat阶段的，如果跳过这两个阶段就发布产品，这对一个银行来说显然是不可能的，起码目前来说是不可能的，可能未来几年后银行it也会像互联网公司一样，做到2周甚至1周就发布一个版本，这样的快速迭代。在不可能改革现有流程的前提下，我们又对Scrum流程进行了改造，我们的敏捷迭代只涵盖了开发需求分析分析、设计和开发阶段，对于测试和运维还是和原来一样独立由测试中心和数据中心来实施，因为对于一家传统国有大型银行，让所有环节都陪着我们疯显然是不太现实的，几年后可能其他中心的领导会慢慢接受真正的全流程敏捷，这样笨重的银行也能够和互联网产品一样跑起来。

迭代排期和传统项目产品排期协调问题

上面说了我们只是在需求、设计和开发环节敏捷了，其他环节还没有敏捷，这是个不彻底的敏捷，其实在我们开发中心内部也存在不敏捷的项目，例如核心系统和一些比较重要的外围系统都还是传统的实施方式，每年拍5-6个大的版本发布时间点，然后排期实施，但是我们敏捷项目是每个月都会发布一次版本，这就使得我们的节奏和其他传统系统是不一致的，如果我们的产品涉及到需要核心系统改造，可能我们最后的上线时间是一样的，但是有个问题是，我们迭代一结束了，核心系统的开发团队才需求分析结束，我们迭代二结束了，核心团队才总体设计技术，最后我们前几个迭代都是在我们假想的核心接口中开发完成的，这势必会存在一个严重的问题就是，核心系统总体设计结束后肯定和我们开始假象的核心会提供的接口存在出入，需要我们敏捷团队重新返工，而且我们一直到核心开发完后才能进行接口联调，在核心系统接口开发完之前可能我们都是用自己的挡板进行的开发和测试，用过挡板的应该都知道挡板功能的单一，这就导致核心系统开发完和我们敏捷产品集成测试的时候，我们暴露出一堆问题，因为前期的迭代都是我们自己玩，人家核心系统根本没陪你测过，所以这个问题就是由于相关联产品开发周期不同步导致的问题。因为没办法要求核心系统也在短时间内陪着我们改成敏捷开发模式，毕竟银行的核心系统还是要以稳定为主，后来就改成了所有敏捷产品的需求都在核心系统产品进入测试阶段或者上线后才可以排期实施，这就解决了周期不同步的问题，但这也使得敏捷产品发布时间的延迟，只要涉及到核心系统的需求就变的不敏捷了。

APP组迭代和服务端迭代、UI设计配合问题

因为我一直是负责APP开发的，所以对APP开发的流程还是比较了解的，我们做APP开发不像服务端开发，上来只要有接口文档就可以开发，我们依赖很多东西，首先UI设计师要出图，并且将切图给到APP开发的同学，界面做好后还需要服务端的同学提供接口进行开发测试。APP开发在迭代中依赖的东西比较多，我们在刚开始转敏捷迭代开发模式的时候发现每次迭代一开始，APP开发人员都是最闲的，没事做，因为啥都没有，要图没图，要接口没接口，后来我们参考了其他互联网公司的做法，将UI设计和服务端接口开发提前一个迭代实施，这样APP开发人员一到迭代就可以全身心投入开发。但是会有同学问了，我们经常会遇到一些项目是要求app端和服务端同步实施的，而且要求的上线时间比较紧，如果app开发慢了一个迭代那肯定是赶不上发布的，面对这种情况，我在app组内是要求所有前端开发人员都使用mock和mock server来模拟服务端接口，这样我们前端就有了很大的自主权，不用完全依赖于后来同学开发完才能实施。

持续集成

经常有人问我“敏捷迭代中什么最重要？”，在我看来敏捷迭代中持续集成最重要，这个回答可能很多人不能理解。其实我们换个角度来思考就很容易理解，我们做软件开发为什么要使用敏捷迭代开发模型，因为敏捷迭代模型能够让每个人专注在开发用户故事，充分调用开发人员的主观能动性，让任务能够在最短的时间完成并上线，但是我们功能两周后上线了，这并不意味着我们任务完成了，我们还要去看这个功能完成的存不存在bug，如果上去后全是问题，自然只是一个不合格的敏捷迭代，如果功能上线快了，但是线上都是问题，这也必将引起领导的不满，最后的效果可能还不如用传统的瀑布模型慢慢的实施，保证没有问题。所以在敏捷开发中不是说我们不考虑质量了，我们要通过更加先进的方式来保证在每次修改后产品都是可运行的，不存在问题的。这就是为什么我认为持续集成是敏捷中最重要的内容，如果没有持续集成来保证迭代开发的每次代码提交，那么这个迭代的每次代码提交都是充满危险和恐惧的，因为迭代周期一般都比较短，如果是两周一个迭代基本就是第二周周二左右就要提交测试版本给测试人员进行迭代内测试，不然质量是没法保证的，如果没有持续集成，所有开发人员可能在提交给测试人员之前对自己的产品是没有信心的，可能觉得自己的产品可能充斥着bug。但是如果我们实施了持续集成，不管什么时候我们交付给测试人员的时候我们都是自信的，因为我们提交的代码起码是经过持续集成检测的，经过了静态代码复查、单元测试、构建和自动化功能测试这么多持续集成阶段，自然有这份自信。所以如果你发现你的敏捷迭代过程中没有持续集成，那么你的敏捷迭代可能是个假把式，只是样子货，模仿了Scrum的样子，但是没有灵魂。

跨迭代任务问题

我们在迭代的过程中还遇到过一类比较头疼的问题就是跨迭代故事，按照理论来说在Scrum中不应该存在跨迭代的用户故事，用户故事都应该是在一个迭代中完成的，如果一个迭代都完成不了，那么就要对故事进行拆分。我个人觉得这是一种比较理想的状态，实际实施过程中始终会存在一些大型的用户故事，虽然可以进行拆分，但是你会发现拆分后，这些故事也是没办法在一个迭代中完成，这就存在跨迭代的问题，一旦跨迭代后，这就要求我们开发人员将本轮迭代不发布的功能，要在打包的时候将代码注释或者在本地不要提交到当轮迭代开发分支上，这样操作后就会存在人为的一些失误，从而导致版本混乱。当时出现这样的问题后，传统的解决办法是拉多个开发分支，但是我们知道一旦分支多了以后，对于开发人员就可能更加容易犯错，所以我采取的策略是开发人员只在自己本地的git拉个new feature分支提交跨迭代的功能代码，这样每个有跨迭代任务的同学对自己本地的分支是非常了解的因为他一直专注在这部分功能的开发，能够最好的管理好这些跨迭代的代码。这样做的缺点就是一旦开发人员的电脑如果坏了或者出问题后可能存在这部分个人代码丢失的风险，不过现在电脑没那么容易坏了，如果有企业nas，也可以定期备份每个人硬盘的内容来保证内容不丢失。

版本分支问题

敏捷迭代中的版本分支其实和传统瀑布开发的版本分支策略没有本质的区别，关键还是看实施过程中是否存在大量的跨迭代任务，如果存在比较多的跨迭代任务，我们可以为重叠的几个迭代任务单拉分支，如果只存在比较少的跨迭代任务那么可以采用上面的方案，这样更加轻量级，这样也更加符合快速的迭代，开发人员不会有太多的代码merge工作，也减少了出错的可能性。我理想的敏捷迭代版本分支是一条master分支，用于记录发布的版本，一条dev分支，用于记录迭代开发的内容，版本发布后将代码merge到master分支，其他问题都在个人local git解决。但是了解instagram的同学应该知道，instagram那么多的功能，那么快速的迭代，他们只有一个master分支，可以做到代码一提交经过持续集成后就发布生产，想想这要求开发人员和老板得有多大的心才敢这样啊！

版本发布周期问题

敏捷迭代目前用的比较多的迭代周期一般是2周，也有部分特别快速的互联网公司做到了一周一个迭代版本发布，我们当时做过一个实验，一开始我们采用4周一个迭代，在实施4周一个迭代前我们居然感觉4周相对于原来瀑布式开发流程3个月一个版本简直太短了，后来我们真正实施的时候发现4周我们也可以完成原来3个月的工作。。。可见原来我们的工作效率有多么的低，后来我发现在4周的迭代中前两周大家工作进展都比较慢，后来我把缩短到2周一个迭代，一开始大家都很抵触，觉得2周发布不了版本，不可能有独立可发布的版本上线，后来实践下来在做到很好的故事拆分后，每个迭代分配的任务都是可独立上线的，大家也都在2周内完成了工作，所以用了敏捷后你会发现原来我们有那么大的潜力。

总结

敏捷的形式是很好模仿和学习的，估计培训一周所有人都能说个头头是道，但是在具体实施过程中会遇到各种问题，一方面的问题是由于公司原流程和敏捷迭代流程的冲突，另一方面是开发人员对敏捷开发的适应性，还有一方面就是敏捷迭代的质量保证。第三点我觉得是我非常重视的一点，不能说用了敏捷，项目的bug率就可以提高，项目的文档就可以缺失，项目的需求就可以随便加，所以总的来说整个实施的过程中最难的就是如何保障项目的质量，直白点就是如何来通过完善的持续集成来保证代码的质量是充分可用的。后面我会写一些文章来介绍如何实施持续集成，目前还是有很多公司不知道该如何实施，如何实施效果最好，我会在后续的文章一一介绍。