今天早上坐车,偶遇到一个兄弟公司的开发人员。聊到了他们的日常开发模式。颇有感触,特此记录下来供诸位参考
注:所有对话均为真实内容,部分敏感信息略过
甲:最近还好吧?这么迟才上班的
乙:还好,今天算早的了。要赶去参加今天的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. 敏捷开发和管理中,如何让后进来的新人尽快熟悉产品和架构?
1. RUP项目的失败根源在于力求完美,总想以不变应万变,想法是好的,但不现实,没有把握好时间、人力、物力、财力的投入;
2. 敏捷过程的混乱在于流于形式,没有把握每个观点的本质和适用范围,就生搬硬套;
如果当时有一个对业务非常精通、明确知道客户想要什么、市场需要什么的业务分析人员
如果有一种精通业务和技术,能够为产品确定框架的大拿
那这艘80多人的大船应该能够向着正确的目标前进,并到达彼岸
但实际情况是,没人,或者说没有这么一个小组能够完全了解并控制业务和产品
传统的开发方式很容易出现这样的事情
迭代开会在一定程度上可以解决这样的问题,但我觉得跟敏捷没有直接的关系
用迭代的RUP也能处理好这样的大项目
RUP开发产品开发时间太长,追求完美,而不是短期内迭代产品投入市场收获反馈.
而敏捷用起来有点像散兵游勇,缺少沟通.
其实不管什么方法,只要能迅速拿出产品得到用户认可从市场拿到回报就是好方法.
敏捷开发不是万金油 个人理解
我的脑海里冒出无数个疑问:
A. 敏捷是不是站立式会议,是不是把项目切分成几个小阶段就是迭代了?
不只是站立会议`还有很多管理上的差别`迭代之间的衔接也很重要`
B. 敏捷的团队规模要多大?10个人还是4,5个人?
7+-2
C. 敏捷团队中的人员如何配置?是不是要水平相当,经验相当?
敏捷开发相对来说对人员的综合素质要求要高一些``
D 当团队中出现短板时,敏捷的结对编程会不会变成致命的缺陷?
结对编程应该说是快速提高的好办法`
E 敏捷团队中全功能团队和去角色化(尤其是没有PM这个角色),会不会让项目失控?
没有PM但不是完全没有角色``比如scrum master
F. 敏捷不是完全抛弃文档,但是文档要去到什么级别? 和传统的文档又有什么区别?
文档一般是够用就行``不要过早的细化一些还不知道的东西``
G. 敏捷开发扁平化的结构,如何保证不会出现扯皮和纠缠不休?
团队的整体意识很重要`
H. 站立式会议如果避免沦为流水账汇报,如果让大家清楚得知道你在干什么,遇到什么问题?
流水账式的汇报只要能把事说请清楚就行``本来站立式会议也只是一个加强交流的方式``不是解决问题的地方`
I. 敏捷开发究竟适合哪些业务场景?项目or产品?(同行倾向于项目,说是产品经常要改,可是敏捷的宣言不就是拥抱变化吗)
都可以`可能某些团队有适合的场景`
J. 敏捷开发中,成员分工要如何进行?横向划分或者纵向划分?
纵向划分的较多``以独立的完成可以发布的功能``但必要的情况下`也要有横向的组件团队和集成团队`
K. 敏捷开发和管理中,如何让后进来的新人尽快熟悉产品和架构?
结对
敏捷管理相对来说`对团队成员的要求也比传统方式要高`
对管理人员的管理艺术要求更高`
1. RUP项目的失败根源在于力求完美,总想以不变应万变,想法是好的,但不现实,没有把握好时间、人力、物力、财力的投入;
2. 敏捷过程的混乱在于流于形式,没有把握每个观点的本质和适用范围,就生搬硬套;
恩,貌似奔走在两个极端
还是花点钱请咨询公司吧,别有桥不走非得摸着石头过河。
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的。如果有兴趣可以去看看相关资料。
一个大公司做本领域的产品,应该有很多的积累的,还要用2年的时间来RUP,这个绝对是有问题的
可以根据需求的分级,一部分功能的往上加
敏捷在国内的大部分公司都很难实施
估计RUP也差不多吧,东西出不来和采用什么软件方法应该关系不大。
这样只能是麻杆打狼两头受气,杯具