软件开发的关键
来源：广州软件开发 编辑：广州软件开发公司 日期：2017-03-29
许多有开发规范的企业会采用瀑布模型、V模型或迭代等模型进行开发，但是，当出现进度紧张的项目时，这样项目会很自然地采用“Coding & Testing”的开发模式——上来就编码、写完代码再测试的原始开发方式。所以那些规范看起来只是给进度宽松的项目用了，进一步说，他们认为Coding & Testing的开发模式效率是相对高的，而需求分析、设计等活动是给那些有时间并且想让项目看起来开发过程“漂亮”的项目来做的。
如果Coding & Testing的开发模式是高效率的，那么不论这个项目的进度是否紧张，都应该选择这样的模式，没有理由做画蛇添足的事情，而且也不是开发过程繁琐等同于规范、等同于漂亮，简单才是美。如果Coding & Testing的开发模式是低效率的，那么进度紧张的项目更没有理由采用该开发模式。因此，不论Coding & Testing的开发模式是高效率还是低效，只有在进度紧张的项目采用该模式，这样的做法逻辑上是讲不通的。
那么相对于软件工程所提出的一些开发模型，Coding & Testing的开发模式是高效率还是低效的？其实，回答这个问题就像回答“是马车跑得快还是汽车跑得快一样”一样容易。
软件开发过程中，最重要的工作莫过于需求分析了，如果客户的需求没有搞清楚，所编写的代码同垃圾没什么两样。而需求分析也往往是最有挑战的工作，要求需求分析人员不仅仅有计算机知识，更重要的是要有领域知识，接下来要具备很强的沟通能力。软件不是存在与真空中，它一定是用力帮助我们解决生活和工作中一些问题，比如项目管理软件是用来辅助项目经理进行项目管理的；淘宝的商品交易网站软件为买家和买家提供了远程进行商品交易安全便捷的手段。如果，要做好项目管理软件，那么需求分析人员要掌握项目管理的知识；同样，为淘淘做网站软件的软件工程师来说，他们一定要很熟悉B2B/B2C的业务模式。计算机知识好比我们学会了汉字、掌握了语法和修辞，这些并不能保证我们会成为一个优秀的作家，生活的丰富阅历和对生活的深度思考才是一个优秀作家的关键技能，而这项关键技能的获得需要长久的磨炼和甚至要一定的天赋。相类似的，掌握领域知识远比掌握计算机知识难，比如学JAVA语言，三个月应该可以精通，而要掌握管理知识、掌握金融业务流程也许经过三年才刚入门。因此，一位研究雷达的教授曾说过：“我宁可要一点计算机都不懂但是懂得雷达的人也不要计算机精通但一点雷达知识都没有的人做学生。”
要做好需求，需求分析人员还要具备很强的通过能力。客户需求几乎从来都不会清晰地摆在项目面前，需求发生人员首先要识别干系人，然后用合适的方法挖掘干系人的需求和干系人确认需求，这个过程需要责任人要有很强的人际交往能力、语言通过能力和文字通过能力。
最后需求分析人员要掌握一定的计算机知识，因为需求架起了客户到设计人员之间的一个桥梁，需求分析人员最后要把客户需求以设计人员能够理解的技术语言描述出来，把客户需求传递给设计开发人员，这项工作通常体现在软件需求规格说明书中。
相比之下，从事编程的程序员，仅仅懂得编程语言就够了，而一门计算机语言的掌握对于智商不是很低的人来，花费一两个月完全足够，特别是由于硬件的发展，编程越来越重视程序的可读性，而不鼓励使用编程高超技巧让程序很难维护。
软件设计的重要度介于需求和编程之间了。需求告诉我们软件要做什么，解决what的问题，而设计告诉我们软件是如何实现这些需求的，解决how的问题。简而言之，良好的需求确保软件做了正确的事情，良好的设计确保软件正确地做事情。软件设计是对复杂问题不断分解简化的过程，当一个复杂问题被分解为众多个简单的模块，再去实现各个模块就会变得很容易。
从软件需求分析、到软件设计、到编码，越是前期的工作越是重要、越是有难度，对软件质量的影响也是越大。我们来看看建筑行业是如何做的，也就懂得这个道理。
享誉全球的华裔建筑大师贝聿名有许多不作，如约翰·肯尼迪图书馆、巴黎卢浮宫玻璃金字塔、香山饭店等等。那么，他的这么多作品中，有哪个是他亲手建造的？众所周之，我国建筑工人大都是的来自乡下“农民工”，是他们一砖一瓦地建起了高楼大厦，甚至是建筑上艺术品，然而，建筑行业最需要的和敬仰的是贝聿名建筑大师，而不是建筑工人。程序员就如同这些建筑工人一样，所做的工作技术含量不大，依据设计去实现就好了，建筑工人依据设计按照建筑的技术要求一砖一瓦地砌，而程序员依据设计按照程序语法规则一个个字符罗列，主要是体力劳动了，复杂的脑力劳动在前期的建筑师和软件分析师、设计师完成了。
我们好像没有见过哪一幢大楼没有事先的设计而直接开建的，这样的大厦多半在没有建好前就会倒掉。而许多“软件大厦”呢，在没有搞清楚需求、没有设计的情况下就开始一一行代码在建造了，“软件大厦”是无形，如果它能映射到有形的大厦，那么它们一定是七扭八歪的，可能交给客户前就倒塌成一片废墟。
长久以来，编码工作被视为复杂的高智力活动，因为在Coding & Testing的开发模式下的确如此：编程人员已不是纯粹的程序员，他/她在编程时候头脑中要假象出客户的需求是什么，同时也要考虑设计问题。哇，一个人在一件事还要考虑其它的很复杂的事情，这样工作的确复杂得很，是否有能力超强的人在做编码同时能够把需求和设计做好？当软件规模小、复杂度低时，会有这样的人，但是对于如今我们普遍面对的软件，其规模和复杂度已经不允许一个人同时做几样复杂的工作。搭一个狗窝，不必要把需求、设计活动独立出来，而建筑奥运鸟巢绝对不会有人敢一边在建造一边在考虑需求和设计。
1998年，华为公司在印度成立印度研究所，学习印度先进的软件开发管理经验。国内工程师看到印度人做项目很奇怪，项目已经开始了，他们不像中国工程师那样在电脑前埋头敲啊敲，而是大家站在白板前“争争吵吵”，吵着吵着，需求就吵清楚了，然后再把需求文档化，之后还要进行严格地评审，进一步发现需求理解不错误的地方。如果让中国工程师来做这个项目，此时，估计已经把代码写得过半了，可是这些印度人居然连一行代码都没写！真不知道这些“效率低下”的印度人如何让印度成为软件产业强国的！接下来，印度工程师会依据需求设计系统测试用例，此时还可能发现少量的需求错误。再接下来的设计、编码、单元测试、集成测试和系统测试一路通畅！编码的工作量一般不会超过项目总工作量的15%，最后系统测试活动一般占总工作量的10%。而中国工程师做的项目，典型的情况是，很快地代码编写出来了，接着再测呀改呀，改呀测呀，没完没了，最后交给客户，客户会说这不是他们想要的，那不是他们想要的，再接着改呀测呀……最后当客户拿到了还算满意的产品时，项目的总工作量已远远超过了印度人开发方式所需要的工作量。
见图2.1，选择Coding & Testing的开发模式的人们会认为，虽然事先做好需求和设计的确可以减少编码、测试以及返工工作量，然而需求和设计本身所占用的大量的工作量足以超过它为编码、测试、返工所节约的工作量。然而，事实与他们的臆想差别很大，见图2.2，省略了需求和设计，相当于把需求和设计的问题遗留到了后期去解决，其工作量会以十倍、百倍的膨胀，导致最后的测试和返工工作量非常庞大，项目延期在所难免了。
图2.1 臆想的省略需求设计工作会减少总工作量
图2.2 实际的省略需求设计工作会大大增加测试和返工工作量
我曾经来到一个软件项目的开发现场，该项目正处于需求分析阶段，我走进他们容纳着二、三十人的办公室，屋里很安静，大家都各自在电脑前辛勤地工作着，如果这时走进来的是总经理，这样的场景也许会让他很满意，但作为接触过许多项目的过程改进咨询顾问，我却嗅到了项目正走向失败的气味。电脑不会告诉我们客户的需求是什么，如同一个作家，不会抱着字典奢望它会带来写作灵感一样。一个项目如果没有努力把各个干系人的需求挖掘出来、描述清楚，并和客户进行确认，意味着这个项目后期的不得不承受大量失效成本，最终意味着项目的超预算、延期。
相关阅读
广州软件开发公司业务咨询卢先生 手机18998818351 售后服务热线：020-22076940
