敏捷方法和实现（四）

第二天

当你第二天见到Claudia时，她看上去十分期待。你问她出了什么问题，她也正好从问题说起。

“是这样，对于这个网站，我考虑了好久，发现我们遗漏了很重要的一点。首先，我希望网站的用户能够搜索产品。同时，我认为他们应改能够通过某种方式来结账。我同样注意到我们没有设计出给购物车添加商品的进程。”

“好的。让我们赶紧解决一下这些问题并且更新一下我的草图。然后我们将更新一下我昨天晚上画的产品的备忘录草图。现在先从这张图开始吧，好吗？”

现在，你忙碌起来，并且询问关于搜索的问题。可不可以给搜索页加个超链接，或者在每个网页上显示一个搜索条？Claudia最终认为在每个网页显示一个搜索条会更好些。

搜索主要是操作什么呢？换句话说在数据库中的哪些字段可以被搜索呢？Claudia想了一会儿决定搜索条件设置为分类名称和产品名称。你补充说搜索简介也并不是一件困难的事情。在Claudia思考的同时，你更新了主页的草图，它现在看上去像图2-7.你给Claudia展示新绘的草图，并且告诉她每个网页的头部将会显示搜索条。

图2-7

可访问性和易用性（Accessibility and Usability）

在现在网站的开发中有两个重要的话题，就是可访问性和易用性。首先，易用性（usability），是说尽可能把网站做的简单易用——并不仅仅是对于开发者来说，更是对系统的真实使用者来说也是如此。这就意味着给按钮添加适当的标签并且超链接的语言组织上要求用户能够明白。

这同样意味着在每个页面上放置一致风格的导航栏，并且在用户期望的地方放置搜索关键字（search features）（并且产生易于理解的搜索结果）。

可访问性是说竭尽全力保证在使用你的网站时能够提供给用户可视化的、可听的、可以认知的、可以在允许范围内出错的（motor-reflex impairments）系统。例如，给图片添加alt标签，使用ul制作导航栏，使用css/div而不是表格来布局，给表单添加标签(labels)。想象一下试图构建这样一个网站，当显示关闭时，仅仅用屏幕阅读器（screen reader）来指导你使用音频设备——网站自身开发的音频设备。

易用性和可访问性是两个重大的话题，但是学的越多，应用的越多，就越有助你成为一个web开发的好手。提供两个重要的信息资源：www.useit.com（Jakob Nielsen的易用性学习网站）和www.knowbility.org（一个澳洲的非盈利性可用性咨询组织）。

既然您刚才提出来了，现在创建一个搜索结果（Search Results）的网页是再简单不过了。你询问她希望查询结果怎样显示，可不可以像分类视图一样对于每个出现的产品，显示名称、图片和简短说明？

“是的”，Claudia说，“但是一定要清晰的显示你现在是显示一个产品还是一个分类。”

你制作了分类的草图并且迅速把它作为模型运用到搜索结果的草图中，因为它看上去非常类似分类视图。你给她看了一下显示的效果，如2-8所示：

图2-8

“现在看上去不错”，Claudia说，“可能我们应该首先把分类列举出来，仅仅列举出标题，缩微图和说明都不需要。”她又想了一会儿，摇了一下头。“还是把这个放一放吧。我们能不能处理下‘现在购买’和结账的部分？”

“我认为当他们点击了某个产品的‘现在购买’的超链接时，网站的后台程序能够将信息添加到购物车中。”你说。

“是的，这非常像今天你看到的网站”，Claudia说，“可以在他们添加一件商品到购物车后给一条简便的确认信息。”

“我同样认为我们应该显示一个购物车的图标或者链接以便能够产看购物车的详细信息，”，你继续说，“我们可以把这个链接添加到导航栏，仅仅在购物车中有商品时才显示。”

你没有告诉Claudia，但是你决定使用cookie来跟踪购物车中的条目。你知道CodeIngniter拥有强大的构建、编辑和删除cookie的函数库。所有你需要做的就是跟踪和某件产品相关联的ID和可能的其他选项，例如型号或者颜色。

“如果我们这么做，那么我觉得应该将‘现在购买’的链接换成‘添加到购物车’来最大限度的减少混淆”，Claudia说，然后笑了笑，因为你已经更新了一些草图，包括产品细节，如图2-9所示：

图2-9

你提出说，这个草图能够显示不同的状态，包括他们所谈到的确认信息。（You mention that this mockup shows different states, including the confirmation message they talkedabout.）Claudia立刻明白了这幅草图的象征意义，但是她想看一下购物车网页的草图。

“它需要显示购物车中的每个条目，按照产品来正确的分类，”，她说，“它们需要能够实现从购物车中立即结账。事实上，你可能需要更新一下确认信息来允许人们实现立即结账。”

你笑了一下，因为你根本不能阻止事情的发展——她已经完全进入到这个项目中了，这跟你以前做过的项目有很大的不同。你意识到，在你构建购物车的网页时，你最好还是把价格保存在购物车的session中——这就意味着一个突然的价格变动将不会影响想要结账的使用者。在继续之前你记下来刚才的问题，同时意识到需要对cookie进行加密来增加安全保障。对于这个问题，你进一步询问了Claudia。

“这是正确的，即使在实际操作中，你也需要做到改动价格不要太频繁，有时甚至是在周末或者深夜修改，”，她回答说，“但是同时，当某个人在线的时候我做出了价格更改也是完全有可能的。”

“当某个人把商品放入购物车后要结账时会发生什么？”

“奥，在结账过程中的最后时刻检查一下所有数据，”她说。在你和她谈话的过程中，你已经完成了购物车的粗略草图。如果2-10所示：

图2-10

“在每行条目的后面都有一个X符号以便让用户从他们购物车中将这条记录删除。”你解释说。

Claudia指着这幅草图说，“有一些东西遗漏了。没有重新计算的按钮。你知道，他们可能决定要两件abc类型的衬衫，而不是一件。”

“我们使用AJAX来动态更新总体数目，并不需要做你说的那些”，你的解释看上去令她很满意。你知道这样队来说更简单了，但是需要用户开启JavaScript。你还需要在程序运行中做一些错误验证。但是其他的事情同样困扰着她。

“怎样计算税收和运费呢？一些商品可能要比其他的重。我们不能计算一个统一的比例。”

“我假定你使用贝宝（Paypal）或者Google支付来结算付款，既然这样，让我们把这部分留作后期考虑，这还是比较好整合的。”

Claudia点点头说她对这些草图比较满意。“很好”，你说，现在是和她分享产品备忘录让她成为一个真实网店店主的时候了。既然她知道自己所使用的产品备忘录的意义，现在是开始第一个短周期（sprint）的时候了。

重温一下产品备忘录

你对Claudia解释说产品备忘录是这个项目的讲过优化的需求列表。她是店主，并且像创建、维护产品备忘录并且把它当做集中的命令式的需求类表，通过它们可以取得在任一单独短周期中的所有任务。

每个短周期，是某种形式的时间段（通常是1至4周），在这期间完成规定的任务。其目标就是在每个短周期的末尾都构建出潜在的可以用的软件，所以明白不要在每个短周期中分配过多的时间和其他资源是很重要的。

你进一步解释说你已经列出了六条产品备忘录的需求。

1.作为用户，可以在主页查看重点突出的产品以便于购买。

2.作为用户，可以在主页查看相关联的其他的产品以便于购买。

3.作为用户，可以查看分类列表，以便于导航到相应的分类。

4.作为用户，可以查看产品详细信息网页，以便于购买这件产品。

5.作为用户，可以在产品详细信息网页中看到相关联的产品，以便于完成配套或者购买附件。

6.作为用户，可以查看产品的缩微图和大图以便于立刻就能想象出产品的模样。

“每个需求通常可以解释为这种情况：拥有一个X，我想做Y，所以我能做/实现Z”，在你查看各条需求的时候你解释说。

“看上去我们需要多添加一些条目”，Claudia说，然后添加了需求7和需求8：

7.作为用户，可以快速的搜索到产品。

8.作为用户，可以查看购物车，以便方便的结账。

写完后，他对这些条目想了很长一段时间，然后说：“这里没有提及任何东西是关于管理员——也就是我——我现在要在线管理商店了。我同时在这里没有看到任何关于跟踪顾客信息的地方。同时，我甚至还没有告诉你我关于设置一个在线邮箱来宣传这个网站并且联系顾客的想法。”

“这正是您适合做销售商的原因”，你回应道，“你所应做的一切就是把所有信息写到产品备忘录中，并确定他们的优先级。我的工作就是优先做最重要的条目——列表中的第一条——创建一系列的任务作为每个需求的验收的标准。”

“你是怎样做到这些的？能给我举个例子吗？”

“好的”，你回答说，“我先看一下前两条，它们是处理首页的，然后创建一系列的任务。例如，我需要创建用户浏览网站所能看到的网页。我同样需要创建允许网站和数据库交互的模型。我还需要创建数据库中的数据表本身。我还需要创建所有组织网页中条目的所有函数。”

你对Claudia的惊恐付之一笑，“你对这一些完全不用担心。只需要知道，我已将我们的合作用草图描绘出来，并且制定了产品备忘录，能够创建一些理所当然的任务。同时注意到，对于前两条需求，需要做很多工作，例如创建数据表可以有助于我更快的完成剩余的程序。它们是事半功倍的，至少在不同场合也是可以重新使用的。”

“而且”，你继续说，“接下来我将要说到我将在第一个短周期中处理所有的这些备忘录条目。我对于在为期四周的短周期完成这些条目感觉非常自信，这也就意味着在您的网站建设的第一个迭代周期中，它将像我们在草图中所描述的那样表现完美。”

Claudia点了一下头，“我很自信的认为你知道自己应该做什么。我的工作就是坐下来思考一下所有将要在网站实现的功能，并且将我的想法记录到产品备忘录中，以便你能在完成第一个备忘录后接着从事下面的工作。”

“还有一件事”，你说着抬起了一只手，“这个过程允许你修改自己的想法，但是要尽量避免在每个短周期中有大方向的改变，小方向的修正还是允许的。这就更能使我们的工作做的更快更漂亮。”

你们两个都认为现在是分开工作的时候了。虽然这个团队很小（只有你和Claudia），你还是决定接下来的一天要举行一个例会，因为你需要开始做一些很基础的工作：在开发服务器上安装CodeIngniter并且创建初始化数据库表。这些工作不完成，剩下的活儿就没法干了。

创建短周期备忘录

你已经致力于处理在四周内应该完成的，八条已经存在的产品备忘录。你浏览了一下这些条目，开始创建一个短周期备忘录。

1.在服务器上安装、配置CodeIgniter。

2.创建产品和分类的初始化数据表。

3.创建一个产品模型，包含以下函数，根据分类列出所有产品，对于给出的产品列出详细信息，列出所有同一分组的其他产品。

4.创建一个分类模型，包含以下函数，列出分类树，列出大分类的所有子分类，列出分类的详细信息。产品模型同样包含一个允许你列出某个分类所有产品的函数。

5.对于每一个可视页面，创建一个控制器，包含显示首页、关于我们、联系我们、搜索结果、产品详情、购物车和分类视图的函数。

6.创建一些特殊的控制器函数，用来运行搜索和添加商品到购物车的cookie处理。

7.创建其他的购物车函数，以便来显示购物车的所有信息、用AJAX重新计算总计价格、删除购物车中条目。

8.创建所有需要在网页中显示的视图。这更像是通过引用包含一个主模板来减轻你以后的工作。

这就是你所有你现在需要的详细说明。如果团队扩大了，你可能需要更多的详细说明，但是这份备忘录，结合你的草图和产品备忘录，应该足够保持你步入正轨了。

结论

既然你已经经历了整个过程，你就会明白这个自适应的过程是多么的有价值。在开发过程中你将会发现不管Claudia对于细节方面（比如说首页）改变有多大，但是通过敏捷方法和CodeIgniter工具，调整路线、保持进度、事先预定目标都是很简单的。

在下一章，你将学会怎样在LAMP(Linux-Apache-MySql-PHP)服务器中安装和配置CodeIgniter并且快速浏览一下所有涉及的部分（控制器、模型、视图、配置文件、类库、助手，还有其他内置工具）。

在你继续旅行之前请记住以下几点：

❑ 敏捷方法是自适应的而不是预定的。

❑ 如果你在一个具有固定时间的软件团队中工作，敏捷方法将工作的更好。

❑ 最好按照自顶向下的方式来收集需求并且同顾客一起画出草图。

❑ 尽快由店主（你的顾客）负责管理产品备忘录是很重要的。他们即使有些东西会一时记不起来，但总比你什么也不知道要强。

❑ 作为开发者，你的任务就是把产品备忘录的条目转化为每个短周期备忘录中的功能性的任务。

❑ 同样，你有职责来正确的评估。不要在给定的短周期内完成超负荷的任务。

❑ 不要忘了，许多功能性的任务可能对当前短周期（甚至未来的短周期）中的各个部分起到杠杆作用。例如，对每个数据表设置好模型，将使你能在项目中剩余的任务即快又好的处理这些数据表。

❑ 敏捷的关键就是把项目切割成可管理的几大块。重点在于在每个迭代周期或者短周期中生成潜在的可执行的软件。如果一个任务不能按时正确的完成，那么最好重新分析一下它的重要性并且加以处理，而不是任其崩溃继而产生更大的问题。

❑ 由于敏捷项目是倾向于迭代的，所有有些时候很难对顾客准确估计完成时间。记住要根据每个工作单元和迭代周期考虑，仅仅给出一个大概时间。时间跨度越大，你越不好准确估计。工作单元越大，你越不好准确估计。例如，如果你估计是两星期的工作，你可能在预计时加或减百分之五；一个六个月的工作，可能要加或减百分之三十。

原文

The Second Day

When you see Claudia the next day, she looks concerned. You ask her what’s wrong, and she starts right in.

“Well, I’ve been thinking a lot about the web site, and I think we’re missing some key points. First of all,

I want users of the site to be able to search for products. I also think that they need some way to check

out. I’m also concerned that we haven’t thought through the process of adding items to a Shopping Cart.”

“That’s fine. Let’s walk through them all quickly and update our mockups. Then we’ll update the

product backlog I started last night and let you take it over from there, OK?”

With that, you’re off and running, asking about search. Would it be better to have a link to a search page, or

a search widget on each page? Claudia definitely thinks that a search widget on each page would be better.

What does the search operate on? In other words, what fields in the database does it search through?

Claudia thinks for a moment and settles on category names and product names. You add that it wouldn’t

be that hard to also search through descriptions. While Claudia considers this, you update the home

page mockup so that it looks like Figure 2-7. You show Claudia the new mockup and tell her that

every page would have the search widget on the top.

Figure 2-7

Accessibility and Usability

Two very important topics in modern web development involve usability and accessibility. The first,

usability , is all about making a site as easy to use as possible — and not just easy to use for you the

developer, but for the eventual user of the system. It means putting appropriate labels on buttons and

links — in the language the user can understand.

It also means placing consistent global navigation on every page, and adding search features in places

that users expect to find them (and that generate search results that are easy to understand).

Accessibility is about doing the best you can to make sure users with visual, auditory, cognitive, and

motor-reflex impairments can use your site. It’ s about adding ALT tags to images, using UL lists for

navigation, using CSS divs instead of tables for layout, and adding labels to form fields. Imagine trying

to use a web site with the screen turned off, and only having a screen reader to guide you with audio

instructions — instructions it gets from the site itself!

Usability and accessibility are each huge topics, but learning more about them and applying what you

learn will make you a better web developer. Two great sources of information are www.useit.com

(Jakob Nielsen’ s usability site) and www.knowbility.org (an Austin-based accessibility consulting

non-profit organization).

Once you have that figured out, it’s pretty easy to create a mockup of the Search Results page. You ask

her how she wants the results to show up. Should it be just like the Category view, with a name, image,

and short description for any products that come up?

“Yes,” Claudia says, “but make it really clear when you’re showing a product or a category.”

You take a Category view mockup and quickly use it as a model for a Search Results mockup, which

looks a lot like a Category view. You show her the results, which look like Figure 2-8.

Figure 2-8

“That looks fine for now,” Claudia says. “Perhaps we should list categories first, with their own

headings, without thumbnails and descriptions.” She thinks some more, and then shakes her head.

“Let’s leave it for now. Shall we tackle the ‘buy now’ and checkout areas?”

You hesitate momentarily because you really want to show her the product backlog you started, but

Claudia is really caught up in the spirit of things, and you hate to break the flow. So you adapt your

approach and spout out some ideas you have on the “buy now” pages.

“I think that when they click the ‘buy now’ link for a product, the underlying web site should simply

add their information to a Shopping Cart,” you say.

“Yes, that’s like a lot of web sites you see today,” Claudia agrees. “Just show them a quick note that

confirms they’ve added a product to their cart.”

“I also think we should show them a little icon of a shopping cart or a link they can click to view their

Shopping Cart,” you continue. “We can add the link to the top navigation bar, only showing it if

the Shopping Cart has items in it.”

You don’t tell Claudia, but you plan on using a cookie to keep track of Shopping Cart items. You know

that CodeIgniter has powerful functions for creating, editing, and deleting cookies. All you would need

to do is keep track of the individual IDs associated with a product and maybe some other choices, like

size or color.

“If we’re doing that, then I would suggest we change the ‘buy now’ links to say ‘add to cart’ to keep the

confusion to a minimum,” Claudia says, and then smiles to herself because you’ve already updated

various mockups, including the product detail, shown in Figure 2-9.

Figure 2-9

You mention that this mockup shows different states, including the confirmation message they talked

about. Claudia immediately grasps what the mockup represents, but she wants to see a mockup of the

Shopping Cart page.

“It needs to show every item in the Shopping Cart, grouped correctly by product,” she says. “They

should be able to check out immediately from the cart. In fact, you may want to update the confirmation

message to allow folks to check out immediately.”

You laugh because you can’t help it — she’s really getting into it, which is a big change from other

projects you’ve been on. You realize, though, as you mock up the Shopping Cart page, that you’d better

store the price in the Shopping Cart session — it wouldn’t do to have a sudden price update affect users

who are trying to check out. You make a note to yourself that before going live, you need to encrypt the

cookie for an added measure of security. You confirm by asking Claudia about this issue.

“That’s correct, although in practice, we would only make price changes very rarely, and even then on

the weekends or late at night,” she answers. “But still, there’s a pretty good chance that someone could

be online when I make a price change.”

“What happens if someone tries to check out with a product that has been pulled after it’s put in a user ’s

Shopping Cart?”

“Oh, just check for anything like that at the last minute, during checkout,” she says. While you and she

have been talking, you’ve come up with a rough mockup of the Shopping Cart page, which looks a lot

like Figure 2-10.

Figure 2-10

“The x’s next to each line item allow the user to delete the item from their Shopping Cart,” you explain.

Claudia points at the mockup. “There’s something missing. There’s no recalculate button. You know,

when they decide they want two of the abc shirts instead of just one.”

“We’ll use AJAX to automatically recalculate the totals without having to do any of that,” you explain,

which seems to satisfy her. You know that this will make some things easier for you, but it will require

users to have JavaScript enabled. You will need to put in some validation and error checking right before

going live. But something else is still bothering her.

“What about calculating taxes and shipping? Some items are heavier than others. We can’t just do a flat

rate.”

“Since I assume you’re using Paypal or Google Checkout to handle payment, let’s leave that part until

later, as it’s easy enough to integrate.”

Claudia nods and says she’s satisfied with the mockups. “Good”, you say, because it’s time to share the

product backlog with her and make her a true product owner. Once she knows her way around

the product backlog, it’s time to plan the first sprint.

Revisiting the Product Backlog

You explain to Claudia that the product backlog is a prioritized list of requirements for her project. She is

the product owner and, as such, creates and maintains the product backlog and uses it as the centralized,

authoritative list of requirements, from which are derived all the tasks that are undertaken in any

individual sprint.

Each sprint, furthermore, is any unit of time (typically 1 to 4 weeks) in which tasks are worked on. The

goal is to have potentially shippable software at the end of each sprint, so it’s important not to

overcommit time and other resources.

You further explain that you’ve started the product backlog with six requirements:

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.

“Each requirement is stated in general terms: As an X, I want to do Y, so I can do/achieve Z,” you

explain, as you go over every item in the list.

“It looks like we need to add a few more items to the list,” Claudia says, and adds Items 7 and 8:

7. As a user, I want to search for products to find them quickly.

8. As a user, I want to be able to see my Shopping Cart, so I can check out more easily.

Once she is done, she thinks about the list for a long time before speaking. “There’s really nothing in

here about the administrator — me — and how I would manage the online store. I also don’t see

anything on here about keeping track of customers. And I haven’t even told you all my ideas about

wanting an online newsletter to help promote the site and communicate with my customers.”

“This is why you’re better suited to be the product owner,” you respond. “All you have to do is put the

information into the product backlog and then prioritize it. My job is to take the most important items —

the ones on the top of the list — and create tasks that allow me to check off each requirement.”

“How do you do that? Can you give me an example?”

“Of course,” you reply. “I would look at the first two items, which have to do with the home page, and

create a whole series of tasks. For example, I need to build the web page that represents what users see

when they visit the site. I also need to create the models that allow your web site to interact with the

database. I also need to build the database tables themselves. I also need to build all the special functions

that organize items on the page.”

You smile at Claudia’s dismay. “You don’t have to worry about all that. Just know that now that I have

mockups that we’ve built together and a product backlog, I can create tasks that make sense. Also notice

that a lot of the things I need to do for the first two requirements, like building database tables, also help

me build the rest of the application quicker. They’re one-time tasks, or at least, tasks that can be reused in

different contexts.”

“Furthermore,” you continue, “I’ll probably say right now that I’ll tackle all these backlog items in the

first sprint. I’m feeling pretty confident that I can tackle those items in a 4-week sprint, which means

the first iteration of your web site should behave pretty much as we mocked up.”

Claudia nods. “I feel pretty confident that you know what you’re doing. My job is to sit down and think

about all the things I want from this web site and capture all my ideas in this product backlog so you can

keep working after the first backlog.”

“One more thing,” you say, holding up a hand. “This process allows you to change your mind, but let’s

try to limit major changes in direction for each sprint, while allowing minor course corrections

throughout the process. That will make it easier for us to work faster and smarter.”

You both decide that it’s time to work separately. Although the team is very small (just you and

Claudia), you decide to hold daily meetings starting the very next day, which means that you need

to get started with some very basic tasks: installing CodeIgniter on a development server and creating

the initial database tables. Without these tasks being complete, the rest of your task list isn’t even doable.

Creating a Sprint Backlog

You’ve already committed to tackling all eight existing product backlog items in 4 weeks. You look over

the list and start knocking out a sprint backlog:

1. Install and configure CodeIgniter on a development server.

2. Create the initial tables for products and categories.

3. Build a model for products, with functions for listing all products by category, listing product

details for any given product, and listing other products that belong to the same group as a

product.

4. Build a model for categories, with functions for listing all categories as a tree, listing

subcategories for a category, and listing category details. The products’ model already contains a

function that allows you to list all products in a category.

5. Create a controller for all visible pages, with functions for the home page, About Us, Contact Us,

Search Results, Product Detail, Shopping Cart, and Category view.

6. Create special controller functions for running the search and adding items to a Shopping Cart

cookie.

7. Create other shopping cart functions that allow you to display everything in a Shopping Cart,

recalculate prices with AJAX, and delete line items from a Shopping Cart.

8. Create all the views needed to display web pages. This will more than likely involve a master

template with includes as needed to minimize your work later on.

This is about all the detail you’ll need at the moment. If the team were larger, you might need more

detail, but this backlog, combined with your mockups and the product backlog, should be more than

enough to keep you on the right track.

Conclusion

Now that you’ve gone through the process, you can see how valuable this adaptive process is. You’ll see

later in the process how much Claudia changes her mind about certain details (such as the home page),

but with Agile methodology and CodeIgniter tools, it’ll be easy to adjust course and stay on schedule

and within budget.

In the next chapter, you learn how to install and configure CodeIgniter on a LAMP (Linux-Apache-

MySQL-PHP) server and get a quick overview of all the pieces involved (controllers, models, views,

config files, libraries, helpers, and other built-in tools).

Keep the following points in mind as you continue on your journey:

❑ Agile methodologies are adaptive as opposed to predictive.

❑ Agile methodologies work best if you’ve got a small team working with a software project that

is easily time-boxed. The team should meet regularly (daily if possible) and communicate about

their achievements, to do’s, and risks.

❑ It’s almost always better to gather requirements by starting top-down and drawing mockups

with the customer.

❑ It’s important that the product owner (the customer) take charge of the product backlog as soon

as possible. They’ve forgotten more about their business than you’ll ever know.

❑ It’s your job as developer to convert product backlog items into functional tasks in a sprint

backlog.

❑ It is also your responsibility to estimate properly. Don’t overcommit with too many tasks in any

given sprint.

Don’t forget that many functional tasks can be leveraged across various areas of the current

sprint (and even future sprints). For example, setting up good models for each database table

allows you to quickly and easily work with those database tables for the rest of the project.

The point of Agile is to break projects into manageable chunks. The emphasis is always on

potentially shippable software at the end of any iteration or sprint. If a task can’t be completed

properly or on time, it’s good and proper to try to reanalyze its importance and do something

about it, instead of letting it fester and become a big problem.

Because Agile projects tend to be iterative, it’s sometimes hard to give accurate estimates to

customers. Remember to think in terms of time spent on units of work and in iterations, and

only give ranges. The further out the timeline, the less accurate you can be. The bigger the unit

of work, the less accurate you can be. For example, if you are estimating a 2-week job, you might

give an estimate that is plus-or -minus 5 percent. A 6-month job may be on the order of plus-or -

minus 30 percent.