软件开发之管理观

软件开发管理（软件工程、软件质量）一直是一个很火,很热的名词.不仅在各种各样的报刊,杂志上,而且在网络上更是充斥了这样的言论.在软件企业中,在政相关部门里,也是一个被不断提到的话题.但是,正因为谈的多,才显示出底子里的缺乏和肤浅,才容易被人们误解和歪曲.因为,如果,对一件事情,每个人都以为自己是专家时,就说明真正的专家反而是少的.那么,到底,应该怎样理解这件事情呢?到底怎样才做称得上好呢呢?到底软件工程、开发管理等带给我们的是什么呢?到底我们应该怎样去提高软件质量呢?我自己也不敢妄言是这方面的专家,但正是因为专家的缺乏,我才可以在这里将我的一些想法说出来,希望可以有一些参考价值。

1.管理者本性的迷失

本人认为这是软件开发管理中最要害的问题，这个问题不解决，别的方式、方法、模型等等的有效应用都无从谈起。

我们这些成人自然本性的迷失皆因受惑于两大秀色可餐的馅饼：一是对完美的执着，一是对趋同的企求。孩童最容易融进自然，因他本身就是最自然的存在。我们这些成人，因为有了许多阅历，却可能迷失自然的本性。因此本人认为：本性丧失于对完美的执着！

本性常常在求全、求完美的过程中丧失。同人的认识一样，所有的人都是片面的。完美的东西是不存在的。这是任何一个成功的管理者所必须有的判断。在对软件人员的管理中这点尤其重要。有的人热衷于绝对化，说一个人行，这个人就是完美无缺的，甚至连排泄脏物的方式都是可圈可点的；说一个人不行，这个人就是十恶不赦、粪土不如，甚至找不出一点可以接受的地方。如果执着地盯着他人的弱点，并从多个方面去放大，这个人很可能就一无是处。如此看人背后引发的危机是你会在这样的放大过程中沦为孤家寡人；相反，如果超越一些现实的迷象，能够抓住他人一些独特的品质，能够洞悉这些品质与一个群体合力的连接点，你就得到了人才，形成一个有力的软件精英团队，获得成功。翻翻中国历史上的酷吏史话，多数不是贪赃枉法的恶人，而恰恰是以天下为己任的实干家。本性在趋同的追求中沦丧。

2. 按客观规律办事

项目经理不是神仙，领导不是神仙，开发人员不是超人。按照估算模型估出来的进度是10个月，非要压缩成5个月，能省的过程无非就是测试、评审、讨论、文档、纪录。快速编码，留下无穷无尽的维护！不能追求完美，更不能追求完缺！！！

3. 重视软件过程的严肃性

有一只高素质的SQA队伍，有一批职业化的项目经理队伍和良好的开发团队。

4. 尊重客户并同他们紧密协作

开发软件的唯一理由是为了支持客户。只有客户能够告诉你他们需要什么，因为他们是业务领域的专家。为了保证你建立正确的系统，与客户紧密工作难道不是非常有道理吗？

5. 只接受符合实际的项目计划

软件公司或市场的压力经常导致项目计划不符合实际。无论何时，只要使用“如果每件事都按我们估计的方式发展，而且我们足够幸运的化，我们就可以将项目作好”来阐明计划的话，那你就有麻烦了。事情不总是按你想象的方式进行，不管多少人力投入一个项目，许多软件的开发的不同工作都会耗费非常大量的时间来完成。记住，十个女人也不能在一个月里生一个孩子。如果你迫于压力，接受了一个不切实际的项目计划，那么你必须回去向老板阐明计划不实际的原因。你的理由也许不被接受，你还得执行该计划，但至少你为项目进行了争取。有不现实计划的项目组常常时采取了捷径，但却导致项目在远远落后于进度时，项目仍在停步不前。

6.要能够辩明你的工作

应当非常明白为什么正在开发你的系统或相关部分？你是否知道它技术上的可行性？是否其他人做过该类原型，显示出你正在做正确的工作。你的软件在经济上有意义吗？它是否值得去做，是否可保持你的组织的竞争力或打开新的市场？一旦你开发的产品完成后，是否你的组织能够操作它？你是否有一些人可以操作并维护该系统？是否可以得到操作规程和文档？是否有支持计划？如果你不能辩明你的工作，为什么你还在做它呢？

7. 任何人都不能妨碍他人

员工不应只想玩玩，就使用技术。你用技术，因为这合情合理，或对解决在手边的问题有用。许多开发者仅仅为了获取经验而建议使用如EJB （Enterprise Java Beans ）或CORBA等“流行”的技术。你是在浪费你老板的时间与金钱来实现自己的目标。另外，不要为了揭示你的单位软件结构的弱点而引入病毒，或删除数据或程序。如果真的有弱点，通知管理层，不要造成任何损害。

8. 不要“只是适当的”重用任何可重用的东西

因为大家喜欢从零开始，而不是重用已有的成果，这些年，软件专业人士的生产率并没有显著的提高。有很多的软件成果可以被重用，如源代码、组件、文档、文档模板、模型甚至通过应用模式重用其他人的技术。只要可以，就去致力重用其他人好的工作成果，而不是假设你可以从零开始做事，并比其他人更好（不幸的是，这正是许多开发员的心态）。现在，重新发明“轮子”，并不是一件荣耀的事。

9.“只开发基于实际需求的软件”

如果你没有需求，你不需要开发任何东西。无论什么类型的系统，你总可以从为它定义需求开始。人们或其他系统如何使用你的系统？它需要怎样好的执行？它必须具有什么样的使用特点？它必须在什么平台下运行？不管你的系统使用什么技术，它是什么样的业务类型，你总可以先确定它的需求。其他都是干咳。

10. 请停止重复教条

给予项目组最大损害的是那些相信如：数据至上，编码最重要/建模最重要，或是我们是用例驱动等一些小教条的人。软件开发非常复杂，这些教条只是覆盖了对于过程的缺乏理解问题或者只是解决问题的一个或几个方面。实际上，数据只是整个过程的一个小部分；而为了使软件成功，需要的不仅仅使源原代码；对描述需求来讲，仅有用例是不够的。教条只是在人们之间建立了阻碍，并减小了小组的成功机会。

11. 不应仅仅关注软件的执行

成功开发不只是做出执行速度快的软件。根据项目的类型、级别不同,创建可扩展、可理解、可维护、可用或重用的软件也许更为重要。软件执行速度仅仅只是软件评价标准的一方面，但是太多的开发员只注重该项，而影响了他们整个的工作质量。

12. 要持续改善开发人员的沟通技巧

如果你不能与其他人有效沟通，好点子又有什么用呢？你也许可以写出世界上最好的源程序，但是，你不能写一封E-MAIL来告诉你的老板与小组成员你所做的，那么你的杰作可能根本得不到承认。

13. 要文档化所有自己开发的

现代软件开发模式是你做为一个小组成员进行工作，如果没别人能够理解你的工作，那你就没有对工作做出任何贡献。很明显，好的文档能使你的工作容易被理解。实际上，简而言之，好的程序员在开始编码之前，会文档化他们的代码。

14. 软件不仅仅是技术

技术是有趣的，但它只是开发软件过程中的一部分，是很重要的部分之一。不管是好是坏，你的工作还需要你熟练地与用户、经理、同事、卖主或操作人员打交道。

15. 软件不仅仅是开发

必须牢牢记住，你的用户，或是你的上层经理，在你开始工作前，很可能已经花费了极大的精力来挑选和识别软件开发项目，还必须组织开发过程并对质量、进度、成本进行管理等。一旦你将软件发布给用户，该软件必须要被维护、使用和支持。你需要全面理解如何成为一个有效率的专业人员。