人性化的软件开发

     <p><strong>只要有了优秀的编程工具、高级的编程语言、丰富的构件库和辅助程序建立系统，就能解决所有问题？并及时地在预算范围内交付良好的软件系统吗？ 一个软件开发团队如果想要在项目中获得最大限度的成功，离不开人的因素。</strong></p>    <p style="text-align:center;"><img title="人件集：人性化的软件开发" alt="人性化的软件开发" src="https://simg.open-open.com/show/448193b3b6ca289cac2ecd802f3b389f.jpg" width="160" height="230" /></p>    <p><strong>软件开发团队中的意见</strong></p>    <p>一个软件开发团队如果想要在项目中获得最大限度的成功，取决于团队中的成员能否形成技术性一致意见。但为什么这点如此重要呢？是不是团队成员只 要在诸如目录表格的布局上达成一致，或者建立一个很好的错误汇报机制就行了呢？技术性一致意见指的并不是与同事打成一片就可以了（当然，这也不是说在同事 之间建立良好的关系有什么错误）。技术性一致意见是指充分吸取团队中每个成员的技巧和经验，其目的是为了开发出更好的软件。</p>    <p>职业软件人员也许能够迅速理解一款好的软件，至少当他们看见一个好的软件时会宣称自己能够理解它，但是，在软件开发者中，很少有人能理解技术性 一致意见。可能许多<a href="/misc/goto?guid=4958336262130353199" target="_blank">软件开发</a>者 会说，我们以前使用过一致意见的方法来解决问题，但是效果非常差，他们还会举出许多例子，比如，一些很棒的构想就是在不断的 讨论中葬送了，最后为了所谓的整体性只得做出妥协；本来 6 个月可以完成的项目最后拖了 1 年：团队的能力也没有完全发挥出来。但如果仔细地听听他们的意见，你就会意识到他们所说的解决问题的方式根本就不是技术性一致意见，而是折衷。那么，二者 之间有什么差异呢？</p>    <p><strong>折衷是没有前途的</strong></p>    <p>折衷意味着所做出的选择是一种似是而非的东西。既不是甲，也不是乙，而是一个介于二者之间的东西。我们可以通过一个典型的例子来说明。如你的团 队正在开发一个图形用户界面的项目，一部分人强烈建议直接将控制按钮放在屏幕底部，而另一部分人建议在屏幕的左侧放置一个控制窗体。在这两种意见中，一种 是水平放置，一种是垂直放置，形成了两个极端。那么，一个最具有代表性的折衷方案就是，将控制按钮沿着对角线放置在屏幕的中央。</p>    <p>就像上面的例子所描述的，由折衷所产生的解决方案常常要比任何一个原有的方案都要差劲。但是技术性一致意见就恰恰相反，它所产生的解决方案要比 任何一个原有的方案都要好。如果不使用技术性一致意见，往往会由于顾忌到每种备选方案的优点，而采用优点均衡的方式，但实际上每种备选方案的优点也就丧失 了。真正的一致意见不是基于那种让每个个体都做出让步的折衷，而是基于综合的，新的综合体要比原有的任何一个个体都要好。最后的结局就是，开发出了更好的 软件。</p>    <p>一个综合体是一种具有新颖性的新个体，是集成了原有的每个建议和方案的本质特征的个体。在上面所说的界面设计例子中，可以明显地看出，一个具有 创造性的综合方案是给控制按钮窗体加上选项，由用户来决定是采用水平放置还是采用垂直放置。一致意见的方法不仅仅是将各种选择方案的优点集中起来，而且综 合方案还体现了新的特性和功能。通过集成水平放置和垂直放置这两种方案，我们可以实现终端用户定制。这样，最后的软件产品就集成了各种方案的好的方面，而 不是坏的方面。</p>    <p>形成真正的一致意见并不是一件容易的事情，那些政客和工人谈判代表们对此深有感触。达成一个技术性的一致意见与达成一个政策性的一致意见是有所不同的，但是有些本质特征是基本相似的：二者都需要制定一些约束条件以达成共识，参与者在讨论过程中都需要保持一种信念。</p>    <p><strong>真正的信徒</strong></p>    <p>团队成员必须坚信，从每个人的意见中提取出最好的方面并将其综合起来，就此形成一个技术性的综合体是完全可能的。只有坚信这点，成员们才有可能 坚定不移地寻找最好的解决方案，而不是轻易地折衷或者固执己见。每个成员发表自己对问题的看法，讲述方案的优缺点，通过坚持不懈地努力，成员们可以提高形 成具有创造性方案的可能性，而这种创造性的方案会比原有的任何方案都更好。</p>    <p>当每个成员都相信开发一个好的软件要比在软件中使用自己所喜爱的方案更重要时，一致意见式的设计会发挥更大的作用。如果我们注重最终软件产品的质量，在团队讨论过程中会更容易发现每种意见的优点。</p>    <p>如果团队中的成员不是独自炫耀个人能力，而是认同联合协作的工作方式，那么对于软件开发会更有帮助。有些公司愿意奖励杰出的个人，而不是奖励团 队；或者晋升那些惯于单打独斗，特别是那些不会也不可能与他人共事，常常一个人解决问题的程序员，而不是表彰整个团队。这样的公司会做出如下论断：最好的 软件是他们的天才程序员开发出来的。这些公司意识不到，除了这种方法以外，其实还有其他的方法可以达到更好的效果。</p>    <p>在建立技术性一致意见时，一个必须遵循的原则就是：绝不能以货易货!对于政客们来说，采用以货易货的贸易方式是一种获得成功的经典策略，但对于 技术性一致意见而言，这是有害无益的。举例来说，在上面的界面设计例子中我们可以采用以货易货的方式，如果让我同意你的愚蠢方案，将控制按钮窗体放在屏幕 底部，那么你就要同意我聪明的设计思想，加上没有标签的图标。最终的结果就是，界面不是最好，而只是一个具有两个普通特性的界面。这种以货易货的策略其实 是另一种形式的折衷，而折衷之所以糟糕，是因为在不同方面所做的决策会相互影响。好的技术性一致意见必须将问题分别对待，对于不同的问题分别采用最好的解 决方案，而绝不能因为某个方面固执己见，致使另一个方面让步。</p>    <p><strong>尊重事实</strong></p>    <p>一般来说，大家都认为技术决策所依据的都是技术性因素，诸如事实、可测量的数值、应用中需要考虑的事项等。但实际情况是，诸如感觉、意见、直 觉、偏见等，都会对决策的制定或者问题的解决产生影响，这些都是人在做事情时所不可避免的因素。尽管有些人试图否认、控制、压制这些非理性的因素，但这些 都是绝不可能完全避免的。</p>    <p>对于那些希望采用技术性一致意见方式来解决问题的团队，有一个基本的技巧是必须掌握的：将事实和意见分开。对于一个协同工作的团队来说，如果期 望创造性地解决问题并获得最好的结论，他们必须知道他们已经掌握了哪些信息，并能够随时获得最好的信息。发表意见并不是错误，团队成员应该能够自由地表达 他们的意见。意见是有用的，特别是那些经过深思熟虑的意见，但是成员在表达意见时必须能够保证他们的意见不要和事实、数据、分析混在一起。就算是事实，也 是具有局限性的。例如，在美学或者行销领域中，事实所起的作用可能就会不太显著。遗憾的是，有些团队成员一旦形成自己的意见，他们往往就对事情的真实程度 视而不见了。</p>    <p>有时候，把某些东西称为事实并不意味着它就是真正的事实，因此，团队必须学会如何单刀直入地解决问题，而且大家还需达成一致——不玩文字游戏。 我的第一任妻子在我们共同生活的早期就学会了这一点，只要我说出以“事实很清楚地表明……”开头的一段话，她就会对我所讲的东西表示怀疑，因为这意味着随 后所讲的话极有可能只是我个人的看法，而不是基于任何数据或证据所得到的结论。除了这个尴尬的话题外，我有时还会掉入另一个语言陷阱中，那就是众所周知的 “95％的科学家都认为……”。有些人可能意识到了，在软件业中，有一句同样著名的话：“你知道的，绝大多数的职业软件工程师，至少 95％以上，都会采用这个方法。”当然，如果你还想继续使用这个小技巧，你必须改变百分数，例如：“将近 78％的 WordPerfect 用户都知道最好的方法是……”，“如果我们做个调查，2／3以上的C程序员都会同意……”。有时候，看上去好像真的有那么多的科学家、软件工程师、终端用 户站在你的背后支持你的意见。</p>    <p>但是，这仅仅是我的看法。<br /> <br /> 本文转载自: <a href="/misc/goto?guid=4958336262967847349" rel="nofollow" target="_blank">http://www.programmer.com.cn/11293/</a></p>