做软件开发的都知道瀑布软件开发模型吧，也都知道它已经成为软件工程教科书上一个小节的内容吧，仅此而已，因为它已成为历史，现在已经没有人愿意说自己采用的是瀑布式软件开发模型，取而代之的是敏捷开发模型，这个是大家现在挂在口头上的常用语吧，其实你有所不知的是敏捷开发模型早在10年前就开始被广泛采用了，但软件开发的创新从来没有停止过，敏捷开发现在也已经OUT了，许多新出现的开发方法很多地方都比敏捷方法还优秀，我们暂且统称为精益开发或超精益开发模型吧，下面我们就来看看一个团队如何做到超精益开发的境界。

　　1、选择商品化的技术

　　不管你在哪个国家，总还有一个国家的工程师薪水比你低，作为软件工程师，这是一件让我们很心寒的事情，但事实就是这样，真的很残酷。软件开发工作越来越商品化，借助第三方库和API，使软件开发不再是一件复杂的事情，需要实现的业务逻辑变得越来越简单，Web领域也正在经历一场运动，人们开始重视简单的业务模式和内容质量，而不是技术，因为软件开发已经进化到只需要调用现成的库或API就可以组装成功能强大的系统，开发人员自己写的代码会越来越少，其实这样也会提高软件的质量，组装式开发比一个字母一个字母敲代码稳当多了。

　　2、关注技术风险和市场风险

　　另一个与技术商品化并行存在的现象是缺少关注所谓的技术风险，在上世纪90年代，很难招到优秀的程序员，因此那个时代开发出来的软件都很让人害怕，也让不少公司吃了苦头，项目不是被迫推迟就是被迫取消的情况时有发生，虽然现在情况有所好转，但一样让人不那么放心，项目被延迟，成本超出预算，要进行大规模用户测试时软件还没有准备好的现象仍然频频发生，但一般来说，所有问题都是可以解决的。

　　3、选择没有技术风险的想法

　　虽然我的话听上去象是没有技术风险，但如果你想在复杂的领域创新那还是有的，如语义网络、云计算、搜索或其它高级的或资源昂贵的计算机科学领域，如果正好身处这些领域，你一定能体会到有很多的技术风险，虽然这些新兴技术领域常常会让人很兴奋，但遗憾的是，除了技术风险很高外，市场风险也很大，因此整体风险就翻了一番。在选择创新的领域时，大多数人会选择风险低和更简单的领域，选择高风险和难度高领域的人一般都是技术狂人，一旦成功，他们可能就会获得“xx之父”的美名。

　　4、累积技术债务，快速将产品推向市场

　　这一点并不适合每一个人，如果你在做企业软件开发，你一定要避免累积技术债务，因为它会使你组织中的其他人花时间来处理你构建的软件，如果你开发的是金融或医疗信息系统时，那你一定要小心谨慎。另一方面，如果你开始做的不是很关键的系统，你可以跳过许多最佳实践需要考虑的事项，可以认为是偷工减料的做法，这样做可以更快速地将产品送交测试和推向市场，可以探一下市场风险究竟有多大。

　　5、仅当被黑了才重视安全

　　安全是累积技术债务的鲜活实例，加强安全的技术有很多种，如果你在一家对安全要求很严格的企业里，这一点并不适合你，另一方面，如果可以，放弃最安全的做法，只着眼于简单有效的做法，如输入验证，这样也有助于减少错误。除此之外，你可能想远离会话劫持或复杂的服务器安全配置，或通过被黑尔发现安全漏洞，是的，我拥护被黑后在加强安全保护，但只有不会造成很大损失时才推荐这样做，大多数黑客攻击都没有恶意，而是希望帮助你发现安全漏洞，这样你就不用猜测哪里有安全漏洞，可以专注于核心产品的开发。

　　6、忘掉可扩展性

　　当我希望快速发布一个版本，看市场的反应如何时，忘掉可扩展性是我最喜欢的一件事，扩展性是业务人员最喜欢谈的一个概念，但真正了解这个时髦词语背后概念的人都知道它是这么一回事，简简单单三个字却包含了很多技术和很大的工作量。首先，需要产品的某些部件可以进行扩展，其次，在创新阶段，许多功能添加进来后可能很快又被移除，这是创新的正常过程，没有什么东西是一步成功的，价值在于快速开发，为小部分人提供样品测试，确定这些功能是否值得保留。精益项目的特点就是快速迭代，快速确定哪些功能需要保留和扩展，那些不被看好的功能就应该迅速停止开发并移除，这样可以提高创新的速度。

　　7、对好的想法说“不”

　　根据定义，精益项目需要精益的资源，而本文涉及的是超精益项目，这意味着在任何给定时间只能构建有限的功能，决策过程需要清晰地确定哪些功能是需要的。一个常见的困难是，要在无数的好想法中间确定哪些可以继续做下去，哪些应该停下来，这意味着比以往说“不”的时间更多，一个原则是尽快将产品推向市场，那些违背这个原则的想法都应该先否定，因此需要对好的想法说“不”的魄力。

　　8、没有笨重的语言

　　我知道现在肯定没有人用C++来创建一个Web项目，大部分人都在使用Java，Java对企业来说的确很有吸引力，但它对精益项目来说可能显得有点笨重。很多新项目现在都转向了PHP、Ruby或其它一些拥有快速原型优势的语言，一个成功的例子就是Twitter，它就是从用Ruby On Rails做的原型逐渐发展起来的，它将快速迭代开发模型展现得淋漓尽致，对于Twitter团队，迭代的成果就是Twitter。

　　9、速度高于质量

　　这是另一个有争议的观点，因为从长远来看总是以质量取胜的居多。但在产品开发初期，哪些功能会成功是不知道的，因此唯有快速将产品推向市场，并收集用户的反馈，然后再把重点放在提高产品质量上，如果发现没有人使用这种产品，那么必须承认这是一个廉价且快速的失败，但我们应该从失败中学到东西，避免重复失败，并迅速释放出更好的产品。拥抱精益和超精益项目的团队喜欢“失败”这个单词，因为他们将它看作是成功的前奏，每一次失败的成本很少，并可以从失败中汲取大量的教训，然后在很短时间内发布更好的产品，从而将上一次的失败掩盖掉，因此以小的失败换来大的成功是非常值得的。

　　10、用户体验高于用户界面

　　在过去的15年中，我们看到了网络的成长和成熟，经历了网络泡沫和后泡沫时代，每个时代总会看到很多外观简单，甚至有点丑陋的产品，但给人们带来的价值却很大，尽管它们看起来很丑，但所做的事情却让人欣赏，如著名的Google搜索引擎，Twitter和Craigslist，它们一个共同的特点就是界面简单，但功能强大。我之所以提出这个观点是因为，许多人觉得产品既应该好看，功能又应该很强大，但很多时候是不能两全其美的，核心功能必须强大，然后是易用性，最后才是美观。在开发新产品时，有很多创新的想法需要去实现，因此精益和超精益开发团队可以使用快速原型和迭代不断改进，并最终取得完胜。