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

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

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

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

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

-------------------------------------------------------------
生活就像打牌，不是要抓一手好牌，而是要尽力打好一手烂牌。