所谓SMART，则是以人为本的，承认软件需求变化的不可避免和不可预知。在这一认识的基础之上，Ivar抛出了他的观念，即软件必须从一个小的可运行的skinny system开始，逐渐充实生长称为full-fledge的成熟系统。

下文摘自CSDN首席分析師(CAO，^_^)孟炎的博客。

9月5日在上海举办的CSDN英雄会上，Ivar Jacobson博士做了第一个主题演讲，演讲的题目是《明智软件开发》，概括了Jacobson博士最近一两年对于软件开发的最新思考，而且是他第一次对公众做这个演讲。很可惜由于某些意外事件，大会开场时间拖延了15分钟，本来可以给Jacobson博士的机动时间被拖没了，他到最后只要择其要者简单说几句，很多地方一带而过。会下很多在场的朋友都跟我说，这个演讲实际上是当天最好的演讲。这样一个精彩而重要的演讲，因为时间紧张而未能充分展开，非常令人遗憾。

当天演讲之前5分钟，Jacobson博士突然邀请我给他做现场翻译，并且说：“你只需要在你认为有必要的时候打断我，不要逐句翻译。”我当时压力很大，因为这个演讲我也没听过，一走上前台，我脑子里噌噌噌闪过无数杂念：这个题目到底讲什么？其中涉及的专业知识我不懂怎么办？Ivar博士带北欧口音的英语听不懂怎么办？我该站在他身边还是离他远点以保证大师的光辉形象？我该在什么地方什么情况下打断他？用什么方式通知他？这些问题如果在事前有准备，本来是可以从容应对的，但是事情发生得非常突然，我来不及思考就走到他身边，而且一上来就打开了错误的PPT。在后来将近40分钟的演讲里，我多少有点紧张，表现得不太好，听错听漏了一些地方，没有很好地完成Ivar交给我的任务，对于演讲效果的欠佳，我也负有不可推卸的责任。可能也是因为这个原因，当天我的状态一直不太好，在后面的演讲和主持环节，我始终兴奋不起来。借此机会向在场的朋友致歉。

会后很多朋友都向我索要这个演讲的PPT，不过我这里没有。同事告诉我大会所有演讲的PPT稍后都会共享给参会者，希望有兴趣的朋友留意CSDN的通知。

下面我凭记忆把这个Jacobson博士这个演讲的主要思想扼要列举出来。由于当时我比较紧张，而且人的记忆本身就有出错的可能，因此很有可能不准确。请IJI公司的朋友和在场的听众指出我的错误。

在演讲的一开始，Ivar首先革了旧思想的命。他回顾了软件开发思想从过程化，到面向对象，再到组件化、UML、UP、RUP、XP的沿革，然后说这些思想都曾经自以为银弹，但是都被证明并非银弹。事实上，银弹不存在，我们需要的仅仅是明智的软件开发方法(smart software development)。那么到底什么是smart呢？Ivar认为要搞清楚这个问题，就必须想现在一些流行的unsmart观念开火。比如，很多大型组织相信过程而不相信人，这就是unsmart。过程不能开发软件，只有人才能开发软件。所以软件开发以人为本就是smart。有的人相信工具，但是工具本身只是放大器。如果落在了笨蛋手里，“A fool with tools is still a fool, but a dangerous fool.” 有些人以文档为中心，但是文档并不能执行，而且最重要的是，没有人愿意读文档。机器读不懂文档，人又不愿意读文档，那么制造大量的文档有什么意义呢？还有人使用瀑布模型，相信事前能够产生完整的设计，甚至细节都能考虑清楚，但是随着开发的推进，越来越多的paperware最终把开发工作压垮。这些都是unsmart的观念。

而所谓smart，则是以人为本的，承认软件需求变化的不可避免和不可预知。在这一认识的基础之上，Ivar抛出了他的观念，即软件必须从一个小的可运行的skinny system开始，逐渐充实生长称为full-fledge的成熟系统。在PPT上，Ivar 用一只小羊骨架表示 skinny system，而这只小羊最后将长成又大又肥毛又多的澳洲美利奴羊，这就是成熟系统，相信很多在场的朋友印象深刻。Ivar强调，skinny system必须是skinny，抛弃一切细节，但是又必须可执行。在成长为成熟系统的整个过程中，都必须确保系统是可执行的。随着细节不断地被认识，系统逐渐充实完整。

（Ivar 讲到这里，我在脑子里问了一个问题：“这与我们熟知的非抛弃原型系统有何分别呢？后者不也是强调从一个原型出发，逐渐完善称为产品吗？而且就原型系统而言，实践证明抛弃原型效果比非抛弃原型要好，难道大师的smart就是指这个？另外，这跟敏捷思想有什么不同吗？敏捷不也是强调尽早交付可执行代码，并不断重构吗？”果然紧接着，Ivar就回答了这个问题。）

Ivar紧跟着提到了系统架构，他问在场听众，有多少人认为系统架构很重要，不少人举了手，他满意地说，不错不错,“China is fantastic！”，他在其他国家问这个问题，只有一小部分人认为架构很重要。他认为，对于架构的态度，人们容易走极端。要么认为完全不必要，要么就追求恢宏的企业架构，实际上都不是正确的态度。他认为基本而简单的架构是非常重要的，这是区别smart方法与敏捷方法的关键。他认为，尽管smart方法与敏捷方法共享很多相似的部分，比如重构，增量式的前进，程序员测试，但是在对待skinny system的态度是截然不同的。Agile认为，应尽快产生可执行代码，架构可以随后重构出来，而他认为，skinny system就是架构，开发skinny system的过程也就是确定架构的过程。而架构是一个系统中唯一重要的部分，唯一对质量要求不折不扣的部分，因此必须精心设计，丝毫马虎不得，也别指望事后能够通过重构产生好的架构。另外一方面，也不要执迷于那些通用的庞大的企业级架构。正如skinny system暗示的，好的架构都是小而简单的。Ivar认为，软件各部分对于质量的要求是不一样的，与架构无关的部分，适当降低质量要求以求得开发效率的提升可以的，事后也完全可以通过重构等手段改善之。然而架构却是必须从一开始就认真对待的，兹事体大，不可不察。在这一点上，Ivar还是坚持他在UP中 “Elaboration” 的思想，也即是说，系统早期设计阶段（skinny system）必须力求精心设计，为后面的敏捷式开发提供良好的支撑。

由此可见，Smart方法，基本上可以看做是 UP 与 Agile 的一个有机组合。我没有实践经验，但是从道理上讲，这应该是一种好的方法。听 Ivar 说，他的得力合作者黄邦伟博士已经在多个重大项目中实践此方法，取得非常出色的成果。至于更进一步的细节，我也就不了解了。

以上，供有兴趣者参考，并请知情的朋友指出错误之处。

下文摘自某大牛的博客

大家对需求的理解差异，是软件失败的最主要原因，引起了错误的预算，工期的预计以及人员的安排，最终导致质量无法保证，我们这么多年用的软件工程理论难道都是有问题的吗？从面向对象，UML建模，RUP,XP,甚至Scrum。是这些体系有问题？还是我们没有用好呢？

我个人并非计算机专业出身，完全凭的自学，所以对于标准的软件开发理论一直没有深入的研究过。面向对象的思想也是在我2002年放弃php转学java之后才有一点体会的。UML我只用让他给客户做过方案，因为对方的一个家伙必须看这个。至于RUP,XP我没机会实践了。我公司的团队必须按照现有的适合的开发方法继续做，不可能随便换一个什么理论。从根本上讲，现有的软件开发系统思想并没有给我什么帮助。我在开发中遇到的最大问题，并不是怎么开发，而是无法准确理解用户的需求，而且用户的需求变更也是无法控制的。你不改？我们就不付款，你们看着办。 关系弄僵了，我想挨批评的肯定还是我们自己。

他提出了Smart的概念，也就是“明智软件开发”。我们来看看他的内容是什么。

一 什么是Smart
 1 他引用了爱因斯坦的一句话， Things should be done as simple as possible – but no simpler.

不好意思，这句话是我第一次看到。用简单的方法解决问题，应该是最好的。这个观念我在论坛里看到过许多人提到过。

个人认为简单有几个情况

  1 原始的简单，因为不会高深的技术和方法，对付着弄出来就行了，但是这个东西能用
  2 能从一群解决方案中，选出一个最简单的实现方法，能满足需求，能用，虽然可能在某个方面不适合以后的扩展。
  3 被迫的简单，因为工期催促，不能考虑那么多了，只能简单的实现最主要的功能，许多细节并不完善的简单。类似于原型。

我们面对用户一个很简单的需求，如果找一个手快的人，估计1-2个小时就能搞定，用户马上就能看到结果并确认，如果按照正规的流程，提交申请，审批，确认，转到开发人员，开发，提交测试，让用户看结果，我估计最快也需要2天，因为要考虑人家不是一天没事的等着你反馈，赶上出差，开会这类事情都要考虑进去的，而且一点用户有修改，这个流程肯定还要走一遍的。

正规适合于许多人一起合作的大系统，特别是人员变动比较大的情况。对于我来说，虽然有10几个人，但项目多，每个项目也就4-5个人，我想那些大公司看着人多，真正一个项目里有效参与的，估计不会到10个人。大家把负责的问题简单化才是解决这类项目的比较好的做法吧。至少我这么认为。

2 Smart意味着什么(What does being Smart mean?)
  Being Smart is not the same thing as being intelligent.
  你可以智力很高不精明，你也可以很精明，但智力却不是很高

  呵呵，我一开始分不清2个的区别，我想大致是这个意思吧。太聪明的人也许太聪明了，他们的设计太超前了，可以满足你5-10年的需求，可许多时候，我们只需要满足这个月的需求就行了，呵呵，仔细想想就知道为什么了。

  Smart is more then having common sense
  你可以拥有常识的东西，但不一定很精明，但是如果你很精明，则你一定拥有常识性的东西。

  我们掌握了许多的东西，这是基础，否则我们无法理解和实现用户的需求。业务的理解重要性远高于对基础的理解，因为对于用户来说，他要求的功能都可能是行业内的常识了。

  Being Smart is being agile, but more

  敏捷是灵活性，可以适应各种情况，而精明则是敏捷+在特定的条件下正确的完成了它。

  我们的项目很灵活，可以很快的进行调整来满足用户的需求，但我们真的需要调整吗？我们的调整真的是对的吗？如果对用户需求理解不足，出现了偏差，那么我们的调整就是错误的。而且我经常遇到用户又再次反悔的情况。 我一般对于用户的新的需求变更，都是最少压3-7天，给用户一个反悔的机会。期间通过其它方式确认需求，特别是那些影响很大的变动。有时还尽力说服用户不要变动，因为我们可以换一个思路给他实现类似的功能。 正确立即用户的需求并正确的实现它，用户高兴，我们也会少了许多的无用功。

二、精明的例子

  1 人
    不精明的人想通过过程和工具来提供人的智力，获得优秀的技能、。
    A Foo with a tools is still a foll but a dangerous fool.

    呵呵，可惜有些人是这样考虑的，希望通过工具来使自己变得更专业，更精明。

    但软件是人开发的，只有合适的人才能开发出合适的软件，而不是工具开发出来的。我个人就曾经在一个关键的系统使用时，用notepad编写了程序和HTML页面，并编译和发布了，那是2001年。许多那时候过来的人，都会怀念手工编写的经历，包括现在还有人鼓励用文本编辑器而不是是IDE来进行开发。这个我就不评价了，呵呵，毕竟年代不同了。

  2 项目
    瀑布式开发是不精明的。应该开发一个拥有核心功能的演示系统，然后再逐步的完善。

    用户其实最关系的地方只有几个，比如老板一般关系报表，你把这个弄出来，他们那里就会通过。 操作人员关心的是是否方便。许多支持的功能，已经锦上添花的功能，完全可以放到后面完成。主题完成，我们再开始绣花。何处是关键，这个要靠人去判断了，特别是根据用户的喜好决定。否则你辛苦做的一个功能，他也许根本不关心。

  3 需求
    需求是不断变化的，而许多人却努力的描述所有的需求，因为这样才能精确估算费用。

    我们应该用基于简单的需求，然后逐步的完善它，卖给用户的是一个定制的系统，与原始的方案作为再次谈判的标准。

    我们国内有点不同，我们大部分是用户提出了一个不是很具体的需求，我们开发了。用户看到后，增加和变动了许多，并且一般不会增加任何费用。这个是很不公平的。如果开发方拒绝开发，那么你这个公司在这个行业的名声将会出现问题。除非你是大公司，是强势的一方，但绝大多数公司不是这样的。用户是付款的，他们才是上帝。如果关系处好了，也许还能谈谈价格。 还有一种情况，就是开发商用低廉的价格中标，然后以各种功能为由增加费用，这个也是一些有些实力的大公司才敢做的，或者是关系非常铁的，还或者有猫腻的情况才可能出现。呵呵，不是你也知道是啥意思。。。。

  4 架构

     2个极端情况
    1）无须架构，直接编码，以后需要时再重构。
    2）架构在一个非常高级的结构上。

    对软件质量影响最大的是软件的架构。

    建议先架构一个核心的系统，只有大的骨架，然后开始编码实现。 没有可执行的代码的架构是个幻想。进行适当的重构。

    架构取决于经验，如果大方向正确，完全可以先进行功能的实现，出现问题再进行局部调整。没有人一开始就能预测所有的问题。需要重构的代码应该符合 1-9原则，而不是2-8原则。绝大部分代码是不需要重构的，因为他们运行次数不大，对系统的影响很小。只有那些频繁运行的代码，才最需要重构，效果也最明显。

   5 建模
    和架构非常类似

   6 测试
    我们有2类人，思考者和清理着。测试人员属于软件世界的清理者。

    如果测试总是在思考之后进行，那就太晚了并且太昂贵了。
    如果你无法验证你做的是否正确，那就先不要做。

    虽然大家都知道测试的重要性，但实际做起来还是有很多困难的，特别是人员和工期紧张的时候。大家还是多争取一些兼职的测试人员吧，呵呵呵，比如你的其它部门的同事，朋友啥的。

    7 文档
     多年以来，我们写了太多的文档了。

    几乎每个领导都非常重视文档，但我们真的需要那么多的文档吗？我们真的需要看所有的文档吗？ 买来电视机，买来笔记本，看用户手册的有多少？但新买了一个电风扇，需要自己组装，看文档的又有多少人？

    软件文档中真正有用的，会被大家经常看的还是那些整体的文档，至于那些细节，人们会自己弄符合个人习惯的东西的，比如贴一大堆纸条，或者写一个txt文件放在桌面上。

    文档应该增加系统的价值，而不是成为累赘。

   8 过程管理
    我没啥好说的。

三、如何变得精明呢？

    1 你应该不断的进步
    2 你应该熟悉不同的角色，比如工程师，过程管理，社会工程师
    3 从你拥有的开始，找到不断提高的一小步，一次只实践一个。

    我们工程师习惯了听项目经理的安排，不断的按照指示和需求文档来用代码实现，我们很少去和客户直接接触，很少作为一个专业的测试人员去搞测试。在一些外包公司更是这样，你只知道自己眼前的这点东西，你不可能熟悉整个系统，因为你没有那个权利，呵呵。
 
   
   
四、Smart到底是什么？

    他啥也没说，只是告诉大家：每个人都可以变得精明。

个人总结：

    我开发软件的时间可是不短了，从1988年接触电脑，到1992年和计算机系的人混的最熟，一直到现在用了6年的Java,期间做了许多的项目，对开发方法也是感触颇深的。

    在软件开发的环节上，需求、设计、开发、测试，越靠前，对后面的影响越大。而出问题最多的并不是设计，而是需求。改来该去，没完没了的系统简直是太常见了。

   用户在不断的学习，他的需求也会不断的完善，不断的增加，我们开发人员就要不断的开发，变更来满足需求。我个人的一般做法是。

   1 分清楚这个项目到底是【形象工程】，还是【实干工程】。这个太重要了，如果搞错了，你的辛苦很可能白搭。

    形象工程：允许你的系统不是很高效，代码不是很优雅，但一定要界面漂亮，使用一些高级的东西来满足用户的虚荣心，系统不能做的太简单，至少看上去是那样，否则他们会觉得拿不出手的。他们宁可用20万的，绝不会用你2万的。至于真正用起来会怎样，没人关心。这个项目很可能在6个月后无疾而终，因为他的做作用已经达到了。 至于啥作用，去问你的客户的老总吧。哈哈
    这样的工程一般是高层处于某个目的提出来的，你必须通过非常手段才能获得内部准确消息哦。

   实干工程：允许你爹系统不是非常漂亮，因为图片多了会影响速度，但要求你的系统必须稳定，必须快速。丑陋一点点不是大问题，可以慢慢完善。 必须实现他们日常工作需要的一些功能，特别是报表。

    这样的工程一般是基层或者中层提出来的，他们需要解决实际的问题，比如加快处理速度，提供合作和信息共享，降低通信费用等很实际的问题。和他们打交道要注意不要惹到了小鬼。你的一个不经意的东西，可能会引起一个最终用户的反感，他可能会成为你项目继续的一个阻碍。和基层的最终用户搞好关系，你的项目则会顺利的很多。即使出现了一些小的BUG,他们也会先通知你，而不会直接向上级汇报的。

    2 找对正确的甲方的配合人员

    有些项目，甲方派了一个基层的文职员来，这样的项目遇到的阻碍会很大。一般我会建议对方让一个中层来做，而且是一个和业务非常熟悉，且说话有一定分量的人来担当。这样需要一些资源的时候，比如开会，找部门人员调研都会比较好办。项目组和这个人一定要搞好关系。他是中间沟通的桥梁。

    3 使用大家最熟悉的技术，加上一点点尝试的技术做开发

    不要追求新技术，那不是项目里用的，而是实验室用的。新技术必须经过大家的共同实践，在正式的业务系统里被证明是有效的，才可以大面积的使用。在一些非关键的地方，正好可以作为实验点。

    我一般在新技术出现后的2年，才会考虑在正式的项目里使用它，因为这时候各种BUG已经修补的差不多了，各种文档也很齐备了，平时的积累也差不多了。大家已经都憋坏了。

    
    4 项目人员要定期沟通，搞好关系。

    这个就不多说了，那些比较内向的人，还是尽可能的多和人沟通吧，机器在好也是死的。

类似的文章

• 2009年03月14日 -- UML之父——Ivar Jacobson介紹SMART方法 (0)

UML之父——Ivar Jacobson介紹SMART方法

PPT下载
CSDN下载
本站下载

类似的文章

• 2009年03月18日 -- 明智軟件開發的共鳴與思考 (0)
• 2009年07月11日 -- Rational Rose、PowerDesign、Visio的一些比较 (0)
• 2009年06月1日 -- 关于需求的文档区别 (0)