敏捷方法和实现（三）

尽可能的收集需求

为了本书需要，你将要和一个需要做建设的电子商务网站的假设顾客工作。下面是在你同意去接见顾客时所知道的确切信息。顾客的名字叫Claudia，她经营一个致力于儿童用品的零售商店。她现在紧紧拥有一个简单的网页，命名为店名（Claudia的孩子），还有一些简单的联系信息。没有更多好的信息供你参考，因为这不像使用预测方法那样，你需要适应顾客的需求。

第一天

当你遇见Claudia时，她看上去是一个有活力的三十多岁的人，正是这个人四年前创办了这家零售商店。这家商店的筹建款是由信用卡、从高薪职位离职后的佣金、亲朋好友的借款中组成的。大概整整用了两年的时间，她才拿到客观的收益，但是通过迎合特殊市场（哪些可以花费任何东西去购买儿童玩具和衣物的妈妈们），Claudia获得了成功。

Claudia十分确信，现在是做扩张的时候了。商店的惊人增长并没有花费很长的时间，但是现在还没有足够的钱来创建另一家实体店。同时她对邮件列表相关的花费也是很不满意。这正是你和Codeigniter现身的时候。虽然她并不知道如何去架设一个电子商务网站，但是她知道一个交易型的网站是她成功的关键——她可以利用一个正确的网站来扩大她的用户群体并且能带来比实体店经营和电话预定更多的收入。

在你一边听一边做记录，大部分是高级的名词和动词。你已经知道一些信息，例如，你需要一些在线商品列表，但是并不确定每件都标明价格、图片、名称，还有某种唯一性标示。此外，他们很可能被组织到某种分类列表中，例如玩具或者衣物。但是这就是你现在所知道的一切。你也知道，这必将涉及消费者，但是你不确定她是否想跟踪每一位消费者的消费情况。

所以现在你可以开始了。现在有的仅仅是解决问题的多个措施。鉴于你在创建此类工程的经验，你应该知道怎样去知道当前的讨论，这应该是没问题的，因为现在讨论的正是Claudia所需要的。她在经营和市场方面是专家，而你是代码方面的专家。通过这点就能建立合作伙伴关系。她最终将成为商品主，提供给你这个开发者对任务的关键描述。

你可以从任何地方开始，真的，但是过去的经验告诉你不要从询问底层问题开始。换句话说，试图去剖析某个产品的每个细节或者分类直接的相互影响只会使Claudia十分困惑。相反，你应该在一张纸上画一个大矩形，并且表示他为“主页”。

你一边说，一边在大矩形的顶部附近画一个水平的小矩形。你解释说这就是你的网店的logo和主导航栏将要显示的地方，通过这里可以跳转到联系我们、关于我们和一些可能的特殊的界面。在大矩形的底部，你画另外一个小矩形，并且解释说，这是网站的底部，在这里将包含版权声明、隐私策略和其他一些细节。

目前为止，你已经画出了类似图2-1的图形：

图2-1

现在，你需要明确什么将要在中间显示。你可以建议显示一些突出的元素或者一些关注点或者可视化的娱乐信息，但是网页也需要用户能快速便捷的导航到网站中的任何一点。

是的，Claudia说，显示突出元素是个好主意，可以是一些能够保持一个星期或者更长，一些她能够控制的而不是随机的。她想要元素的一幅图片，元素的名称，一段简短的说明，还有显示详细信息的超链接。你建议说在首页的右边同时显示一个“现在购买”的按钮会更好些，她同意了。Claudia同时认为在突出元素区域的右侧显示其他元素的随机列表，可以是每个大分类中的某件产品。列表中的每个元素都会标记一个缩微图，产品的名称，显示详细信息的超链接。同样，你也要添加一个“现在购买”的按钮。

现在你所画的首页将是图2-2显示的样子：

图2-2

提到分类，你决定在突出元素的左边放置一个垂直的长方形，告诉她，“在这里我们将列出你商店里的所有分类。让我们花费些时间讨论一下这个地方”。

Claudia点头告诉你说在她现存的库存中，她有五至六种主要商品的分类，每个分类还有他们各自的子分类。目前为止，她的商店中商品分类仅仅有两个层次，于是你知道你需要创建一个分类的层次树和一个两层的导航栏供用户点击，如图2-3所示：

图2-3

你们两个共同看一下这张草图，认为你的设计是相当棒的。你已经在这上面花费了一个小时，但是你没有立即停止，而是决定趁热打铁来创建其他两幅草图：一个是分类的视图一个是详细信息的视图。

Claudia询问关于“现在够买”的网页和购物车的实现。你告诉她这个这个网页可以在明天画出来。毕竟，你需要一些时间来消化你从这次会谈中知道的每件事情。

你决定在分类视图中重用那个基础的矩形。你解释说这是一个分类的视图，用来显示产品的列表，也可以包含其他的分类。例如，如果你有一个衣服的分类，它可能包含一些与衬衫、裤子、裙子、鞋子等相关的子分类。

一个主分类可能和子分类一样拥有一些自己的产品，但在这点上，Claudia不同意，她想让零售的能够显示出层次感。在商店的库存清单中，你永远不会看到某些产品属于一个像衣服一样的高级别的分类。你记下来，只有子分类才能有产品和它们关联。

我们得到了一个简单明了的视图，将和主分类关联的子分类显示或者显示每个子分类的相关联的产品。第一种形式的视图将按字母顺序列出所有的子分类，并且显示子分类的名称、简介和链接到这个分类的产品视图的超链接。

当你问及是否允许主分类或者自分类从在线商店中移动或者删除时，Claudia努力思考了好久，最终同意了。所以现在你知道，你需要跟踪一种状态（活动或者未活动），并且只显示处于活动状态的分类。

接着，你询问在每个分类名字和简介的旁边是否显示某种形式的图片。思考片刻后，Claudia问可不可使用一张和子分类相关联的随机的一个产品的图片。你告诉她，当然可以，但是正好有一个另外的问题出现在你的脑海中，有没有可能一件产品不止出现一个分类中呢？

对此Claudia甚至没有考虑多长时间。她摇了一下头，不会，她说她将商店里的产品保持得很有秩序，她想在网店中也是这样。到现在，你画出了分类的视图（大分类和子分类），如图2-4和图2-5所示：

图2-4

图2-5

在你工作的进行中，你留意到其实这两个草图其实并没有多大区别。所有你应该做的就是检查一下分类的层次，已决定你是要显示产品呢还是子分类。

在Claudia重温了一下这些草图，她提出如果每个产品都提供关联元素会更好。你把这个作为你要开始创建的产品详情网页草图的线索。同样，你使用简写的矩形来帮助你创建首页，但是这次你提供一个空白来显示产品图片的大图、图片名称、更长的描述，还有一个“现在购买”的按钮。

“它并不这么简单”，Claudia对你的草图说，“我们需要提供其他的信息，比如颜色和型号。并且我想在旁边显示关联元素。”

“您所说的关联元素是什么意思？”

“是这样，如果你在查看衬衫时，显示一些裤子或者鞋子会更好些。”她说。

当你问及这是否是随机选择的是，她的回答是否定的，她想像自己的商店里一样构建每个网页。在她的商店中，她都会把全套服装放在一起，因为这么做会促进销售。

“我们就这么做了”，你说，感觉应该稍微停下来记一下笔记。“我们将做一个关联元素的侧栏，但是听上去我们需要找到一个方法，以便在不依靠分类的情况下将产品分组。类似于分组号或者其他的一些东西。所有拥有共同分组号的放在一起。”

她点头同意你所说的。由于有其他的事情去做，所以她急于暂停一会儿。她看着产品详情网页的草图（在图2-6中显示）表达了目前为止对现在的进程很满意。

 

图2-6

“这看上去比我记忆中的高端技术要轻松和可视化的多”，她说，“目前为止你还没有问任何恐怖的问题，仅仅是一些我知道的十分明确的东西，像我所做的生意一样。”

你感谢Claudia的接待，并且约定了第二天的见面时间，来讨论一下“现在购买”网页并且在你的指引下布置一些区域。

消化一下你所了解到的东西

祝贺，你已经完成了整个任务。不仅创建了四个草图（首页、分类视图、子分类视图和产品详情视图），但是你同时得到了大量管业分类和产品的信息。

下面是你所了解到的关于分类的信息：

❑ 分类是有层次的，但是限制在两层。

❑  分类可以是激活和未激活的。

❑ 分类拥有名称、简短说明和完整说明

❑ 分类的图片从与他们关联的产品中取得。

然后是你所了解的产品的信息:

❑ 一个产品只能属于一个分类。

❑ 产品有名称、大图片、缩微图、简短说明、完整说明和其他可能的数据参数，比如型号和颜色。

❑ 一件产品可以通过组或者套装和其他的产品相关联。

❑ 虽然没有提及，但是可以明确的推断出产品也可以是处在活动和未活动的状态。

❑ 虽然没有说明，但是可以推测一些是必要的，那就是每件产品都要有以十进制表示的价格。

将你所知道的分类的信息转化为在MYSQL中建表的查询语句，你将得到类似于下面的信息：

   1: CREATE TABLE ‘categories’ (

   2:  

   3: ‘id’ INT NOT NULL AUTO_INCREMENT ,

   4:  

   5: ‘name’ VARCHAR( 255 ) NOT NULL ,

   6:  

   7: ‘shortdesc’ VARCHAR( 255 ) NOT NULL ,

   8:  

   9: ‘longdesc’ TEXT NOT NULL ,

  10:  

  11: ‘status’ ENUM( ‘active’, ‘inactive’ ) NOT NULL ,

  12:  

  13: ‘parentid’ INT NOT NULL ,

  14:  

  15: PRIMARY KEY ( ‘id’ )

  16:  

  17: ) TYPE = MYISAM ; 

  18:  

同样，将你所知道的产品信息转化MySQL的查询语句，你将以下面这段内容结束：

   1: CREATE TABLE ‘products’ (

   2:  

   3: ‘id’ INT NOT NULL AUTO_INCREMENT ,

   4:  

   5: ‘name’ VARCHAR( 255 ) NOT NULL ,

   6:  

   7: ‘shortdesc’ VARCHAR( 255 ) NOT NULL ,

   8:  

   9: ‘longdesc’ TEXT NOT NULL ,

  10:  

  11: ‘thumbnail’ VARCHAR( 255 ) NOT NULL ,

  12:  

  13: ‘image’ VARCHAR( 255 ) NOT NULL ,

  14:  

  15: ‘sizes’ ENUM( ‘s’, ‘m’, ‘l’, ‘xl’ ) NOT NULL ,

  16:  

  17: ‘colors’ ENUM( ‘red’, ‘blue’, ‘green’, ‘brown’, ‘white’, ‘black’ ) NOT NULL ,

  18:  

  19: ‘grouping’ VARCHAR( 16 ) NOT NULL ,

  20:  

  21: ‘status’ ENUM( ‘active’, ‘inactive’ ) NOT NULL ,

  22:  

  23: ‘category_id’ INT NOT NULL ,

  24:  

  25: ‘featured’ ENUM (‘true’, ‘false’) NOT NULL,

  26:  

  27: ‘price’ FLOAT( 4, 2 ) NOT NULL,

  28:  

  29: PRIMARY KEY ( ‘id’ )

  30:  

  31: ) TYPE = MYISAM ; 

  32:  

在这里，对于colors和sizes字段使用enum类型稍微有些不合适，因为不同类别（一个是鞋子，一个是衬衫，一个是裤子）的型号可以是任何数字并且有许多不同的颜色分类。但是现在来说，给出的这些就够用了。

当然，画草图并且构思MySQL数据表是个好主意，但是在你和Claudia下次见面之前，你需要画一幅产品的备忘录草图。这个备忘录草图将会把所有你所希望看到的电子商务网站的特性列举出来。

记住下面的论述，你（在电子商务网站中）所构建的商品和真实商店中的商品（鞋子、衣服，等）有根本的区别。只要你划清楚这两个概念，你将会做的更好。

看过你的笔记和草图后，你在一些成功经验（story）的基础上创建了一个初步的产品备忘录草图。一个成功的经验通常遵循这样的准则，“做了X，我想做Y，于是我能做Z”。下面是一些你能够使用在产品备忘录草图中的经验——请记住虽然店主也能够做这些，但是如果你做出范例的话会使工作进行的更快。

1. 作为用户，我能够浏览在首页中的重点突出产品，并能购买它。

2. 作为用户，我能够浏览其他相关联的产品并能购买他们。

3. 作为用户，我能够浏览分类列表并能导航到网站的这部分分类。

4. 作为用户，我能够被导航到商品详情网页并能购买商品。

5. 作为用户，我能够在商品详情网页中查看相关联产品，以便于完成配套或者购买搭配商品。

6. 作为用户，我能够在想了解产品的外貌时，可以查看产品的缩微图和大图。

这些现在就足够了。明天，你将会见Claudia让她来浏览你的产品备忘录草图。

原文

Gather Your Requirements While You May

For the purposes of this book, you are working with a hypothetical customer who wants to build an

eCommerce site. That’s really all you know when you agree to meet with the customer. The customer ’s

name is Claudia, and she runs a thriving retail store devoted to “all things kids.” She only has a very

basic web presence that gives the name of the store (Claudia’ s Kids ) and some basic contact information.

This is not a lot to go on, which is OK, because, unlike when using predictive methodologies, you want

to adapt to the customer ’s needs.

The First Day

When you meet Claudia, she turns out to be an energetic 30-something who started her retail store 4

years before. The store was funded in part with credit cards, the severance from the high-tech job she

was laid off from, and a loan from various friends and family. It took almost 2 years for her to claw out a

decent profit in the store, but by catering to a specific market (moms who would pay anything to

provide their kids with branded clothes and toys), Claudia has made a success of it.

Claudia’s pretty sure it’s time to expand. It didn’t take long for her phenomenal growth to flatten out,

but there isn’t enough money coming in to expand to a second brick-and-mortar store. Nor does she feel

comfortable with the costs associated with a mail order catalog. This is where you and CodeIgniter come

in. Although she has no idea how to code an eCommerce site, she knows that a transactional site is the

key to her success — she could, with the right site, expand her customer base and bring in lots of revenue

beyond what comes in from walk-ins and the occasional long-time customer who phones in an order.

As you listen, you’re taking notes, mostly about high-level nouns and verbs. You know already, for

example, that you will need some kind of online catalog of products. You don’t know what pieces of

information you will need to track for each product, but you can be sure that each will have a price, a

photo, a name, and some kind of unique identifier. Furthermore, they’ll probably be organized into some

kind of category scheme, such as toys or clothes. But that’s all you know right now. You also know that

there are customers involved, but you don’t know if she wants to track each unique customer.

So now you have a place to start. There are only so many ways to attack the problem. With your previous

experience building these kinds of systems, you know how to guide the discussion, which is fine, because

that’s what Claudia wants. She’s the expert on her business and marketplace, and you’re the expert coder.

From here forward it’s a partnership. She will eventually become the product owner in the process, the

person who provides you, the developer, with the kind of necessary input to delineate tasks.

You can start anywhere, really, but you’ve learned from past experience not to start by asking bottom-up

questions. In other words, trying to dissect every single possible field for a product or how categories

interact would just confuse Claudia. Instead, you draw a big rectangle on a sheet of paper and label it

“home page.”

You tell Claudia that the best way to start is with a prototype mockup. That way the two of you can start

figuring out the major components of each page and from there fill in the look and feel and other details.

As you talk, you draw a smaller horizontal rectangle near the top of the big rectangle. You explain that

this is where the store’s logo and main navigation will go — pages like Contact Us, About Us, and

perhaps special features or deals. At the bottom of the big rectangle, you draw another smaller rectangle,

and explain that this is the site’s footer, which will contain a copyright notice, a link to the privacy

policy, and other minutiae.

So far, what you’ve drawn looks a lot like Figure 2-1.

Figure 2-1

Now, you need to know what goes in the middle. You suggest some kind of featured item or point of

focus or visual interest, but the page also needs to allow users to navigate quickly and easily to any point

in the site.

Yes, Claudia says that a featured item is a good idea, perhaps something that could stay up for a week or

so, something that she could control instead of something random. She wants a photo of the item, the

item’s name, a short description, and a link to some kind of detail page. You suggest that it might be

good to have a “buy now” button as well, right on the home page, and she agrees. Claudia also thinks

that something off to the right of the main feature might be a random list of other items, maybe one

product from each major category. Each item in the list would feature a small thumbnail, a product

name, and a link to a detail page. Again, you fill in a “buy now” link as well.

Your home page drawing now looks like Figure 2-2.

Figure 2-2

Speaking of categories, you decide to put a long vertical rectangle to the left of the main featured item,

telling her, “This is where we’ll list all the categories in your store. Let’s talk about those for a bit.”

Claudia nods and tells you that in her existing inventory, she has five or six major categories of products,

each with their own subcategories. So far, her store only has two levels of categories, so you know that

you will need to build a hierarchical category tree and a two-level navigation depending on what the

user clicks on, as illustrated in Figure 2-3.

 

Figure 2-3

You both look at this mockup and decide that what you have is pretty good. You’ve been at it for about

an hour, but instead of quitting just yet, you decide to push ahead to create two other page mockups: one

for the Category view and one for the Detail view.

 

Claudia asks about the “buy now” page and the actual Shopping Cart. You tell her that this page can be

mocked up tomorrow. After all, you need some time to assimilate everything you’re learning from this

meeting.

You decide to reuse your basic rectangle for your Category view. You explain that this is a generic view

that shows any list of products and/or other categories. For example, if you had a clothing category, it

might have certain subcategories associated with it: shirts, pants, skirts, and shoes.

A main category might even have individual products associated with it as well as subcategories, but at

this point Claudia says, “no”, that she wants to mirror the retail environment to some degree. In the

store’s inventory system, you would never see individual products associated with a high-level category

like clothes. You make a note that only subcategories can have products associated with them.

The result is a fairly simple Category view, featuring all the subcategories associated with a main

category or the products associated with a particular subcategory. The first type of view would list all

subcategories alphabetically, with subcategory name, description, and a link to view products within

that category.

When you ask if it’s possible to have categories or subcategories removed or deleted from the online store,

Claudia thinks long and hard and finally agrees to allow it. So now you know that you need to track some

kind of status (active or inactive, live or in progress) and only show the ones that are active or live.

Next you ask if you should show some kind of image next to each category name and description. After

some thinking, Claudia asks if it’s possible to pull a random image from a product associated with a

subcategory and use that. You tell her that, of course, it’s possible, but something else just occurred to

you: Is it possible for a product to be in more than one category at a time?

Claudia doesn’t even have to think very long about it. She shakes her head, no, and says that she keeps

things very organized in her store and intends to do the same online. So far, your diagrams for the

category views (category and subcategory) look like Figure 2-4 and Figure 2-5.

 

Figure 2-4

 

Figure 2-5

As you work, you take note that there really isn’t that much of a difference between the two mockups.

All you have to do is check to see where you are in the category hierarchy to show products or

subcategories.

As Claudia reviews these mockups, she mentions that it would be nice to offer related items for any

product. You take this as your cue to start the process of creating a mockup for the Product Detail page.

Again, you use the shorthand rectangles that helped you create the home page, but this time you provide

space for a large product image, image name, longer description, and a “buy now” button.

“It’s not that simple,” Claudia says, reacting to your mockup. “We also need to provide other

information, such as colors and sizes. And I’d like to show related items off to the side.”

“What do you mean by related items?”

“Well, if they’re looking at a shirt, it would be nice to show some pants or shoes,” she says.

When you ask if these would be random selections, she says, “no”, that she would like to construct each

page like she does her store. In the store, she will routinely put together outfits, as doing it this way

increases her sales.

“Let’s do this,” you say, feeling a need to go away for a while to take better notes. “We’ll do a related

items sidebar, but it sounds like we need to figure out a way to group things together that doesn’t

involve categories. Something like a group number or something. Everything with the same group

number stays together.”

She nods and understands where you are going. She has other things to do, so she is also anxious to step

away for a while. As she looks at the mockup for the Product Detail page (shown in Figure 2-6), she

mentions how happy she is with the process so far.

Figure 2-6

“This is a lot more relaxed and visual than I remember from my high-tech days,” she says. “So far you

haven’t asked any scary questions, just about stuff that I know really well, like my business.”

You thank Claudia for her time and set an appointment for the next day, in which you’ll talk about a

“buy now” page and fill in some other holes in your knowledge.

Assimilating What You’ve Learned

Congratulations, you’ve done a whole lot of work. Not only have you created four mockup pages (home

page, category view, subcategory view, and Product Detail view), but you’ve also absorbed a great deal

of information about categories and products.

Here’s what you know about categories:

❑ Categories are hierarchical, but limited to two levels.

❑ Categories can be active or inactive.

❑ Categories have a name, a short description, and a long description.

❑ Images for categories are derived from the products assigned to them.

And this is what you know about products:

❑ A product can only belong to one category at a time.

❑ A product has a name, a large image, a thumbnail, a short description, a long description, and other possible metadata, such as sizes and colors.

❑ A product can be associated with other products to form groups or outfits.

 

Although not mentioned yet, one could correctly deduce that products can be active or inactive.

Something else not mentioned, but presumably a requirement, is that every product has a price

expressed as a decimal number.

Converting what you know about categories into a query that would create a table in MySQL, you

would have something like this:

   1: CREATE TABLE ‘categories’ (

   2:  

   3: ‘id’ INT NOT NULL AUTO_INCREMENT ,

   4:  

   5: ‘name’ VARCHAR( 255 ) NOT NULL ,

   6:  

   7: ‘shortdesc’ VARCHAR( 255 ) NOT NULL ,

   8:  

   9: ‘longdesc’ TEXT NOT NULL ,

  10:  

  11: ‘status’ ENUM( ‘active’, ‘inactive’ ) NOT NULL ,

  12:  

  13: ‘parentid’ INT NOT NULL ,

  14:  

  15: PRIMARY KEY ( ‘id’ )

  16:  

  17: ) TYPE = MYISAM ; 

  18:  

Similarly, converting what you know about products into a MySQL query, you would end up with the

following:

   1: CREATE TABLE ‘products’ (

   2:  

   3: ‘id’ INT NOT NULL AUTO_INCREMENT ,

   4:  

   5: ‘name’ VARCHAR( 255 ) NOT NULL ,

   6:  

   7: ‘shortdesc’ VARCHAR( 255 ) NOT NULL ,

   8:  

   9: ‘longdesc’ TEXT NOT NULL ,

  10:  

  11: ‘thumbnail’ VARCHAR( 255 ) NOT NULL ,

  12:  

  13: ‘image’ VARCHAR( 255 ) NOT NULL ,

  14:  

  15: ‘sizes’ ENUM( ‘s’, ‘m’, ‘l’, ‘xl’ ) NOT NULL ,

  16:  

  17: ‘colors’ ENUM( ‘red’, ‘blue’, ‘green’, ‘brown’, ‘white’, ‘black’ ) NOT NULL ,

  18:  

  19: ‘grouping’ VARCHAR( 16 ) NOT NULL ,

  20:  

  21: ‘status’ ENUM( ‘active’, ‘inactive’ ) NOT NULL ,

  22:  

  23: ‘category_id’ INT NOT NULL ,

  24:  

  25: ‘featured’ ENUM (‘true’, ‘false’) NOT NULL,

  26:  

  27: ‘price’ FLOAT( 4, 2 ) NOT NULL,

  28:  

  29: PRIMARY KEY ( ‘id’ )

  30:  

  31: ) TYPE = MYISAM ; 

  32:  

At this point, using an enum for colors and sizes is a bit iffy, as there may be any number of size

classifications (one for shoes, one for shirts, one for pants) and many different available color classes. But

for right now, this will do.

Of course, having mockups and some idea of what your MySQL tables look like is a good thing, but

before your next meeting with Claudia, you need to draw up a product backlog. The product backlog

will serve as a list of all the features you want to have in the resulting eCommerce web site.

Remember in the following discussion that there is a fundamental difference between the product you

are building (the eCommerce site) and the products in the actual store (shoes, clothes, etc.). As long as

you keep the two concepts straight, you’ll do fine.

Looking over your notes and mockups, you develop an initial product backlog based on successful

stories. A good story usually follows the pattern “As an X, I want to do Y, so I can do Z.” Here are a

few stories you can put in the product backlog — and please note that normally the product owner

would do this, but at this point it’s faster for you to set a precedent:

1. As a user, I want to view a featured product on the home page so I can buy it.

2. As a user, I want to view other related products on the home page so I can buy them.

3. As a user, I want to view a list of categories so I can navigate to those parts of the site.

4. As a user, I want to be able to navigate to Product Detail pages so I can buy products.

5. As a user, I want to see related products on a Product Detail page so I can complete outfits or

buy accessories.

6. As a user, I want to be able to see product thumbnails and images as often as possible to get an

idea of what the products look like.

This is enough for now. Tomorrow, you’ll meet with Claudia and she’ll take over the product backlog.