明智軟件開發的共鳴與思考
本文内容遵从CC版权协议, 可以随意转载, 但必须以超链接形式标明文章原始出处和作者信息及版权声明网址: http://www.penglixun.com/tech/program/thinkinf_about_uml_smart.html
所谓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 项目人员要定期沟通,搞好关系。
这个就不多说了,那些比较内向的人,还是尽可能的多和人沟通吧,机器在好也是死的。