web应用的规划

第一次翻译，也有许多没弄明白，谅解。

原文http://railsapps.github.io/rails-product-planning.html

软件开发过程

有些人认为软件开发是从写代码开始的。但是事实上，产品的规划是软件开发过程的第一阶段。

产品规划，是实行从概念到编码的核心，是使项目顺利开工的关键。可以说，你自己开发的简单

应用，你不需要顾虑很多，也不需要写说明书，只需要写写代码。但是，尽管你的应用看起来很

简单，如果你是单独经营的，产品规划也是很有用的。软件项目有一个趋势,就是越来越复杂，并

且花费的时间超过预期的。至少至少，在你开始写代码之前，产品规划可以帮助你专注于你的想

法。如果应用变的复杂了，产品规划会帮助你跟踪进度和确定方向。

而对于大的项目，当你是该项目团队的一员时，或者说其他人的时间和金钱处在危险之中时，产品

规划是一个健壮的软件开发过程的关键因素。如果你打算让公司成长发展，产品规划是最基础的。

花费多少时间在产品规划上由你决定，但是，请考虑做到以下几点：

* 它能帮助你知道需要实施的功能

* 它能帮助你给商业合作伙伴描述和论述产品特征

* 它具有一份清单，让你知道要做什么，还能帮助你跟踪进度

* 它是接受度测试或集成测试的基础

产品拥有者（product owner）

一个应用中包含哪些特征和功能是由谁来决定的呢？如果你是项目的发起者或者说你在开发你自己

的项目，显而易见，你来决定你的应用要做什么，你是产品拥有者。但是考虑一下其他情况，比如

一个学生被分派了一项作业，一个顾问负责规划筹建客户的项目，或公司的一个开发团队。有人给

你一个开发一个应用的任务，一个是项目的目标比较高，另一个是项目的特征和功能的执行细节都

处在灰色地带，你夹在其中。典型地，一个客户或执行管理不会给你提供一个详细的产品要求的说

明书。此时，很多开发者只是想知道开发什么。此种情况下，产品拥有者是空白的，未知的。

产品拥有者可以是一个技术专家，或是一个商业人士。他的责任是审视这个应用，了解用户的观点，

决定哪些特征和功能是必不可少的，哪些又是必须去除的。没有产品拥有者的话，一个项目可能会

在模棱两可中崩溃，会在个人突发奇想中偏移，最终不能使任何人满意。

用户的故事（User Stories）

产品拥有者做产品规划最主要还是要了解用户。

用户的故事是一种方法，用来讨论和描述软件应用的要求。这个写用户的故事的过程将会帮助你确定

应用程序需要的所有特征。把应用程序的功能分解成单个的用户故事，能够帮助你组织你的工作并跟

踪进度，走向终点。

用户的故事常常被表达成如下格式：

作为<角色>

我想要<什么>

结果是<什么>

示例，下面是应用程序预登陆的用户故事

*索取邀请*

作为网站的访问者

我想要一个邀请

结果是网站推出后，我及时得到通知

*看到所有索取*

作为网站的拥有者

我想要看到所有来索取邀请的访问者清单

结果是我可以知道我提供的服务是否很受欢迎

*发送邀请*

作为网站的拥有者

我想要给那些来索取邀请的访问者发送邀请

结果是访问者可以通过邀请尝试访问网站

*收集邮箱地址*

作为网站的拥有者

我想要收集邮箱地址列出投邮清单

结果是我可以在网站推出前发送公告

*注册后在社交网络分享*

作为一个用户

我想要在我注册之后，分享到社交网络

结果是我的粉丝将会了解这个网站

我们在运行应用时可以将这用户故事清单作为我们的任务清单

行为驱动开发（Behavior-Driven Development）

行为驱动开发是一种软件开发方法，它以用户的故事作为自动测试的基础。用户的故事演变成测试的场景，

有了自动测试，产品拥有者能够确定开发者是否把需求的特征和功能做好了。这个过程叫做接受度测试。

自动测试也使开发者很容易确定在添加了新的特征、修复bug或重写代码后应用程序是否依然正常工作。

这个过程叫做集成测试。

下面是运用Cucumber行为驱动开发怎么样把用户的故事作为基础的方法

*写用户的故事

*用户的故事变为Cucumber的场景

*依据Cucumber的场景创建接受度测试。

*对每个特征进行编码

*每个特征编码完成后进行接受度测试

Cucumber场景把用户的故事转变为实施产品特征的一系列的步骤的单纯的描述。

当一个团队里有非程序员，而他又参与产品需求的定义时，或当需要一份说明书和接受度测试使应用的实现

保持独立时，Cucumber是很合适的。

不用Cucumber下的行为驱动开发

（Behavior-Driven Development Without Cucumber）

也有Cucumber的可替代品，它们在项目更小或团队中人想舒适地阅读软件代码时也许更合适。

许多rails开发者运用Capybara in combination with RSpec创建集成测试，这个在Ryan Bates’s How I Test Railscast

中都有描述。运用RSpec and Capybara的方案用户的故事仍然能够成为产品规划的基础。不用Cucumber，运用

RSpec and Capybara，应用程序的特征仍然能够被测试，而特征仍是基于用户的故事的。

线框图和模型（Wireframes and Mockups）

用户的故事不是规划一个web应用的唯一技术。常常在写用户的故事之前，产品拥有者会为各种页面画草图，

画草图是你将对应用的一些想法可视化的一个阶段。画草图最后成为线框图或模型，这两个说法常常可以互

换使用，但是在意义上有所不同。

一个线框图能够展现网页上的功能元素，它不应该描述提出了的网站的图形设计，而应只是网页的简单示意

图，没有颜色，没有图形。

模型给线框图增加了图形设计，包括商标、颜色、占位符内容。模型给出一个网站个性以及提出了的功能的

印象。建线框图最流行的工具之一是Balsamiq Mockups。

平面设计（Graphic Design）

根据需要，平面设计是和应用程序开发分开的一部分。很少的人是平面设计者，同时又是程序员。平面设计

所用的工具不同，平面设计者典型地会使用Adobe Photoshop，尽管有些精通网页的设计者会直接用html

和css做设计。

如果你幸运，你开发应用的时候从平面设计者那里获得了帮助。如果你非常幸运，你也许会和一个懂用户体

验及交互的设计师合作。

如果你和一个平面设计者一起工作，你也许要合作，通过样板或简要设计来定义你的应用程序的外观及给人

的感觉。如果设计者用photoshop工作，你将面临挑战将设计框架从photoshop转换为HTML和CSS。有这

样的服务公司收取费用做这个，但是很明显如果和一个直接用html和css做设计的设计师合作更容易。

当需要整合平面设计和代码的时候，rails特别具有挑战性。rails用在view文件中混合了html标签和ruby程序

代码。很少有设计者适应在html中混杂者ruby代码，那么只能靠你你自己来整合它们了。

如果你没有一个平面设计师的帮助，你可以用Twitter Bootstrap或其他的前端框架例如Zurb Foundation在你

的应用中快速地添加吸引人的设计。