明智软件开发的共鸣和思考 - 读Ivar博士PPT的读后感

从CSDN首页看到了曾总的2008英雄大会的总结性文章，其中的Ivar Jacobson的主题演讲“明智-软件开发的新趋势”引起了我的注意，然后查看了孟岩的博客，并下载了里面的ppt,仔细研读，感受颇深。

大家对需求的理解差异，是软件失败的最主要原因，引起了错误的预算，工期的预计以及人员的安排，最终导致质量无法保证，我们这么多年用的软件工程理论难道都是有问题的吗？从面向对象，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 项目人员要定期沟通，搞好关系。

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

写的太多了，估计错别字不少，先这样吧。希望对大家有帮助