如何快速发布你的点子？

文／邱俊涛

过去的几年中，我参加过好多次Hackday活动。每次看到在为期两天的时间里，2-3个人将一个想法变成现实，都会有一种强烈的成就感。而且这个Hack的过程中，会重拾编程的乐趣，大家的积极性都非常高，用着各种有趣的技术（大数据，开源硬件，Node.js，GIS系统），逐步的将模糊的想法，变成现实，并最终为客户带来价值。

通过这些Hackday的经历，以及在众多项目中的经验，我总结了一些轻量级的方法/实践。这些方法/实践非常容易落地，并且久经验证。在很多项目中已经在不断的使用。它们可以帮你更好的将一个想法变成现实，并且在随后的开发中还可以继续发挥作用而不至失效（测试，构建脚本，自动化部署等等）。我希望你可以在自己的项目中尝试这些方法/实践，也希望这些方法/实践可以真正的帮助你和你的项目取得成功。

细化你的“点子”

根据一个已有的产品来参考，演绎，并形成自己的产品并非难事，而创新则是一件非常困难的事情，因为你需要“无中生有”。在ThoughtWorks，我们有这样一些步骤可以帮助客户来梳理信息，并最终交付产品，简而言之，可以归结为这样几个步骤：

1. Discovery（用户研究，探索）
2. Define（归纳洞见，发现）
3. Design（原型设计，验证）
4. Delivery（制定计划，实施）

01

上图是一个“点子”的原型（一个交换技能的应用，用户可以教别人自己擅长的技能，作为交换，也可以从别人那里学习心得技能），原型事实上是第三步的产物。我们通过一些调查（口头采访，或者问卷调查）得到一些基本的信息，然后归纳这些信息，并和真实用户再次确认，得到一个概念。有了概念，再来设计一个基本的原型，这个原型还可以迭代数次，然后进入下一个阶段。

前三个阶段更多的是用户体验设计师，以及客户的业务人员参与的。在前三步完成之后，进入实施的时候，软件工程师开始投入。这篇文章更关注第四步(Delivery)中的各种实践，通过这些实践，我们可以很好的完成交付计划，使得我们的好想法最终可以变成为用户提供服务的产品。

实现“点子”的方法

在软件领域，将一个想法变成实际的产品需要经历若干个阶段。按照传统的软件开发方式，会有前期的调研，需求分析，概要设计，详细设计，编码实现，测试，发布等一系列的流程。这种方式对每个阶段的定义都非常明确，而且每个阶段需要依赖前一个阶段的输出，因此往往被称为“瀑布模型”。后来慢慢发现，这个模型的反馈周期太长，一个软件从调研到发布往往需要数年，当发布之后，可能市场早已经沧海桑田。人们后来发明了更加符合现代市场需求的“敏捷开发”，在敏捷中，更加强调短平快的将需求变为产品。

简而言之，敏捷开发更强调：

1. 快速发布
2. 渐进增强
3. 小步迭代

而在敏捷开发的继承者精益中，这几点理念也被更进一步的深化。由于没有办法预见未来，我们只能用一种边做边看的方式来验证想法。简而言之，就是先根据经验和调查，做出一个合理的推断，然后定义好范围，构想出一个最小可行产品（MVP），这个MVP的功能非常内聚，非常紧凑，我们需要尽可能快的让其上线，并被真是的用户使用，测试。根据这些用户的反馈，我们会做一些调整，比如去掉那些很少人使用的功能，聚焦在用户喜欢的功能上；从用户的实际使用中，调整界面元素的位置，子功能的入口等等。这个过程会持续多轮，最后的结果会是一个有真是用户使用，并且比较贴近真实需求的产品。当然这还不够，我们需要不断的打磨，渐进式的增强产品的功能，逐步完善功能等。

有一个非常形象的图，可以看出瀑布模型和敏捷开发两种方法的对比：

02

敏捷开发通过逐步细化，迭代前进的方式，分阶段的将需求实现，在整个过程中，更容易做到快速调整。

所有的这些过程，都非常依赖“快速”这个关键点。如果MVP花了3周就产生了，但是为了让其上线，你花费了1个月，那么很可能这个MVP已经过时了；如果你确实快速的将MVP发布了，在得到了用户的很多反馈之后，花费1个月来实现这些反馈，又会让你落在竞争对手之后；如果快速的发布了多次，并且幸运的是，你的用户量变多了，如果花费很长时间来调整架构，则可能失去当前的市场窗口。也就是说，你需要非常快速地对变化做出反应！

轻量级的开发方式

开发中的三个重点

在工程实践中，我认为有三个特别需要注意重要的点，这三点可以极大程度的改善项目现状，提高效率，并使得产品的高质量交付成为可能，它们分别是：

1. 自动化（自动化一切）
2. 质量内嵌（defect的数量，是否真正满足了需求）
3. 代码本身的质量（可读性，可维护性，可扩展性）

自动化包括，自动provision，自动部署，自动化测试，自动打包等等。这是提高团队开发效率的必要工具。比如书中提到的grunt/gulp脚本，jasmine/rspec/capybara测试，部署脚本，vagrant/Chef等，都是关于如何将日常开发中的任务尽可能的自动化。

软件没有Bug当然是所有人都追求的，我们有很多中方式来保证代码质量。而在编写产品代码的同时，写大量的自动化测试，是投入产出比最高的一种了。通过单元测试，集成测试，以及一些有限但是关键的UI测试，我们可以覆盖很多的需求，而将这些测试自动化起来之后，可以节省大量的开发/测试成本，并减少回归测试的代价。

要支撑快速的发布，我们需要一系列的技术实践。这些技术包括环境的搭建，框架的使用，代码的编写，产品的发布；而且包括后台的数据库设计，业务代码，同样还有前端的展现等。

03

何为轻量级？

在《轻量级Web应用开发》中，我介绍了一系列的实践/工具，这些实践/工具贯穿整个软件开发的生命周期，使得敏捷开发/精益的开发方式变得可以“落地”。比如如何使用轻量级的开发框架来搭建API原型，如何将应用发布在免费的云平台上，如何通过虚拟化技术快速搭建开发环境，从而节省环境配置的投入，如何快速平滑的发布，如何使用测试先行的方式来保证代码质量，如何做高效的自动化UI测试等等。

• 轻量级Web框架
• 前端开发流程
• 构建工具
• 环境自动化（开发环境的搭建，CI服务器的搭建）
• 自动化部署
• UI测试
• 实例驱动（书中有很多的实例，也有很多从项目中总结出来的实践）

这是一本主要关注开发实践的书，书中通过很多实际的例子来帮助读者建立一套完整，高效，轻量级的开发方式，这些方式可以直接在你的下一个项目中使用。甚至如果项目的技术栈变成了另外一种语言，你也可以迅速找到同类的替代品。比如rake之于gradle，sinatra至于spring-mvc等等。

每个组件都是可以替换掉的，比如ORM，如果你觉得DataMapper无法满足实际需要，那么可以换成ActiveRecord。如果Rails太重，使用Sinatra或者Grape或许是一个更好的选择。AngularJS包含了太多东西，Backbone.js或许适合你的场景，而也未尝不可以用Riot.js来替换掉Backbone中的view层。

在本地，可以将应用部署到一个vagrant+chef来provision的环境中，而通过部署自动化，这个动作可以很容易的在AWS的云上实现。轻量级的开发方式，帮助你用最小的代价来替换系统中的任意一个组件，因为每个组件在一开始都是按照可替换原则选用的。

另一方面，轻量级的另一个意思是：现发布静态的版本，然后再将内容替换为动态版本。发布一个静态的页面非常容易，具体细节可以参考这篇文章。当需要动态内容是，免费版的Heroku是一个触手可得的选择，AWS则是一个更加专业的选择（各种服务都配置完善，你只需要关注自己的应用部署即可）。
</div>