跳转到内容

敏捷开发框架下的软件工程/第二轮迭代

来自维基教科书,开放世界中的开放书籍

第二轮迭代概述

[编辑 | 编辑源代码]

第二轮迭代是开发过程的核心。在这一轮中,我们从对业务问题/机会的高层理解,到系统部署并被用户实际使用,完成了整个过程。

在第一轮迭代中,我们已经

- 建立了开发团队

- 与客户建立了牢固的沟通渠道

- 确认了我们与客户对项目高层需求的共识

- 制定了方法和工作实践。

在第二轮迭代中,我们将经历一个完整的开发周期。我们首先详细地确定需要做的事情,然后制定如何做,最后(你猜对了)去做。在本轮迭代结束时,我们将拥有一个功能完善、实用且已部署的系统。该系统具体的功能(以及哪些功能留到第三轮迭代中完成)我们稍后会再讨论。现在,重要的是我们知道交付日期是最重要的变量。这被称为时间盒,这意味着我们将调整我们想要做的事情,以适应可用的时间和资源。

请记住,每个部门的内部细节并没有明确定义。更重要的是信息的流动,我们会在移动到该部门的输出时不断完善和增强我们的理解。不过,我们应该始终能够解释我们为什么做某件事,并证明它是如何帮助我们实现目标的。

虽然这里关注的是结构化流程,但我们根据敏捷原则执行这些流程。我们期望每天的工作以Scrum会议为基础,以质量和最简单可行的方式为中心,并将重点放在结果上,而不是为了流程而流程。始终用象征性的眼光审视这个部门,以a)检查所有工作流是否被覆盖,以及b)了解你正在做的事情如何直接推动该部门的结果。我们应该尽可能地让客户参与整个过程,并在每个部门结束时发送正式的文档(有时是详细的提案,有时是更新信)。

评估部门是迭代之间的过渡。在评估部门,我们将回顾迄今为止完成的工作,并规划下一个部门。这是通过提案正式化我们与客户互动的重要阶段。


功能需求

[编辑 | 编辑源代码]

功能需求部门可以用一个词概括:“什么”。在这里,我们确定系统需要做什么(而不是如何做)。

功能需求是描述软件应该提供的功能、软件应该具有的特性以及软件应该实现或帮助用户实现的目标的说明。功能需求陈述以“系统应该...”开头。(注意:有些人试图用用户故事“用户应该...”来替代这种说法)。它们通常伴随着系统需求:“系统应该具有...”

为了获得这些功能需求,我们经历了一个收集和理解尽可能多信息的流程。我们需要很快地理解我们合作的组织的每一个细节。从第一次访谈开始,我们就必须了解该业务。幸运的是,我们有一些技巧可以帮助我们收集和结构化这些信息,从问题之上和之下进行工作。我们使用功能分解来帮助我们理解业务流程,使用数据建模来识别结构和关系,使用逻辑结构来捕获业务规则。我们还会观察和询问用户。

这些技术将直接引导我们得出定义系统必须做什么的功能需求。我们测试这些功能需求,确保它们能解决业务机会,并且是可开发的(尽管我们必须小心不要限制我们的思维)。这些需求将成为我们开发的基础,并传递到下一个部门。


交互设计

[编辑 | 编辑源代码]

在交互设计中,我们开发符合功能需求的系统的外观和感觉。虽然我们大多数情况下都认为界面是电脑屏幕,但大多数项目都有其他非屏幕界面元素,例如表单、报告,有时还有物理交互系统。

该部门的输出是一个设计提案,我们将正式向客户展示。客户和用户应该密切参与这个部门。

这是整个开发过程中最有趣和最有创意的阶段,但它也是一个需要非常严格和谨慎的部门。所有五个工作流可能同时运行,你应该预期同时进行多个任务。

这次有四个技巧

- 测试所有东西:用户不会像你一样思考或行动

- 不要作弊:在你最喜欢的 IDE 中构建一个界面,然后倒着进行流程是行不通的。不要忽视对话框图。

- 用户应该忘记他们正在使用你的系统:成功的衡量标准主要在于与用户如何完成某项任务的模型相匹配,人们喜欢简单的东西,所以你应该尽可能地优雅:几个精心设计的界面远比大量杂乱无章的界面好得多。

- 重新开始。这个部门很辛苦,但也是最令人满意的。如果有些事情行不通,那就继续尝试;如果行得通,那就测试它,直到它崩溃。在这里做对要比在编码了很长时间后才做对容易得多。请记住,对于用户来说,界面就是系统,其他所有东西都只是机制 - 这必须是正确的。

这里的信息流动直接来自功能需求,我们将它们转化为用户执行的任务(我们对用户进行详细的考虑)。我们将这些任务发展成图示,代表完成这些任务的最佳方式。然后,我们考虑所有可能出错的事情,并确保我们的系统可以支持这些错误。在进行这些操作的同时,我们会关注开发一个支持我们正在使用信息的逻辑数据模型。同时,我们也会开发设计主题。从隐喻开始,我们会想出一些关于系统外观的替代方案。这意味着外观风格,但可能更重要的是交互风格。

然后是最重要的部分:将主题、对话框图和逻辑数据模型转换成线框界面。我们将这个界面作为纸质原型与实际用户进行测试。预期在这里你会意识到自己完全做错了什么,然后回到对话框图、设计主题、任务甚至功能需求。重要的是认识到这个阶段的迭代性质,修改过去的决定,添加或更改功能需求是开发过程的一部分。

我们将交互设计开发和测试的结果以交互设计演示/文档的形式呈现给客户。

设计规范

[编辑 | 编辑源代码]

在设计规范中,我们详细说明交互设计。

在本部门结束时,我们将拥有一个蓝图,可以提供给程序员。他们应该能够完全按照我们指定的规范构建系统。设计规范将外观和方法整合在一起。我们采用设计主题和线框图,开发详细的界面规范和完整的已设计产品,如用户手册。除此之外,我们还继续开发数据库(这里的关键是“没有魔法” - 所有数据都来自某个地方,并去往某个地方)。物理数据模型是关于系统要存储和操作的信息的详细规范。

除了界面的“如何”,我们还确定后端的“如何”。这从数据库和系统架构(以图示表示)开始,然后是关于编码结构的决定,最后是稳定开发平台的开发和测试。

稳定开发平台是构建系统的框架。例如,对于具有 Web 前端的数据库,我们希望你演示通过 Web(插入、删除、查询、更新)以及任何标准基础设施(登录等)进行连接和基本数据库功能。


实现阶段是根据规范构建系统。这是你获得迄今为止所有辛苦工作回报的地方。在稳定平台的基础上,结合经过设计和测试的物理数据库以及详细的界面规范,这个实现不应该是一项巨大的任务。幸运的是,软件工程也有助于实现阶段。我们使用来自极限编程(XP)的几个工具来帮助我们。我们使用模块化和基于模式的开发,使用结对编程,使用基于测试的开发。我们进行了广泛的测试,然后我们进行了更多测试。我们仔细考虑部署系统的最佳方式,然后我们执行它。在进行这些操作的同时,我们还会培训用户。

在本部门结束时,我们将拥有一个可运行的系统,更重要的是,它被用户实际使用。


当系统使用一段时间后,我们需要花时间进行评估。这不仅仅是“它是否有效?”(虽然这也很重要),还包括对功能需求的仔细审查(是否正确?是否遗漏了任何内容?等等),以及对开发所有方面的反思。客户应密切参与此反思过程。

华夏公益教科书