小A是支枪，子弹未打光----之"狙击步枪"篇
在开始今天的正文之前，先举一个例子，话说：
其实通过上面的例子，不难发现，在三个小贩向老太太推荐自己的卖的水果时，出现了三种
不同的结果．其中＂
第一个小贩一上来就不问清红皂白，只掌握了表面的需求（老太太要买）就完全用自己的主
观臆测来向客户推荐自己的商品（我的李子又大又甜）．这种情况其实多出现在新手或那些急于
写代码的程序员．
第二种则是比第一种要更成熟，他在耐心听完客户的描述（老太太想买酸李子）之后才开始
介绍推销自己的李子．这种情况是一般软件设计过程中通用的做法，即根据客户的目标和愿望（
老太太买李子不是为了儿媳妇而是为了抱孙子）直接进行开发的，需求分析做的一般，这也是目
前IT公司比较普遍的做法．
第三种显然要比前两种高明的多，因为他所销售的弥猴桃要比李子贵很多．其实他这里用的
是销售中比较高明的手段，就是在归纳用户需求的基本上，通过分析来引导用户需求，从而最终
超越并创造出新的客户需求．
所以这里需求要分为表面需求（如产品和采购指标）和深层次的潜在需求（客户遇到的问题）
其实与客户交流时常发生．每一个到你公司寻求帮助（解决方案）的客户其实都可以把他们
做为一个病人，而我们就是医生（有专业的架构和开发经验和行业背景）．而病人通常是不会知
道自己的病因是什么，只会按表面层次上所体现的症状来让你诊断，而医生通常在了解用户问题
(他的需求)后，会结合自身的经验（行业知识）来帮助用户找出真正的病根所在（即挖掘出需求
背后的需求）．这种抓药方式才是真正的治标治本．
其实一般的技术人中因为平时过于关注技术本身，会有意无意的忽略上面的问题．而其实恰
恰是只有真正理解和重视用户需求，才能让我们从所谓的"技术开发核心"转型到"分析和设计核
心"上来．而如果不重视需求分析，我们就会像第一个小贩那样，最终什么都得不到，即使我们对
这个客户说我们采用了什么高新技术，什么优秀框架等等，用户也只会云里雾里一头雾水，最终
还是无法让其真正将预算投给我们．
说到这里，有必要介绍一下SOA了，不是因为它时髦，而是SOA其实还是一个面向业务需求
的架构方式，这里不要太在意"面向服务"这几个字，其实归根结底最终还是面向需求，面向" 时刻
在变动的" 需求．因为公司企业在激烈的市场竞争中需要灵活配置，快速响应的系统．通过SOA
精心设计的体系架构"实现"商业利益（因为标准不是架构，架构也不是"实现"）并让公司企业迅速
抓住在市场出现稍纵即逝的商业机会．而这才是SOA真正存在的价值．从这个角度上讲，SOA的
应用范畴要在EAI之上，尽管用SOA架构方式进行EAI整合是不错的选择 (因为从头进行SOA架构
对一个有一定的 IT资产(硬+软件)的公司却无疑是一次大的手术．)
SOA的发展可以分为两个阶段，以2006为"分水岭"，2005年以前是各大软件供应商均专注于
自己的 SOA理论研究和框架开发．2006年以后各个大型软件服务提供商开始结成盟，陆续形成了
一系统 SOA规范和标准，并推出各自的面向SOA开发，发布，运营服务产品，如：
BEA：EAI软件Tuxedo、应用服务器WebLogic以及SOA信息传输软件AquaLogic等通基础平台
IBM: WebSphere 等
Oracle: Oracle SOA套件 等
SAP : Enterprise Services Architecture Adoption Program(企业服务架构验收程序) 等
Microsoft: WCF,BizTalk Server(充当ESB角色)等
SOA只是一种架构软件的方式，并不是什么新技术，甚至有专家提出即便使用CORBA（Common
Object Request Broker Architecture），DCOM等老牌技术也可以开发出SOA应用．
当然在形成了事实标准之后，一系列规范也相应出台，如SCA(服务组件架构：Service Co-
mponent Architecture), SDO(服务数据对象：Service Data Objects) ,BPEL(业务流程执行
语言:Business Process Execution Language, 最初是由BEA、IBM和Microsoft联合制订),
ESB(企业服务总线：Enterprise Service Bus)等等．
说了上面这些东西，可以有些朋友开始奇怪我为什么要把写作方向转到SOA上，主要还是因为
业务需求的关系．之前已说过业务需求在实际设计开发的重要性．而做为小A这个技术型从业者而
言，当其遇到技术和业务需求这两方面的问题时，即使知道业务很重要，但也需要一个切入点来帮
助其过渡到重视公司业务上来．而通过SOA的学习，可以一方面研究新的软件架构技术，比如微软
的WCF，另一方面各大公司无论从白皮书到实际案例上都会有关于业务需求分析方面的内容介绍．
所以通过研究SOA，可以满足其同时钻研技术和业务的双层需要．所以小A隐约感觉这是一个切入
点．而下面这张表格摘自园子里一位朋友翻译的SOA in the Real World.pdf的内容，可以帮助理
用开发的行业背景，而在中国做企业级开发生存比较艰难，有关这方面的内容可以参见一下范凯(网
名：robbin，JavaEye创始人）的这篇文章，小A赞同其中的大部分观点．其实通过这篇文章也可以
看出，不管你是JAVA还是.NET程序员，在国内做企业级应用开发的困境没什么太大区别．当然小A
也同朋友和同事偶尔在MSN聊过类似这样的话题，朋友也劝其别趟这汪"混水"，老老实实做Web开发．
不过这个问题倒不是什么重要因素，因为小A可以把其做为自己的"爱好"来加以"关注"．而关注
SOA的另一个原因是REST的兴起．其实目前REST已经是SOA的一个分支了，其也给SOA概念中
植入了简易性为中心的理念．在WCF在3.5已支持了REST架构，并在Codeplex上已有DEMO让
其学习，所以就开始与朋友们一起研究起SOA和REST．
当然在这之前小A也遇到了每个开发人员都会遇到的问题，是做一个彻头彻尾的技术人员，不
去研究业务及行业知识，还是做一个即精通技术同时又精研业务和市场（相当于"会武术的流氓"）．
我想不同的人在这个问题上会有不同的答案，包括大多数情况下意见一致的朋友．
当然做纯技术的研究未尝不是一种选择，但这是一种苦行僧的生存方式．当然在IT圈中（包括
园子里）都不乏其人人，让人很是敬佩．但小A感觉内心深处还是受不了那种清规戒律和孤独．
并且在小A看来在国内这种人还主要是靠用出书，做顾问和培训讲师，甚至所研究领域的产品
代言人等方式来生存．而这让小A感觉没太大意思．不过还是要阐明的是这类人是真正意义上的"照
明信号枪" ，其发射的照明弹可以帮助IT从业者们解决学习之路上的疑问并照亮尽是"泥泞"的周边
即然想走"会武术的流氓"路线，接着就是如何挖掘并分析用户需求了．有关这方面的内容，在
市面上都有相关的图书来说明，这里就不多作阐述了．通过研究和分析用户需求，可以帮助我们抓
住用户，让我们每一行代码都像狙击步枪的子弹一样命中需求的"靶心"．如下图：
接着再说说两个与本文关系不太大的话题
先聊聊SNS, 目前国内的SNS领域已有了不少先行者，比如 51，校内，海内，开心等．而且后
续跟上的还有一些公司．但不知怎么搞的，小A感觉在商业模式不太明朗的情况下，SNS与其说是块
蛋糕，倒不如说是"粪坑", 起码里面的大粪还没有变成可以出卖赚大钱的肥料. 而各个 SNS网站就像
是一根根的 "搅屎棍"，把SNS从内含到外延搅得越来越难以理解，先是抄FACEBOOK，接着再在国
内大家近亲繁殖．今天你搞个"买卖好友"，明天我也搞一个．今天你来个"停车场"，明天我也搭一个，
无非换换名目罢了．搞得SNS网站成了一个个"人贩子网"和"网上停车场"，也许还感觉不够热闹，开
放完API再搞什么大赛，你开发个葵花点穴手，我就搞个菜花或麻花点穴手，真是你方唱罢我登场．
而用户这边只是看过一场又一场大戏，当然也许满足了网民的某些需求，但黏性在哪里呢．起码小A
注册了上述几个网站后，基本上是想起来才去（平均每周一次）．这里不妨套用赵本山老师那句话：
"也许一个崭新的互联网泡沫即将诞生!!!"
而网民是什么需求呢，小A感觉应该有两种"本能性"的需求，一个是"个性展示"，一个是"交流沟
通（在圈子,好友等范围内）"．而似乎中国网民平时生活中不太善于表现自己，起码中国的文化是那
种不温不火的感觉，所以在网上就像变个人，不停的秀自己，表达自己的声音和其它信息．这也是为
什么BLOG之类的应用在国内为什么火的原因，并且即便SNS将来成长起来甚至成为互联网主流，也
不太可能对BLOG造成根本威胁．当然MYSPACE里也有个人空间等应用，但小A感觉SNS应该加强
调社会化关系而非关注个体．FACEBOOK应该就是以此为中心，起码在FACEBOOK上如果没有好友，
活动或加入"网络"等应用的话，你即使"死(虽注册时间长但很久没活动)"在上面也不会有人知道．而似
乎麦田还在这两个本能性需求（麦田称为主体性和主体间性）上左右权衡，是否存在成功驾御平衡这
两种需求的平台．
另外一个话题就是UP和Agile了.
不过可喜的是UML三友之一的ivar jacbson已开始探索并让手下人实践其新的思想"明智软件开发方
法",即：
UP 与 Agile --=>Smart Software Development (明智的软件开发方法)
而前阵子他来中国座谈软件开发时也介绍了一些情况，请看这篇文章．因为大家时间有限，下
面将其主要内容罗列一下：
而去年他老人家就向敏捷开发抛出了某些友善信号，请看这篇文章：敏捷到底是什么？
其核心内容如下：
好了，到此今天的内容就要结束了．
当然本文的内容有一定的主观因素影响，是小A 结合自身性格和技术特点所做出的某种选择，
不确保本文发表后将来还是"一程不变"．所以大家不用生搬硬套．另外希望本文能为鼓励大家寻找
思路提供一些"愚见"．如果不同意本文观点，请在看完之后尽快忘记所谈内容，以免误人前程．
好了，今天的内容就先到这里了．有兴趣的朋友可以在回复中进行讨论．
tag:开发,webservice,soa,wcf,手 枪,步枪,framework,SNS,UP,agile
作者:代震军,daizhj
原文链接:http://www.cnblogs.com/daizhj/archive/2008/09/12/1289817.html
一位老太太离开家门，拎着篮子去楼下的菜市场买水果。她来到第一个小贩的水果摊前问道：
“这李子怎么样？”
“我的李子又大又甜，特别好吃。”小贩回答。
老太太摇了摇头没有买。她向另外一个小贩走去问道：“你的李子好吃吗？”
“我这里是李子专卖，各种各样的李子都有。您要什么样的李子？”
“我要买酸一点儿的。”
“我这篮李子酸得咬一口就流口水，您要多少？”
“来一斤吧。”老太太买完李子继续在市场中逛，又看到一个小贩的摊上也有李子，又大又
圆非常抢眼，便问水果摊后的小贩：“你的李子多少钱一斤？”
“您好，您问哪种李子？”
“我要酸一点儿的。”
“别人买李子都要又大又甜的，您为什么要酸的李子呢？”
“我儿媳妇要生孩子了，想吃酸的。”
“老太太，您对儿媳妇真体贴，她想吃酸的，说明她一定能给您生个大胖孙子。您要多少？”
“我再来一斤吧。”老太太被小贩说得很高兴，便又买了一斤。
小贩一边称李子一边继续问：“您知道孕妇最需要什么营养吗？”
“不知道。”
“孕妇特别需要补充维生素。您知道哪种水果含维生素最多吗？”
“不清楚。”
“猕猴桃含有多种维生素，特别适合孕妇。您要给您儿媳妇天天吃猕猴桃，她一高兴，说不
定能一下给您生出一对双胞胎。”
“是吗？好啊，那我就再来一斤猕猴桃。”
“您人真好，谁摊上您这样的婆婆，一定有福气。”小贩开始给老太太称猕猴桃，嘴里也不
闲着：“我每天都在这儿摆摊，水果都是当天从批发市场找新鲜的批发来的，您媳妇要是吃好了，
您再来。”
“行。”老太太被小贩说得高兴，提了水果边付账边应承着。
“这李子怎么样？”
“我的李子又大又甜，特别好吃。”小贩回答。
老太太摇了摇头没有买。她向另外一个小贩走去问道：“你的李子好吃吗？”
“我这里是李子专卖，各种各样的李子都有。您要什么样的李子？”
“我要买酸一点儿的。”
“我这篮李子酸得咬一口就流口水，您要多少？”
“来一斤吧。”老太太买完李子继续在市场中逛，又看到一个小贩的摊上也有李子，又大又
圆非常抢眼，便问水果摊后的小贩：“你的李子多少钱一斤？”
“您好，您问哪种李子？”
“我要酸一点儿的。”
“别人买李子都要又大又甜的，您为什么要酸的李子呢？”
“我儿媳妇要生孩子了，想吃酸的。”
“老太太，您对儿媳妇真体贴，她想吃酸的，说明她一定能给您生个大胖孙子。您要多少？”
“我再来一斤吧。”老太太被小贩说得很高兴，便又买了一斤。
小贩一边称李子一边继续问：“您知道孕妇最需要什么营养吗？”
“不知道。”
“孕妇特别需要补充维生素。您知道哪种水果含维生素最多吗？”
“不清楚。”
“猕猴桃含有多种维生素，特别适合孕妇。您要给您儿媳妇天天吃猕猴桃，她一高兴，说不
定能一下给您生出一对双胞胎。”
“是吗？好啊，那我就再来一斤猕猴桃。”
“您人真好，谁摊上您这样的婆婆，一定有福气。”小贩开始给老太太称猕猴桃，嘴里也不
闲着：“我每天都在这儿摆摊，水果都是当天从批发市场找新鲜的批发来的，您媳妇要是吃好了，
您再来。”
“行。”老太太被小贩说得高兴，提了水果边付账边应承着。
其实通过上面的例子，不难发现，在三个小贩向老太太推荐自己的卖的水果时，出现了三种
不同的结果．其中＂
第一个小贩一上来就不问清红皂白，只掌握了表面的需求（老太太要买）就完全用自己的主
观臆测来向客户推荐自己的商品（我的李子又大又甜）．这种情况其实多出现在新手或那些急于
写代码的程序员．
第二种则是比第一种要更成熟，他在耐心听完客户的描述（老太太想买酸李子）之后才开始
介绍推销自己的李子．这种情况是一般软件设计过程中通用的做法，即根据客户的目标和愿望（
老太太买李子不是为了儿媳妇而是为了抱孙子）直接进行开发的，需求分析做的一般，这也是目
前IT公司比较普遍的做法．
第三种显然要比前两种高明的多，因为他所销售的弥猴桃要比李子贵很多．其实他这里用的
是销售中比较高明的手段，就是在归纳用户需求的基本上，通过分析来引导用户需求，从而最终
超越并创造出新的客户需求．
所以这里需求要分为表面需求（如产品和采购指标）和深层次的潜在需求（客户遇到的问题）
其实与客户交流时常发生．每一个到你公司寻求帮助（解决方案）的客户其实都可以把他们
做为一个病人，而我们就是医生（有专业的架构和开发经验和行业背景）．而病人通常是不会知
道自己的病因是什么，只会按表面层次上所体现的症状来让你诊断，而医生通常在了解用户问题
(他的需求)后，会结合自身的经验（行业知识）来帮助用户找出真正的病根所在（即挖掘出需求
背后的需求）．这种抓药方式才是真正的治标治本．
其实一般的技术人中因为平时过于关注技术本身，会有意无意的忽略上面的问题．而其实恰
恰是只有真正理解和重视用户需求，才能让我们从所谓的"技术开发核心"转型到"分析和设计核
心"上来．而如果不重视需求分析，我们就会像第一个小贩那样，最终什么都得不到，即使我们对
这个客户说我们采用了什么高新技术，什么优秀框架等等，用户也只会云里雾里一头雾水，最终
还是无法让其真正将预算投给我们．
说到这里，有必要介绍一下SOA了，不是因为它时髦，而是SOA其实还是一个面向业务需求
的架构方式，这里不要太在意"面向服务"这几个字，其实归根结底最终还是面向需求，面向" 时刻
在变动的" 需求．因为公司企业在激烈的市场竞争中需要灵活配置，快速响应的系统．通过SOA
精心设计的体系架构"实现"商业利益（因为标准不是架构，架构也不是"实现"）并让公司企业迅速
抓住在市场出现稍纵即逝的商业机会．而这才是SOA真正存在的价值．从这个角度上讲，SOA的
应用范畴要在EAI之上，尽管用SOA架构方式进行EAI整合是不错的选择 (因为从头进行SOA架构
对一个有一定的 IT资产(硬+软件)的公司却无疑是一次大的手术．)
SOA的发展可以分为两个阶段，以2006为"分水岭"，2005年以前是各大软件供应商均专注于
自己的 SOA理论研究和框架开发．2006年以后各个大型软件服务提供商开始结成盟，陆续形成了
一系统 SOA规范和标准，并推出各自的面向SOA开发，发布，运营服务产品，如：
BEA：EAI软件Tuxedo、应用服务器WebLogic以及SOA信息传输软件AquaLogic等通基础平台
IBM: WebSphere 等
Oracle: Oracle SOA套件 等
SAP : Enterprise Services Architecture Adoption Program(企业服务架构验收程序) 等
Microsoft: WCF,BizTalk Server(充当ESB角色)等
SOA只是一种架构软件的方式，并不是什么新技术，甚至有专家提出即便使用CORBA（Common
Object Request Broker Architecture），DCOM等老牌技术也可以开发出SOA应用．
当然在形成了事实标准之后，一系列规范也相应出台，如SCA(服务组件架构：Service Co-
mponent Architecture), SDO(服务数据对象：Service Data Objects) ,BPEL(业务流程执行
语言:Business Process Execution Language, 最初是由BEA、IBM和Microsoft联合制订),
ESB(企业服务总线：Enterprise Service Bus)等等．
说了上面这些东西，可以有些朋友开始奇怪我为什么要把写作方向转到SOA上，主要还是因为
业务需求的关系．之前已说过业务需求在实际设计开发的重要性．而做为小A这个技术型从业者而
言，当其遇到技术和业务需求这两方面的问题时，即使知道业务很重要，但也需要一个切入点来帮
助其过渡到重视公司业务上来．而通过SOA的学习，可以一方面研究新的软件架构技术，比如微软
的WCF，另一方面各大公司无论从白皮书到实际案例上都会有关于业务需求分析方面的内容介绍．
所以通过研究SOA，可以满足其同时钻研技术和业务的双层需要．所以小A隐约感觉这是一个切入
点．而下面这张表格摘自园子里一位朋友翻译的SOA in the Real World.pdf的内容，可以帮助理
清一些概念和认识上的问题:)
用开发的行业背景，而在中国做企业级开发生存比较艰难，有关这方面的内容可以参见一下范凯(网
名：robbin，JavaEye创始人）的这篇文章，小A赞同其中的大部分观点．其实通过这篇文章也可以
看出，不管你是JAVA还是.NET程序员，在国内做企业级应用开发的困境没什么太大区别．当然小A
也同朋友和同事偶尔在MSN聊过类似这样的话题，朋友也劝其别趟这汪"混水"，老老实实做Web开发．
不过这个问题倒不是什么重要因素，因为小A可以把其做为自己的"爱好"来加以"关注"．而关注
SOA的另一个原因是REST的兴起．其实目前REST已经是SOA的一个分支了，其也给SOA概念中
植入了简易性为中心的理念．在WCF在3.5已支持了REST架构，并在Codeplex上已有DEMO让
其学习，所以就开始与朋友们一起研究起SOA和REST．
当然在这之前小A也遇到了每个开发人员都会遇到的问题，是做一个彻头彻尾的技术人员，不
去研究业务及行业知识，还是做一个即精通技术同时又精研业务和市场（相当于"会武术的流氓"）．
我想不同的人在这个问题上会有不同的答案，包括大多数情况下意见一致的朋友．
当然做纯技术的研究未尝不是一种选择，但这是一种苦行僧的生存方式．当然在IT圈中（包括
园子里）都不乏其人人，让人很是敬佩．但小A感觉内心深处还是受不了那种清规戒律和孤独．
并且在小A看来在国内这种人还主要是靠用出书，做顾问和培训讲师，甚至所研究领域的产品
代言人等方式来生存．而这让小A感觉没太大意思．不过还是要阐明的是这类人是真正意义上的"照
明信号枪" ，其发射的照明弹可以帮助IT从业者们解决学习之路上的疑问并照亮尽是"泥泞"的周边
环境．如下图：
即然想走"会武术的流氓"路线，接着就是如何挖掘并分析用户需求了．有关这方面的内容，在
市面上都有相关的图书来说明，这里就不多作阐述了．通过研究和分析用户需求，可以帮助我们抓
住用户，让我们每一行代码都像狙击步枪的子弹一样命中需求的"靶心"．如下图：
接着再说说两个与本文关系不太大的话题
先聊聊SNS, 目前国内的SNS领域已有了不少先行者，比如 51，校内，海内，开心等．而且后
续跟上的还有一些公司．但不知怎么搞的，小A感觉在商业模式不太明朗的情况下，SNS与其说是块
蛋糕，倒不如说是"粪坑", 起码里面的大粪还没有变成可以出卖赚大钱的肥料. 而各个 SNS网站就像
是一根根的 "搅屎棍"，把SNS从内含到外延搅得越来越难以理解，先是抄FACEBOOK，接着再在国
内大家近亲繁殖．今天你搞个"买卖好友"，明天我也搞一个．今天你来个"停车场"，明天我也搭一个，
无非换换名目罢了．搞得SNS网站成了一个个"人贩子网"和"网上停车场"，也许还感觉不够热闹，开
放完API再搞什么大赛，你开发个葵花点穴手，我就搞个菜花或麻花点穴手，真是你方唱罢我登场．
而用户这边只是看过一场又一场大戏，当然也许满足了网民的某些需求，但黏性在哪里呢．起码小A
注册了上述几个网站后，基本上是想起来才去（平均每周一次）．这里不妨套用赵本山老师那句话：
"也许一个崭新的互联网泡沫即将诞生!!!"
而网民是什么需求呢，小A感觉应该有两种"本能性"的需求，一个是"个性展示"，一个是"交流沟
通（在圈子,好友等范围内）"．而似乎中国网民平时生活中不太善于表现自己，起码中国的文化是那
种不温不火的感觉，所以在网上就像变个人，不停的秀自己，表达自己的声音和其它信息．这也是为
什么BLOG之类的应用在国内为什么火的原因，并且即便SNS将来成长起来甚至成为互联网主流，也
不太可能对BLOG造成根本威胁．当然MYSPACE里也有个人空间等应用，但小A感觉SNS应该加强
调社会化关系而非关注个体．FACEBOOK应该就是以此为中心，起码在FACEBOOK上如果没有好友，
活动或加入"网络"等应用的话，你即使"死(虽注册时间长但很久没活动)"在上面也不会有人知道．而似
乎麦田还在这两个本能性需求（麦田称为主体性和主体间性）上左右权衡，是否存在成功驾御平衡这
两种需求的平台．
另外一个话题就是UP和Agile了.
其实在需求分析面前，无论你是采用什么开发方法都跳不出它的"五指山"，即使是敏捷:)
就目前而言，这两个阵营谁都无法干死谁，而这种两雄并立各自为战的情况还要持续一段时间，不过可喜的是UML三友之一的ivar jacbson已开始探索并让手下人实践其新的思想"明智软件开发方
法",即：
UP 与 Agile --=>Smart Software Development (明智的软件开发方法)
而前阵子他来中国座谈软件开发时也介绍了一些情况，请看这篇文章．因为大家时间有限，下
面将其主要内容罗列一下：
存在即合理，现有的开发流程和工作方式一定有它的合理性，应渐进地采纳敏捷中一些合适的
实践，仔细审视各种工件的合理性和必要性，要防止借敏捷的旗号来偷工减料（尤其是放弃必要的
设计和架构工作）。
做应该做的事情并不容易，不多也不少就更加困难了。那么，我们应该从需求分析阶段开始就
引入“明智”。
用UML为软件的所有部分进行建模并不“明智”；不进行建模，直接编码同样不是 “明智”之举。
而找出真正需要建模和编码的东西才是“明智”的。那些“东西”是什么呢？他们是最本质的用例和对
这些用例所处场景的本质。他们是实现了场景本质的组件和这些组件中的特殊部分。因此，事关
本质。
实践，仔细审视各种工件的合理性和必要性，要防止借敏捷的旗号来偷工减料（尤其是放弃必要的
设计和架构工作）。
做应该做的事情并不容易，不多也不少就更加困难了。那么，我们应该从需求分析阶段开始就
引入“明智”。
用UML为软件的所有部分进行建模并不“明智”；不进行建模，直接编码同样不是 “明智”之举。
而找出真正需要建模和编码的东西才是“明智”的。那些“东西”是什么呢？他们是最本质的用例和对
这些用例所处场景的本质。他们是实现了场景本质的组件和这些组件中的特殊部分。因此，事关
本质。
而去年他老人家就向敏捷开发抛出了某些友善信号，请看这篇文章：敏捷到底是什么？
其核心内容如下：
敏捷是关于以下三件事情的：
1.最重要的，敏捷是一门社会工程学。这是敏捷最大的特点。它关注的是，如何以一个团队的
形式开展工作，如何激励团队成员，如何相互合作等等。
2.敏捷是轻量级的。RUP完全依赖显性知识，与此不同，敏捷还依赖隐性知识。在RUP中，我
设法把我们认为是最佳的实践记录下来。然而，人们根本不阅读关于开发过程方面的书，写下这些
书也就毫无意义了。相反，敏捷认为，只要有掌握足够知识的人，就可以开发出优秀的软件。当然，
这个观点倍受质疑，但是事实的确如此。
3.敏捷提供技术实践。这其实是敏捷中贡献最微弱的部分。它所提供的技术实践几乎没有包括
新技术。迭代与增量式开发，都是存在很久的观点。用户故事，则是某种特殊类型的简化版用例。
最为有趣的新想法就是测试驱动的开发。我并不是说敏捷技术实践毫无价值，而只是强调，如果它
仅仅就是这些内容的话，我们就不会为敏捷如此痴迷了。
1.最重要的，敏捷是一门社会工程学。这是敏捷最大的特点。它关注的是，如何以一个团队的
形式开展工作，如何激励团队成员，如何相互合作等等。
2.敏捷是轻量级的。RUP完全依赖显性知识，与此不同，敏捷还依赖隐性知识。在RUP中，我
设法把我们认为是最佳的实践记录下来。然而，人们根本不阅读关于开发过程方面的书，写下这些
书也就毫无意义了。相反，敏捷认为，只要有掌握足够知识的人，就可以开发出优秀的软件。当然，
这个观点倍受质疑，但是事实的确如此。
3.敏捷提供技术实践。这其实是敏捷中贡献最微弱的部分。它所提供的技术实践几乎没有包括
新技术。迭代与增量式开发，都是存在很久的观点。用户故事，则是某种特殊类型的简化版用例。
最为有趣的新想法就是测试驱动的开发。我并不是说敏捷技术实践毫无价值，而只是强调，如果它
仅仅就是这些内容的话，我们就不会为敏捷如此痴迷了。
看来UP阵营表现的比较大度，很有"大家"风范，小A也期盼着这两种开发方法和平共处，共同
繁荣的那一天．好了，到此今天的内容就要结束了．
当然本文的内容有一定的主观因素影响，是小A 结合自身性格和技术特点所做出的某种选择，
不确保本文发表后将来还是"一程不变"．所以大家不用生搬硬套．另外希望本文能为鼓励大家寻找
思路提供一些"愚见"．如果不同意本文观点，请在看完之后尽快忘记所谈内容，以免误人前程．
好了，今天的内容就先到这里了．有兴趣的朋友可以在回复中进行讨论．
tag:开发,webservice,soa,wcf,手 枪,步枪,framework,SNS,UP,agile
作者:代震军,daizhj
原文链接:http://www.cnblogs.com/daizhj/archive/2008/09/12/1289817.html
