《敏 捷 教 练：如何打造优秀的敏捷团队》—6.5 难关

6.5  难关

在实践过程中，可能会碰到以下难关。

没有面向用户的功能

用户故事最适合用于描述真人用户的需求。如果项目要重写基础框架或架构，通常就不会有任何明显的面向用户的功能描述。

类似“作为一名……我想要……这样是为了……”这样的模板恐怕没什么作用。但“谁想要这个？为什么？”等类似的问题依然有助于理解工作安排。团队照样可以交谈，讨论要解决什么问题，能带来什么好处，要用哪些故事测试来确认故事是否已可交付。

用户故事也可以用于给一堆技术任务包装一个更有意义的描述，这能让客户和管理层更清楚每个迭代里所做的事情。如果用开发人员的技术语言来描述这些工作，像库啊、代码段啊、什么的，对客户来说就跟听天书一样了。

下面来看个例子。下面有一段描述了一些基础框架相关的工作内容，但没有讲清楚为什么需要做这件事情。“在Fred上安装WIBLv2”，WIBL是一个代码库，Fred是一个网络服务器。让我们假定使用WIBLv2更新软件的目的是针对亚洲市场处理不同的字符集。我们可以把它重写成一个用户故事：“作为产品经理，我想要看到用亚洲字符集显示的书籍信息，这样我们就能够把书卖到亚洲市场了。”这样能更清楚地阐明这件事情的缘由。最初的描述“在Fred上安装WIBLv2”是实现这个新用户故事的一个任务。新的用户故事还能够指引团队得出需要运行的测试，以证明此故事。

需求必须有记录

有些组织严格要求正式记录软件需求，通常是因为它们处在受监管的行业之中，必须显示它们遵守了某个可审核的流程。也有些时候是因为要使用这些信息来支持团队间的工作移交，例如把工作移交给某个运营团队。

用户故事还是可以用，只是现在还需要把它们记录下来。可以采取拍数码照片(或是复印件)的方法，快速创建故事的电子记录。讨论用户故事时在白板上画有草图，你或许也想把它们记录下来。如果你需要记录十分完整的文档，可以在用户故事交谈完成后再写。

创建文档而不受代码干扰还有另一种方式，使用FIT[1]这样的测试框架以可执行需求的形式来写故事测试。

团队无法见面

显然，如果团队成员分布在不同的办公室里，交谈的时候就无法使用卡片和便事贴。你仍然可以以用户故事为基础进行交谈，讨论用户的需求和确认故事已实现所需要进行的故事测试。若无法使用索引卡，就选择其他简单可行的办法。例如，可以使用桌面共享软件(如NetMeeting或WebEx)，以便各地团队能看见相同的画面。索引卡没法用，就配合使用一些简单的软件，只要能创建虚拟便事贴即可。