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

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

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

甲：最近还好吧？这么迟才上班的
乙：还好，今天算早的了。要赶去参加今天的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.    敏捷过程的混乱在于流于形式，没有把握每个观点的本质和适用范围，就生搬硬套；

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

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

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

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

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

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

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

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

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

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

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