5.3 敏捷工程中的主要实践
敏捷工程中的主要实践涉及完整团队、结对编程、测试驱动开发、持续集成与用户故事。
5.3.1 产品待开发功能列表和用户故事
关于需求，有一个神乎其神的神话：如果你把它写下来，用户就能得到其真正想要的东西。然而，事实上并非如此。用户写下来的东西，可能也不是他们真正想要的。
敏捷中使用产品待开发功能列表代替需求文档。
产品待开发功能列表由所有的功能特性［包括业务功能，非业务功能（与技术、架构和工程实践相关），提升点以及缺陷的修复等］组成。这些内容也是将来产品版本发布的主要内容。
一个完整的待开发功能列表是一个蓝图，可以根据它来把产品改造成我们期望的样子。但是在Scrum中，订单是根据产品和产品使用环境的演化而不断演化的，所以订单是动态的，我们会持续改变它以确保我们的产品是最合理的、最有竞争力的和最有价值的。
良好的产品待开发功能列表需要具备以下特点。
优先级越高的待开发功能列表需要越清晰、越详细。
对每个待开发功能列表项（包括成本、复杂度、风险、功能点）进行估算。优先级越高的待开发功能列表的估算越精确，在估算过程中可能会导致待开发功能列表的优先顺序发生变化（对于那些很重要并且可以快速完成的功能，先实现）。我们要经常进行估算，估算方式可以由整个团队共同决定。
把产品实施或者技术支持部门反馈的许多产品缺陷放入待开发功能列表中，确保对所有的技术问题都做了充分的考虑。
产品待开发功能列表要按照发布版分组，要让开发团队的所有成员了解总体开发目标。
要指定一个负责人来管理待开发功能列表。这个人的职责是管理和控制待开发功能列表。对于商业产品的开发，待开发功能列表的负责人也许会是产品经理、项目经理或者其指派的人。
图5-8展示了产品待开发功能列表的例子。
在产品待开发功能列表中，要使用用户故事描述需求，有的文章认为待开发功能列表就是用户故事。用户故事从用户的角度来对需要改进的功能进行简单的描述，是将团队焦点从编写功能需求转移到讨论它们的最佳方式。用户故事可以写在索引卡片、便签上，也可以排列在墙上或桌子上。
▲图5-8 产品待开发功能列表
注意：粒度要保证可测试、可验证，在一个Sprint内可以完成。
如下面一个用户故事：作为 <教师或学生>，我想<登录教务手机App>，以便于 <我能正常查看课表或者查分>。该故事的描述过于粗糙，还需要针对该故事进行详细讨论。
（1）教师和学生登录手机App的流程是否一样？如果不一样，那么这不是一个独立的待开发功能列表。
（2）登录的具体过程如何？还有什么关键点？是否要密码？密码是否区分大小写？用户名是否区分大小写？是否可以记录用户名？是否可以记录密码并且在下次自动登录？密码在传输过程中是否加密？在写待开发功能列表时可以进一步补充。但这些不一定都实现，或者可以先实现优先级高的。
经过详细讨论，将这个用户故事分解为若干个小的用户故事，其中的一个可以这样描述。
作为<教师>，我想<登录教务手机App，使用的密码和用户名需要记录>，以便于 <我在一个月内再次登录时无须重新输入用户名和密码>。
用户故事可以写在卡片上或者Excel表格中。图5-9中的例子是关于货运单的用户故事。
▲图5-9 货运单的用户故事
产品待开发功能列表保证了需求的可视化，能够让开发团队、利益相关者等人很容易看到它的内容、状态、进展等。
版权声明：51Testing软件测试网获得人民邮电出版社和作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
