Agile 101: CoC & Why Agile is Hard

冰云同学给的命题作文 blog post: http://www.blogjava.net/raimundox/archive/2007/03/30/107375.html

我常常听到这样的观点：敏捷软件开发并不是真正的革命性的方法，它所采用的技术大多都是古已有之的。比如迭代，你看很哪本软件工程的教科书上没有提到迭代开发呢？在比如说User Story，看上去也不只不过是Use Case的翻版而已吧！甚至我看RUP也和敏捷方法没有太大的区别吧！
要我说，这些人要么是不真的了解敏捷开发，没有认识到敏捷开发的革命性，只是用外在的形式来把它和其他方法进行了比较。有又或者是实施敏捷方法的时候不彻底，所以四处碰壁以至于搞起了修正主义。最可怕的就是某些大公司，看敏捷火了，总有包装一下，到底还是要卖产品。敏捷软件开发就是一个革命性的方法，只不过它要颠覆的不仅仅是低质量的软件开发方式，更重要的是，它要颠覆软件生产企业和软件的使用企业之间的生产关系！!这一点在敏捷宣言里写得再明白不过了

Customer collaboration over Contract negotiation

敏捷软件开发，就是要以一种更合理的共赢的合作关系，代替以前畸形的采购式的合约关系。为什么合约关系就是畸形的？我们来看看合约双方的处境。

首先软件团队方面承担了过多的风险：业务变化，改代码！！商业抉择转换，改代码！！凭啥你甲方的缘故非要我承担额外的成本？你说我冤不冤？冤！但是人家甲方也冤！！人家花了大把的银子，拿到一堆不能用的软件（你要是硬件人家还能转手卖点钱），就像你要砍树别人给你把铲子，你要种树人家给了你把锯。搁你，你也不愿意。且不说博弈，就算双方都有心把事情做好，按合同来，甲方不干；不按合同来，乙方不干，最后变成“有心杀贼无力回天”，大家一起扯扯皮等二期算了。lose-lose，没有赢家。

那么合作的关系是什么呢？合作的关系就好比你去subway买三明治，面包你自己选，要什么肉你来挑，蔬菜，cheese，酱汁你也自己看着办。技术我来，口味你选。技术失败我负责，口味不合适你负责。你做你的强项我来我的强项，最终大家高高兴兴嘻嘻哈哈不吵不闹，作出一顿可口午餐。这是时候，生产关系变了，我不是你的冷冰冰的供应商，你也不是我邪恶的客户，我们是拴在一根绳子上的蚂蚱。成功是我们的，失败也是我们的。荣辱与共，携手并肩。听着有点耳熟？没错，SaaS。敏捷宣言早就说了，CoC啊。从供应商变成服务商，从服务商变成战略合作伙伴，这是在给软件企业指出路，新的生产关系已经尽在其中了。

如果看不清敏捷的这个根本革命点，以为还是开发方法的小打小闹，那么敏捷根本实施不成。这话一般我不敢说的，程序员自发实施敏捷，只在一种情况下可能成功：大企业的IT部门。再赶上个强力的IT领导，自家人嘛，有什么不好谈的。一来二去，就成功了（看看C3，说白了不就是IT部门和业务部门？）但是，如果是做项目的公司，你营销手段不改变，敏捷就不可能成功。你的客户跟你不是合作关系，你通过敏捷增加质量（符合性质量）的工作就不会被人可，那么就不能成为投资，只能是成本。当成本增加到不可承担的时候，敏捷就不了了之了。为什么好多人说老板没有响应？旧的生产关系下敏捷根本就是负担。

说道这里，说一下以敏捷闻名的ThoughtWorks。其实很多人都以为ThougtWorks只有方法论咨询，没错我们是有方法论咨询，但是也有业务模式咨询，客户业务模式不改变，他怎么能彻底敏捷？这点大家不可不查啊。

让人绝望的文章

Business Model的变化才是根本性的变化.

CoC似的方式就把一次性的大谈判,变成了很多次的小谈判.
甲方也许会担心,乙方是否会有意夸大每个功能点的代价.
比如在房屋装修中,很多对装修不熟悉的人愿意选择
"包工包料"的一站式合同方式,以避免麻烦.

作为开发方来说,大多欢迎CoC似方式,但业务活动需要比较高的
预见性,以做各相关方面的准备与协调.这也会是个需要平衡的地方.

有个问题,这种CoC似的方式,需要什么样的条件才适用呢?

在工程中用监理来作这样的事
PS:监理还带表国家信用

raimundox实际上设定了一个很高的门槛：客户和开发商必须是合作关系，才能敏捷。

合作关系对于客户意味着：客户要把自己的业务决策权利拿出来和开发商分享；
合作关系对于开发商意味着：开发商要做的事情不单单是软件开发，必须参与客户的业务决策；

因此合作关系下的客户：必须对开发商有充分的信任，相信并且愿意开发商参与公司业务决策；
因此合作关系下的开发商：必须对客户的业务有相当程度的精通，能够在某种程度上指导客户进行业务决策；

推导：处于合作关系下的开发商实际上已经变成了咨询公司，从一个合约关系乙方的弱势地位变成了给客户以指导的咨询强势地位。

结论：软件开发商必须向软件咨询公司转型，例如IBM，埃森哲，毕博莫不如是。

展望：具备向软件咨询公司转型实力的开发商太少，但这应该是软件行业的努力方向，只有这样，才能树立竞争门槛，淘汰掉绝大多数实力弱小的开发商，扭转软件行业低价劣质竞争的弊病。

虽然大公司在很多方面具备得天独厚的优势，但是小公司一样具备其特有的优势。

在这里，其主导作用的还是“人“ 。

举一个比较极端的例子：即使一个大公司背景的咨询，如果其具体合作过程中的工作得不到对方的认可，一样丧失“信任”的基础。反过来，一个小公司背景的咨询，如果能够在具体合作过程中得到乙方的认可和肯定，一样可以赢得“信任“和“尊重“。

虽然，相对来说，大公司可以更容易达到这一点，但是小公司具备的优势仍然是不可替代的，这也是很多项目存在选择余地的理由。

所以，一个项目性质的团队如果真正具备了“敏捷“的“基础“， 那么这个团队在经历一些努力之后，仍然会得到广泛的认可和“信任“的，当然，这个团队在大公司或者小公司的区别并不能成为唯一左右合作的因素。

说道具备“敏捷“特性的项目团队，我做过一些思考，大致应该具备如下几个核心人才：
* "敏捷“的业务分析/咨询 人员

* "敏捷“的技术带头人

* "敏捷“的一两个技术核心人员（用于指导，带领新员）


* "敏捷“的市场关系人员 （嘿嘿，或许在范围之外）




业务分析/咨询 在项目中是至关重要的作用，至于什么才算“敏捷“呢，raimundox在这个帖子里面提到了一个很重要的要求：
http://www.iteye.com/topic/65999

最后一点或许不成为团队的一个因素，当然，这都在项目拿到手的前提下的成立的团队而言。

我还是认为用第三方的方式比
咨询+开发商的方式要公平,公正
咨询公司如果能以甲方为主要客户群体
才能让软件业良性发展
现在咨询公司总是给开发商作咨询.....

大的咨询公司，例如IBM，埃森哲，毕博就不谈了，人家是是直接面向最终客户的，提供整体解决方案，大包大揽的。

小的咨询公司，例如现在JavaEye注册的咨询公司，之所以不愿意直接面对最终客户，而选择给软件开发商提供咨询，原因实在过于明显：

合格的咨询师都是可遇不可求的稀缺资源，一个小咨询公司能有几个撑得起门面的咨询师就已经很厉害了，你要保证咨询师不被大公司挖走，你可以想想需要出多少工资和多高的待遇才能留住。咨询公司自己接项目做，把这些咨询师投入开发，公司会赔本赔的很惨。如果咨询公司自己招聘程序员接项目做开发，那就已经变成一个软件开发商了，而且还是一个没有什么竞争力的开发商，越是大项目，越需要公司充足的现金储备，越需要降低开发人员的运营成本，在国内，软件开发商只能拼成本，拼价格。所以小的咨询公司绝对不能接项目，否则会死得很惨，必须做那些回款速度快，不需要牵扯太多时间的业务，例如按天计算的培训和咨询等等。有时候我们也会碰到客户希望直接把项目交给我们来做，但现在我们已经不敢接项目了，所有找上门的项目肯定全部推掉。

大的咨询公司如IBM公司，他的咨询师成本没有那么高，因为他所有的咨询业务是基于他的软件产品和服务的，咨询师的培养很快，一般水平的开发人员，只要熟读公司内部的产品服务文档就可以了。所以你可以看到IBM的咨询师提供服务，总是随身去查他们电脑里面的一个内部文档库，超出这个范围的问题，他们就解决不了，当然你可以要求level up，只要加钱，他们会派更高级的咨询师过来。

ThoughtWorks是一个特例，介于咨询公司和软件开发商的一个中间形态。TW不是一个卖软件产品的咨询公司，所以他的咨询师成本也很高。TW既给开发商提供咨询，也给最终客户提供咨询和开发，这个时候他的角色更像一个开发商，但和开发商唯一不同的就是TW的收费方式是标准的咨询公司收费方式，按人天或者人月计算。据我所知，TW在国内给客户做项目的报价每人月至少10万人民币起价，在10万－20万之间。

虽然作为咨询公司直接接项目对于其他国内小咨询公司来说是条死路，但对于ThoughtWorks来说，由于TW的人月报价很高，而且是开口合同，不按项目签合同，按照标准的咨询公司每月一笔每月一笔的收费，所以TW可以赚钱。

但是也要看到，ThoughtWorks的模式在国内是不可复制的。在国内能够接受如此高的人月报价，而且是按照咨询方式签开口合同进行收费的客户很稀少。只有那些认“ThoughtWorks”品牌而且有钱的客户才会找ThoughtWorks，同时这样的客户由于对ThoughtWorks品牌认知度很高，所以很愿意主动配合TW的咨询师，以合作的关系共同推进项目的开发。在这种情况下，再配合ThoughtWorks的敏捷软件开发实践，项目成功把握自然很高。所以前提条件就是：有钱，对“ThoughtWorks”品牌认知。这当然也需要ThoughtWorkers们在国内不遗余力的宣传。

回到主题上来，针对国内的软件开发商，特别是具备一定实力的软件开发商来说，应该建立一个良好的公司技术梯队：少数精英级别的咨询团队和数量比较庞大的开发团队。利用咨询团队建立竞争门槛，利用开发团队降低成本。

首先，楼主犯了致命错误。
Customer collaboration over Contract negotiation
这里说的是协作胜过合同，没有说协作可以替代合同。
敏捷十分强调平衡，而不是楼主的极端。

合同是协作的有利保障。就像法律在我们社会中的作用一样。
楼主接下来的例子，也都是在已经下了结论的基础上把读者向着自己的结论上引。
按照合同就会扯皮，按照合同就会lose-lose，不知道楼主是如何这么顺利的得出这个结论。
合作当然是为了Win-Win，午餐例子有些无聊。请问楼主，你有没有在没有合同为基础的情况下(包括口头合同),成功实现你的所谓的Win-Win？？？？？？？？？？？？

敏捷宣言都没说自己是革命，签署宣言的人也都说不是革命，不知道楼主为什么还非要给安个革命的帽子。

楼主最后出现广告。 -_-||||
Robbin一说我才知道：

哦，原来TW也是要签合同的哦！

实际上作为交付为主的项目，没有这么高。我估计是以讹传讹了。想想看，我们较高级咨询的项目中（比如架构咨询，SOA咨询什么的），比较资深的咨询师差不多1,200$/天吧。你就算请他4周，20天，也不多才24,000$，也就是将近20w，不过这类咨询项目一般都不会这么久。因此实际交付性的项目中，更不会有这么高的天价了。或者我们应该报这个价格才符合大众对TW的定位吗？这个好消息应该告诉我们BD了。



这两个说法都不确切，咨询的前提是双方的信任。因此你牌子再大还是要让客户认可你的，认为你确实可以提供价值。并不是只有牌子和口碑就可以做好咨询的。此外，我们有很多start up和small-medium company的客户，并不是很有钱，但是的的确确在TW的帮助下赚到了钱。因此并不是说你有钱才来找TW，你想赚钱一样可以找TW。至于说客户合作，我们中国区有一个case带点政府性质，人家一开始也是不鸟我们的。我们的bd/cp/ba一齐努力下，客户才从不理解不合作，到逐步理解，到合作的。并不是大家一听TW就一下子变成完美客户了。

最后成功交付的关键点有很多，我们也在不断反思，最近各个office也都在展开Delivery Assurance的总结和培训，以更好的为客户交付价值。