一定要站在领导的角度来思考问题，要理解领导的意图啊。

 

南宋初年，岳飞几次向宋高宗请战，收复失地。为什么屡次遭拒，甚至被贬职？

不理解领导意图呗，当时宋钦宗还没有死，还被金国作为俘虏软禁着。如果岳飞收复失地，救回宋钦宗，那么宋高宗怎么办？

From: Code Complete (By: Steve McConnell)

 

In software development, nontechnical managers are common, as are managers who have technical experience but who are 10 years behind the times.
Technically competent, technically current managers are rare. If you work for one, do whatever you can to keep your job. It’s an unusual treat.

If your manager is more typical, you’re faced with the unenviable task of managing your manager. “Managing your manager” means that you need to tell your manager what to do rather than the other way around. The trick is to do it in a way that allows your manager to continue believing that you are the one being managed. Here are some approaches to dealing with your manager:
 ● Plant 895 ideas for what you want to do, and then wait for your manager to have a brainstorm (your idea) about doing what you want to do.
 ● Educate your manager about the right way to do things. This is an ongoing job because managers are often promoted, transferred, or fired.
 ● Focus on your manager’s interests, doing what he or she really wants you to do, and don’t distract your manager with unnecessary implementation details. (Think of it as "encapsulation” of your job.)
 ● Refuse to do what your manager tells you, and insist on doing your job the right way.
 ● Find another job.

 

The best long-term solution is to try to educate your manager. That’s not always an easy task, but one way you can prepare for it is by reading Dale Carnegie’s How to Win Friends and Influence People.

 

在软件开发过程中，非技术人员往往是管理者。最为例外的情况是管理者有工作经验，但是已是十年未再干过了。会技术的管理者是少见的。如果你为某一人工作，应尽力保住你的饭碗。这不是一件容易的事情。作为一个阶层，每一位雇员都想升到他并不能胜任的层次。

如果你的上司并不是一个特别的人，你将不得不学会如何面对你的上司。“控制你的上司”意味着你应告诉你的上司怎样去做，而不是用其他方法。其要决在于用这样一种方法使你的上司相信你仍是受他管理的一员。以下是一些对付你上司的方法：

最好的解决方法是努力说服你的上司。这并不是一件容易的事情，但是你可阅读《How to Win Friends and Influence People》（《怎样赢得朋友和影响他人》）一书以学会如何准备这件事。

what is Scrum and Scrum(development)

 

Other useful website about Scrum:

 

There has a book you can download for free:Scrum and XP from the Trenches

You can get more information about the auther: Henrik Kniberg, and his blog is: http://blog.crisp.se/henrikkniberg

OPF   Organizational Process Focus

OPD  Organizational Process Definition

OT    Organizational Training

OPP  Organizational Process Performance

OID   Organizational Innovation and Deplotment

 

PP    Project Planning

PMC  Project Monitoring and Control

SAM  Supplier Agreement Management

IPM   Integrated Project Management

RSKM Risk Management

IT     Integrated Teaming

ISM   Integrated Supplier Management

QPM  Quantitative Project Management

 

REQM  Requirements Management

RD    Requirements Development

TS    Technical Solution

PI    Product Integration

VER   Verification

VAL   Validation

 

CM    Configuration Management

PPQA Process and Product Quality Assurance

MA    Measurement and Analysis

DAR   Decision Analysis and Resolution

OEI   Organizational Environment for Integration

CAR   Causal Analysis and Resolution

REQM Requirements Management

PP     Project Planning

 

OPP  Organizational Process Performance

OEI  Organizational Environment for Integration

 

OID   Organizational Innovation and Deplotment

1. 你们的项目组使用源代码管理工具了么？
　 应该用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly都可以。我的选择是VSS。

2. 你们的项目组使用缺陷管理系统了么？
　 应该用。ClearQuest太复杂，我的推荐是BugZilla。 

3. 你们的测试组还在用Word写测试用例么？ 
　 不要用Word写测试用例（Test Case）。应该用一个专门的系统，可以是Test Manager，也可以是自己开发一个ASP.NET的小网站。主要目的是Track和Browse。

4. 你们的项目组有没有建立一个门户网站？
　 要有一个门户网站，用来放Contact Info、Baselined Schedule、News等等。推荐Sharepoint Portal Server 2003来实现，15分钟就搞定。买不起SPS 2003可以用WSS (Windows Sharepoint Service)。 

5. 你们的项目组用了你能买到最好的工具么？
　 应该用尽量好的工具来工作。比如，应该用VS.NET而不是Notepad来写C#。用Notepad写程序多半只是一种炫耀。但也要考虑到经费，所以说是“你能买到最好的”。 

6. 你们的程序员工作在安静的环境里么？
　 需要安静环境。这点极端重要，而且要保证每个人的空间大于一定面积。 

7. 你们的员工每个人都有一部电话么？
　 需要每人一部电话。而且电话最好是带留言功能的。当然，上这么一套带留言电话系统开销不小。不过至少每人一部电话要有，千万别搞得经常有人站起来喊：“某某某电话”。《人件》里面就强烈谴责这种做法。 

8. 你们每个人都知道出了问题应该找谁么？
　 应该知道。任何一个Feature至少都应该有一个Owner，当然，Owner可以继续Dispatch给其他人。

9. 你遇到过有人说“我以为…”么？
　 要消灭“我以为”。Never assume anything。 

10. 你们的项目组中所有的人都坐在一起么？
　　需要。我反对Virtual Team，也反对Dev在美国、Test在中国这种开发方式。能坐在一起就最好坐在一起，好处多得不得了。 

11. 你们的进度表是否反映最新开发进展情况？ 
　　应该反映。但是，应该用Baseline的方法来管理进度表：维护一份稳定的Schedule，再维护一份最新更改。Baseline的方法也应该用于其它的Spec。Baseline是变更管理里面的一个重要手段。

12. 你们的工作量是先由每个人自己估算的么？
　　应该让每个人自己估算。要从下而上估算工作量，而不是从上往下分派。除非有其他原因，比如政治任务工期固定等。 

13. 你们的开发人员从项目一开始就加班么？
　　不要这样。不要一开始就搞疲劳战。从项目一开始就加班，只能说明项目进度不合理。当然，一些对日软件外包必须天天加班，那属于剥削的范畴。 

14. 你们的项目计划中Buffer Time是加在每个小任务后面的么？
　　不要。Buffer Time加在每个小任务后面，很容易轻易的就被消耗掉。Buffer Time要整段的加在一个Milestone或者checkpoint前面。 

15. 值得再多花一些时间，从95%做到100%好值得，非常值得。
　　尤其当项目后期人困马乏的时候，要坚持。这会给产品带来质的区别。 

16. 登记新缺陷时，是否写清了重现步骤？
　　要。这属于Dev和Test之间的沟通手段。面对面沟通需要，详细填写Repro Steps也需要。 

17. 写新代码前会把已知缺陷解决么？
　　要。每个人的缺陷不能超过10个或15个，否则必须先解决老的bug才能继续写新代码。 

18. 你们对缺陷的轻重缓急有事先的约定么？
　　必须有定义。Severity要分1、2、3，约定好：蓝屏和Data Lost算Sev 1，Function Error算Sev 2，界面上的算Sev 3。但这种约定可以根据产品质量现状适当进行调整。

19. 你们对意见不一的缺陷有三国会议么？
　　必须要有。要有一个明确的决策过程。这类似于CCB (Change Control Board)的概念。 

20. 所有的缺陷都是由登记的人最后关闭的么？ 
　　Bug应该由Opener关闭。Dev不能私自关闭Bug。 

21. 你们的程序员厌恶修改老的代码么？
　　厌恶是正常的。解决方法是组织Code Review，单独留出时间来。XP也是一个方法。

22. 你们项目组有Team Morale Activity么？
　　每个月都要搞一次，吃饭、唱歌、Outing、打球、开卡丁车等等，一定要有。不要剩这些钱。 

23. 你们项目组有自己的Logo么？
　　要有自己的Logo。至少应该有自己的Codename。 

24. 你们的员工有印有公司Logo的T-Shirt么？
　　要有。能增强归属感。当然，T-Shirt要做的好看一些，最好用80支的棉来做。别没穿几次就破破烂烂的。

25. 总经理至少每月参加次项目组会议要的。
　　要让team member觉得高层关注这个项目。

26. 你们是给每个Dev开一个分支么？
　　反对。Branch的管理以及Merge的工作量太大，而且容易出错。 

27. 有人长期不Check-In代码么？
　　不可以。对大部分项目来说，最多两三天就应该Check-In。 

28. 在Check-In代码时都填写注释了么？
　　要写的，至少一两句话，比如“解决了Bug No.225”。如果往高处拔，这也算做“配置审计”的一部分。

29. 有没有设定每天Check-In的最后期限？
　　要的，要明确Check-In Deadline。否则会Build Break。 

30. 你们能把所有源码一下子编译成安装文件吗？ 
　　要的。这是每日编译（Daily Build）的基础。而且必须要能够做成自动的。 

31. 你们的项目组做每日编译么？
　　当然要做。有三样东西是软件项目/产品开发必备的：1. bug management; 2. source control; 3. daily build。 

32. 你们公司有没有积累一个项目风险列表？
　　要。Risk Inventory。否则，下个项目开始的时候，又只能拍脑袋分析Risk了。

33. 设计越简单越好越简单越好。
　　设计时候多一句话，将来可能就带来无穷无尽的烦恼。应该从一开始就勇敢的砍。这叫scope management。 

34. 尽量利用现有的产品、技术、代码千万别什么东西都自己Coding。BizTalk和Sharepoint就是最好的例子，有这两个作为基础，可以把起点 提高很多。或者可以尽量多用现成的Control之类的。或者尽量用XML，而不是自己去Parse一个文本文件；尽量用RegExp，而不是自己从头操 作字符串，等等等等。这就是“软件复用”的体现。

35. 你们会隔一段时间就停下来夯实代码么？
　　要。最好一个月左右一次。传言去年年初Windows组在Stevb的命令下停过一个月增强安全。Btw，“夯”这个字念“hang”，第一声。 

36. 你们的项目组每个人都写Daily Report么？
　　要写。五分钟就够了，写10句话左右，告诉自己小组的人今天我干了什么。一则为了沟通，二则鞭策自己（要是游手好闲一天，自己都会不好意思写的）。

37. 你们的项目经理会发出Weekly Report么？
　　要。也是为了沟通。内容包括目前进度，可能的风险，质量状况，各种工作的进展等。

38. 你们项目组是否至少每周全体开会一次？
　　要。一定要开会。程序员讨厌开会，但每个礼拜开会时间加起来至少应该有4小时。包括team meeting, spec review meeting, bug triage meeting。千万别大家闷头写code。 

39. 你们项目组的会议、讨论都有记录么？
　　会前发meeting request和agenda，会中有人负责主持和记录，会后有人负责发meeting minutes，这都是effective meeting的要点。而且，每个会议都要形成agreements和action items。

40. 其他部门知道你们项目组在干什么么？
　　要发一些Newsflash给整个大组织。Show your team’s value。否则，当你坐在电梯里面，其他部门的人问：“你们在干嘛”，你回答“ABC项目”的时候，别人全然不知，那种感觉不太好。

41. 通过Email进行所有正式沟通 
　　Email的好处是免得抵赖。但也要避免矫枉过正，最好的方法是先用电话和当面说，然后Email来确认。 

42. 为项目组建立多个Mailing Group 
　  如果在AD+Exchange里面，就建Distribution List。比如，我会建ABC Project Core Team，ABC Project Dev Team，ABC Project All Testers，ABC Project Extended Team等等。这样发起Email来方便，而且能让该收到email的人都收到、不该收到不被骚扰。 

43. 每个人都知道哪里可以找到全部的文档么？
　　应该每个人都知道。这叫做知识管理（Knowledge Management）。最方便的就是把文档放在一个集中的File Share，更好的方法是用Sharepoint。 

44. 你做决定、做变化时，告诉大家原因了么？
　  要告诉大家原因。Empower team member的手段之一是提供足够的information，这是MSF一开篇的几个原则之一。的确如此，tell me why是人之常情，tell me why了才能有understanding。中国人做事喜欢搞限制，限制信息，似乎能够看到某一份文件的人就是有身份的人。大错特错。权威、权力，不在于 是不是能access information/data，而在于是不是掌握资源。 

45. Stay agile and expect change 要这样。
　　需求一定会变的，已经写好的代码一定会被要求修改的。做好心理准备，对change不要抗拒，而是expect change。 

46. 你们有没有专职的软件测试人员？
　  要有专职测试。如果人手不够，可以peer test，交换了测试。千万别自己测试自己的。 

47. 你们的测试有一份总的计划来规定做什么和怎么做么？
　　这就是Test Plan。要不要做性能测试？要不要做Usability测试？什么时候开始测试性能？测试通过的标准是什么？用什么手段，自动的还是手动的？这些问题需要用Test Plan来回答。

48. 你是先写Test Case然后再测试的么？
　　应该如此。应该先设计再编程、先test case再测试。当然，事情是灵活的。我有时候在做第一遍测试的同时补上test case。至于先test case再开发，我不喜欢，因为不习惯，太麻烦，至于别人推荐，那试试看也无妨。 

49. 你是否会为各种输入组合创建测试用例？
　　不要，不要搞边界条件组合。当心组合爆炸。有很多test case工具能够自动生成各种边界条件的组合??但要想清楚，你是否有时间去运行那么多test case。 

50. 你们的程序员能看到测试用例么？
　　要。让Dev看到Test Case吧。我们都是为了同一个目的走到一起来的：提高质量。

51. 你们是否随便抓一些人来做易用性测试？ 
　　要这么做。自己看自己写的程序界面，怎么看都是顺眼的。这叫做审美疲劳??臭的看久了也就不臭了，不方便的永久了也就习惯了。

52. 你对自动测试的期望正确么？
　　别期望太高。依我看，除了性能测试以外，还是暂时先忘掉“自动测试”吧，忘掉WinRunner和LoadRunner吧。对于国内的软件测试的现状来说，只能“矫枉必须过正”了。

53. 你们的性能测试是等所有功能都开发完才做的么？
　　不能这样。性能测试不能被归到所谓的“系统测试”阶段。早测早改正，早死早升天。

54. 你注意到测试中的杀虫剂效应了么？
　　虫子有抗药性，Bug也有。发现的新Bug越来越少是正常的。这时候，最好大家交换一下测试的area，或者用用看其他工具和手法，就又会发现一些新bug了。

55. 你们项目组中有人能说出产品的当前整体质量情况么？
　　要有。当老板问起这个产品目前质量如何，Test Lead/Manager应该负责回答。 

56. 你们有单元测试么？
　　单元测试要有的。不过没有单元测试也不是不可以，我做过没有单元测试的项目，也做成功了??可能是侥幸，可能是大家都是熟手的关系。还是那句话，软件工程是非常实践、非常工程、非常灵活的一套方法，某些方法在某些情况下会比另一些方法好，反之亦然。 

57. 你们的程序员是写完代码就扔过墙的么？
　　大忌。写好一块程序以后，即便不做单元测试，也应该自己先跑一跑。虽然有了专门的测试人员，做开发的人也不可以一点测试都不做。微软还有Test Release Document的说法，程序太烂的话，测试有权踢回去。

58. 你们的程序中所有的函数都有输入检查么？
　　不要。虽然说做输入检查是write secure code的要点，但不要做太多的输入检查，有些内部函数之间的参数传递就不必检查输入了，省点功夫。同样的道理，未必要给所有的函数都写注释。写一部分主要的就够了。

59. 产品有统一的错误处理机制和报错界面么？
　  要有。最好能有统一的error message，然后每个error message都带一个error number。这样，用户可以自己根据error number到user manual里面去看看错误的具体描述和可能原因，就像SQL Server的错误那样。同样，ASP.NET也要有统一的Exception处理。可以参考有关的Application Block。

60. 你们有统一的代码书写规范么？
　　要有。Code Convention很多，搞一份来发给大家就可以了。当然，要是有FxCop这种工具来检查代码就更好了。 

61. 你们的每个人都了解项目的商业意义么？
　  要。这是Vision的意思。别把项目只当成工作。有时候要想着自己是在为中国某某行业的信息化作先驱者，或者时不时的告诉team member，这个项目能够为某某某国家部门每年节省多少多少百万的纳税人的钱，这样就有动力了。平凡的事情也是可以有个崇高的目标的。

62. 产品各部分的界面和操作习惯一致么？
　　要这样。要让用户觉得整个程序好像是一个人写出来的那样。

63. 有可以作为宣传亮点的Cool Feature么？
　　要。这是增强团队凝聚力、信心的。而且，“一俊遮百丑”，有亮点就可以掩盖一些问题。这样，对于客户来说，会感觉产品从质量角度来说还是acceptable的。或者说，cool feature或者说亮点可以作为质量问题的一个事后弥补措施。 

64. 尽可能缩短产品的启动时间要这样。
　　软件启动时间（Start-Up time）是客户对性能好坏的第一印象。

65. 不要过于注重内在品质而忽视了第一眼的外在印象程序员容易犯这个错误：太看重性能、稳定性、存储效率，但忽视了外在感受。而高层经理、客户正相反。这两方面要兼顾，协调这些是PM的工作。

66. 你们根据详细产品功能说明书做开发么？
　　要这样。要有设计才能开发，这是必须的。设计文档，应该说清楚这个产品会怎么运行，应该采取一些讲故事的方法。设计的时候千万别钻细节，别钻到数据库、代码等具体实现里面去，那些是后面的事情，一步步来不能着急。

67. 开始开发和测试之前每个人都仔细审阅功能设计么？
　　要做。Function Spec review是用来统一思想的。而且，review过以后形成了一致意见，将来再也没有人可以说“你看，当初我就是反对这么设计的，现在吃苦头了吧”

68. 所有人都始终想着The Whole Image么？
　　要这样。项目里面每个人虽然都只是在制造一片叶子，但每个人都应该知道自己在制造的那片叶子所在的树是怎么样子的。我反对软件蓝领，反对过分的把软件制造看成流水线、车间。参见第61条。

69. Dev工作的划分是单纯纵向或横向的么？
　　不能单纯的根据功能模块分，或者单纯根据表现层、中间层、数据库层分。我推荐这么做：首先根据功能模块分，然后每个“层”都有一个Owner来Review所有人的设计和代码，保证consistency。 

70. 你们的程序员写程序设计说明文档么？
　　要。不过我听说微软的程序员1999年以前也不写。所以说，写不写也不是绝对的，偷懒有时候也是可以的。参见第56条。

71. 你在招人面试时让他写一段程序么？
　  要的。我最喜欢让人做字符串和链表一类的题目。这种题目有很多循环、判断、指针、递归等，既不偏向过于考算法，也不偏向过于考特定的API。

72. 你们有没有技术交流讲座？
　  要的。每一两个礼拜搞一次内部的Tech Talk或者Chalk Talk吧。让组员之间分享技术心得，这笔花钱送到外面去培训划算。

73. 你们的程序员都能专注于一件事情么？
　  要让程序员专注一件事。例如说，一个部门有两个项目和10个人，一种方法是让10个人同时参加两个项目，每个项目上每个人都花50%时间；另一种方 法是5个人去项目A，5个人去项目B，每个人都100%在某一个项目上。我一定选后面一种。这个道理很多人都懂，但很多领导实践起来就把属下当成可以任意 拆分的资源了。 

74. 你们的程序员会夸大完成某项工作所需要的时间么？
　  会的，这是常见的，尤其会在项目后期夸大做某个change所需要的时间，以次来抵制change。解决的方法是坐下来慢慢磨，磨掉程序员的逆反心理，一起分析，并把估算时间的颗粒度变小。 

75. 尽量不要用Virtual Heads 最好不要用Virtual Heads。
　  Virtual heads意味着resource is not secure，shared resource会降低resource的工作效率，容易增加出错的机会，会让一心二用的人没有太多时间去review spec、review design。一个dedicated的人，要强过两个只能投入50%时间和精力的人。我是吃过亏的：7个part time的tester，发现的Bug和干的活，加起来还不如两个full-time的。参见第73条。73条是针对程序员的，75条是针对 Resource Manager的。 

Parkinson's First Law: Work expands to fill the time available.
Parkinson's Second Law: Expenditures rise to meet income.
Parkinson's Third Law: Expansion means complexity; and complexity decay.
Parkinson's Fourth Law: The number of people in any working group tends to increase regardless of the amount of work to be done.
Parkinson's Fifth Law: If there is a way to delay an important decision the good bureaucracy, public or private, will find it.
Parkinson's Law of Sience: The progress of science varies inversely with the number of journals published.
Parkinson's Law of Delay: Delay is the deadliest form of denial.
Parkinson's Law of Data: Data expands to fill the space available.
Parkinson's Law of Meetings: The time spent in a meeting on an item is inversely propotional to its value (up to a limit).
Parkinson's Law of 1000: An enterprise employing more than 1000 people becomes a self-perpetuating empire, creating so much internal work that it no longer needs any contact with the outside world.

Mrs. Parkinson's Law: Heat produced by pressure expands to fill the mind available, from which it can pass only to a cooler mind.

大多数软件项目都是失败的。事实上，Standish group 的报告显示 80% 多的项目是不成功的，原因是超出了预算、未能按时完成、遗漏功能或者因为一个项目中同时出现了这些问题中的其中几个。此外，30% 的软件项目执行得很糟糕以至于半途而废。根据我们的经验，使用现代技术（例如 Java、J2EE、XML 以及 Web 服务）的软件项目都逃不出这个规则。

本文概述了软件开发项目的最佳实践。一些业界泰斗，如 Scott Ambler、Martin Fowler、Steve McConnell 和 Karl Wiegers，已经在因特网上写了许多这样的最佳实践，本文也引用了这些最佳实践。另请参阅本文末尾的相关信息部分。附带的文章软件开发项目实施指南描述了有助于提高项目成功率的十条最重要的因素。

最佳实践

1. 开发流程（Development process）－ 为手头的项目选择适当的开发生命周期流程很重要，因为其他的所有活动都是从这个流程派生出来的。现代的软件开发项目多数都是在瀑布式流程的基础上采用某种螺旋式方法。有几种方法可供选择，包括 Rational 统一流程（Rational Unified Process，RUP）、IBM® Global Services 方法（IBM® Global Services Method）以及极端编程（eXtreme Programming，XP）。有个流程当然比根本没有要好，但在多数情况下流程的执行情况要比使用的是什么流程更重要。以上列举的常用方法都包含关于如何执行流程的指南和构件模板。此外，RUP 还有一系列描述使用 RUP 的最佳实践的书 [1][2][3][4]，即便不选用 RUP，这些书也是获得最佳实践的极好来源。给 RUP 加插件也是可以的。请为基于 WebSphere® J2EE 的项目下载 WebSphere 插件。

2.需求 － 收集需求并就需求达成一致是项目成功的基础。这并不一定意味着需要在建立好体系结构、完成设计和编码工作之前确定所有的需求，但对于开发小组来说明白需要构建什么是很重要的。质量需求分两种：功能性的和非功能性的。一种记录功能性需求的好方法是使用用例（Use Case）。注意：用例被用于非面向对象的项目。Armour 和 Miller 著有一本关于用例主题的权威著作 [5]。非功能性需求描述应用程序的性能和系统特性。收集非功能性需求很重要，因为他们对应用程序体系结构、设计以及性能都会产生重要影响。请参阅 Construx Web 站点上的非功能性需求清单。

3.体系结构 － 为您的应用程序选择合适的体系结构是关键。有好几次 IBM 被要求复查出问题的项目，结果发现开发小组没有应用知名的业界体系结构最佳实践。与 IBM 联系是避免这类问题的好方法。我们的顾问可以与您的开发小组并肩工作以确保项目沿正确的轨道开始。经过实验证明可靠的实践称为模式，有经典的 Gang of Four [6] 模式、Java 模式 [7]，也有 EJB 设计模式 [8]。Sun 公司与此相应的是核心 J2EE 模式（Core J2EE Pattern）目录 [9]。IBM 也发布过一些最佳实践和参考应用程序体系结构 [10]。引言中说过许多项目都是失败的。通过对这些失败的项目的研究提出了反模式这个概念。这些反模式是很有价值的，因为它们针对哪里出了问题以及为什么会出问题提供了有用的信息。

4. 设计 － 即使有了好的体系结构，也可能设计不好。许多应用程序不是设计得过于复杂就是设计得过于简单。这有两个基本原则“尽量简单”和信息隐藏。对于许多项目来说，使用 UML 进行面向对象的分析与设计（Object-Oriented Analysis and Design）很重要。有关 UML 的书有很多，但我们推荐 UML User Guide [11] 和 Applying UML and Patterns [12]。重用是面向对象的很有前途的一个方面，重用经常会因为需要额外的工作来创建可重用资产而变得无法实现。代码重用是重用的一种形式，当然也有其他一些能够提高效率的重用种类。

5. WebSphere 应用程序设计 － IBM 拥有关于 WebSphere 系列产品的最佳实践和设计模式的广泛知识。每个项目都是不同的，我们的顾问有丰富的经验来帮助您。即使您只聘请我们的顾问很短一段时间，这种投资回报（ROI）也是很大的，因为您可以在以后的项目中节省开销。我们的专家也发表过大量有关这类知识的文章，包括高性能 Web 站点注意事项和自主计算指南。

6. 代码的构建 － 代码的构建虽然只是整个项目工作的一小部分，但往往是最明显的部分。其他同样重要的工作还包括需求、体系结构、分析、设计以及测试。在没有开发流程（所谓的“编码加修正”）的项目中，也会有这些任务，只不过被统称为“编程”而已。构建代码的最佳实践包括每日构建和冒烟测试。Martin Fowler 进一步提出了连续集成（continuous integration），这个概念还集成了单元测试和自测试代码概念。注意，即使连续集成和单元测试是通过 XP 流行起来的，您也可以在所有类型的项目中使用这些最佳实践。我建议使用标准框架（比如 Ant 和 JUnit）使构建和测试自动进行。

7. 对等审查 － 审查别人的工作很重要。经验证明这种方法可以及早消除问题，审查和测试一样有效，甚至比测试还有效。开发流程中任何构件都需要审查，包括：规划、需求、体系结构、设计、代码以及测试案例（test case）。Karl Wiegers 的文章 Seven Deadly Sins of Software Reviews 说明了执行对等审查的正确方法。对等审查有助于以最快的速度提高软件质量。

8. 测试 － 即使日程安排再紧也不可以推迟或省去测试。测试是需要计划的软件开发的一个必不可少的部分。提前测试也很重要；这意味着要在开始编码前就安排好测试案例，测试案例的开发与应用程序的设计和编码同时进行。同样也有许多现成的测试模式。

9. 性能测试 － 测试通常是用于检查应用程序缺陷的最后一招。它是劳动密集型工作，通常只检查编码缺陷。体系结构和设计上的缺陷可能会漏掉。一种检查体系结构缺陷的方法是在部署应用程序之前对其进行模拟负载测试，并在性能问题真正成为问题前就处理它们。

10. 配置管理 － 进行配置管理涉及到了解组成您的系统或项目的所有构件的状态，管理这些构件的状态并发布系统的不同版本。配置管理比单独的源代码控制系统（比如 Rational Clearcase）管理的内容更多。同样也有针对配置管理的最佳实践和模式 [13]。

11. 质量和缺陷管理 － 为项目建立质量优先级和发布标准很重要，这样就可以制定一个计划来帮助开发小组开发出高质量的软件。当对项目进行编码和测试时，缺陷的出现和修正比率有助于测量代码的成熟程度。使用链接到源代码控制管理系统的缺陷跟踪系统也很重要。例如，使用 Rational ClearCase 的项目还可以使用 Rational ClearQuest。使用缺陷跟踪，就可以在准备发布项目时对项目进行测量（gauge）。

12. 部署（Deployment）－ 部署是向用户发布应用程序的最后阶段。如果您的项目进行到了这一步 － 那就恭喜您啦！但仍然会有可能出错的地方。您要制定部署计划，并且您可以使用 Construx Web 站点上的部署清单。

13. 系统操作与支持（System operations and support）－ 没有操作部门就不能部署和支持新应用程序。支持范围对于回答和解决用户问题至关重要。为缓解问题流，应用程序缺陷跟踪系统中引入了支持问题数据库。

14. 数据迁移（Data migration）－ 多数应用程序都不是全新的，而是改善或者重写的现有应用程序。从现有的数据源迁移数据这本身通常就是一个比较大的项目。这不是初级程序员能做的。它与新应用程序一样重要。通常新应用程序的业务规则更好，数据质量有可能更高。提高数据质量是一个复杂的主题，已经超出了本文讨论的范围。

15. 项目管理（Project management）－ 项目管理是项目取得成功的关键。本文描述的许多其他的最佳实践都和项目管理有关，出色的项目经理已经知道了这些现有的最佳实践。我们推荐的项目管理权威著作是 Steve McConnell 编写的 Rapid Development [14]。如果把项目管理的其他清单和技巧的数目考虑进去，您会感到大吃一惊，居然有那么多的项目经理不知道这些技巧，并且也没有从以前的项目中吸取教训，比如：“如果没有计划好，就等于计划着要失败。”一种管理困难项目的方法是通过使用时间定量（timeboxing）。

16. 衡量是否成功 － 您可以根据卡内基梅隆大学软件工程学院（Software Engineering Institute at Carnegie Mellon University）的业界标准软件能力成熟度模型（Capability Maturity Model，CMM）来衡量您的开发流程。多数项目处于 1 级（初级）。如果按照上面描述的最佳实践和附带的文章，软件开发项目实施指南，中的执行，就可以开发出更加成熟的软件，使项目取得成功。

结束语

本文提供了一系列有助于提高软件开发项目成功率的最佳实践。遵循这些最佳实践，您的项目成功的机会会更大。

中国人大都喜欢用武侠小说来比较软件开发，但是在实战武功中，只有葵花宝典才是最厉害的，也只有掌握了葵花宝典，才能称为“不败”。
       但什么才是软件开发的葵花宝典？
       让我们先从一些现象出发。我们的前提是，软件开发是一项智力密集型劳动。对于智力密集型劳动，我们观察到的现象是，个体的表现差异很大，团队的表现差异很大，组织的表现差异很大，国家的表现差异很大。这不象体力占主要的劳动，象百米王跑百米的速度也仅比我快50%。但在棋类运动中，一个高手可以车轮战数位低手，而且毫无例外地将他们一一击败！
      这些智力运动员表现出的特点是，计算精确而且速度快。其行为很象东方不败。虽然关于葵花宝典的传说很多，但最准确的描述只有一个字“快”。东方不败已经快到了吓人的地步。就象卡斯帕罗夫已快到了深蓝的地步。

　　有一则关于物理学家玻尔的轶事，有一次玻尔在普林斯顿大学听两个年青教授演讲他们的工作成果。期间玻尔突然发言说，如果照你们的研究算下去，会得到一个很有意思的推论。结果两个年青教授回去计算了两天，果然得出了同样的结论。玻尔是如何做到这样快的？

　　在软件开发中，我们同样注意到这样一种高手，他们可以每天写出一千行左右的高品质代码。他们可以运用已有的一些软件包，迅速完成一个新的产品。他们可以在很短的时间内，学会一项新的程序语言或是新技术。他们表现出一种神奇的速度。
　　在武侠小说中，所有的高手都有一些凡人不能企及的表现。象张无忌学太极，用龙爪手击败龙爪手名家；乔峰用太祖长拳击败天下英雄；姑苏慕容以其人之道还治其人之身，令狐冲一剑剌瞎十几双眼睛等等。我认为，之所以他们能做到这样，关键是在于他们快。

　　快并不意味着不准或品质差。快与品质并不矛盾。
　　高手的快，其实包含着很高的品质在其中。如果你因为高手的快，就质疑其品质，那就相当于在问：东方不败出手那么快，会不会刺不准？东方不败并不满足于刺死对手，他会在对手身上刺朵花。他把杀人变成了艺术。准确来说，他真正的兴趣不在杀人，而在于艺术。
　　退一步说，就算东方不败第一击有点偏差，他稍作修正后，马上跟上的第二第三击，也会击中他想击中的地方。在武功差的对手剑还没拨出来的时候，他已杀死对方并刺上了一朵花。

　　所以真正的软件高手，他并不满足于他的代码能有效地工作了，他认为编程是艺术，并醉心于其中。在低手能写出一个版本的时间里，他已经写出了第十版。其品质当然不可同日而语。就象一个九段棋手，在给定的时间里，他能计算十种可能，并将每种可能计算到100手之后，从中选择一种最有利的下法。低手岂有苟全的机会？
　　高手写软件总是不停地在重构(refactoring）。高手喜欢迭代式开发。高手说，增量就是打补丁，迭代就是推倒重来。对于软件这种东西，写一遍它可能ok（做到这一点也不容易），写十遍就是一个伟大的产品，再多写一遍它就更伟大些。
　　高手快的诀窍在于他很熟悉各种东西。高手看书很快，因为每一本新书里，值得他好好看的新技术只有一两章的内容。他能迅速看完，并准确领会这本书的中心思想和价值。而对于一个新手，每句话都是新的，他都需要去理解，每一段例子，他都需要去试。

　　很少看到一种100%全新的技术或理论。就象java language specification里说的，java没有使用任何新技术，用的都是业界久经考验的技术。对于高手来说，那些技术都是他所熟悉的。自然，很快他就从一个c++高手变成了java高手。如果一个编程新手学java，学两年也不如一个高手学两个月的。高手学新东西快。

　　高手写代码速度快。统计结果说，人均每人月的有效代码速度大概是300至400行。但那是业界平均生产效率。对于高手来说，这个数字太低了。每天写300至400行是完全有可能的。因为在写代码时，所有知识都已具备，已经没有任何需要他多花时间的事情了。他甚至很少需要debug。
　　高手重用代码的能力很强，熟悉新的api的速度很快。这也是因为，他曾经使用过很多的api，重用过很多的代码。他知道哪些是可用的，哪些有缺陷。他既过用qt，也用过gtk+，也用过windows api & mfc，也用过awt & swing。新的api对他来说，也是老熟人。 
    高手喜欢用轻量级的工具，象vi，notepad，最多到ultraedit这样复杂的。高手用这种工具写出很多的东西。这些工具就象东方不败的针。那根针已具有神奇的魔力，有时候它可以当激光枪来用。
　　对于一些重量级的工具，高手虽不常用，但一经使出也威力大于常人。如果让东方不败用剑，最厉害的剑术名家也会败得很难看。高手其实用过很多的重量级工具，而且深知其优缺点。所以使出来，就会把威力发挥到最大，而把缺陷减少到最小。而低手则不然，总是把缺陷加以大大的发扬而浑不知其精髓何在。就象很多人学用uml、rup、xp、design pattern那样。
　　高手所学博杂且融会贯通。高手做什么都快，当低手还在一愁莫展的时候，高手已经圆满解决问题，去干别的事去了。

　　相信你有一点点想成为高手了。但是有一个问题亟等解决，那就是“欲练神功，必先自宫”的问题。这一点其实是有比喻意义的。就是说，你必需抛弃一些世俗的人们很看重的东西。有诗为证：
　　世人都晓高手好，只是寂寞受不了
　　世人都晓高手好, 只有名利忘不了
　　世人都晓高手好, 只有金钱一定要
　　世人都晓高手好, 天下美女都要抱
     世人都晓高手好, 不写代码最最好

 

　　高手的武功不是一朝一夕练成的。还记得玻尔那件轶事吗，玻尔回答说，他年青时也计算过很多的问题。在很多计算的基础上，高手能培养起一种感觉。高手不写代码就能做设计是因为他以前写了很多的代码。而且他们会保持写代码，以保证自已的水平不下降。想一想九段高手是如何练成的。最难做到的是能忍受十年磨一剑的寂寞。别人在父母那里撒娇时，他们在一旁用功。十年磨一剑，剑就成了东方不败的针。
　　在你下定决心要做高手之后，也就是下定决心抛弃那些世俗的追求之后，也就是你下决心忍受那些来自于庸俗的人的白眼、攻击和谩骂之后，你就具备了练成神功的必要条件。
　　事实上其实你不必一开始就练神功，一开始大家可能是为了钱，房子，汽车，美女才编程序的，然而后来艺术就从中产生了。那时高手就不再关注那些东西了。卓别林曾说过，他开始进入那个圈子也是为了钱，后来艺术就从中产生了。当然，也有人一开始是为了艺术，后来变成为了钱。

　　所谓三十而立，就是说到了三十，你找到了你的真爱，值得用一生去追求的那种。比如说有的人到了三十认为这一辈子应该赚尽可能多的钱，这也没什么不好，也可以把赚钱本身变成一种艺术，所谓资本运作是也。所以在三十以前，有些私心杂念没什么。三十以后还这样是可耻的。而我，想做一个程序员。

　　每个人做自己最喜欢的事。这个世界需要程序员，也需要资本运作。所有真正的程序员，他最喜欢的事是编程和他自已。如果他后来去做ceo去了，不再编程，只说明他本来不是一个真正的程序员。

　　在成为高手的路上，要有热情，要循序渐进，要持之以恒。
　　要靠自己，书要快快地看。要试图迅速理解其主旨。其实你快快看所接受的信息量，与慢慢看接受的差不多。能明白多少很大程度上取决于你的功底。以后用到再回过头来看。一本对你来说新东西太多的书，不要指望看一次就全理解吸收。就象很多功力不够的人看design patterns那本书一样。慢慢看还不如找到多种 信息来源，都快快看一遍。对于一个完全陌生的领域，只看一本书很远远不够的。
    要靠自已，事要快快做。有一个朋友，几年前我介绍他去玩玩linux，他也表示想玩，但他现在还没碰过。他失去了很多机会。
    平时要有意识提高自己写代码的速度，其实你一天写15行有效代码，与你写50行有效代码，其品质是差不多的。你应该把那些业界平均水平抛诸脑后，把超越自己做为唯一目标。等到你写了很多各式各样的代码，你的水平就不一般了。一个老师曾向我介绍他的学英语的决窍，他说你去啃原版小说，啃到50本，就和一般人有很大距离了。就是这个理。如果你写得太慢，怎么能写得多？水平怎么能提高？
　　要靠自己，学很多别人怕学的东西。低手总会说：这么多东西怎么学得过来啊。于是就少学或不学。这样就成不了高手了。高手有非常广的知识面，有很丰富的经验。知道很多低手不知道的事。玩过很多低手听都没听过的东西。
　　要靠自己，努力满足客户的各种需求。个人技能是在满足客户的各种需求的过程中提高的。比如你喜欢用delphi，客户说一定要用vb，那你就答应他，然后把自己培养成为vb的高手。用户的需求看似**，但对你是一个机会。

　　怎样才能做到看书快，写代码快，学新东西快，一个显而易见的途径就是将工作并行化。你在一台机器上make时，同时可以在看别的文档和聊天。对于计算机是这样，对人也是这样。如果你只能串行地处理问题，你的速度将提高有限。你的大脑有很大潜力可挖，它应该是一个多任务分时系统。努力减少它idle的时间。搞经济的samuelson被人称为human brain main frame，可见他的大脑有多快。
　　让你的思维快起来，你就会区别于那些反应迟钝的人。如果你不能让人生的道路变长，就让它变宽。这世界变化快，需要你变得比它快才行。
　　这样加快并不会让你短命，相反，你有更多的时间来享受生活和锻炼身体。你的生活将更有品质，更丰富，更有意义。面对变化，你将立于不败之地。我们都是和自己赛跑的人，需要跑得比昨天的自己更快。

1、彼得原理

每个组织都是由各种不同的职位、等级或阶层的排列所组成，每个人都隶属于其中的某个等级。彼得原理是美国学者劳伦斯·彼得在对组织中人员晋升的相关现象研究后，得出一个结论:在各种组织中,雇员总是趋向于晋升到其不称职的地位。彼得原理有时也被称为向上爬的原理。 这种现象在现实生活中无处不在:一名称职的教授被提升为大学校长后，却无法胜任；一个优秀的运动员被提升为主管体育的官员，而无所作为。 对一个组织而言，一旦相当部分人员被推到其不称职的级别，就会造成组织的人浮于事，效率低下，导致平庸者出人头地，发展停滞。 因此，这就要求改变单纯的根据贡献决定晋升的企业员工晋升机制，不能因某人在某个岗位上干得很出色，就推断此人一定能够胜任更高一级的职务。将一名职工晋升到一个无法很好发挥才能的岗位，不仅不是对本人的奖励，反而使其无法很好发挥才能，也给企业带来损失。

2、酒与污水定律
酒与污水定律是指把一匙酒倒进一桶污水，得到的是一桶污水；如果把一匙污水倒进一桶酒，得到的还是一桶污水。在任何组织里，几乎都存在几个难弄的人物，他们存在的目的似乎就是为了把事情搞糟。最糟糕的是，他们像果箱里的烂苹果，如果不及时处理，它会迅速传染，把果箱里其他苹果也弄烂。 烂苹果的可怕之处，在于它那惊人的破坏力。一个正直能干的人进入一个混乱的部门可能会被吞没，而一个无德无才者能很快将一个高效的部门变成一盘散沙。组织系统往往是脆弱的，是建立在相互理解、妥协和容忍的基础上的，很容易被侵害、被毒化。 破坏者能力非凡的另一个重要原因在于，破坏总比建设容易。一个能工巧匠花费时日精心制作的陶瓷器，一头驴子一秒钟就能毁坏掉。如果一个组织里有这样的一头驴子，即使拥有再多的能工巧匠，也不会有多少像样的工作成果。如果你的组织里有这样的一头驴子，你应该马上把它清除掉，如果你无力这样做，就应该把它拴起来。

3、木桶定律
水桶定律是讲一只水桶能装多少水，这完全取决于它最短的那块木板。这就是说任何一个组织，可能面临的一个共同问题，即构成组织的各个部分往往是优劣不齐的，而劣势部分往往决定整个组织的水平。 水桶定律与酒与污水定律不同，后者讨论的是组织中的破坏力量，最短的木板却是组织中有用的一个部分，只不过比其他部分差一些，你不能把它们当成烂苹果扔掉。强弱只是相对而言的，无法消除，问题在于你容忍这种弱点到什么程度，如果严重到成为阻碍工作的瓶颈，你就不得不有所动作。

4、马太效应
《新约·马太福音》中有这样一个故事:一个国王远行前，交给3个仆人每人一锭银子，吩咐道:你们去做生意，等我回来时，再来见我。国王回来时，第一个仆人说:主人，你交给我的一锭银子，我已赚了10锭。于是，国王奖励他10座城邑。第二个仆人报告:主人，你给我的一锭银子，我已赚了5锭。于是，国王奖励他5座城邑。第三仆人报告说:主人，你给我的1锭银子，我一直包在手帕里，怕丢失，一直没有拿出来。于是，国王命令将第三个仆人的1锭银子赏给第一个仆人，说:凡是少的，就连他所有的，也要夺过来。凡是多的，还要给他，叫他多多益善.这就是马太效应,反应当今社会中存在的一个普遍现象,即赢家通吃. 对企业经营发展而言,马太效应告诉我们,要想在某一个领域保持优势,就必须在此领域迅速做大。当你成为某个领域的领头羊时,即便投资回报率相同,你也能更轻易地获得比弱小的同行更大的收益.而若没有实力迅速在某个领域做大,就要不停地寻找新的发展领域,才能保证获得较好的回报。

5、零和游戏原理
零和游戏是指一项游戏中，游戏者有输有赢，一方所赢正是另一方所输，游戏的总成绩永远为零，零和游戏原理之所以广受关注，主要是因为人们在社会的方方面面都能发现与零和游戏类似的局面，胜利者的光荣后面往往隐藏着失败者的辛酸和苦涩。 20世纪，人类经历两次世界大战、经济高速增长，科技进步、全球一体化以及日益严重的环境污染，零和游戏观念正逐渐被双赢观念所取代。人们开始认识到利已不一定要建立在损人的基础上。通过有效合作皆大欢喜的结局是可能出现的。 但从零和游戏走向双赢，要求各方面要有真诚合作的精神和勇气，在合作中不要小聪明，不要总想占别人的小便宜，要遵守游戏规则，否则双赢的局面就不可能出现，最终吃亏的还是合作者自己。  

6、华盛顿合作规律
华盛顿合作规律说的是一个人敷衍了事，两个人互相推诿，三个人则永无成事之日。多少有点类似于我们三个和尚的故事。 人与人的合作，不是人力的简单相加，而是要复杂和微妙得多。在这种合作中，假定每个人的能力都为1，那么，10个人的合作结果有时比10大得多，有时，甚至比1还要小。因为人不是静止物，而更像方向各异的能量，相互推动时，自然事半功倍，相互抵触时，则一事无成。 我们传统的管理理论中，对合作研究得并不多，最直观的反映就是，目前的大多数管理制度和行为都是致力于减少人力的无谓消耗，而非利用组织提高人的效能。换言之，不妨说管理的主要目的不是让每个人做得更好，而是避免内耗过多。

7、手表定理
手表定理是指一个人有一只表时，可以知道现在是几点钟，当他同时拥有两只表时，却无法确定。两只手表并不能告诉一个人更准确的时间，反而会让看表的人失去对准确时间的信心。 手表定理在企业经营管理方面，给我们一种非常直观的启发，就是对同一个人或同一个组织的管理，不能同时采用两种不同的方法，不能同时设置两个不同的目标，甚至每一个人不能由两个人同时指挥，否则将使这个企业或这个人无所适从。 手表定理所指的另一层含义在于，每个人都不能同时选择两种不同的价值观，否则，你的行为将陷于混乱。

8、不值得定律
不值得定律最直观的表述是:不值得做的的事情，就不值得做好。这个定律再简单不过了，重要性却时时被人们忽视遗忘。不值得定律反映人们的一种心理，一个人如果从事的是一份自认为不值得做的事情，往往会保持冷嘲热讽，敷衍了事的态度，不仅成功率低，而且即使成功，也不觉得有多大的成就感。 因此，对个人来说，应在多种可供选择的奋斗目标及价值观中挑选一种，然后为之奋斗。选择你所爱的，爱你所选择的，才可能激发我们的斗志，也可以心安理得。而对一个企业或组织来说，则要很好地分析员工的性格特性，合理分配工作，如让成就欲较强的职工单独或牵头完成具有一定风险和难度的工作，并在其完成时，给予及时的肯定和赞扬；让依附欲较强的职工，更多地参加到某个团体*同工作；让权力欲较强的职工，担任一个与之能力相适应的主管。同时要加强员工对企业目标的认同感，让员工感觉到自己所做的工作是值得的，这样才能激发职工的热情。

9、蘑菇管理
蘑菇管理是许多组织对待初出茅庐者的一种管理方法，初学者被置于阴暗的角落（不受重视的部门，或打杂跑腿的工作），浇上一头大粪（无端的批评、指责、代人受过），任其自生自灭（得不到必要的指导和提携）。相信很多人都有过这样一段蘑菇的经历，这不一定是什么坏事，尤其是当一切刚刚开始的时候，当几天蘑菇，能够消除我们很多不切实际的幻想，让我们更加接近现实，看问题也更加实际。 一个组织，一般对新进的人员都是一视同仁，从起薪到工作都不会有大的差别。无论你是多么优秀的人才，在刚开始的时候，都只能从最简单的事情做起，蘑菇的经历，对于成长中的年轻人来说，就象蚕茧，是羽化前必须经历的一步。所以，如何高效率地走过生命的这一段，从中尽可能汲取经验，成熟起来，并树立良好的值得信赖的个人形象，是每个刚入社会的年轻人必须面对的课题。

10、奥卡姆剃刀定律
1 2世纪，英国奥卡姆的威廉主张唯名论，只承认确实存在的东西，认为那些空洞无物的普遍性概念都是无用的累赘，应当被无情地剃除。他主张如无必要，勿增实体。这就是常说的奥卡姆剃刀。这把剃刀曾使很多人感到威胁，被认为是异端邪说，威廉本人也因此受到迫害。然而，并未损害这把刀的锋利，相反，经过数百年的岁月，奥卡姆剃刀已被历史磨得越来越快，并早已超载原来狭窄的领域，而具有广泛、丰富、深刻的意义。     奥卡姆剃刀定律在企业管理中可进一步演化为简单与复杂定律:把事情变复杂很简单，把事情变简单很复杂。这个定律要求，我们在处理事情时，要把握事情的主要实质，把握主流，解决最根本的问题，尤其要顺应自然，不要把事情人为地复杂化，这样才能把事情处理好。