来自 Rational Edge：一位经验丰富的软件开发专业人员提出了一份他个人的建议，并且描绘了一幅通过改进和提高开发过程从而使项目获得成功的良好习惯，它涉及到交流沟通、用例、测试和市场营销等方面。
在过去两年中，无论是从事内部的还是外部的软件开发项目，我都会遇到这样或那样的挑战，同样也会发现一些在不同项目中都普遍适用的良好习惯。既然我懂得了如何利用这些习惯来克服困难，于是我决定将其作一些梳理并记录下来，作为本文的提要。
这些笔记可以归纳为如下四条策略：
弥补缺乏面对面交流所带来的不便
撰写更好的用例
确保有效的测试
支持市场工作
这项别具风格的建议决不是包罗万象。我的目的并不是教授您如何构造软件，而是和您探讨一些对于项目成功与否至关重要的技术或非技术性的问题。有时，一个好项目和一个堪称经典的项目之间的差异是由一些看起来无关紧要的因素造成的。我的建议所着眼的是那些相对较小却很关键的部分，它们可以作为整个工程的代表。
弥补缺乏面对面交流所带来的不便
人人都知道项目成功关键的因素是良好的交流与沟通。这是一个相当大的题目，在此我仅其中一个确实能使项目之间产生出好与坏差别的方面加以论述。
面对面交流的好处
整个团队能够在同处在一个地区是一件非常值得庆幸的事情。通常这种情况会发生在那些小规模的、刚刚起步的业务身上。几个理想坚定、雄心勃勃的人为共同的目标而奋斗，一同体验和经历着每中同样的细节。同样，一些更大规模的组织有效的使用灵活的方法在面对面交流的基础上建立它们的内部流程。当某一个团队同处在一座建筑物内时，其成员能够在午餐时、走廊内、下班后进行面对面的交流，这些非正式的会面通常比安排好日程的会议更具效率。我至今仍记得无数次这样的情形：当我在一个长时间的讨论之后从被写的满满当当的白板上面抄录下笔记之后，正是这些被大家分享观点和想法成为了新的方案的基础。
然而，业务的成功和事业的发展通常会使得将一个高水准的团队固定在同一个地点变得越来越不现实。由于并购、合作项目以及外包开发的出现，要求我们能够在不同时区、不同文化之间成功地进行交流和沟通。在这样一种情况下，什么才是我们好的选择呢？
分布式环境下的交流的开展
第一个映入我们脑海的答案大概是电子邮件了。我曾经觉得电子邮件确实是一种有效的沟通渠道，但它同时也是被滥用甚的一种渠道。如果电子邮件的传送距离过长以至于人们没有时间去阅读它们，那还有什么用呢？根据我的经验，如果包含三条以上的信息，那么您应当转而使用电话进行交流了。这个小小的规则帮助我节省了大量的时间，使得我不必去撰写那些关于Lotus Notes软件的无意义的文本。
此外，还有其他的一些沟通渠道，尽管它们并不能够取代面对面会议的亲密性，但它们确实能够提高一个团队的合作能力和理解能力：
项目主页。 在网络上建立一个主页，从而为项目提供了一个极好的单向交流渠道（如果您使用wikis技术或者论坛/博客方式的话，也可以是双向的交流渠道）。主页上可以解释项目的具体内容是什么，确定所要达到的主要目标，以及介绍团队的成员。管理者同样可以应用这一页面来发布代码标准，“如何做”将帮助团队成员设置环境，凡此种种。

在线聊天。 这种交流形式在团队成员之间创建了一个虚拟的合作环境，营造了一种轻松的交流思想的气氛。显然的，通过即时消息系统随时向同事寻求帮助要比通过电话交流要有效率的多。例如，IBM的系统，Lotus Notes SameTime系统，与Lotus Notes地址录结合在一起，因此您可以轻易地在您的组织内部找到正确的连接，并且看到那个人是否已经登录到SameTime。如果您看到指示器显示“忙”，您可以判断出此人同样也没有时间接听您的电话。SameTime同样允许您邀请多人一同聊天，因此说这是一种进行合作讨论并且立刻做出决定的非常好的方法，并且它省去了为进行一次正式会议而作的准备。
一些聊天程序还包括了其他一些有意思的功能，比如个性化可用性消息，为将来之用而保存副本的功能，等等。我之所以加亮了IBM SameTime是因为它提供了许多由于其与Lotus Notes电子邮件系统相结合而产生的附加功能。请记住，不同的聊天工具提供不同等级的安全性，并不是所有的聊天工具都能很好的适用于职业应用的。

缺陷跟踪系统。 这是另外一种有效的沟通渠道。每一个软件开发项目都必须能够处理功能增进的需求以及程序缺陷报告。一个有效的缺陷跟踪系统，例如IBM Rational ClearQuest，能够帮助开发团队规范化这些需求和报告。特别地，通过Rational ClearQuest和IBM Rational ClearCase结合而获得的统一变化管理（UCM）的能力，将允许您将缺陷记录和源代码联系起来，这将大大提高在日常事务上的交流质量。例如，如果对于一个不能正常工作的组件我需要得到帮助，我可以找到该组件在缺陷跟踪数据库中的入口，并且查明该组件是否在执行进一步的工作，以及谁在执行那项工作。

“一杯咖啡。” 从另一个方面来说，每一种交流的工具都是人。当有人打电话给你仅仅是问候一下您近在忙什么，特别是在您处在工作压力下的时候，难道这不是一件非常令人感到欣慰的事情么？尽管您的同事可能正处在地球的另一端，记得这些非正式的交谈对于巩固一个团队发挥着多么巨大的作用仍然是非常重要的。即使您使用的是完善的管理和报告工具，有些时候与另一个人的交谈仍然是获得正确信息的的方法。邀请您远方的同时共饮一杯咖啡如何？也许一个没有事先安排的电话会在工作结束之前的一小段时间内打来。请记住，如果您起初经常拨出这样的电话，那么您也将接到更多这样的电话。
撰写更好的用例
从某个角度来看，我们可以认为用例也是交流沟通的一种形式。但是，它却远远不仅仅如此，所以我在这里将其单独处理。
用例较之于其他系统设计技术有两个大的优点。首先，它们为每一个参与项目的人员提供了一个关于终的用户需求的正确理解。其次，您可以在源代码的第一个原型出来的很长一段时间之前对这些用例进行装配。弄清楚应用程序的关键原理以及用户的真正需求，一方面为今后同客户开展富有成效的合作开启了大门，另一方面也为在产品合成过程中不同角色和团队之间的合作奠定了基础。
简单的说，用例是描述下列两件事情之一的一个简单的文档：
用户要求必须事先的关键功能（业务用例）.
或者
用户（活动者）与业务系统之间的交互（系统用例）。
也许您在想：“所以什么？那仅仅是另一个文档。”实际上，当我第一次面对要将需求和用户的期望写进文档之中，使之可以被不同的项目角色共享这一挑战之前，我也抱有同样的想法。在项目初的阶段里，测试团队和文档团队开始向我们询问一些关于我们将做什么以及各部分之间将如何协同工作等等细节。直到我发现用例之前，我的回答总是矛盾的、混乱的和非常耗费时间的。
当然，一旦我发现使用用例来计划和回答这些问题是多么的有效，我便面临着另外一项挑战：学习如何更加有效的撰写用例。
了解用户
在进入交互和特定情节之前，理解所有目标客户群并将其彼此区分开来，并且把他们的要求和需要列入清单是非常重要的。不同的用户群有着不同的业务用例。例如，一位负责确认遵循一套特定的全球性标准的测试人员的需求在很多方面不同于一位拥有相似职责的开发者。开发者也许拥有知识、工具以及职权来修补那些错误的地方，但是测试者则是记录下这些缺陷然后等待开发者来作出改正。
在设计应用程序时，除非您弄清了这两类用户的特定需要，否则您有可能设计出一个两方面需求都不能得到满足的系统。
业务用例与系统用例
取决于被讨论系统的不同，在业务用例和系统用例之间可能存在着巨大的差异。一个是描述用户的业务，而另一个描述的是用户同系统的交互活动。然而，这两种类型的用例之间的区别也可以变得模糊。例如，在一个软件开发项目中，系统是业务。当您开发和测试一个特定的系统功能的时候，很容易会忘记终的用户很可能不会用您所采用的方法使用该系统，甚至都不会拥有同样的需要。
为了理解业务用例和系统用例之间的区别，想象一下软件开发团队已经承担了一项软件应用程序开发任务，并且要保证其在全球各种不同地区的环境下都可以同样出色的运作。为了确保该应用程序达到这些要求，该团队必须遵循一套小化的全球规则。1 这些规则在一套规范中被严格定义，不能随意被更改。开发团队需要针对这些规则来审核自己的代码，目前这些工作必须由手工来完成。一位程序师（审核员）必须打开源文件来查找同指定规则相矛盾的地方。
该组织收到一份执行决定，要建造一种能够使这些全球性规则（及其他规范）得到自动分析的工具，并且集合一支团队来开展这一项目。目标是将业务用例中手工操作的那部分替换为软件应用程序（即系统）。这一手工过程非常耗费时间且容易出现错误。并不是所有的程序师都能够同样好的理解这一全球性的规则，许多人很可能没有注意到这之间存在的矛盾之处。另外，团队成员在持续的工作压力下变得越来越快的生产产品。一个可以核查全球化规则的自动化的系统将降低忽视某条规范的风险，并节省大量的时间。
在这个特定情节中，业务用例“在核查之前复审每一份源文件”可以被看作：
对于工作区内的每一份源文件：
打开源文件。
逐行阅读代码（注：需要深入的代码知识）。
如果您发现了一个可以的方法，请参考包含这一规则的网页（注：非常耗费时间）。
如果可能的话，通过修改代码解决该问题（对于开发者的业务用例）。
对于测试者来说可选的流程：如果您不能正确地解决这个问题，请将发现的问题记录在Word文档中并提交给开发人员。
打开下一份源文件并重复上面的步骤。
正如您所看到的，这是一套冗长的流程，但却是实现自动控制的一个非常好的候选方案。
系统用例的价值
一旦您定义了用户的“是这样”的流程和目标，您能够指定那些用户活动的部分是一个自动控制的系统所能提供的。尽管它们仍然包含着用户的活动，系统用例却是以系统为中心的，来描述用户同系统交互的过程。然而，请注意系统用例应当在业务流程的背景下被定义。终，我们的目标是帮助用户处理业务问题。
这里是在我们虚构的项目中，团队是如何定义基础系统用例的，假设用户是团队的一个成员：
前提：全球性的规则在IDE的复审特性的代码中被授权使用。
在IDE中打开代码复审工具。
（步骤之打开工具）。
运行一个代码复审。
主流程——点击按钮“Run”。
（在新区域内列出可选流程的详细描述）。
复审自动化复审的结果（发现的问题）。
对于每一个发现的问题，解决之：
主流程：提交缺陷。
（在新区域内列出可选流程的详细描述）。
如果您不能够修正这一代码，则提交缺陷。
（步骤之缺陷提交）。
一个包含以上这些步骤地简短的文档将提供充分的信息，使得读者了解到终产品应该是什么样子，它将如何帮助客户处理他们的业务，等等。即使这一信息没有被明确的说清楚。
下面是拥有系统用例而带来的一些显而易见的好处：
即使没有一个代码被分类为“代码复审完毕，等待测试”，测试人员也能够针对上面描述的功能制定出一份测试方案。
另外，正是基于这一点，文档编写者可以针对代码复审创建并且（或者）添加文档中的结构。
开发管理者在此之后可以使开发进度更加优化，以便使得第一份开发构造将至少满足该用例的主要流程。
用例促进了项目的开发，并且使得全体团队成员在项目伊始忙碌起来。如果您仍然没有将您的工作关注到用例上，那么请给它们一次机会。您所付出的努力将是值得的。

确定系统用例适当的详细程度
在每一个用例步骤中应该包含多少信息呢？
我更偏爱于取得系统用例并将其根据业务用例分类，并且同样通过一组步骤将大量的用户交互活动分类。该组步骤解释了该步骤的目的，并且可以在某些细节在实现过程中改变的情况下保持不变。这种方法使得文档更加易懂，它将系统用例和业务用例联系起来，并且如果产品执行变化时它允许用例可以被容易的修正。
例如，在上述系统用例中的简单的步骤“运行代码复审”中，向细心的读者传递了一个非常有价值的信息，包括：
代码复审被结合在IDE中。
代码复审必须在使用中，或者“运行”。
代码复审提供了一个关于违背某套有效性标准的问题清单。
某些问题可以被迅速的修正。
代码复审将获得迅速的修正。