接下来几章将关注的项目是为一家虚构的公司手工制品编写的，该公司专门将消费者与制作和销售各种独特手工制品的工匠联系起来。这些产品涵盖广泛的材料和用途，包括家具、工艺品和珠宝项目，如珠子和用于成本计算的碎片。几乎所有的东西都是有人愿意做的，也有人愿意买的。
手工制作的东西（HMS目前正在寻找一种简化业务流程的方法，让工匠通过主网站提供他们的产品。目前，当一个工匠创造了他们愿意出售的东西时，他们会向HMS中心办公室的人发送一封电子邮件，如果是新的东西，会附上一张或多张照片，如果是以前提供的新版本或一套产品，有时还会附上新照片。HMS中心办公室的某个人将相关信息复制到他们的 web 系统中，并进行一些基本设置以使项目可用。从那里开始，一旦消费者决定他们想要订购工匠制作的物品，订单将通过另一个手动流程进行，HMS中央办公室通过电子邮件向工匠发送订单信息。
所有这些手动过程都很耗时，有时容易出错。有时，他们花了很长时间，以至于不止一位客户试图购买同一件商品，因为信息仍在处理中，以获得第一份订单：
手工制作的东西**的网站运行在现成的系统上，不容易修改。它确实有一个 API，但该 API 被设计用于内部访问过程，因此存在安全问题，需要充分开放对它的访问，以允许工匠通过新的 web 应用程序开发连接到它。
The business that this imaginary company does is, perhaps, not terribly realistic. It certainly doesn't feel like it'd actually be able to compete with existing businesses such as Etsy or (maybe) craigslist or eBay. Even so, the implementation concepts for the system are reasonably realistic, in that they are variations of tasks that need to be implemented across several real-world problem domains. They're just combined in an unusual fashion.
由于以下章节旨在表示单个开发迭代，在一个至少有点类似看板方法的过程中，在进入这些迭代/章节之前，有一些来自预开发过程的工件值得注意。
新系统的主要目标是简化和（尽可能）自动化现有流程，将工匠的产品纳入在线目录。明确地：
- 技工应能够提交产品信息，而无需通过基于电子邮件的流程。作为这一变化的一部分：
- 将实施一些数据输入控制，以防止简单错误（丢失或无效数据）。
- 工匠将能够修改他们的产品数据，但有一些限制，并且在这些修订生效之前仍需要进行审查。不过，他们至少能够停用实时产品列表，并激活现有但已停用的项目。
- 产品审查人员将能够直接进行修订（至少对于简单的更改），并将项目发回进行重大修订。流程的这一部分是松散定义的，在开发周期的后期可能需要进一步的细节和定义。
- 产品经理的数据输入任务将显著减少，至少就新产品的设置而言。新系统将解决大部分或全部问题。
在进行任何详细设计之前，新流程的用例图如下所示：
目的是为每位工匠提供一个可安装的应用程序，使他们能够与HMS主办公室进行交互。该本地应用程序将连接到 Artisan 网关，Artisan 网关将处理 Artisan 到主办公室的通信，并将 Artisan 传入的数据存储为任何待批准内容的暂存区。从那里开始，审阅者（和/或产品经理应用程序将允许产品审阅者和经理使用其本机 API 将 Artisan 提供的产品移动到主网络商店中。在这一点上，带有一些粗略的进程间通信流的逻辑体系结构如下所示：
在这些图和前面提到的初始概念之间，有许多特定的用户需求已经被捕获。在开发过程中，或者至少在开发规划过程中，可能会出现更多的问题（因为迭代的故事是充实的）。
Artisan 及其产品背后的实际数据结构尚不清楚，只是产品是可以由一个且只有一个 Artisan 拥有的不同元素。需要更多的细节来实现这些，以及确定哪些数据在何处（何时）移动，但它们之间的关系已经可以用图表表示：
目前缺乏关于这些元素的内部数据结构的信息，这也使得任何类型的 UI 设计规范都很困难，如果不是不可能的话。类似地，很难确定用例和逻辑架构/数据流图中尚未隐含的任何业务规则。这些也需要更多的细节，才能发现更有用的东西。
从这些信息中可以推断出一些其他不同的项目，它们属于以下开发前步骤之一：
-
风险：
- 审查/管理应用程序与Web Store 数据库之间的连接是单向的，这可能表明需要小心控制数据流。实际上，应用程序可能至少需要能够从数据库中读取数据，只要这样才能找到和修改现有产品，而不是一次又一次地创建新的产品条目。
- 用例图显示，技工可以在不涉及产品审查人员的情况下激活或停用产品，但架构和流程没有任何明显的方式来处理该功能。至少，应该检查 Artisan 网关到Web Store 数据库的连接，但这可能会在以后的相关开发迭代中发生。由于 web store 系统有一个 API，因此该过程可能可以通过Artisan****Gateway对web store 应用程序的 API 调用进行管理，但尚未对其进行评估。
-
项目管理策划资料：
- 如果项目已经进入开发车间，那么所有可行性、成本分析和其他业务级别的检查都已经完成并获得批准的可能性就很大。虽然这些结果可能不需要任何具体的信息，但如果出现问题，知道它们可能是可用的是一件好事。
为了展示敏捷过程在其下开发系统时的样子，hms_sys的开发将分解为几个迭代。每个迭代都有一个单一的高级目标，涵盖一个或多个章节，涉及一组共同的故事。在第 4 章、方法、范例和实践中讨论的敏捷方法中，这些章节比任何其他章节都更接近看板方法，因为每个迭代中完成的故事数量和总规模在迭代之间存在显著差异。在 Scrum 环境中，这些迭代将是时间受限的，分为时间受限的块——也就是说，每个迭代将计划持续一定的时间长度。以下章节及其相应的迭代是面向目标的，每个章节都旨在实现系统功能的某个里程碑。在这方面，他们也接近于遵循特性驱动开发模式。
每次迭代将处理相同的五个项目：
- 迭代目标
- 故事和任务的集合：
- SDLC 模型中的需求分析和定义活动（视需要而定）
- 系统架构和设计活动，也来自 SDLC 模型，视需要而定
- 编写和测试代码。
- 系统集成、测试和验收。
- 发展后的考虑因素和影响：
- 实施/安装/分发
- 操作/使用和维护
- 退役
每一次迭代都有一个非常具体的目标集要完成，并且目标集中得相当紧密，建立在先前迭代的成果之上，直到最终的系统完成。按照顺序，每个迭代的目标是：
- 发展基础：建立项目和流程。每个功能迭代需要在测试完成时可测试、可构建和可部署，因此在系统项目中需要提前支付一些注意事项，以确保在开发过程中有一些共同的基础来构建这些功能。
*** 业务对象基础：业务对象数据结构和功能的定义和开发。
*** **业务对象数据持久化**：**确保可以根据需要存储和检索使用中的各种业务对象。**
*** **服务基础**：**构建主办公室和 Artisan 服务的基本功能，这将是整个系统通信和数据交换流程的主干。**
*** **业务通信**：**定义、细化并实现系统组件之间的实际通信过程，特别是服务层实现。**********
******这些迭代中的每一次都可能会有数量惊人的设计和实现级决策，并且有很多机会在各种各样的功能、概念和实现场景中运用各种软件工程原理。
每一次迭代的成果都将被记录在一组用户故事中，这是在检查 Scrum 和看板方法时描述的类型。每个迭代完成的标准将包括完成与之相关的所有故事，或者至少解决这些故事。例如，为了适应功能依赖性，一些故事可能必须移动到以后的迭代中，在这种情况下，在系统开发的后期才可能完成这些故事的实现。
一旦所有的故事都被定义得足够详细以允许开发，代码本身就会被编写出来，既可以用于与每个故事相关的实际功能，也可以用于该代码的自动测试——单元测试和内置的回归测试功能。如果可能且切实可行，还将编写集成和系统测试代码，以期从这些角度对新代码提供相同的自动化、可重复的测试。每个迭代的最终目标将是一个经过测试（并且可以根据需要重新测试）的可部署和功能代码库。在早期的迭代过程中，它可能不完整，甚至不可用，但就其提供的功能而言，它将是稳定和可预测的。
该过程的这一部分将构成接下来几章的主要内容。毕竟，编写代码是开发的关键方面。
hms_sys的操作/使用、维护和退役阶段将在开发完成后进行深入讨论，但随着开发的展开，将努力预测与系统寿命部分相关的特定需求。在核心开发阶段可能会编写代码，也可能不会编写代码来解决系统活动生命周期中的问题，但在这些工作中出现的任何预期需求，至少可以在开发工作中编写一些文档，供系统管理员使用。
hms_sys的预开发和高级概念设计项目相当简单，至少在预开发规划周期中可用的详细程度上是如此。一旦各个迭代功能的用户故事被充实起来，更多的细节就会浮出水面，还有大量的问题、实现决策和细节。不过，有一个迭代将首先发生。
正如所暗示的，第一次迭代更多地关注工具、过程和实践的定义，这些工具、过程和实践将在最终系统的实际开发中发挥作用。开发团队和团队管理者很可能已经决定了其中的大部分决策和设置。即便如此，我们还是有必要看看一些选项和决策标准，希望这些选项和标准能够帮助我们做出这些决策。它们可以（并且经常）对开发过程中的工作状况产生重大影响。******