敏捷开发历程回顾

学习并尝试敏捷以来，目前是第三个团队。

第一个团队，在一个小公司，我负责公司两个开发团队之一。那是第一次带队开发，没有什么项目管理经验，在强大的开发压力下，有一段时间把自己搞的焦头烂额:团队成员比较清闲，因为他们没能力解决复杂的问题，我自己天天忙死累活。痛定思痛的开始研究项目管理，尝试了一些传统的管理方式，很不给力，然后就接触到极限编程、敏捷开发。

首次的敏捷尝试，给了我很多惊喜。我们对一个旧系统进行了较大的升级改造（累积了数年的一个面条式程序，可以想象它的糟糕程度）

在这次开发过程中，我们尝试了结对编程、测试驱动、立会、回顾总结等等一些敏捷的方式方法。

这是一次非常有益的尝试，我们顺利完成升级，减少了客服部90%（客户部给的数据）的工作量（解决客户造成的错误），敏捷所推荐的方法都是非常有益的方法，但是在尝试中也发现了一些问题

1. 测试驱动对开发人员的要求，测试驱动对开发人员的要求较高，完全的测试驱动开发是对常规开发流程的一个颠覆，当刚从学校毕业不久的各位童鞋（公司资金有限，只好做程序员摇篮）对编程语言还没有做到熟悉熟练的情况下，要求他们做到测试驱动，几乎不可能。强制要求测试优先，几乎让项目进度停顿。

2. 结对编程对进度的影响，结对，长期坚持优势明显，但是1强多弱的开发团队（很多项目组的组成结构，当时的团队就是这样的结构）也存在很多问题，首先就是强弱结对，有时会造成较弱一方的悲观情绪或依赖情绪，同时也拖延了较强一方的进度（当项目进度对1强依赖较多时，进度的拖延是比较严重的）。两个较弱的人结对所产生的效益是微弱的，需要很长时间才能看到明显效果（当时感觉至少3个月到半年）。

3. 立会的效果逐渐减弱，当初期立会的新鲜感过去后，加上项目进度压力，立会的效果有明显的减弱，立会成为参与者简单的应付式陈述自己的工作，互相之间并不关心对方的工作内容。


 

一些变异的方式：

1. 测试驱动调整为加强测试，互相测试，1强做发布测试。或者由1强的人编写测试用例，或者使用代码审核替代测试等等，以减弱对初级开发人员的要求

2. 松结对编程（前一段时间看到相关的文章，把名词扒过来用用），加强程序设计的讨论，减少编写代码的结对。不过对于弱弱结对还是进行了不强制的提倡。

3. 轮流组织立会，交换论述对方工作，工作内容轮换

第二个团队，我到了一家较大的公司。大公司的开发是体制化、编制化的，比如简单的上传文件，在第一个团队时需要自己写一个（或copy一个）上传功能，但在第二个团队，我们需要找负责上传文件的团队所要接口。比如对大数据表的处理，第一个团队需要自己分表分库处理，第二个团队我们可以找更为核心的研发部分负责解决大数据量得问题。

第二个团队是一个不太开心的经历（虽然领导、同事人都很好，虽然年终给的也较为丰厚），当第二个团队的公司建立的时候，敏捷还未诞生，经过了多年，第二个团队所在的公司已经形成自己的开发文化氛围（在公司文化影响下），简易的、快速的、产品导向的开发（不知这样形容是否准确，这只是我自己的感觉）。

产品出原型，领导拍板，开发尽快把它弄上线，这就是我们的开发流程。在这个流程中，我负责一个开发小组，但我却无法推广敏捷，原因很多：

1. 简单的产品，第二个团队的成员个人能力比第一个团队好了很多，同时产品难度不增反降，大部分项目或功能只是需要我们设计几个表，然后以web的形式展现。这种情景下，结对、测试驱动只会浪费时间然后让领导咆哮（速度是公司推崇的准则之一，所以挑灯夜战是常事）。立会也变的可有可无。第二个团队的开发压力比较大，不是因为产品的难度，而是因为大量的简单产品，以及这些产品不停的改版，大量的简单的产品只能让我们沦为了熟练工种。

2. 简单的架构，公司有一套通用的设计框架，很简单的三层架构，鉴于产品的简单，复杂的架构

3. 松散的团队，虽然我负责一个开发组，但我对团队成员不能完全掌控，我上边的高级技术经理会越级指挥、安排小组成员的工作，团队成员也经常会被派去支援其他组的开发（当然，有时其他组也需要派人帮助我们组开发）

等等，还有其他一些原因吧，无法一一列举，核心的两点原因：

1. 团队的开发流程已经固定，要做出改变很难，挑战固有、惰性的文化很难

2. 敏捷开发需要高层的支持。松散的开发团队，让我想在自己小组尝试敏捷的机会都没有。

目前所在的是我的第三个团队，组建的时间还不常，已经在内部推广了一些敏捷的方法，发布了三次测试版程序，以后会慢慢总结在这个团队中的敏捷尝试。

总结一下自己敏捷的一些感受：

敏捷的效率：

敏捷开发需要长期的坚持，初期推行敏捷可能不会马上看到明显的效果

敏捷的适用性：

记得在敏捷开发刚出现时，其中一个案例就是团队放弃或很少使用初级开发人员，而充分利用高级开发人员的效率完成项目。和朋友、同事的讨论中也基本可以认定，敏捷更适合于中高级开发人员组成的团队，敏捷的一些准则是高级开发人员的开发流程的提炼。

对于主要或者包含很多初级开发人员的团队，推行敏捷最好做一些变化（除非老板允许你先对团队进行敏捷培训3-6个月，而不追问进度的话）

敏捷的阶段性推广

1. 立会、回顾、产品设计讨论 简单的实现原则等这是比较简单、见效快而明显的敏捷方法

2. 结对编程，长期的结对编程对提高团队整体实力的效果是非常显著的。如果敏捷开发环境不理想，做不到完全结对编程，松结对编程较好的选择。对于结对编程，也可以采用必要时就结对而不是完全结对。

3. 用户故事、迭代开发，让我们更加了解产品，也可以使我们更快的应对产品需求的变化，在我的实践结果表明项目进度更快了。如果无法做到让用户、产品人员参与到开发中，那么及时反馈项目进度对项目的开发是很有益的。

4. 测试驱动，重构，更好的设计模式，这些方式对于团队成员的要求较高，如果团队成员能力没有达到这样的开发水品，强制推行不是一个好主意，利用强弱组合结对、加强培训、加强代码审核+重构力度，逐渐形成一个开发氛围，慢慢影响团队成员。

没有经过正规敏捷训练，自己摸索着实践敏捷，一路跌跌撞撞的也有几年了，有很多不当之处，欢迎指正交流。

ozdoo技术系列文章 转载请署名