刘忠谈互联网企业产品研发的敏捷实践

个人简介 刘忠，FreeWheel 研发中心应用软件部总监 现任FreeWheel研发中心应用软件部总监，有近10年的项目管理，研发团队管理经验。加入FreeWheel之前，曾任优酷网核心工程师、高级技术经理。无限融易公司系统架构师。搜狐网高级工程师。东方瑞科研发部，互联网部经理。开发并成功交付过如FreeWheel MRM Adversiting Platform, 中国网通/电信宽带计费系统，优酷网等高负载、高可用系统。对一个快速变化并且追求高质量的企业如何实践合适的软件过程和有深入的探索和体会。

敏捷中国大会是国内敏捷技术领域最高水平的大会。今年的敏捷中国大会（AgileChina 2009），以Pragmatic Agile为主题，参会者以高端开发者和技术管理者为主，融合管理和工程实践，推广全面敏捷之路。

   

1. FreeWheel研发中心应用软件部总监刘忠先生你好。我的第一个问题是FreeWheel大概是什么时间开始了解到敏捷开发的过程，又是什么时间开始着手采用敏捷开发的呢？

FreeWheel应该说比较新，从我们研发中心成立的第一天，我们的的老板就提出了一个要求说，我们要采用敏捷的方式去做我们engineer内部和PM之间的一个process，所以应该说我们从第一天就开始实施敏捷软件开发。

   

2. 那我想问一下在你认为在快速交付过程中你感觉最重要的因素是什么？

快速交付因为本身就涉及到一个风险，大家没有特别多的时间进行思考，那么这里边就会涉及到一个由PM作为需求方，他提出要一些东西，而engineer作为一个执行方，我需要把这样的一些东西按照质量和时间把它做好，那么这里边双方的沟通是非常非常重要的。整个快速迭代的过程当中所有信息的透明，这个是非常非常关键的一个因素。

   

3. 在实现快速交付的过程中是怎么样去保证项目的质量呢？

这个会分几个方面，因为每一次迭代所需要做的东西的重要程度或者对客户的影响的大小是不一样的，对于那些影响非常大的需求点，我们前期是要做非常多的密切沟通。那么同时你要能够在短时间内很快的做出一些改变或者说一些功能，测试本身的要求是非常高的。这个测试是指我们的开发人员自己写的单元测试，以及全自动化的这样的一些测试的覆盖，使得你在做一些修改或者增加一些新功能的时候，你对原来已经存在的一些功能做回归测试的这样的压力就会小非常的多。那么以及测试驱动开发，还有结对编程，这样一些敏捷的实践都能够帮助我们最大化强化这方面的一个考虑，让我们短时间内可以做得比较好。对于一些就是比较小的需求，对客户的影响可能没有那么的大，那么这一方面我们可能容错的这个程度就可能会比较高一点，那开发人员把它快速的做出来，然后PM review一下，可能就没有那么serious这样的一个process去做这个事情。

   

4. 在FreeWheel内部一个典型的敏捷开发团队的规模是怎么样的？

FreeWheel现在研发中心一共有大概60个工程师，我们应该说整个研发中心都在实施敏捷的process，但是这60多个人是分两个大的部门，同时每个部门是分成不同的小组，根据业务来分，不同小组实施的一些具体的实践是有所不同的。并不是说所有的Team都完全一样，就是跟每一个不同的Team的人员组成、他们的知识背景是有关系的。那具体来说像董彬，刚才和我一起做演讲的那位同学，他是我们的一个senior的工程师。那么他带领的那个Team就在结对编程以及测试系统开发这方面会走在比较前面，那么同时会带动其他的Team来做，就不同Team他本身所输出的那个子系统对质量的要求也会有所不一样，所以他们focus重点都会不太一样。那基本上这个团队我们是希望保持在一个比较小的规模，这也比较适合做现代企业管理，就需要怎么样把一个大公司做到比较小，那一般来说一个小团队在比如说不超过八个人我觉得都还是比较好的Team。

   

5. 刚才你提到了结对编程这样的方式，那您还能再详细描述一下典型的敏捷团队的一般的人员构成以及团队的日常工作流程吗？

对这个问题以前是有一些误解，认为敏捷他本身是一个对个体要求比较高的process，要求每个人各方面的能力都比较强，那对于在FreeWheel上确确实实我们在招聘的时候，就对我们所招聘的员工的挑选是非常严格的，各方面都会考察。但是我们也会有一些实习，也会有一些并没有太多工作经验的member。每个人我觉得都能够在敏捷的这个process的框架下发挥他所独特的那一份价值，而且敏捷的process非常非常强调的一点是什么呢，就是一个沟通，通过沟通把整个信息的渠道给打通了，那么这样一些senior member他所有的经验很容易能够传递到刚加入的一些新member，大家都会很enjoy这样一个process，一起来贡献他们自己的value。

   

6. 那么在敏捷团队内部采用的具体是哪些敏捷实践，在这些实践过程中有哪些经验和教训？

我觉得在FreeWheel目前实施的比较成功的一些敏捷实践排在第一位的当然是迭代，就是整个的发布会是比较短周期的这样的一个发布，比如说一个月，或者是五周，这个是第一位的。然后再往下，我觉得比较成功的一个是测试驱动开发和端到端的自动化测试，那么这两个是和FreeWheel的产品本身对质量的要求是密切相关的，我们在这方面的投入的精力比较大。然后就是结对编程这个对促使Team之间的人员直接的沟通这方面是有非常重要的意义。然后再会有一些辅助性的，比如说站立会议，然后还会有一些其他的──实际上和敏捷没有什么关系，但是我们也觉得非常非常重要，比如说做一个项目的时候，我们要有一些风险清单，那么这样的一些工具，可能会是在管理意义上的一些工具都能够帮助我们去实施敏捷。

   

7. 那么FreeWheel在采用敏捷模型之后那是否可以去量化的评价这个敏捷模型所带来好处呢？

关于量化我觉得是整个管理界都在思考的一个问题，尤其是对于工程师的工作成果的量化考核我觉得这个是一个双刃剑，尤其是对于敏捷process，它所强化的那一部分恰好是我觉得是最难量化的。因为他强化的是什么呢？是一个工作点是在于人，而不是说流水线process。那么人和人之间的这个通过敏捷所带来的好处很可能是一些士气上面的改变、对文化的认同和其他Team之间的信任，那么这种东西很难去量化，但是当然最终在结果上面、在生产效率上面会有一些量化的指标。但是我觉得这确确实实是一把双刃剑，一旦量化能，你定下一个指标，这个指标很可能就是错的，我能够告诉你的一个就是我们团队在做同样的一个系统做了两年之后，他们的士气还都非常的高，基本上没有一个人员说提出辞职，因为我做这个事情很无聊，那么同样我们的QA member也是一样的，同样一个产品，这个在很多公司是做不到的。

   

8. 在FreeWheel是如何去实现团队最终的自组织呢？

团队自组织这个我并不认为一定要实现这样的目标，那么这里边一方面管理层，我觉得是要适当的引导，尽可能的你的管理层要发现你下面每个member他的一些长处，要充分利用他们的一些长处，而且不断给他们一些挑战。那么把他们的一些长处经过一些结合，你可能这样的一个结构就自然而然的辐射出来了。那么这个我觉得是一个上下齐力的一个结果。

   

9. FreeWheel内部在实施敏捷的过程中是自上而下，还是自下而上这样的一个过程？

这个是我今天演讲的一个核心主线，有可能在演讲里边没有特别好的体现出来。我们觉得敏捷的实现,对它的这个思考你要采取什么样的实践，然后他能够给我们商务是带来一些什么样的价值，我怎么样一步一步的去做这个事，这个思考过程是需要从上而下去考虑它。那么这个考虑包括你对你的文化本身和敏捷的这个适应程度，你产品本身的特点，那么和敏捷里边的哪些实践会有更好的关联性，这些方面自上到下管理层要不断的去思考，而真正的变成大家可以去实践的一个东西，这个还是要自下往上慢慢的形成。因为这个你从上强制，跟大家说你们要结对编程，这种事情根本就不管用。那么很多时候管理层会有一个这样的引导，通过一些training把这样的一些东西介绍给大家，然后培养一些骨干，然后他们在Team里边先小范围的去试行，然后慢慢的我觉得就会对公司会有一个自下往上的影响。

   

10. 那您是否认为在FreeWheel每个人都比较适合在敏捷团队中工作呢？

目前看的话，我觉得是的，每个人都有他的贡献。

   

11. 最后还想请您给准备实施敏捷的一些开发团队分享一些您的经验和需要注意的事项？

因为我的主要经验倒还不是一个大型的企业如何去转型到敏捷，而更多的经验是在一些Startup以及研发人员规模，比如说不到100个这样的一些经验。我觉得比较重要的一点，一个好的process，他本身绝对不应该成为一个所谓的变革，就是说对你的公司带来非常剧烈的振荡，而且process这种出发点你必须要从整个公司的目标、价值观去出发，然后具体的效益会体现在你公司的业务和产品上面，要从这个角度去考虑，然后具体到实施可以小范围的去做一些尝试，甚至可以在一开始的时候引用一些外力，比如说找一些咨询公司帮你迈出第一步，这么去做。

   

12. 谢谢刘忠先生接受我们的采访。

谢谢。