【原】敏捷开发沉思(真实对话)

今天早上坐车，偶遇到一个兄弟公司的开发人员。聊到了他们的日常开发模式。颇有感触，特此记录下来供诸位参考

注：所有对话均为真实内容，部分敏感信息略过

甲：最近还好吧？这么迟才上班的
乙：还好，今天算早的了。要赶去参加今天的standup meeting。

甲：Standup meeting ？ 你们在用敏捷管理啦？
乙：是啊。推行几个月了。

甲：为什么突然推行敏捷管理啊？印象中你们是很严格的RUP流程啊
乙：唉，你不知道。原来那个项目，做了2年，上头投资了2亿美金，光是开发就有80号人在做。结果2年来都没有什么明显的成果。上面决定把这个项目交给其他公司来做。

甲：为什么会这样啊？
乙：因为搞产品设计的人，一开始就把产品想象和设计得非常完美。于是投入了大量的人力，物力，时间来开发。但是这个产品实在太复杂了，中间反复改了很多次，等他们开发出来后人家客户早就不要了。根本赚不到钱，但又不能扔掉所以只能外包给第三方公司维护。

甲：哦，这样啊。是啊。电信行业的变化实在太快了，传统的方法有点跟不上。尤其是你们这种很注重过程、文档的研发部门。
乙：因为这样，原来这个项目组解散，所有人要么转到其他项目组，要么走。最近走了很多人！

甲：那你呢？
乙：我现在转到另外的项目组，这个项目组采用的是敏捷开发。和原来完全不一样

甲：那你们都采用了哪些敏捷实践？
乙：迭代式开发，站立式会议，结对测试(自己发明的)，扁平式的组织结构

甲：你们的Scrum master是自己培养的还是空降的？
乙：没有Scrum master，是大家按照对敏捷的理解来进行的。

甲：你对敏捷的感觉如何？
乙：怎么说呢....有好有坏。好处就是灵活很多，省去很多繁冗的流程。坏处就是很容易失控。

甲：此话怎讲？？
乙：就拿我们组来说，我们组的规模是10个人，每个人都是“全功能角色”(：这是Scrum里面提倡的全功能团队的一种方式)。

甲：然后呢？这样不好吗？
乙：不！因为每个人的能力不同，有新同事能力很一般，根本无法承担“全功能角色”的要求。

甲：那不是还有“结对编程”吗？
乙：这样也有问题。两个水平相差很远的开发人员一起结对。高水平的很忙，水平一般的无事可做。

甲：嗯，结对编程的一个前提条件是水平相当
乙：是啊。要不就变成带新人了。而且如果两个人对需求的了解不同的话，那就更麻烦了。

甲：怎么会出现这种情况，你们在迭代开始阶段和每天的站立式会议中没有统一好认识吗？
乙：因为上面说是“敏捷”，所以很多时候我们在迭代开始阶段只有一个PPT，描述一个简单的原型就开始动工了

甲：汗~~~，敏捷提倡面对面的交流胜过文档。但也提到要合理的文档。你们这样做我觉得曲解了敏捷了
乙：是啊！一个PPT叫人怎么干活啊，所以我们划分任务的时候都是按照“纵向”的功能模块划分，生怕“横向”划分后各种接口定义沟通太麻烦了。

甲：嗯....可是这样看起来，我完全看不到敏捷的任何好处啊
乙：嗯。实际上，我更喜欢RUP，虽然麻烦但很清楚

甲：那你们连文档都没有，测试的时候怎么保证：
乙：我们有结对测试

甲：结对测试？有这个吗？
乙：是我们自创的。因为我们的组是5个开发人员对1个测试人员，所以测试人员经常应付不过来。所以我们让测试在工作时拉上开发，一起过流程。

甲：那你们有持续集成吗？
乙：没有。我前面说了嘛，我们都是按模块划分的，都是每个模块自己做内测。然后进行集成测试。

甲：那不是很容易在集成测试出问题？
乙：是啊，经常需要反复

甲：你们一个迭代通常要多久？
乙：大概一个月吧

甲：我感觉我们国内对“敏捷”的理解有点流于纸面。都是重形式轻本质，甚至有点纠枉过正。
乙：是的。尤其是文档这块，很不习惯！对后进来的新人要求很高，因为没有文档，所以只能看代码，很郁闷

甲：那不懂就问啊，难不成从头看到尾，你们的业务那么复杂
乙：大家都忙啊，很多时候新人问问题大家都不怎么理睬

甲：我实在看不到任何敏捷的优势，从你们这里。
乙：就说嘛，我还是喜欢RUP。现在组里的气氛有点和以前不同了，以前很活跃的，现在有点沉闷

聊到这里时已经到了公司。可是我的思维没有停下来，脑海里一直在思考他说的问题：

作为一个严格的研发中心(拿过不少总部的大奖)，为何于出现这种情况？我印象中3年前我在那个办公室时，很羡慕他们那群技术大拿天天开技术大会，那个项目是一个非常大的项目，而且具有很大的后续潜力。可是现在被同行打得找不到北，据说现在每年只能挣几十万！这个数连缴每个月的水电开支都不够。

为什么为什么？？？如果是传统的RUP流程和大公司那种对产品无限制的完美要求，把这个项目拖垮的话，那么为什么在实行了敏捷开发和管理后，还有人愿意回到原来的RUP流程中去呢？

我的脑海里冒出无数个疑问：

A. 敏捷是不是站立式会议，是不是把项目切分成几个小阶段就是迭代了？

B. 敏捷的团队规模要多大？10个人还是4，5个人？

C. 敏捷团队中的人员如何配置？是不是要水平相当，经验相当？

D 当团队中出现短板时，敏捷的结对编程会不会变成致命的缺陷？

E 敏捷团队中全功能团队和去角色化(尤其是没有PM这个角色)，会不会让项目失控？

F. 敏捷不是完全抛弃文档，但是文档要去到什么级别？ 和传统的文档又有什么区别？

G. 敏捷开发扁平化的结构，如何保证不会出现扯皮和纠缠不休？

H. 站立式会议如果避免沦为流水账汇报，如果让大家清楚得知道你在干什么，遇到什么问题？

I. 敏捷开发究竟适合哪些业务场景？项目or产品？(同行倾向于项目，说是产品经常要改，可是敏捷的宣言不就是拥抱变化吗)

J. 敏捷开发中，成员分工要如何进行？横向划分或者纵向划分？

K. 敏捷开发和管理中，如何让后进来的新人尽快熟悉产品和架构？

评论

24 楼 guyuanwuxin 2011-06-24  

RUP管理错误，此公司应该优化裁剪自己的RUP，不应该换到敏捷等管理上面。
这样只能是麻杆打狼两头受气，杯具

23 楼 quTomorrow 2011-06-21  

啥敏捷，就是叫个敏捷的名字的吧。还不如叫混沌式软件开发。

估计RUP也差不多吧，东西出不来和采用什么软件方法应该关系不大。

22 楼 ouyangshixiong 2011-06-21  

楼主的失败的大项目证明。产品人员不行，技术再牛逼也没有用。反过来，因为项目的失败又来折腾技术，那是失败中的失败。

21 楼 energykey 2011-06-21  

我们也是敏捷，不过山高皇帝远，敏捷成了不写文档的借口了。

20 楼 crystal82 2011-06-19  

很好的总结，收了~~~

19 楼 victor71 2011-06-15  

学其神而非学其形。再好的管理方式也要结合实际。

18 楼 lkj107 2011-06-14  

个人感觉这种需求都确定了的项目用敏捷不太合适

一个大公司做本领域的产品，应该有很多的积累的，还要用2年的时间来RUP，这个绝对是有问题的

可以根据需求的分级，一部分功能的往上加

敏捷在国内的大部分公司都很难实施

17 楼 黑暗浪子 2011-06-13  

这些问题我的回答是这样。
A. 敏捷是不是站立式会议，是不是把项目切分成几个小阶段就是迭代了？

肯定不是你说的这样
B. 敏捷的团队规模要多大？10个人还是4，5个人？
理论上是7加减2，包括所有角色，product owner，scrum master，开发，测试等人员

C. 敏捷团队中的人员如何配置？是不是要水平相当，经验相当？

最理想情况是需要水平相当，经验相当的，但现实中几乎不可能。人员配置，1个product owner，1个scrum master，1-2个测试，3-4个开发。
D 当团队中出现短板时，敏捷的结对编程会不会变成致命的缺陷？
肯定是致命缺陷，但是经验浅的人更加需要主动，人人都从没经验过来的，关键看你是否全身心主动投入。
E 敏捷团队中全功能团队和去角色化(尤其是没有PM这个角色)，会不会让项目失控？
优秀的scrum master起着监督和引导作用。如果scrum master不行，项目不失控是不可能的
F. 敏捷不是完全抛弃文档，但是文档要去到什么级别？ 和传统的文档又有什么区别？
这个有很多说法，还是根据项目实际情况来看。我个人觉得这方面敏捷做的相当不好。
G. 敏捷开发扁平化的结构，如何保证不会出现扯皮和纠缠不休？
听大多数的人的意见。如果出现难以定论的事情，可以让每个坚持已见的人做一件事情。老外说法是“时间窗”或“小石子”，其实就是中国人说的投石问路，花少量时间，比如半天，让每位按自己的想法实现，如果到了时间没有完全实现或者实现效果很垃圾，那么就找其中最好的一种想法去做，其他人都统统闭嘴吧。
H. 站立式会议如果避免沦为流水账汇报，如果让大家清楚得知道你在干什么，遇到什么问题？
stand meeting中，每人只说三件事。昨天做了什么，今天要做什么，昨天碰到哪些问题。如果大家听了还是不清楚，那只能说明平日互相之间沟通太少或这个人表达能力太差了，时间长了，他在项目里就是短板，就可以自行淘汰。
I. 敏捷开发究竟适合哪些业务场景？项目or产品？(同行倾向于项目，说是产品经常要改，可是敏捷的宣言不就是拥抱变化吗)
敏捷我认为不适合产品。其实项目也经常要改。所以说拥抱变化这句话是没错的。但是产品管理和项目管理看似一样，其实大不同。最早我看到的资料都称之为敏捷项目开发管理。为啥现在就说敏捷开发了，我也纳闷。
J. 敏捷开发中，成员分工要如何进行？横向划分或者纵向划分？
分工和之前说的一个问题中人员配置很相同。不过我不清楚你说的横向，纵向是指前后端和模块划分吗？好像敏捷中开发的task都是每位项目成员自己认领的呀。其实说task不好，应该说userstory，如何划分用户故事可是大学问。这个可以找mike cohn写的一本书看看。
K. 敏捷开发和管理中，如何让后进来的新人尽快熟悉产品和架构？
首先后进的新人一定要对敏捷有概念。不可能要人培训他一些基本敏捷的管理理论。其次对于项目情况，个人认为每位老成员有责任去告诉他。还有刚开始进入项目，最好可以先和测试人员做结对。老实说，老外说的结对编程是XP里提出的，后来scrum里更加明确结对不应该仅仅指开发，也应该有设计，测试，写文档等等项目中需要的工作。

我对敏捷的看法是它不是银弹。有时候我们在运用这些老外提出的理论到实际中时候，还必须根据项目本身情况进行一些创新。可惜现在天朝大多数搞敏捷的人都是依葫芦画瓢，生搬硬套，当作解决任何项目中发生的问题的万能药。这种做法和想法实在是太可笑了。另外18摸也响应形式，搞了个agile RUP的。如果有兴趣可以去看看相关资料。

16 楼 rubynroll 2011-06-08  

无语...
还是花点钱请咨询公司吧，别有桥不走非得摸着石头过河。

15 楼 Crusader 2011-06-08  

拥抱变化之美 写道

个人认为，楼主提到的“乙方”出现了两个错误：
1.    RUP项目的失败根源在于力求完美，总想以不变应万变，想法是好的，但不现实，没有把握好时间、人力、物力、财力的投入；
2.    敏捷过程的混乱在于流于形式，没有把握每个观点的本质和适用范围，就生搬硬套；

恩，貌似奔走在两个极端

14 楼 chengji518 2011-06-08  

开发团队中，是不是每个人都尽心尽力，这个问题有待大家思考。搞产品设计人有时候一个想法，会搞死一大堆人，这也是个问题。管理也很重要，这是毋庸置疑的。每个人遇到的问题都不一样。找到合适的解决办法，有时候放弃也是一种好的选择。

13 楼 pior 2011-06-07  

rebornphoenix 写道

我的脑海里冒出无数个疑问：

A. 敏捷是不是站立式会议，是不是把项目切分成几个小阶段就是迭代了？

不只是站立会议`还有很多管理上的差别`迭代之间的衔接也很重要`

B. 敏捷的团队规模要多大？10个人还是4，5个人？

7+-2

C. 敏捷团队中的人员如何配置？是不是要水平相当，经验相当？

敏捷开发相对来说对人员的综合素质要求要高一些``

D 当团队中出现短板时，敏捷的结对编程会不会变成致命的缺陷？

结对编程应该说是快速提高的好办法`

E 敏捷团队中全功能团队和去角色化(尤其是没有PM这个角色)，会不会让项目失控？

没有PM但不是完全没有角色``比如scrum master

F. 敏捷不是完全抛弃文档，但是文档要去到什么级别？ 和传统的文档又有什么区别？

文档一般是够用就行``不要过早的细化一些还不知道的东西``

G. 敏捷开发扁平化的结构，如何保证不会出现扯皮和纠缠不休？

团队的整体意识很重要`

H. 站立式会议如果避免沦为流水账汇报，如果让大家清楚得知道你在干什么，遇到什么问题？

流水账式的汇报只要能把事说请清楚就行``本来站立式会议也只是一个加强交流的方式``不是解决问题的地方`

I. 敏捷开发究竟适合哪些业务场景？项目or产品？(同行倾向于项目，说是产品经常要改，可是敏捷的宣言不就是拥抱变化吗)

都可以`可能某些团队有适合的场景`

J. 敏捷开发中，成员分工要如何进行？横向划分或者纵向划分？

纵向划分的较多``以独立的完成可以发布的功能``但必要的情况下`也要有横向的组件团队和集成团队`

K. 敏捷开发和管理中，如何让后进来的新人尽快熟悉产品和架构？

结对

敏捷管理相对来说`对团队成员的要求也比传统方式要高`

对管理人员的管理艺术要求更高`

12 楼 hlj79513 2011-06-05  

听起来是挺好的.不过觉得每个团队都有自己的特性,不能一概而论吧...
敏捷开发不是万金油 个人理解

11 楼 cppasm 2011-06-05  

对RUP的理解有问题吧，RUP和敏捷也不是对立的，而且RUP的一个特点应该就是可以让各个团队根据自己的情况对其方法进行裁剪

10 楼 andy_ghg 2011-06-04  

郁闷，到目前为止我还在搞作坊式编程。但是我决定不了这个现状。悲苦中。

9 楼 Sunny_kaka 2011-06-03  

感觉你们的方法可能有点极端.
RUP开发产品开发时间太长,追求完美,而不是短期内迭代产品投入市场收获反馈.
而敏捷用起来有点像散兵游勇,缺少沟通.

其实不管什么方法,只要能迅速拿出产品得到用户认可从市场拿到回报就是好方法.

8 楼 guozq518 2011-06-03  

恩    看了很有感触   应该好好想想

7 楼 llyzq 2011-06-03  

LZ故事中部门所开发的产品周期太长，最关键是对业务、客户需求、市场和产品架构失去了控制

如果当时有一个对业务非常精通、明确知道客户想要什么、市场需要什么的业务分析人员

如果有一种精通业务和技术，能够为产品确定框架的大拿

那这艘80多人的大船应该能够向着正确的目标前进，并到达彼岸

但实际情况是，没人，或者说没有这么一个小组能够完全了解并控制业务和产品

传统的开发方式很容易出现这样的事情

迭代开会在一定程度上可以解决这样的问题，但我觉得跟敏捷没有直接的关系

用迭代的RUP也能处理好这样的大项目

6 楼 拥抱变化之美 2011-06-03  

个人认为，楼主提到的“乙方”出现了两个错误：
1.    RUP项目的失败根源在于力求完美，总想以不变应万变，想法是好的，但不现实，没有把握好时间、人力、物力、财力的投入；
2.    敏捷过程的混乱在于流于形式，没有把握每个观点的本质和适用范围，就生搬硬套；

5 楼 zhaodidong 2011-06-03  

从国外找几个概念 回中国吹捧一番 到最后啥也没做