摘
要
小型软件组织的软件过程改进始终是软件行业面临的一个挑战，诸如CMMI等过程改进和评估模型都是基于大型项目的成功经验总结而来的[1]，对于我国占软件组织总量70%以上的小型组织而言，存在诸多不合适的地方。为了实现小型组织的有效过程改善，近年来发展起来的敏捷开发方法是一个很有价值的途径，而且更能体现小型组织“小而灵活”的特点。用户故事是极限编程的重要实践之一，体现沟通、反馈、简单等极限编程原则，非常适合于需求易变化的小型组织/小型项目[2]。为全面了解用户故事的实施方法和规程，本文介绍一种用户故事驱动的软件开发模式，使用用户故事进行软件需求分析，制定发布计划和迭代计划等，实现软件项目和过程的可控性。经过部分项目的验证，这种方法非常适合10人以下的小型项目团队。
关键词 用户需求 故事 迭代
A User Story Driven Software Development Method
Abstract Software process improvement in small organizations
is a challenging task; process improvement and assessment
models, such as CMMI and ISO 15504, are best practices
of large organizations and projects [1]. In china, 70
percent of software organizations are small organizations;
upper models aren’t suitable for small organizations,
not reflecting the “small and flexibility” character
of small organizations. To support the process improvement
in small organizations, Agile development methods are
very valuable [2]. User Story is one of the important
practices of eXtreme Programming, encouraging communication,
reflection and simpleness. To learn the development
model of user story, the article introduces a user story-driven
software development method oriented to small organizations
and projects. The method is valuable for project team
less than 10 people proved by some projects.
Key words User Requirement, User Stories, Iteration
现在很多研究机构都在研究如何有效实现小型组织的过程改进问题，有的研究思路是对已有CMMI或者ISO9001模型进行剪裁；有的研究成果则另辟蹊径，敏捷开发就是现在一种很流行的方法[3]。极限编程(XP)是Kent
Beck在1998年首先提出的，是敏捷方法中最著名的一种方法，它由一系列简单却互相依赖的实践组成。用户故事是XP的核心实践之一，用于捕获和组织需求，摒弃传统冗长繁琐的需求文档，提供处理需求变更的灵活机制。
本文简要分析用户故事的特征，讨论如何基于用户故事定义发布和迭代计划，总结流行的基于用户故事驱动的软件开发方法。这种软件开发方法可以有效解决小型组织过程完善面临的问题，充分体现小型组织的灵活特征，有效促进软件过程改进。
1 用户故事
用户故事描述了对软件（或系统）用户或客户有价值的功能。用户故事包括三方面内容：书面描述（用于计划和备忘），交谈（细化故事细节），以及测试用例（验证故事实现）。用户故事描述的传统形式是手工书写的用户故事卡，
Ron Jeffries称如上三方面内容为Card(卡片)、Conversation(交谈)和Confirmation(确认)[2]。
开发者辅助客户编写故事，告诉客户所编写的故事是进一步讨论的引子，而不是详细的需求规范。在任何项目中，需要客户团队根据故事的重要性来安排开发者的工作，回答所有开发者的问题，编写所有的故事。客户团队包含多个成员（诸如测试人员、产品经理、真实用户、交互功能设计人员），确保软件满足目标用户的需求。
在编写故事之前应该建立用户角色模型，必须包含对项目成功至关重要的角色，尽量保证所有用户对系统完全满意。
1.1 用户故事的特性
如想创建优秀的故事，需要认真领会6个属性，分别是：独立性、可协商性、对用户或者客户有价值、可预测性、短小精悍，以及可测试性。Bill
Wake使用缩写词INVEST表示6个属性。
1）独立性。尽可能避免故事之间存在依赖关系，故事间依赖关系会产生优先级和规划问题。
2）可协商性。故事是可协商的，不是必须实现的书面合同或者需求。
3）对用户或者客户有价值。确保每个故事对客户或用户有价值的最好方式是让用户编写故事。
4）可预测性。开发者应该能够预测（至少大致猜测）故事的规模，以及编码实现所需要的时间。
5）短小精悍。故事规模对实现有影响，何种故事规模最合适，取决于开发组规模、开发组的能力，以及技术实现等方面。
6）测试性。所编写的故事必须是可测试的。
1.2 用户故事与IEEE803、用例和场景的比较
当今流行的其他需求获取和定义方法包括：用例、IEEE830软件需求规格说明，以及场景设计。下面简单说明用户故事与它们的区别[6]。
（1）与IEEE803需求规格说明的区别。用户故事与IEEE 830软件需求规格说明的最根本差异是：对于后者，只有编写完所有需求时，才能知道每个需求的成本；对于用户故事，每个故事在定义时就需要提供成本的估计值，客户知道团队的速度和每个故事的点数。
（2）与用例的区别。用例最早由Ivar Jacobson在1992年提出，用例通常与统一软件过程相联系。用例描述系统和角色之间的交互。两者差别主要在于：
1）范围不同。二者都用来体现商业价值，但故事规模可以设定比较小（例如，10天完成），以便以此为单位安排工作。用例包含的范围可能比故事大得多。
2）完成程度不同。James Grenning曾指出：故事卡中的文字“加上验收测试用例就基本等同于用例”，这意味着故事对应于用例的基本流，而故事的测试要求对应于用例的备选流。
3）寿命不同。用例通常是持久的工作产品，在产品开发和维护时，用例一直存在。然而，故事通常只存在于实现该故事的迭代中。虽然故事卡可以存档，但是许多团队都将故事卡销毁。
4）编写目的不同。用例的目的是记录客户和开发团队的一致意见。故事是为了便于制定发布计划和迭代计划，并作为有关用户需求细节方面的交谈备忘录。
（3）与场景的区别。场景不仅指用例的一个路径，而且还用于人-机交互设计。交互设计中的场景不同于用例中的场景。实际上，交互设计中的场景一般比用例更大、更广。Carroll指出场景包含以下特征性：背景场所、演员、目标，以及行为和事件。用户故事和情景的基本区别是二者的范围和详细程度不同。场景包含更多的细节，而且场景的范围涵盖多个故事。
2 用户故事驱动的软件开发过程
在故事驱动的开发过程中，用户和客户始终参与全部开发过程中。在项目中期，他们不应该，也不容许离开。项目最初的故事通常是在专题讨论会中完成的，但是在项目的任何时期都可以调整故事。开发者有了最初的一组故事，便可以估计每个故事的规模。
客户团队和开发者共同确定迭代周期的长度，项目期间应该采用相同的迭代周期。一旦确定了迭代周期，开发者就可以估算一个迭代周期的工作量，称之为“速度”（velocity）。
为了制定发布计划，需要将故事卡分成几叠，每叠代表一次迭代。每叠包含数个故事。优先顺序最高的故事安排在最前面的叠中优先处理。
在每次迭代周期开始以前，客户团队可以修改计划。迭代周期结束时，就可以获知开发团队的真实速度，这时采用真实速度改进迭代和发布计划。这意味着可以通过增减故事的方法调整每次迭代的故事数量。图1是用户故事驱动软件开发过程的基本流程。
图1 用户故事驱动的软件开发过程
相对于其他开发方法，基于用户故事的软件开发方法更加倡导沟通和协作，鼓励和积极拥抱需求变更，这种开发模式更加适合小型组织/项目的产品特点和组织特点，而且这种开发模式也是实施大型过程改进模型，诸如CMMI和ISO/IEC
15504的基础[4]。
2.1 故事估计
必须由整个团队来共同估计故事，估计方法应该具有以下特点：无论何时发现故事的新信息，都可以调整故事；适用于大故事和小故事；估计花费时间不长；为项目计划和工作安排提供有用信息；能够容忍不精确的估计；用于项目发布。
故事点数（story points）是满足上述要求的方法之一。故事点数的优点之一是每个团队可以据自身情况来定义它。有的团队可能将一个故事点数定义为一天的理想工作量。另一个团队可能将一个故事点数定义为一周的理想工作量。估计过程是一个迭代过程，过程如下[5]：
1）召集参与估计的客户和开发者。拿出所有的故事卡和一叠空白卡，给每个参与者发几张卡片。客户从故事卡中随机选出一个故事，并读给开发者听。在初步了解这个故事后，开发者尽可能提问，客户尽可能详细的回答。如果客户不能回答，客户可以猜，也可以要求开发者推迟实现该故事。
2）在每个故事的提问和回答结束时，每个开发者在卡片上写下故事实现的估计值，估计值对其他开发者保密。如果团队规定一个故事点数代表一个理想工作日的工作量，那么开发者应考虑该故事包含多少故事点。如果团队规定故事点数代表故事的复杂度，那么开发者应考虑该故事的复杂性。
3）在每个人都完成了估计后，大家都亮出卡片，如果估计值有差异，由最高者和最低者解释自己的估计。
4）大家共同讨论。其他参与者可能会提出一些新观点。客户澄清开发者关注的问题。这种讨论可能会引出新故事。
5）讨论结束后，开发者再次在故事卡上写下估计值，写完后亮出卡片。一般而言，在第二轮时估计值就一致了。但如果不是这样，就让最高者和最低者阐述自己的想法，重复上述过程。
2.2 发布计划
许多软件项目都争取每2至6个月发布一次。一些网站项目的发布更频繁，即使如此，也应该在发布中引入新的功能。一种有效的方法是根据产品开发路线图来启动发布计划，产品开发路线图标明每次发布的重点。根据产品开发路线图，使用如下两个问题启动发布计划：计划在何时发布？各个故事的顺序如何？
一旦回答了这两个问题，就能根据开发团队在一次迭代中完成工作量的估计来制定发布计划，合理地预测需要多少次迭代才能完成一个满足客户要求的产品发布。
如果某项目有100个故事点数，每次迭代的速度是20个故事点数，就应该使用5次迭代来完成该项目。发布计划的最后一步是将各个故事指派到各次迭代中。客户和开发者从优先顺序最高的故事中选出总点数为20点的故事，并分配到第一次迭代。后面的20个故事点数对应于第二次迭代，如此类推，直到分配完所有的故事。
2.2.1 设定故事优先级
现在有多种评判故事优先级的标准。从技术角度可以考虑以下内容[7,8]：
1）故事不能达到用户期望的风险（例如：达到一定的性能特征、设计一个新的算法）；
2）如果推迟本故事，对其他故事可能产生的影响。
此外，客户也有衡量故事优先级的其他尺度，诸如：
1）多数用户或客户对该故事的需求程度；
2）少数关键用户或客户对该故事的需求程度；
3）某故事与其他故事的结合特点（例如，故事“缩小”的优先顺序可能并不高，但是它的互补故事“放大”的优先顺序高）。
总之，开发者和客户各有故事完成顺序计划。当二者不一致时，开发者必须服从客户。
2.2.2 确定迭代长度
总体说来，应该由开发者和客户共同选定合适的迭代长度。迭代长度通常为1到4周。迭代周期短有利于适时调整项目进度和项目计划。
在同一个项目开发中，应尽可能坚持同样的迭代长度。坚持同样长度，项目将呈现出与团队步伐一致的自然节奏。当然，有时候也需要改变迭代长度。例如，某团队一直采用3周的迭代长度，现在突然要求他们准备出新版本，在8周后进行一次重要的商业演示。该团队与其在完成两次迭代后就一直等待演示，还不如安排两个正常的3周迭代和一个短的2周迭代。应该避免随意改变迭代周期的长度。
2.2.3 将故事指派到各次迭代中
发布计划将故事粗粒度地分配到各次迭代中。在每次迭代的开始，制定更细致的计划非常重要。
要计划一次迭代，应该召集团队举行迭代计划会议。客户和开发者都应该参加。开发团队要考虑故事的细节，所以势必要提出一些有关的问题。客户应对这些问题做出答复。通常，迭代计划会议的活动次序如下：讨论一个故事；将故事拆分为多个任务；确定每个任务的开发责任人；完成所有故事的讨论和任务分配后，开发者分别估算自己接受的任务，确保不超量。
故事已经很小了，足以作为工作单位，如果能将故事拆分为更小的任务，对项目会更有利。首先，对于多数团队而言，故事通常不是由一个程序员（或者配对程序员）来实现。因为程序员精通特定领域，而分工可以提高开发速度，所以要将故事拆分到多个程序员。
2.3 验收测试
用户故事很关键的一点是将测试看作开发过程的一部分，而不是“实现后再做”的工作。制定测试用例是产品经理和测试人员的共同职责。产品经理利用自己的组织经验来推动项目，测试人员则怀疑和审视项目。在迭代开始时，他们共同编写尽可能多的测试用例。
验收测试用例含有大量信息，程序员应该在编码之前就可以使用这些信息。当然，要想使程序员因此受益，故事的测试用例应该在故事编码实现之前完成。编写测试用例的时机通常为[2,8]：
1）在客户和开发者探讨故事的过程中需要获取清晰的细节时；
2）在迭代周期开始时（在编码之前）；
3）在故事编程中间或完成编程后发现新测试需求时。
因为软件是用来实现用户预期的，所以最好由用户编写测试用例。客户可以与程序员或测试人员一起编写测试用例，但是至少应该由用户确定测试要求，这种测试要求可用于证明用例书写是否正确。此外，开发团队也需要编写与隐含故事需求相关的测试用例。
3 结论
本文根据小型软件企业的实际开发需求，用户需求变更快等特点，阐述一种用户故事驱动的软件开发方法，总结在实施用户故事方法时需要特别注意的地方。这种方法与其他软件开发方法相比有以下优点：注重口头沟通；易于被所有人理解；用户故事的大小适中，可用来制定计划；支持迭代开发；鼓励推迟细节；支持随机设计；鼓励参与性设计；建立默契的领悟。但是可能出现的问题也比较突出，常见问题包括：在一个有许多故事的大型项目中，很难理解用户故事之间的关系；虽然故事可以提高团队中的默契领悟，但是很难覆盖到大型团队/项目，尤其是分布式项目。这些都是需要进一步完善的方面，有关研究也正在进行中。
| 
