敏捷之旅-段念说豆瓣成长的土壤

      作为敏捷之旅北京站的筹划人员，在讨论请那位业界比较享誉盛名的人士进行keynote演讲时，我一直不是很理解为什么小组成员极其推崇豆瓣的段念进行最重要的第一个Keynote的演讲，孤陋寡闻的我在百度和他微博上得到的信息实在看不出来他有什么亮眼的地方，当时我对自己说了，答案只能在大会现场才能知道了，而在段念讲完之后，我感觉浑身在轻轻的颤抖，因为段念讲述的生长正是我苦苦寻找的东西。

      因为是一个以‘敏捷开发’为主题的大会，所以段念上来先向听众问了如下几个问题：是不是有团队使用敏捷，就是敏捷呢？建立一个准确的流程和体系，敏捷就能持续了吗？敏捷开发中要程序员做的自承诺，是否是资本家压榨工作所使用的圈套？敏捷如何提高效率？

      种种问题，段念的回答也非常简洁，一个工作方法是否能够解决团队的问题，根本在于能否实践团队中显示出效果；作为一个实践者，豆瓣本身是在没有规划的情况下使用敏捷的，让整个团队自动自发去喜欢上某种工作方式和工具，比建议一个明确的流程和体系更能吸引才华横溢而又有个性的工程；

     就机构组织敏捷转型来说，越往核心层(管理层)其本身的价值差异不大，都是为了创造出一个高效的工作团队，时刻都有具体的成果出现；但是因为这些成果展出对于实际进行工作的团队而言，突然出现的改变造成的不适应，往往会造成这些工作团队为了迎合高层的指示而做敏捷，但是在具体工作上还是使用习惯上的工作模式，因此可以说敏捷转型在企业中越向外扩展，其差异越大。 因此段念建议：敏捷最好是生长出来的，而不是计划出来的。

     豆瓣开始仅有一个简单的社区，而随着用户在社区内自发的组织进而开发出了读书、电影、线下活动等功能，这可谓是豆瓣豆瓣生长的特性，根据这种特性，也定义了豆瓣的敏捷不可能是领导层组织、设计出一个该生长模式,豆瓣本身仅仅是为发展提供了一个良好的环境和土壤。

      段念本身认为豆瓣在敏捷实践之中，还是存在很多问题，尤其强调随着开发工程师人员的增加，彼此之间的沟通往往会出现问题，同时豆瓣坚持小团队，保持团队人数少于10人。同时豆瓣本身提倡快速迭代，快速发布，并且是让用户不会觉得豆瓣有巨大的变化，但实际上豆瓣每天在UI上都在不断发生的改变，尝试发掘用户的喜好，因此如果好奇的人如果三年前有切对豆瓣的页面，会发现和今天豆瓣的UI是巨大的。

      产品经理尤其不喜欢敏捷开发，因为他们认为敏捷开发往往代表者民主，需要同工程师协商决定的可行性，而产品经理们认为不通过商量他一天可以想出7个决定，如果和工程师进行商量，可以1个决定都确定不好。

      工程师有较好的质量意识，为此他们还创造了一个happy day，具体的方式就是找出工作日的一天，工程师们针对某个问题进行集体攻关，各自编写代码，看谁能够最好的解决这个问题。随着豆瓣面向业务开发的不断增加，工程师的数量也在增加，这时候面对一个具体的开发项目该如何分配工程师去进行工作就成了一个实际的问题，因为当工程师完成这个项目之后，可能立刻就会加入到另外一个项目中去，而之前项目需要这个工程师去修改之前工作出现的bug或者新功能的时候，这个工程师本身已经没有时间了，因此豆瓣的工程师们发明了‘攻城机动队’这个组织，他们的大本营在‘攻城师湿地’，当他们的指挥官PM(产品经理)过来带领攻城师们去攻关新的项目的时候，这些攻城师上次项目出现的问题，留在‘攻城师湿地’的会帮助他们解决这些问题。

      豆瓣提供的土壤和空气培养除了有解决问题并抱有解决问题心态的工程师，在豆瓣内部工程师们可以随便调侃别的团体完成的产品，而这些产品的研发团队却不敢怒吼回击：“如果觉得不好就自己做一个”，因为豆瓣的工程师可能会真的抽时间做出一个更好的产品，段念说这是一个玩笑，但是拥有如此土壤的豆瓣，绝对拥有如此执着的工程师。

------------------------------------------------------------------

我的微博： http://weibo.com/192jiang

我的豆瓣： http://www.douban.com/people/fulmination/

本文出自 “麒麟天空” 博客，转载请与作者联系！