敏捷教练-第六章

第六章理解构建什么

如果团队成员想要交付有价值的软件，他们需要多做一些额外的工作来理解使用者和商业的价值，用户故事会帮助他们这样做。用户故事支撑敏捷团队做的所有工作，他们是计划、开发、测试的基础。

我发现团队在努力转换用户故事，因为他们把用户故事看成了需求文档，被动地接受而不问任何问题。他们错过了一个重点：用户故事的重点是去问问题，然后更好地理解用户需要什么，找到分析需求的方法。

本章，我们将共同学习如何向团队引入用户故事，并且避免一般的陷阱。

6.1 Life Cycle of a User Story（用户故事的循环）

我们和蝴蝶的生命周期做比较，来讨论一下用户故事的生命周期。

用户故事开始于一个概念，就像一个蛋。这个主意引起了一些交流，通过交流主意慢慢地变大了然后改变了形状，就像毛毛虫。交流聚集成了特别的测试用例，就像蛹。这些测试用例包含了软件需要做什么，被用户故事包含的软件成型了。最后，可以工作的软件出现了，就像一只美丽的蝴蝶。这个生命周期在产生用户反馈和新的主意之后，就是全部的循环。大多数的时间，敏捷团队的用户故事都有生命周期中的这些不同阶段。

要帮助团队理解，用户故事是通过同客户的交流，随着时间的过去，从一个产品演化到另外一个产品。如果他们冷藏得太快，他们将失去用户故事的意义。鼓励团队不断地去问一些问题，改善他们对需要实现的功能的理解

Ron Jeffries总结了用户故事的三个方面，称之为3Cs

卡片：在索引卡上写上用户故事，以帮助召开群体会议

交谈：问问题，建议拆分故事的方法

确认：同意用来评估故事完成的测试用例

介绍这个咒语“卡片、交谈、确认”给团队，帮助他们记住这三个元素。

6.2 Encouraging Conversations（鼓励交谈）

关于用户故事的交谈帮助团队理解需要构建什么。这些交谈需要被开发人员和测试人员、和顾客一起对于用户故事细节的理解来驱动。注意到是否团队正在努力去找打需要构建什么，提醒他们去问顾客，而不是去猜。

其他的交谈可能是关于以后迭代的用户故事。这些交谈可能会经常被客户所驱动，他们需要更早地看到什么将被开发。她不能没有帮助就去做这些事情，因为她不懂技术细节和团队的能力。鼓励她在探索未来用户故事时，和团队去交流

注意：这些早期的关于用户故事的交流直到计划会议都没有被保存起来、这个浪费了团队的时间去讨论还没有思考完故事。相反，要建议和顾客、一些开发人员或者测试人员一起以小团队来讨论新的用户故事。后面和整个团队一起评审这些。

Liz Says. . .

Get the Conversation Started

要在团队和顾客之间做好催化剂，检查他们是否构建了正确的事情。例如，如果你发现开发人员努力在找出软件应该做什么，说一些类似下面的话：

“你和Kate交流过了吗？他是我们的顾客，可能她会帮助搞出来，你现在有时间吗？”

在交谈开始运作后，你可以躲到幕后了。当团队习惯了进行交谈，他们开始很开心，不需要你再帮忙了。

6.3 Working with Cards（使用卡片）

我们经常发现敏捷团队在计划会议上使用带投影仪的计算机，来找到用户故事。这个谋杀了交谈，因为团队看着投影仪的屏幕，等待去更新每一个故事。介绍索引卡片，作为一种可以替换的方法，来记录关于用户故事的交谈。通过在桌子上面移动卡片，把用户故事按照迭代去分组，，这样比在电子表单上移上移下更更容易。

你要自己向团队展示如何使用卡片。在一个新卡片上写下你听到的每一个故事，把他们放在会议上每一个人都能看到的位置。现在，会议中的每一个人都能为写故事贡献力量。

检查你在卡片上写的是否都包含了所说的。如果没有，建议顾客纠正或者重新写卡片。当正在讨论的故事被改变了，给卡片加注释，或者撕掉它，写一个新卡片。

Rachel Says. . . Rip It Up

记住索引卡反应了你对于用户故事的现在的理解。如果在一些讨论后，用户故事改变了，不要担心撕掉你已经完成的卡片，要重新弄一个新的。

我期望在每一个计划会议都能看到一些撕掉的卡片。当我看不到的时候，我会关心团队是否和顾客交流，是否对于用户故事的实现有疑问。

Demonstrate writing cards, and then stop.

当会议进行时，停止你自己写所有的卡片。当有人提议新的主意时，请他自己写自己的卡片。你能会说类似下面的话“我们不想忘记这些，你能写一张卡片吗？”或者简单的等到有其他人拿起笔然后不用提示就去做这件事情。这个很自然的发生，因为当几个人正在谈论时，一个记笔记的人可能跟不上，你需要很快地找到团队的参与者、

在桌子中间放一堆的卡片和笔，这样任何人都能写卡片。我们发现使用索引卡仅仅在小团队在小桌子上时会有作用。对于超过5个人的团队，建议他们使用水平和正交的卡片。你可以在墙上使用粘贴纸（或者便携式团队版），或者你可以在活动挂图上贴索引卡。现在，团队可以看到所有的卡片，不需要伸长脖子或者混乱地挤在一起。

任何时候，都要让团队使用卡片更容易，不仅仅是在计划会议上。在团队办公室要有充足可用的纸张（而不是锁在壁柜里），还要有收藏卡片的工具（CD盒、塑料套，包扎夹子）

Use a consistent layout for story cards.

提醒团队，这些卡片最后将放在白板上，团队每天的站会将参考这些，这个帮助团队持续使用用户故事。在顶端使用一个短的小标题。通过标上数字，向在其他团队看到的一样，交流难跟踪的故事。使用一个标记写容易读的标题，这个标题要足够大，使得团队可以读到，不用直接走到白板前去辨认。如果团队习惯于在卡上的同一个位置（例如在右端的底部）进行估计，这也是很有帮助的。

Story Templates（故事模板）

当一个团队不熟悉用户故事时，你可以推荐他们使用类似于下面的故事模板：

“作为一个用户，我希望使用。。功能，来获得。。。好处”

下面是一个填写好的例子：

“作为一个购书者，我希望看到顾客评论书，所以，我能决定是否要买这本书”

这个模板帮助团队成员记住要清晰地澄清谁是使用者，开发这个故事讲有什么好处。

团队需要了解不同类型的用户，这样他们才能填写“作为”这个部分。你可以建议团队建立一个投资者地图或者对典型的使用者进行照片描述。更好的方法是安排团队出去见在软件使用环境中真实的使用者。

我遇到过一些团队，他们虔诚地使用用户模板，没有真正地理解用户故事。他们强制地把他们的工作都套到用户模板中，写下了类似下面的故事“作为一个开发人员”或者“作为一个XML反馈引擎”。向他们解释如果没有用户合作，然后使用这个模板可能不会帮助团队更好地理解需求，所以没有必要使用它。

提醒团队，用户故事模板的目的是帮助团队去学习问问题，这样可以提高他们的理解，而不是就填充一个表格。一旦团队习惯了使用用户故事，团队可以丢掉用户模板。一个短的标题就可以了，任何在卡上的注释都可以很简单的会议记录，不需要过多。不管团队是否使用模板，写用户故事时，都要用让整个团队包括顾客都理解的语言、

在故事已经作为可以工作的软件实现周，团队依赖测试、不是卡片来获得故事的细节。他们可以把卡片给扔了，但是有时看原始的卡片可以勾起关于会谈的记忆。如果团队需要在后面的迭代中增加更多的相关故事时，这个很有用。因为这个目的，大多数的团队保留着过去迭代的很多卡片，但是他们并没有经常去查阅这些卡片。

6.4 Confirming the Details(确认细节)

一旦团队理解了基础故事，谁是使用者，他们将要解决什么问题，团队需要讨论细节并且达成如何实现的共识。和团队一起使用一套测试来确定每个故事的范围，这套测试的通过来确认故事已经“done”。故事的测试帮助团队清楚什么需要构建、需要做多少的工作。

故事的测试开始于在故事卡的背面胡乱涂写的一些内容。建议团队在这个点计划进入下一阶段前，这个方法就足够了。后来，这些注释在后面的阶段用于作为可测试的脚步的基础。

我们会发现，有时团队期望顾客自己来进行这些测试。帮助团队了解这是不太可能的事情，一个生意人总是在考虑哪件事情运行正确而不是运行错误。举个例子，当考虑如果做一本书的研究时，他们很可能更关心使用者如何做，而不是如果没有结果显示将发生什么。

小心测试这个词的出现，你的顾客可能为了一个突然地退出做出一个解释，因为这个单词给了这样一个印象-技术会议就要开始了。不是恐吓他们不要使用技术语言，而是建议团队跑通一些真实的例子。例子帮助团队检查他们理解的团队如何去做，什么行为将满足顾客的需求。例子帮助团队去发现什么错误处理导致的形式。

以使用一些用户接口为开始，现在鼓励团队去问顾客类似于下面的问题：

l  用户将要开始什么数据？

l  用户希望看到什么数据？

l  我们需要了解这些生意规则吗？

用户接口的草图会起作用，一些粗糙的草图也很有用。这些是团队需要一起理解的内容，不是表面。

现在，提醒团队去问什么将是错误的。什么输入的数据将被处理？考虑一下不好的数据

和真实的质量。在这个研究中，提醒团队他们不是在写测试脚本，他们还不需要找到每个边界条件。

下面是一些用户故事的测试：作为一个顾客，我想要找到一本书，这样我就可以买它。这个使用了用户模板Given-When-Then

l  当用户在搜索页，输入“敏捷指导”（仅有1个匹配），当用户点击搜索按钮，全部的书的细节（标题、作者、书皮图案、摘要、价格、评论）。增加到商店按钮都出现了。

l  当用户搜索页，输入“测试驱动开发”（有多个匹配）， 当用户点击搜索按钮。一系列书的概要（标题、作者、价格）都显示出来了，以价格顺序排列，在概要旁边，有1个显示更多的按钮。

l  当用户搜索页，输入“瀑布式开发”（没有匹配），当用户点击搜索按钮，出现“对不起，没有找到这本书”的信息

如果就几个测试，那么在故事卡的背面记录下这些测试。或者增加他们到一个分开的卡片，然后用夹子夹到故事卡上。小心，如果故事有一大堆卡片要夹上去，这个表明故事太大了，或者团队讨论的细节太多了。

我们一起看一下一个团队是如何得出故事是如何测试的。

Working Out Story Tests

Amanda是一个PO，她作为一个网上书商类型的客户。在站会上，她请求团队增加这样一个功能：如果增加ISBN的搜索到已存在的网页，会有多少困难。Damian和Larry,一个开发人员和一个测试人员，愿意和她一起看一下故事的细节，然后可以给出一个初始估计。

Damian 问：“为什么用户要使用ISBN搜索？他们已经可以通过作者或者关键字进行搜索”

Amanda解释：“这个来源于上次的用户可用性测试，看起来有些用户很着急，不想使用我们的搜索菜单”

Damian皱起了眉头，“为什么我们不能重新设计搜索工作吗？我猜当我们得出如何去做时，这是一个快速的事情。Amanda点头然后写下了故事卡片

接着，他们去讨论例子如何实现。输入一个ISBN例如934356433，应该显示一个书的结果页。模板在网页上已经存在了，所以不需要想更多的显示细节。Damian写下了这个故事的测试。

Damian问到：“如果用户没有输入全部的ISBN，将会发生什么事情？如要部分ISBN匹配吗？”

Amanda想了一会儿，“不完全对，他们偏离了故事要求，我们直接让他们到标准的没有结果的页面，然后显示TOP热点链接，如何？”Damian写下了第2个故事的测试

Larry,测试人员，读到：“我能需要处理十三个数字的ISBN吗？”Amanda点点头，他在第一个故事卡的底部增加了这个注释。

“就在他们输入字母我们才返回结果吗？输入空白和连字符怎么办？”

Damian 说“当然，抹掉空白和连字符不是多大的工作量，所以我们要把这个添加上。”

Amanda同意“好主意“

团队成员现在都很高兴，他们足够理解用户故事，可以给出一个估计。

这个故事展示了故事的测试时如何添加的，有些故事可能是被推迟的。

用户故事是一个简单的技术，团队可以通过和使用者交流他们需要什么，来理解顾客的需求。作为一个教练，你的关注点是在使用敏捷之前，消除他们开发的坏习惯，而不是问为什么和提供改变。向他们展示如何使用用户卡片，鼓励他们去进行用户故事的交谈，给他们提供好的建议，找出作为故事测试的更多的细节

6.5 Hurdles（障碍）

下面是你可能遇到的障碍

No User-Facing Functionality（非用户功能）

当用户故事用来描述真实使用者的需求时，是更有效的。如果你正在进行一个项目去重构或者建立架构，那么经常是没有明显的用户功能去描述。

模板“作为。。。我希望。。已获得“不一定很有用。但是问题是：“谁想要这个，为什么”帮助揭示了如何按优先级来处理这个工作。团队仍然可以讨论如何来解决这个问题、交付的好处、故事的测试（可以确认是否交付了故事）

用户故事可以帮助把技术任务形成一些有意义的描述，这个对客户和管理者来说更清晰，使得他们能了解每一个迭代有哪些需要完成。如果工作使用开发人员的技术语言（数据库和代码）来描述，对于顾客来说听起来是很神秘的。

下面是一个例子。下面关于架构的描述没有表达出为什么是需要的“在Fred上安装WIBLv2” WIBLv2是一个代码库，Fred是一个网页服务器。假设软件正在使用WIBLv2进行更新，将去处理亚洲市场上不同的字符。如果我们把这些写成用户故事，“作为一个PO,我希望通过看到在亚洲市场上的展示的书的信息，以便我能把书卖到亚洲市场”。这里标识了做这个工作的清晰的原因。原来的描述“在Fred上安装WIBLv2”是实现这个用户故事的任务。新的用户故事让团队了解如何进行测试才能证实这个故事的运行

Requirements Must Be Documented（需求一定要文档化）

一些组织强制要求，软件需求一定要是正式的文档，经常因为他们是正规的工业，必须要表明他们在遵循正规的流程，这些要被审计。或者有时这些信息需要从一个团队传给另一个团队，例如运营团队。

你仍然可以从用户故事开始工作，但是现在你需要将他们文档化。快速地建立故事的电子版记录是拍照片（或者复印）。在用户故事讨论的过程中，你可以在白板上记录一些速写图。如果你需要更多的完整的文档，可以在用户故事讨论会再写。

另外一个写文档的方法是，使用测试框架例如FIT去记录用户故事的测试来作为可执行的需求。

Team Can’t Meet Up（团队不能碰到）

显然的，卡片和粘贴卡不能在不同的办公室的团队间使��。你能使用用户故事作为会议的基础，需要讨论用户的需求和讨论使用什么样的测试来证实故事已经被执行。不是使用用户索引开，做简单的事情也可以奏效。例如，你可以使用桌面共享软件（例如netmeeting），这样在每一个位置的团队可以看见同样的屏幕。然后使用一些基本的软件，允许你写下虚拟的注释而不是写下索引卡

6.6 Checklist（检查）

l  教会团队“卡片、会议、确认”模式，去帮助他们记住用户故事有三个重要元素：会议、卡片、确认。鼓励团队去通过和客户的交流来确认每一个用户故事

l  你自己来写卡片，向团队展示如何写用户卡片，然后要留出一些空余的位置给团队去写卡片

l  确信卡片或者注释在团队空间、故事讨论中是有用的

l  “作为。。我希望有这样的能力，以此来。。获得利益”是一个有用的用户故事模板。要小心，不要让这个成为填空练习：这个模板是鼓励团队去问问题，一旦他们问了正确的问题，团队可以丢掉模板

l  支持团队在计划会议之前，得出故事的细节。如果你有一些团队成员，这个帮助用户故事成型。他们会问问题，以及建议故事测试。