作团队感悟(18)----如何引进开发方式

本文作者:sodme

本文出处:http://blog.csdn.net/sodme

声明: 本文可以不经作者同意, 任意复制, 转载, 但任何对本文的引用都请保留文章开始前三行的作者, 出处以及声明信息. 谢谢.

前记：

说中国IT浮躁，一种表现是，国外只要有个什么新鲜概念，国内圈子里就马上炒起来了，说：人家发明了一种什么什么开发方式，多么多么先进，效果多么多么好，要不我们也试试吧？

这是一篇有关“如何引进开发方式”的作团队感悟，其核心思想是：每个团队，都会在技术水平、团队氛围、心理心态等方面有诸多不同，我们不能武断地以别人对一种开发方式的评价而冒然决定在不在自己的团队中使用。即使是要使用这些新概念，也要根据团队实际情况进行改良和再造，抓住新概念的本质精神，对具体方式进行简化和借鉴，以求更好促进当前的开发。

引入正文----

敏捷开发，早已不是什么新鲜概念，但我本人对于敏捷最本质含义的理解，是在近一两年才逐渐深刻起来的。

我认为，敏捷二字的含义，至少有这样两层：

一是研发速度的敏捷，通过优化协作方式、设计方式等等快速推进研发过程；

二是对市场需求的快速响应，这个决定了产品的方向。

也就是说，在我看来，“敏捷”，是相对于整个产品线而言的，它绝不仅仅只是研发阶段需要，这个完整的产品线包含了：策划设计、产品研发、产品运营、客服反馈、市场营销等多个环节，敏捷的方法可以从研发拓展到其它多个领域，从总体上提高整个产品对于市场和用户需求的响应速度，从总体上提高整个团队对于产品战略的执行速度。

把“敏捷”仅仅理解为研发的敏捷，是一种狭隘，但研发的敏捷，是其它环节敏捷的根基所在。

单就敏捷开发而言，它本身只是一个概念，由这个概念衍生了很多可以让研发更快速的具体开发方式，比如结对编程，比如SCRUM。而无论采用什么样的开发方式，其最终目的都只有一个：又快又好的出产品，敏捷理论也不例外。“快”和“好”，成为我们不断为之追求的目标。

而事实上，当你对敏捷的应用越来越驾轻就熟，越来越心领神会的时候，你会发现，敏捷不只是一种开发理论，它甚至，是一种宗教。因为，它通过这种非常具体的方式在传播信仰，树立共同的价值观，这种价值观，就是：分享、务实、精益求精。这种体会，也在我们采用了SCRUM之后愈加深刻。

我们的SCRUM，严格意义上来说，并不是教科书上那种非常规范的SCRUM，我们只是截取了SCRUM中最精华也对我们最有用的部分加以采用。

早在前面的文章里，我就曾经提过，我们的研发是这样：

1. 制定阶段性的研发目标，之前的作法是整个团队有一个统一目标，现在已经变成每个小组有一个目标；

2. 在阶段性研发周期内，将研发任务拆解，我们没有特定的系统分析人员，每个人都从头到尾设计自己的完整系统，包括了：系统分析、编码、白盒测试；

3. 每天有一个晨会，每个研发人员都要参加，在这个晨会上，每个人简单讲三句话：昨天“完成”了什么内容；今天准备“完成”什么，需要谁配合；昨天的工作中有哪些教训和经验；

4. 在研发过程中，通过多种手段充分分享开发信息，比如：面对面的交流、IM的广播、电话交流等等；

5. 每个研发人员享有充分的自我管理权利，上级只关注你作的结果，而不再关心你作的过程。

由上面的几点可以看出，这种开发方式，要求每个人都能有良好的自我管理能力，要能管理自己的研发进度，研发质量和研发效率。但是，人无完人，并不是每个人都能很好的作到自我管理，遇到这样的情况怎么办？

我们的作法是这样：

1. 想尽各种办法，帮助他提高自我管理水平，比如：由有经验的同事传帮带，参与每个小组的小晨会和关键系统研发讨论，辅导他们的开发流程；利用各种方式将好的自我管理方法分享给其他人；

2. 如果他的自我管理水平实在太差，但他本人工作很努力，那就只有安排一些对自我管理要求不大的系统给他，把整个产品的研发风险降低；

3. 如果他不仅自我管理水平很差，而且不学习、不进取、不分享，我们只有放弃他，不会再在他身上浪费时间。

可能，我们使用的敏捷和SCRUM开发方式，会被很多正统人士认为并不是真正的敏捷和SCRUM方式。但我想说的是，我们学方法、学理论，最重要的，是抓住其核心点，要看怎么作才对我们的团队和项目更有利，完全没必要按照各种敏捷范式把相关的流程和人员全部准备齐了再来按书本上教的方式进行敏捷，每个团队完全可以根据自己的情况进行精简或者完善。

我始终认为，越简单的东西，就越容易持久。因为，越简单，就越能让更多数的人理解、记住并使用它。说到开发方式这一块，也是如此，如果一个开发方式的流程太过复杂和繁琐，它必然无法获得大面积推广。所以，在听到一种新的开发方式时，我会首先思考是否能用于我们的团队，而后，我会思考如何更简单的用于我们的团队，如果使用方式太过复杂，我不会选择它。

就各种各样的敏捷方法而言，我们绝不会教条化的去引进，需不需要用、能不能用，完全应我们自己的需求和感受而言。比如，对结对编程这种方式的使用，就是非常灵活的。

我们平时的开发，是以SCRUM为主导，以其它开方式为辅。如果我们遇到一块逻辑，在服务器和客户端的逻辑上是相似的，就会由参与者自己临时采用结对编程的方式，把这块逻辑作完。而一旦作完了这块逻辑，就又会恢复成各自开发的状态。

我听说，很多单位在采用结对编程时，为了让两个人能轮流编程，甚至采用了两个人只给配一台电脑的方法，在整个项目的开发期，都是两人用一台电脑。我不知道其他人在这种情况下会感受如何，就我自己的体会而言，我很反感这样长期的结对编程模式，因为它让我的工作环境没了隐私性和自由。在整个的研发周期里，编码只是其中的一个环节，还有很多其它的事要作，而这些事，我不想也没必要让旁边还有一个人看着。这样的方式，让我觉得太过教条化。

我们奉行的是，首先，要让作事的人自己爽起来，如果一种开发方式会让开发者很不爽，不管它多么先进，我们都不会马上强制采用，我们宁愿去花时间、花代价让开发者自己体会该不该用，能不能用，最终能自觉使用。

所有的所谓管理，其最终的落实，都在一个“人”字上，一种方式不行，我可以换一个，但如果你把“人”和“人心”给“毁”了，代价就要大得多。开发方式的选择要因应团队成员的现实状况，这个现实状况既包括了技术水平，也包括了心理心态，当技术水平和心理心态没到那一步的时候，强行推进一种开发方式，其效果只能是适得其反，在这种时候，我们更多应该考虑的是，如何更好更快的提高和改善大家的技术水平和心理心态。