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

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

甲:最近还好吧?这么迟才上班的
乙:还好,今天算早的了。要赶去参加今天的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. 敏捷开发和管理中,如何让后进来的新人尽快熟悉产品和架构?


-------------------------------------------------------------
生活就像打牌,不是要抓一手好牌,而是要尽力打好一手烂牌。
posted on 2011-06-01 23:31 Paul Lin 阅读(908) 评论(1)  编辑  收藏 所属分类: 软件过程与软件方法项目管理


FeedBack:
# re: 【原】敏捷开发沉思(真实对话)
2011-09-20 00:51 | Lorry Li
我们新公司刚成立不久,我在负责软件开发部的工作,最近一直在思考推行 MSF for Agile(Scrum) v5.0,看了很多关于Agile的文章,尤其看了你的这个帖子,我犹豫了。。。希望能一起探讨一下哈。 我QQ:5578929
注:我在美国达拉斯,跟国内时差13小时(比国内晚)  回复  更多评论
  

只有注册用户登录后才能发表评论。


网站导航:
 
<2011年9月>
28293031123
45678910
11121314151617
18192021222324
2526272829301
2345678

常用链接

留言簿(21)

随笔分类

随笔档案

BlogJava热点博客

好友博客

搜索

  •  

最新评论

阅读排行榜

评论排行榜