选择正确的开发技术不一定就会保证项目的成功——但是选择错误的开发工具一定会给你带来灾难性的后果！ 在没有选择一些极端混合技术的前提下，软件开发工具是足够你选择的。在多年的开发工作中，我经历了一些惨痛的经验教训，在此分享十个帮助大家选择合适的开发工具的技巧。
1.不要指望某一个工具能当银弹使用。 人们经常犯的最大错误是在挑选软件时总以改善软件开发流程为前提，习惯性的认为，只要软件改变了，那些问题就会“溜走了”。这简直无稽之谈！我目睹过无数的ALM系统在安装使用1，2个月以后，除了剩下一大堆零星的“碎片”外，其它真的毫无用处。难道这些系统真的很糟糕吗？俗话说：“工具是死的，人是活的”。如果你的团队仅仅是学着如何使用它，而不是去根据项目实际去探索，去进行变动，让工具变成你项目的一部分。那么项目也会在工具中慢慢的死掉。 2.当心集成 我们常常看到因为集成工作（太过复杂），结果在集成过程中的人工投入远远大于免费软件节省的部分，大幅增加了预算。这也适用于对软件开发工具的选择上。集成的“代价”要远远高于把现有资源进行整合，它是开发过程中的一个流程，并且在这个流程当中需要花费时间去对软件项目进行重新研究或者学习其他东西，这种现象在软件集成里面是很普遍的。 3.不要被“整体（total package）”愚弄 大多数时候，程序员喜欢用“整体（total package）”来解决一个问题，可事实并不支持这种做法，甚至会使问题更糟。下面以MS SQL Server为例，说它是个不错的软件，但集成的软件良莠不齐（尤其是SQL Server Reporting Services），如果用别的插件代替捆绑的会更好。 4.做一个试点项目 一份通用报告显示：“70%的IT项目被视为失败的”。项目为什么会失败？或许这就是做试点项目的原因。选择一个较小的、新的或低风险的项目来使用一些新的工具或者技术进行开发，最后再进行诚实的评估以便今后可以更好的利用该工具。如果在没有这两种压力的情形下：“某个部分不工作造成了整个项目失败”或者“如果我们选择不佳，会拖垮整个工作团队”，很容易去避免陷入“沉没成本的谬论”中，并且试图使一个坏产品正常工作。 5.丢弃试点项目 谈到“沉没成本谬论”，请抵制住试点项目给你带来的诱惑，不要把试点项目移到整个系统中运行。下面列出了几个理由：
请记住，保持试点项目的独立性。最好是一个使用新工具并且没有取得巨大成功的小项目，在试点项目退出后可以推荐团队使用这些工具。 6.考虑团队背景 好马配好鞍，如果你把一个非常好的工具给一个不适合的团队，那么这个工具也就非“好鞍”啦！例如，我认为Mercurial是一个非常奇妙的版本控制工具，但是人们如果从“瀑布背景”去看它，就不会发现它的好处。相反，那些人会觉得Team Foundation Server会更好，但是如果从敏捷这个背景去看，它并不是一个非常好的选择。 7.评估学习曲线 有些工具会很好学，一个简单易学且适用的工具远比那些拥有强大包且不能在项目中灵活运用的工具更有效。例如，人们在无数的项目中使用微软的项目管理工具或者类似的工具，但几乎都会变的一团糟，当人们停止更新项目时，这个工具遍会成为一个麻烦。我最近在使用Trello，它的门槛很低而且容易使用，在项目中稳定性也很好。是不是这样Trello就可以作为全能的项目工具使用了呢？是根本不可能的，因为人们都会有一个这样的感觉：“手里使用的工具总比那些未使用的要好！” 8.确保它能解决实际问题 在使用一项新技术或者新工具时，它很容易使人觉得兴奋，但重要的问题是，它是否适合，是否可以解决问题。比如在几年前，我曾仔细研究过F#，并且有一段时间为研究它的算法而着迷，可是后来它并没有解决我当时所面临的真正问题。那个时候竟用F#来代替C#，这种做法真的有点乱中添乱。我还有过并行处理的经验，尽管使用多语言和多系统编写多线程代码更容易，但是在实际应用程序中，很难去维护并且很少有应用程序可以证明你的技术。 9.开放==开源？ 单词“开放”的意思越来越无意义了。我们已经目睹了很多项目正在逐步“开放”，这样做的好处是让索赔工作更加容易，如果这些代码对你的项目有用，你还需要关注一些额外的东西？什么是许可证？这些都使用常见的标准吗？这些标准都是可以免费使用的吗？有时候“开放”并不意味着开源或者意味着在许可标准下。 10.审核供应商 作为顾客，我们常常习惯性的使用供应商提供的某些我们根本不需要东西。根据定义，每一种关系都是独特的，但是我已经学会了如何选择适合的东西。虽然下面这个列表不是非常详尽，但都是应该注意的供应商很难处理的问题：
原文来自：techrepublic |
