Martin Fowler关于敏捷开发的主题演讲

软件本来就应该是一种精英产业。可以自动化的都必然被自动化，软件业从来就不需要蓝领。

gigix真是气宇非凡啊，可以吐出“从来就不需要”这样的豪言壮语。

“应该是”不代表“目前是”，或者“现实是”。软件和其它的产业一样，是有阶层的。不同的阶层需要以不同的“过程”以适应之。愈处于核心的精英团队，愈无常态，经常是处于变化和不稳定的状态。而非核心的“凡人”们，则相对稳定，需要比较可测度的方法学。

因此个人认为，XP+Agile和CMM并不是对立的关系，只是其适用范围和对象不同。

传统的软件工程学采用的是预测性方法？我觉得, 总结性多一些。当然也根据过去的总结，进行后面的预测。

一直在看CMM讨论。
http://forum.iteye.com/viewtopic.php?t=9459

高来高去的、概念名词考究的学术讨论，很多东西都纠缠在“你对这个概念名词的理解有问题，你不知道这个，你不知道那个...”。我不敢参与，只敢在一旁静静地听课。
只好趁机在这里说两句浅显易懂的地球人都明白的观点。

CMM的目标是可重复的熟练工。CMM号称更关心过程改进，而不是产生出来的东西。为了简便起见，我还是只讨论CMM产生出来的东西。这比较具体形象一些。鬼知道，过程是什么东西。没有东西出来，过程连完成的机会都没有，更别说改进了。

CMM是以文档为中心。敏捷是以代码为中心。
CMM产生的东西，大部分是文档。敏捷产生的东西，大部分是代码（包括配置发布脚本）。
下面我用XP代替敏捷两个字。不要拘泥于概念用词，凑合看吧.

1. 设计编码能力，废品率，风险
代码的可读性，再怎么改进，也永远比不上最糟糕的自然语言文档（对于Native Speaker来说）。从这点来说，CMM的废品率，要小于XP。

虽然应用程序几乎没有技术门槛，但如果一个公司的设计编程能力实在太差，连这个最低的门槛都过不去，那么不管采用什么管理方法都注定是要失败的。

比如，我是一个采用CMM的公司。我制造了一堆文档，尽管可能到最后，代码都完成不了，也根本对不上文档。我做这个项目失败了。这时候，至少我剩下了一堆文档。至少可以作为失败案例，让别人清楚地看到，我为什么失败。而这些自然语言文档的设计思想可能没用了，但这些自然语言几乎永远不会过时。可以永远作为存档。假设制造的文档占60%，代码占40%，这时候，代码是绝对废品。废品率为40%。从公司的角度来说，至少练习了文档写作。

比如，我是一个采用XP的公司。我的技术能力根本就不行，写了一堆越重构越乱（自以为越牛）的代码，最后失败了（由于XP的特点，也许很快就发现失败了）。那么，我制造的这堆代码，一点用处都没有了。只能扔掉，免得占用硬盘。编程语言，过时非常快。这时候，几乎没有文档。废品率100%.  从公司的角度来说, 除了一个sad story, bad experience, 和赔款，什么都没有获得。

后面的讨论都针对 设计编程能力合格的软件公司。

2. 过程、质量、技术积累
CMM注重过程。XP更注重过程，几乎是偏执地坚持TDD，持续集成。
CMM还有不同阶段工作的变化，一步一步，春夏秋冬。Coder可以有向上爬的理想，爬到详细设计文档写作，爬到概要设计文档写作，爬到需求分析文档写作，爬到架构设计文档写作。
XP没有分工，从头到尾就是这个套路，TDD, Refactory, 和需求直接到交道，从没有工作阶段变化。看不到什么前途，再往上爬，还是Coder。当然，也同时是Designer，Analysist, Architect。但是，你没有下级。只有高级、低级之分，没有上下级，满足不了那种人上人的感觉。
从代码质量和最后的成品质量来说，通过常识也可以判断出来，什么地方投入的越多，什么地方产生的东西就越多。什么地方跌倒了，就从什么地方爬起来。代码最难懂，最难管理，XP就专门针对代码，而目前的计算机发展水平，最后运行的是代码，而不是文档。相同的合格的技术水平前提下，XP产生的代码质量、最终的产品质量一定会高。而CMM的文档制作标准和水平一定会高。
从技术积累角度来看，XP的积累都在程序员的手里，风险大，好容易培养的团队，一跑，我就什么都没有了。CMM的积累都在管理层的手里，风险小，我留下了这么多的文档，我怕谁？再找一批coder，照样干活。

美国军方肯定还是要坚持CMM标准。军事上的东西不能完全控制在某些技术人员手里。怎么能让技术人员爬到头顶上？

3. 展望
作为程序员来说，我当然希望XP能够大发展。而且看来会，因为thoughtworks的进入中国，Martin Folwer的影响力。
但我觉得，软件公司做好XP，也不是那么容易。CMM只要肯花钱，肯培训，肯下功夫写文档，10年，20年，早晚都能过，分工、分阶段都行。XP可是需要持续地全身心投入，最后的目标就是程序员都至少是半个业务员，对业务领域要有相当深入的了解。
从软件开发人员成长来看，XP的速度要快得多。XP软件公司的技术成长也快的多。至于代码规模控制，只是一种线性的增长。TDD, 持续集成，Daily Build能够控制的代码量，要超过CMM能够控制的代码量，而且代码的作者却要少得多。（注意，这里的控制，是指全面细节的控制）
不过，您愿意在一个XP软件公司工作吗？这个公司的充满竞争力的男性占了大多数。男女比例严重失调。而且客户直接打电话找你，说哪里哪里出了问题，压力很大，没有一个中间缓冲层替你挡着。

我在一个CMM类型的公司里做过项目。工作相当枯燥简单，而且郁闷。经常是一帮从来没有编过程序的人，写详细设计文档。
写文档4个月，写代码2个月。（一种不知道从哪里来的错觉，大家都乐观的认为，只要文档写好了，代码写起来就太容易了。印度IT巨头那种管理水平和设计能力不是想想就能达到的。虽然他们的Coder标准很低，但是设计水平很高。）
明明写错的无法实现的文档，也要一步一步上报，才能修改，而当前为了赶进度，只能按照错误的实现，否则就是怠工。至于代码，鬼知道放在一起能不能运行。
当然了，这完全不是软件工程管理的错，而相反，恰好是没有用好“软件工程管理”的错。一门很好的功夫，你却不得要领而入，怪不着功夫。这个例子，又进一步从反方面证明了工程化、文档化管理的重要性。
由于分工细致，工作明确简单重复，那种公司的年轻MM通常很多。

所以，如果你要开一个XP软件公司，最好做女性人数多的公司客户的业务。这样你的程序员的工作，经常和客户公司的MM直接交流需求，才能保证长久的干劲。否则他们会羡慕外包公司的程序员。

如果是可重复，那么你首先按照软件工程的做法应该是复用。这一点上来说CMM是典型的反软件工程。

文档驱动的愚蠢请参看Grady Booch的论述。敏捷是迭代为方式的风险适应性驱动。

文档在很多时候的可阅读性大大低于代码，即使是客户在很多时候也是看不明白文档。这是因为文档的可阅读性要依赖于其必须同步，而且粒度要符合阅读者的理解水平。并且需要重点突出，不能面面俱到。这一点不用我多举例，你只要多做几个项目就可以看到很多例子。
确实如此，但是失败的代价是会有不同的。
问题是恰恰很多时候文档并不能说明你究竟在什么地方失败了，因为你已经迷失在文档的迷宫中了。永远做为存档也是意义不大的，因为如果这些文档不能呈现其逻辑性和连贯性，那么你如何去查阅他们呢？单纯的存储一些不能被使用的文档，是浪费资源，而不是保存资产。
而且在这种情况下，恰恰是对文档写作最大的抵触。文档写作的练习是需要在正确的方式下，使用正确的方法，在有能力的人的指导下进行的。

你确定你是在使用xp了吗？如果是这样，那么你就可以回复到不混乱的地方，而且你还有一大堆的testcase做帮助。这些都是可以复用到其他项目中的。越重构越混乱只能说明你没有按照xp的步骤去做，你没有基本的SCM保证，也没有基本的单元测试做基础。而没有这两者你的文档也起不到什么作用。
你的这个过程不是软件工程上说的过程，而是说方法的流程。过程是一个体系，而TDD只是一种方法，持续集成也是如此。而CMM不重视持续集成方面的工作，恰恰是其在软件工程方面的弱点。
CMM的不同阶段的酷爱其实是其自身最应该克服的弱点，是瀑布方式的残余。在这样的体系下CODER的作用显得非常的奇怪，以因为他们不可能从整体上对系统有了解，根本就无法去用整体的思考进行学习，所谓的进步只是一种幻想。而在CMM下构建构架基本上是不可能进行的一件艰难工作，这一点我会在解释架构的帖子中专门的解释。而所谓的详细设计和概要设计，也是奇怪的说法。你不从整体上理解项目，所谓的详细设计只能是捣浆糊。而由于CMM需求和构建的脱节，很难让构建者学习业务领域的知识。从而造成其领域支持的匮乏，所谓的可以进步到需求分析的领域的说法，完全是一厢情愿。

xp中存在很多角色，也有很的分工。
当然这里我们要重视的是，所谓的人上人的说法。如果你追求的是去所谓的领导别人，所谓的人上人，那么你最好去做政客。
文档写的越多，制作标准越高，水平越高的说法，显然是不懂文档写作的基本原理。文档质量越好，标准越高，恰恰是需要其规模可被控制在最小的范围。只有这样才能更好的被维护，才能更容易的进行阅读以便进行理解。写的越多，条理越多，阅读带来的复杂性越多，维护起来就越是麻烦，越是不能带来同步。在一个不同步的问题文档体系下，你如何去理解系统呢？你怎么判断这些文档的对应关系呢？你如何去判断这些文档中的矛盾上的双方究竟应该相信谁呢？当然你可以使用硬币。
coder可能流动，管理层就不存在流动。一个团队跑了的可能性大，还是管理层跑掉的可能性大？
当你阅读那些不成系统的文档的时候你就知道你该怕谁了？

美国军方坚持的是2176，而不是CMM。很多敏捷者一样在为DOD开发软件。至少在美工技术人员是在管理者的头上的。而上次郭聃说，他们公司的很多人根本就不搭理什么经理，因为谁也不知道这些人什么时候被解职，但是CTO确实很少被更换。
肯花钱的公司是不存在的？否则这样的组织就不是公司了。你时刻要考虑成本。程序员了解业务难度是坏事情，你会因为程序员负责双重角色而多给他50％的工资，还是会选择至少雇佣两个人去完成他现在的工作。你是老板你会怎么做？
如果cmm成为一种推卸责任的理由（印度公司就是这么做的），cmm的价值何在呢？他还能存在10年、20年吗？
你举的例子非常好。
对，这恰恰就是说明管理的落后和对于软件工程思路的不理解。我们做的是软件，需要面对的是快速变化的环境，所谓的多层管理，根本上就不适合这个环境。工作明确不一定就代表工作好做，而且分工明确，也不代表就可以更好的合作。协调同步才是最重要的，不能协调一切都是白搭。
MM的问题不讨论，因为如果你喜欢MM，你最好换一个行业，比如医疗，那里的MM最多，也最漂亮。可惜那里要求你的应变能力更好，和人沟通的能力也更好。
至少我不羡慕外包公司的人，我想这里大部分人也不羡慕。

按照我们程序员的想法，总是以程序code为中心的。认为文档应该反映Code，和Code一致。但是，从工程学的角度，以文档为中心，Code应该反映文档。如果要对Code进行结构上的修改，首先要修改文档，然后才能修改Code。如果code和文档对不上，是coder的责任。如果code和文档对上了，而这个逻辑是错误的。那么，是文档的责任。

文档写多了，即使内容上不提高，形式上也学到了一套标准格式。给我一套template，我向里面填东西就行了。以后我管理的时候，我也拿这套模办，让别人填东西。
文档多了，虽然会难以追索，但还是比Code容易追索多了。而且，标准目录组织结构，标准格式，标准编号，大体上的结构不会太乱，细节上也许完全混乱。雇一个没有技术背景的人进行查阅整理也很容易，谁的责任可以一步步查得一清二楚，至少可以查到上面几层（虽然如此，但是项目失败了，追查责任也有点晚了. 我说的例子, 就是一个失败的例子。主要和设计人员的技术水平有关。另外，把大部分时间花在文档，而不是code，绝对是本末倒置）

而代码的问题，只能由业内人士，看出问题。大家依靠一些业内积累的共识，比如，Pattern，Bad Smell 等。当然，从道理上讲，这是正确的。应该让懂行的人做内行的事情。
我觉得，XP最好的一点就是不断的集成测试。至于重构，我不知道这里面的限度。重构经常带来过度设计。当然，这不是XP的错。XP要求，必须先写Unit Test，你确信了你需要的结果，才能根据这个Unit Test重构自己的代码。但这种严格的过程要求，却阻碍不了很多程序员重构的快感。我完全可以写出fancy unit test, to meet my fancy idea.



对，就做 最赚钱的医疗系统。:D

第一，文档你不能测试它；第二，文档你也不能把它运行起来看看效果。既然又不能测试，又不能运行，你怎么知道它有没有错、是不是符合用户的需求？这就是文档驱动的最大毛病所在。

1 文档和代码一样可以偏离客户的需求.

2 文档大到一定程度 复杂到一定程度 也是难以维护的.

3 文档也是有时效的 到期是要报废的 无法重用的.

4 写文档的不一定是mm 不一定漂亮 不一定年轻.

其实最好的文档就是将与客户的交流 完整的真实的保存下来. 数码相机 录像机 录音笔要随身携带. 还要经常请客户吃饭 现阶段有效交流的唯一手段.

没错，现在连我们自己内部开讨论会，也要随时把白板上重要的讨论拍照下来。

按照你的说法就不要叫工程学了，叫文档写作学好了。既然是工程学就必然更加重视最终的产品。文档驱动的愚蠢我就不给你介绍了，你可以看看Grady Booch的《面向对象项目的解决方案》。

越重构越乱是因为你没有掌握好重构的技巧。重构不是简单的代码修改。有些不肯学习的人仅仅在听说了重构这个名词后就说：“是啊，其实我每天都做代码重构，这有什么神奇的！” 重构需要按照严格的步骤来进行，并且有大量的技巧。你说这句话我可以肯定你没有认真读过《重构》这本书。是不是因为没有足够的时间？但是我认为这本书是我去年读过的最实用和最有帮助的一本书，所以建议你也看看。

TDD 为重构打下了良好的基础，使得你不必依赖人工测试来验证重构是否安全，加快了开发的频率，让你对于重构有了足够的信心。但是并不是说重构就一定要依赖于 TDD，重构和 TDD 的耦合并没有你所理解的这么紧。这个问题我们去年和 potian 已经讨论过了。与你的想法正相反，我从重构中享受到了很大的快感。TDD 和重构相配合带给我的一切尽在控制之中的感觉简直是妙不可言。我可以断定 CMM 永远都不可能给一个开发者这样愉快的感觉。
作为一个开发者，你的地位的上升应该取决于你的专业精神和工作质量的改善，以及用户满意度的提高。这样你所得到的地位才是稳固的。而不是处心积虑地如何向上爬，如何成为人上人。