传统团队和敏捷团队

经常有人问，你们搞敏捷开发工作量是由开发人员自己估的，而不是由经验丰富的技术主管估的，他们自己肯定会把工作量估得非常大，那什么时候项目才做得完？你们每天开那么多会，怎么不把时间放在好好写代码上面？一个迭代这么短的时间既要做设计、又要编码、还要测试，这么急着做出的东西质量肯定不高。系统设计肯定得经验丰富的老手做更靠谱。每当我听到有人说这些问题，我就知道他肯定没有真正的认识敏捷开发，如果真的有实践过，自然就会发现这些问题根本就不是问题，只是杞人忧天而已。

敏捷开发也快搞了快一年了，觉得应该把这一过程中的理解与经验得好好总结一下写下来，还有就是又有一个新团队由传统方法正在向敏捷转型，所以这些经验也可以帮助大家学习一下。

采用敏捷最直接的结果就是，开发产品的效率确实提升了好多倍对比传统模式，为什么这么说，我们团队10个人花了8个月时间开发完成一个系统并完成上线使用，而这个系统在一个朋友公司也有在开发，他们早一点开始，20-30个人花了2年多的时间还没有完全搞出来，当然他们用的是传统的开发方式。

传统开发方式以前工作多年也都是采用它，当初也没觉得它哪里不好，反正大家都这么做的，有问题也觉得正常，你觉得他是瀑布模式又不像，我觉得应该就是作坊模式吧，一直待得也是这种不大的小公司，确实比较像东莞那边的小厂子小作坊，不像大公司那样有太多的制度和流程，目标就是把当前的项目做好做完。中间也在外包工作做过几个月，非常不适用，第一感觉就是太不自由了，连网都不能上就是按照文档码代码就行了，而且要码得一丝不苟，当初就觉得这种开发模式肯定不适合国内的软件公司的。

什么机会接触到敏捷了，就是去年去了新公司，上市公司，本身是不做软件的，准备从设备生成转到行业服务，需要更多的借助互联网、IT数据，所以新成立的团队来做，本来就是从零开始嘛，没有历史包袱，而且上市公司又多金认识高国际化，所以直接把国外敏捷开发的理念引进过来，就请了有名咨询公司帮助团队建立起敏捷开发，所以就有幸开始接触了最先进与最原滋原味的Scrum，为什么说是原滋原味，因为后来也接触了一些国内其它的敏捷咨询团队，好多都是根据国内情况本地化了，所以不是原滋原味了，比如改良后的敏捷没有了估点的过程，而是直接按工时进行估算。

刚开始接触敏捷时候就觉得这种方式不靠谱，因为太理想化，比如说老板接了一个项目规定在固定时间必须完成，不然这个项目肯定就没戏，按照项目的工作量的话在正常情况下肯定是完不成的，按照传统的方式就是老板动员大家在这段时间大家拼一拼，多加加班还是有可能完成的，当然也有可能是完不成的，那就得继续加班到完成为止。而按照敏捷的方式就不是这样处理了，按照团队的速率估算结果完不成，那就得必须告诉老板，要么增加迭代周期，要么减少功能，因为给我这么多量，但我的饭量就只有这么大，那么开始之前就一定得说清楚，而且只能这么做，不能加班，因为长期加班会破坏团队的习惯。所以在当时想来哪个老板会跟你讨价还价，直接就压下来了，这真的是一种理想方法而已，在团队中是行不通的。

自己也是一直都有参与一线编码的工作，我一直认为开发程序是一种脑力智慧，应该是一种很有乐趣的事情，而且刚开始也是体会过这种乐趣，后来工作久了深陷一个又一个的坑中，爬都爬不出来哪来的乐趣可言，程序员变成了码农。后来尝试敏捷后，就是它会营造一种环境，让你又重新回到之前对于编程的那种乐趣。所以敏捷与传统最大的区别就是工作时的环境完全不一样，传统是让你忍过了一个煎熬，接着又要迎接下一个煎熬，而敏捷就是让你感受到编程的乐趣，回归到让你用编程智慧来解决问题，而不是头痛各种项目带来的坑。

说道编程乐趣得好好说一下，从毕业实习出来到公司上班，一直从事医疗软件开发至今已经10来年了，所以除了这份工作能够养家糊口之外，自己对于编程也是出于热爱，不然也坚持不到现在。这么多年来，半路转行的同学同事大把。刚从学校出来就马上投入一线编码，让自己开发的功能客户马上就能用到是很兴奋的事情，自己编写的代码能够卖钱，系统商业化，觉得自己太牛逼了。能够加入公司一开始就能参与核心功能的开发也是进入公司的时机巧，我们一起8个同事入职是由于公司遇到分拆的危机，虽然公司只有几十个人，但是技术老总带着一批骨干跑出去单干了，导致公司一下子空缺一批开发人员，然后就把我们招了进来，进来后就每人分配一个子系统，半个月来熟悉系统，然后去医院支持上线，记得当初接触第一子系统就是门诊医生站。那时候的人还是单纯些，我们8个新入职的同事一起研究代码、讨论代码、修改代码，基本那段时间都是很晚才回家，但是没有觉得很辛苦或不值得。因为大家都是新来的，所以没有什么新老员工的隔阂，交流起来没什么顾虑，玩玩一些问题可以讨论半天，自己弄懂了一个什么控件、什么功能马上分享给大家，所以在很短时间内大家的进步都很快。现在招聘一个新人培养半年都不一定能够承担起系统，但是不到一个月的时间各自都能镇守一方。有时候想想到底什么原因，是现在的小朋友太笨？肯定不是，人家比我们当前可灵泛多了。我觉得一是乐趣主导那种学习环境，再就是刚好遇到大量老员工出走的情形。现在的新人来到公司，确实感觉不到一点编程的乐趣，没有学习的乐趣那么他进步慢那就必然了。为什么环境会变成这样，就是因为原来的老人们觉得自己走来遇到的问题太多，然后就制定一堆制度来解决这些问题，慢慢的这些制度原来越多就形成了一种呆板坏境，而失去原来本该有的乐趣。比如现在新人进来一般都不会直接把新功能分配给他，因为没有经验担心写的代码不行，到时候还是得重写。甚至碰到极端公司，把开发任务像工厂流水线做鞋一样，拆分成很多个部分，然后让新手对着填空，而且每个任务都精确到小时，这样按小时来核算你的工作量，月底工资绩效跟这个工作量挂钩，你说你在这种环境下工作还有什么乐趣而言。而站在公司的角度确实控制了项目风险、控制了人力成本，但这家公司也就变得没有创意、没有冲劲，也不可能做得更大。后来加入的所有公司基本上都走入了这个怪圈，直到尝试了敏捷开发一段时间后，才感觉到大家才有了一些编程的乐趣。敏捷这种思想不是一下子就改变了你认识，而是慢慢的慢慢的改变了你的习惯，让你冲破之前的枷锁，一点一滴的体会到编程的真正乐趣，从而让团队进入一种状态、建立一种默契。说得确实有点玄，做到确实也不容易，而且我的这条路径也不一定适合你，所以我就只是把我的故事讲出来，作为一个引线让你思考，从而找到你自己的方法。

说到公司对待新人的方式，传统团队和敏捷团队确实有很大的差别，传统模式为了让新人更快的上手，一般会给新人安排一个师傅带着，让师傅给新人制定学习计划指导人家，由于师傅手上本来就有做不完的工作，一般头个把月都是丢一堆文档代码让新人看，然后试着给他安排几个简单的功能做做，最后发现新人做出来的东西不行，还得自己重新修改一遍，师傅就觉得带人太麻烦了没有帮到自己的忙，反而占用自己更多的时间，所以就搞得老人一般都不太愿意带新人，就算公司出政策给带新人的师傅额外的补贴，但这种方式也是解决不了根本问题，新人的学习周期还是很长，基本上一年半载都难独立承担开发任务。而敏捷团队不会这样，没有师傅徒弟，也不讲究新人老人，大家在团队中都是平等的，新人刚加入团队就会跟大家一起进入迭代开发，根本没有说先熟悉一段时间，只是说在领用故事的时候，新人只算一半的点数用来降低这个迭代失败的风险。这样新人一进来就有开发任务，一下子就进入一个主动学习的状态，会主动向团队成员的学习，团队成员也会主动帮助他，因为他完不成，那就是整个团队的迭代失败，因为敏捷只考核团队不会针对个人进行考核。这样新人在这种环境下，一般经过2,3个迭代就会成长起来，适用团队的开发节奏，如果3个迭代还没有适用的话，那就是这个人可能不适合这个团队。还有一个问题就是怎样保证新人开发的功能不会出现质量问题，导致返工，比如新人不熟悉业务功能设计考虑不够周全，不太熟悉开发框架代码编写不够规范等，这些问题都会影响产品的质量，而敏捷开发最重要的目标就是保证产品质量，所以这些问题在敏捷过程中都有对应的解决办法，比如设计问题会有设计评审，代码问题有代码评审，团队里的成员会在这些环节里帮助你把关，总之你在团队产生的东西都不是一个人的东西，都是整个团队的东西，人人都会关心。

： » 传统团队和敏捷团队