敏捷开发的形和神

敏捷开发已在公司内部推行了有四五个月了，开始检查各个团队实行敏捷开发之后的效果，以检查团队是否真的敏捷了。按说这是好事，引入一种新的开发模式，是要定期检查一下，以便使这种新的模式能够按照正常的轨道来走，而不至于跑偏了。但现实情况往往是很多的，评估小组就真的能领会到敏捷的精神么？

通过一段时间的敏捷开发执行，确实发现了其好的地方，对于互联网这种需求变化非常频繁的行业，敏捷开发确实比较合适，能更好的适应需求的变化，更快的完成项目的开发和测试进度。内部也树立了几个敏捷开发的标杆团队，供大家模仿参考，但我之前也说过，单纯的照搬模式并适合每个团队，况且你得允许人家吸纳敏捷开发的优势为己用，然后找到适合自身团队的敏捷开发方法。关键就在这个适合自身上，每个团队在敏捷的过程当中，摸索的过程都是不一样的，执行的人也不一样，这注定不会使每个团队都有相同的敏捷模式。

光有敏捷开发的形能起作用么？

我不知道是否有标准的敏捷模式或者规范来告诉我们敏捷开发的第1，2，3步该如何去走，大致上的使用方法肯定是有的，细节的东西肯定也都是前人所摸索出来的。采用过敏捷模式的人都知道敏捷开发的一些标签：backlog，站会，迭代计划，迭代总结会议等等，这些其实都没什么问题，关键在执行之后的效果上，拿backlog的维护和站会模式来说。

Backlog就是以前的user story，这个维护一般是要产品经理来完成的，需要在每个迭代开始之前将该迭代所需完成的部分backlog根据优先级一一维护好，以便开发和测试团队执行。最早制定的模式是每个backlog都必须能在2-3天里面完成，后天发现不行，有些backlog达到所要求的功能确实时间会较长，且无法再拆分，后来变成每个task必须在2-3天里面完成，每个backlog必须在一个迭代里面完成，一个迭代是两个星期。按照这个方式，一个开发周期超过两周的项目必须得拆成好几个backlog，也就是说项目是允许跨迭代执行的，然后按照backlog的优先级原则，优先级高的会先行进入开发。咋看之下是没什么问题的，但一旦同时进行的项目变多了，很多backlog挤在一个需求池里面的时候，问题就来了。

首先是backlog管理的混乱，按照优先级原则开发，部分项目中的部分backlog确实优先级高，业务价值高，先行开发是对的，但几个迭代下来之后，维护这个需求池就比较的吃力了，产品经理确实能看到每个backlog的完成进度，但是每个项目的完成进度看不了了，因为已经拆的七零八落，且有的完成有的还在等待排期，或许一段时间内都排不上了，非常不利于项目的管理。

其次是开发测试人员的混乱，刚进入某个项目，做完一小部分功能后立马投入到另外一个项目中，做一小部分功能然后又去另外一个项目，思维转变来转变去，到最后在理解业务需求的时候发现都串了，特别是几个项目之间有关联性的时候，我终于明白为什么迭代计划会议要开那么久了，就是为了让开发测试人员转变思路的。

站会是敏捷特有的形式，就是每天早上大家面对面站成一圈，各自花1分钟讲述一下过去一天都完成了什么，有什么问题，接下来今天要干什么，有什么需要协助的地方。这种形式其实挺好的，是一种高效的开会模式，能在短短十几分钟完成每个人都发言且形成决议（站会报告），日常的会议组织肯定没有这么高效。前提是整个团队都在一个办公地点，实在不行分两处视频或语音开会也是可以的。有人说这种模式虽然有点奇怪但习惯了就好，但就是习惯不了啊。

站会模式应该是外国人搞出来的，其实国人在这方面确实不像老外那么收放自如，特别是我们的程序员，大都沉默寡言的，本身坐着发言话都很少，别说一群人站着面对面了，别提多别扭。当然开过几次之后会好一些，然后最后的效果是大家都习惯了快速的敷衍了事，赶紧把自己那点讲完，可能还带了很多程序的术语，至少产品经理是不大听得懂的，不过团队成员之间熟悉了之后确实好了很多。

再就是产品经理一般都要赶趟，如果负责的产品线够多的话，一早上的站会就得参加好几次，所以理想中的一个产品经理一个团队的做法，在现实当中也比较难实行，大多数公司都是恨不得把一个人拆成几个人用的。

敏捷开发的神是什么呢？

简单的说，敏捷开发是一种以人为核心，迭代、循序渐进的开发方法。在敏捷开发中，项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中系统一直处于可使用状态。敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式，目标是提高开发效率和响应能力。关键点出来了，就是提高开发效率和响应能力，拥抱需求变化。

虽然说除了原则和实践，模式也是很重要的，多研究模式及其应用可以使你更深层次的理解敏捷开发。但是光有模式也不行，还得掌握其核心目的。我们所说的目标导向，就是这个意思。既然敏捷开发的目标是提高开发效率和响应能力，那是不是只要能实现这个目标的一切方法都是敏捷开发呢？

显然问题的反问就不是肯定的答案了，因为敏捷开发模式的出来，比然已经经过了很多人的传承才会引起大家的广泛认可，有这样的基础在，就证明其有一些特性化的东西是不可磨灭的，比如说站会。那是否可以在引进的模式基础上做适当的转化呢？个人觉得完全是可以的，取其精华去其糟粕嘛。

虽然说没有预先的模式照搬，不会得出后面的神，就像国家的社会主义革命一样，也都是先经历了错误才走到正确的道路上。但是我们已经知道了这样的历史，那就得借鉴历史的教训，结合自身的实际情况，取其精华即可。一个真正实行敏捷开发的团队，绝对不应该有条条框框的东西去束缚他们的手脚。

敏捷开发的形神兼备

Backlog的问题可以通过另外一种方式来解决，即每个项目只建立一个backlog，然后在这个backlog下建立子任务，每个子任务设定优先级和工作量占比，子任务完成后backlog也能显示出一个完成百分比，这样的话首先各个项目的进度能一目了然，其次不会遗漏项目中的既定需求。这样也满足了整个需求池的管理，只不过层级从backlog层移到到了子任务层。

开发人员的思维转变问题，一是通过迭代总结会议和迭代计划会议来缓冲，二是如果开发资源不紧张的话，可以在保证紧急需求的协同开发前提下，尽量安排个别开发单独跟进某个项目的需求，来达到项目的连贯性。

站会问题考虑到中国国情，完全可以坐着开，当然时间上可能就稍微要延误一点了。至于赶趟的问题，这个一时半会没办法解决了。

其实总的来说，敏捷开发还是一种非常好的模式，只是在应用的过程当中，或多或少都会碰到一点问题，照搬照抄一直都不是我们的风格，哪怕大到社会主义革命这个层次，也是建立了中国特色的社会主义。因此我们有必要把原有国外的敏捷开发模式做一些转化，建立起具有中国特色的敏捷开发。