敏捷开发框架下的软件工程 / 第一次迭代 / 规划游戏
| 规划游戏 |
|
 |
软件工程的目标是按时、在预算范围内交付满足需求的软件。正如我们所学，传统的计划驱动方法始终未能实现这一目标。其中一个关键因素是需求收集策略。计划驱动的瀑布模型方法在早期阶段彻底确定需求，然后使用这些需求来指导后续流程。问题是：当需求发生变化时会发生什么？这可能发生在业务本身发生变化时，或者不同的用户考虑软件并提出替代应用，或者客户对软件的可能性有了更深入的了解。
• 需求是指一个陈述，它识别出定义产品或流程需求的功能、物理特性或质量因素，这些需求将寻求解决方案。
功能需求描述系统做什么（功能）。
例如，“系统应为学生注册课程”
非功能需求描述系统具有什么（物理特性）。包括可靠性、质量、安全性和可维护性。
客户和开发人员之间的讨论中，一个挑战是使用的语言。客户是其业务领域的专家，并将使用适合该领域的语言。例如，会计师将使用“投资回报率”（ROI）或“净现值”（NPV）等术语。在教育领域，“学习路径”（POS）或“全日制等值学生”（EFTS）等短语是熟悉词汇的一部分。与此同时，开发人员熟悉技术术语，很容易用这种行话让客户感到困惑。
敏捷方法使用一种需求确定方法，可以描述为“及时”需求分析。与客户和/或用户举行会议，在此期间，根据对问题的当前理解，对需求可能是什么做出最佳猜测。使用的语言必须让客户和开发人员都能理解，因为该过程是持续对话的开始，这种对话将在整个开发过程中持续进行。
肯特·贝克在他的《极限编程》（2005 年）中描述了一个正式的需求收集过程，称为“规划游戏”。这是定义的极限编程实践之一。请记住，极限编程中的关键价值观是
沟通 简洁 反馈 勇气 尊重
规划游戏通过鼓励整个开发团队（包括客户）尽早进行有效的讨论来应用这些价值观。用户故事被记录在索引卡上，并显示给整个团队进行讨论。然后，它们被用于规划开发，包括发布和时间估计。团队成员对卡片进行优先级排序，讨论约束并描述故事完成的测试。迈克·科恩 (2004) 将用户故事应用于敏捷开发，发展了贝克的思想。
“用户故事描述了对系统或软件的用户或购买者有价值的功能。”（第 4 页，科恩，2004 年）
该故事描述了用户在一次会话中将要执行的操作，例如，“学生将访问项目文件”，“学生小组将同时访问项目文件”。
用户故事包含三个部分
1. 故事本身
2. 评论，可能澄清故事的细节，或提出待讨论的观点
3. 用于指示故事完成的测试
杰弗里斯 (2001) 将撰写用户故事的过程描述为“卡片、对话和确认”。卡片用于捕获初始需求，然后在团队中进行讨论，然后实施和测试。这强调了故事作为沟通工具的作用，在开发过程中使用。它们不用于记录流程，也不是合同义务。传统的需求文档同时兼具这两者。
使用这种方法允许团队在整个项目持续时间内分散决策。可以尽早做出宏观决策，这允许进行初始规划。根据需要，可以稍后添加详细信息。早期的、大型的故事被称为“史诗”。
一个故事有多大？
理想情况下，它描述了一个需要 1/2 到 10 天编码的任务，假设开发团队经验丰富。学习估计故事的大小对于开发人员来说是一项重要的技能。规划每个迭代中将包含哪些故事取决于良好的时间估计。
为什么要使用故事卡？
它们强调口头交流而不是书面交流
它们易于所有团队成员理解
它们有助于有效规划
它们支持迭代开发
它们鼓励推迟细节（科恩，2004 年）
一个好的故事是：• 独立的 • 可协商的 • 对用户或客户有价值的 • 可估算的 • 小的 • 可测试的
（韦克，2003 年 a）
 案例研究 Shac09 |
|
小组：软件工程 2007
通过思考各种系统隐喻，班级能够编写大量关于参与隐喻中的人物的故事（例如司法系统 - “律师申请重审”）。这些故事很容易转换为真实系统 - 一个支持可持续房屋建筑竞赛的信息系统。然后，这些用户故事通过计划游戏进行分类和排序。
|
