我们如何做SCRUM

开发团队的可怕梦想是，在开始开发之前，您需要“潜入”一个未知的主题领域并“半估”一个半生半熟的想法。 在这种情况下，您需要在指定的时间以固定的金额按字面意义“ 签血 ”。

实际上，对不准确的需求进行准确的评估是不现实的。 项目管理中的一种典型方法是在开始开发之前拟定详细的TOR。 然后将所有功能一并实现。 但是，这种“ 瀑布式 ”方法已经带来了其他风险：以“ 大爆炸 ”风格启动项目-当您在项目结束时获得第一个结果时。 这可能与实际的业务目标和用户需求相去甚远。

如果您可以采取完全不同的方式，为什么还要冒险？

为什么要SCRUM

在熟悉项目时，会有一种理解：“我们知道我们不知道”，甚至“我们不知道自己不知道的地方在哪里”都可以帮助SCRUM



如果您从未使用过此框架，则SCRUM的细节可能会吓跑，因为一开始您尚不清楚获得工作项目和100％满意所必须走的路。

对于客户而言，这很困难-他无法为发布日期可靠的项目制定战略计划。 未知数令人恐惧，尤其是当您现在需要以这种方式付款时。

但是还有一些优点 ：一开始，客户不应详细描述大型未来系统的所有功能。 而且它还可以随时更改优先级并适应竞争激烈的外部市场。

顺便说一句，在这种情况下是相同的 ，但是很快您将看到我们如何摆脱困境，与客户一起确定了在流程中已经实现的方式和方式。

SCRUM依靠小步骤的概念：尽可能经常且更早地定期发布正在运行的软件版本。 每次迭代都是开发的一个微阶段，并由实践立即进行验证。

这意味着在第一次迭代之后，客户会收到相当有用的（尽管很小但可以正常工作）功能，在实践中对其进行检查，并立即给出反馈。



了解我们如何组织所有工作：重要的关键决策-赋予业务的下一个价值-团队在每次新迭代之前都要采取的措施，结果，系统会沿着至关重要的最优路径发展，直到它变得最适合业务。 这里的客户是团队的一部分。 承包商和客户都对开发的成功负责。 它们位于路障的一侧。

我们就是这种情况，让我们看看吗？

我们想谈谈在“ A +现代教育学院”的自动控制系统中采用经典SCRUM框架的方式-这是位于基辅的现代教育中心，其中包括学校，幼儿园，早期发展中心，音乐，舞蹈和体育学校，艺术工作室和外语学习中心。 总共有1000多名儿童参加了学院的近150种不同课程。

SCRUM是一个框架，可帮助解决工作过程中发生的变化的任务，以便高效，创造性地向客户提供最高价值的产品。

SCRUM的优点以及某些缺点是它是一个非常轻量级的框架。 它不包含对所有问题的答案以及对团队成员的详细说明。 Scrum-“故意不完整”，并且由于这种普遍性。

SCRUM需要适应每个特定项目

客户和承包商如何开始使用SCRUM？

为了以不熟悉的范例进行工作，有时客户必须改变习惯性思维。 与表演者处于同一环境中。 因此，在开发学院系统之前，我们与来自乌克兰Scrum的人员组织了一次联合培训。 它的主要目标是：彼此了解，了解术语，以游戏形式制定所有技术，模拟主要活动，了解从哪里开始，分配角色和登记职责。









在为期三天的联合训练中，我们使用了所谓的直升机视图 ，形成了大笔触的未来系统，并将其以Project RoadMap的形式固定在临时线上。

直升机视图-对情况的一般描述或观点，而不是详细的视图


全球产品路线图

在此阶段之后我们得出什么结论？

1. 联合培训有助于改变客户和团队的想法。
2. 使用产品路线图 ，您可以可视化高级开发计划并大致计划发布。 重要的是要了解这是一个“实时路线图”，它将随着发现新的开发细节而改变
3. 必须在“岸上”就游戏的全球规则达成协议：每次冲刺后， 产品所有者都将获得价值-一种应立即使用的工作系统，然后提供反馈。

第三段是强制性的，没有它，将无济于事。 由于希望在最终完全抽象之后开始发射，导致双方都感到失望，

• 在客户方面：“这是我们的要求，但这不是我们所需要的。”
• 表演者方面：“我们显然做了您所要求的。 现在，您的要求对我们而言完全不同。 我们同意重做所有内容，但费用由您承担。 总的来说，变化如此之多，以至于还要花六个月的时间。”

产品所有者 - 产品所有者负责通过开发团队完成的工作来实现产品的最大价值。 唯一负责产品开发的人

我们所有的安排都在一个简短的清单中。

步骤＃1：业务分析和方法论调整

我们从业务分析开始开发任何项目：您需要了解具体细节。 任何公司中始终都有很多流程，我们在研究中的任务是在构建系统之前找出系统参与者之间的交互方式。

经过一轮有问题的采访并处理了收到的信息后，我们以使用示例的形式收到了对主题领域的描述。



尽管SCRUM不需要开发规范，但是我们已经对主题领域进行了描述，这是一大优势。 该文档构成了产品积压的基础-SCRUM启动的基础。 产品积压-需求，故事，功能的列表，按重要性排序。 有了这样的列表，一切就开始了。 此外，所有要求均以客户可以理解的语言描述。 此列表的元素是用户故事 ，即“用户故事”。

用户故事是对使用该系统的最简单的用户场景的描述，其本质可以表述为：“谁，什么，做什么，什么功能和局限性”。









我们积压下来的203故事产品，按细分分组


用户故事示例

在此阶段之后我们得出什么结论？

1. 我们的冲刺将持续2周。 为什么呢 短距离冲刺很舒服。 他们使团队尽可能“灵活”：准备经常调整他们的计划。 短距离冲刺意味着反馈周期短，从而导致频繁发布。 频繁发布=来自客户的快速评论=减少了错误方向的工作时间=快速培训，改进等
2. 长距离冲刺有其优势-较少的开销，例如冲刺计划，演示等。 但是，我们选择了短期贷款以保持灵活性并降低风险。

冲刺 -创建“就绪”的时间段，即适合使用和发布的产品

步骤2：冲刺计划。 我们如何调整Sprint计划

我们的第一个商业价值是电子杂志。 对于大多数经验丰富的开发人员而言，这似乎是乌托邦式的：我们有一张空白纸，没有单个目录，用户界面，授权系统或单个业务实体，并且我们致力于提供系统中最复杂的功能之一。



怎么样 对于我们来说，有必要获得两件事： 冲刺的既定目标和批准的冲刺积压。

我们的产品负责人始终从开始冲刺计划开始，首先要描述需要做的事情，最重要的故事。 之后，团队从最重要的一个故事开始，评估了所有用户故事的人工成本。 在此过程中，团队对如何工作有很多疑问。

冲刺计划是一项非常重要的SCRUM活动。 每个人都知道进行正确评估的责任，因为：

• 这使企业能够了解在冲刺结束时可以期望的功能。 让我们成为一支可预测的团队，并与客户“在同一页上”
• 半故事的实现价值为零，因此需要确定在一个冲刺框架内计划的所有故事。
• 冲刺期间得分的任何变化都将被忽略；

冲刺的目的就是冲刺的目的 。 最重要的是，应该以业务而非技术来表明目标。 也就是说，使用一种即使对于团队外部人员也可以理解的语言，而Sprint待办事项是从产品待办事项中选择的故事。 这是团队在此阶段确定为最重要的故事列表，并承诺在冲刺阶段完成。


冲刺积压示例

第一次冲刺后的电子杂志

第一次冲刺的简化和假设 。 在系统中-2个用户：老师和父母； 一类-5“ A”； 类的实际组成，直接通过SQL查询手动输入； 当前时间表为5“ A”，也直接通过表格中的条目形成。

用户故事1 ：老师登录系统，并根据当天的课程表为所有科目评分。 一种具有一个简单但已经可以运行的功能的系统。 老师已经在sprint演示中说了什么要方便使用，什么不方便，以便团队在下一个sprint中可以计划更正并提供更新的工具。

真正的价值在于：真正的课堂数字化表现，当前的评估，自动准备月度，学期，季度报告的前景。

用户故事2 ：每周向家长报告邮件的性能。

价值增加：告知父母当前的表现； 老师对作业的评论； 最少但真实的分析。

经过几次冲刺，我决定为教师提供足够的功能来处理电子日记。 因此，我们暂停了该工具的开发，并将重点转移到了计划设计器上。 这对于SCRUM是正常的。 经过十几次冲刺，我回到了电子杂志的发展重点，并且在部分放弃了简化功能之后，我们将电子杂志带到了分析年度业绩所必需的状态。 当时我们需要此功能。 我们已经获得了足够的价值，并积极开发了系统的更高优先级部分。

产品负责人Svyatoslav

供参考 ：为了修复最终（理想）版本，我们不得不返回电子期刊进行几次冲刺。


这是该杂志在第一次冲刺之后的样子，但是已经可以使用它了。


此电子杂志的版本经过12次冲刺后才收到，可以向父母展示。

迭代SCRUM方法的另一个生动示例是进度表构造函数。

在项目开始两个月后，客户收到了第一位计划设计师。 对于一个非常高级的用户来说，它是一个“野蛮的编辑器”。 但是他允许我们为所有五年级引入一个时间表，并在实际的时间表上测试该系统。

花了三个冲刺将其改进为“可视编辑器”。 发展重点已经改变了好几次，但是到了学年开始时，客户收到了一个功能齐全的时间表设计器，在这个帮助下，他在短短一个小时内就将时间表从一年级（A，B，C，D）引入了八年级。

让我们遵循“真正的管理员的野蛮编辑器”-“可视编辑器”-“计划设计器”的路线

您之前是如何制定时间表的？

时间表是在Whatman A1胶粘纸上手动制定的：涂漆，用彩色标记突出显示，胶粘。 班主任花了几个星期甚至几个月的时间来做到这一点。


编辑器的第一个版本：“管理员的原始编辑器”-制定了2018年的时间表


第二个改进版本，借助该版本制定了2018/2019年计划


日程设计器-最终版本

在此阶段之后我们得出什么结论？

1. 每个冲刺必须有一个明确定义的目标。
2. 简化功能然后进行开发是正常的。 为什么SCRUM这么好：在产品开发中没有正确的方法。 这不是一本带有结尾的作业和正确答案的教程。 您总是可以考虑许多替代选项，并以不同的顺序执行它们。 如果在sprint结束时客户获得了一个完整的价值，他可以使用该价值进行工作，测试，输入新数据，然后前进到全局最终任务，则这是正确的方法。
3. SCRUM的主要理念：一开始不追求漂亮的代码，而是专注于为客户提供工作工具。 因此，您可以在工作过程中忍受错误，但是您需要了解：识别这些错误的最佳方法是停止在体系结构和设计级别上考虑理想的代码，并首先为业务提供一个工作原型。
4. 在讨论过程中，更改用户故事并保存所有工件并将其附加到卡上非常重要。

如何使团队切实评估用户故事

如果满足条件，团队将始终充分评估用户故事：详细描述真实用户的行为，指示使用范围和假设，列出接受标准 。 也就是说，团队了解“需要做什么”，并大致建议“如何做”。

为何制定“接受标准”和“使用范围”很重要-这使产品所有者和团队对故事的工作范围有了相同的理解。

评分量表或SCRUM扑克

在SCRUM中，故事评估不是在数小时或数天内进行的，而是在故事点中进行的。 这是团队完成故事必须花费的复杂性，风险和努力的混合体。 对于每个团队来说，一个故事点是个人的经验价值，但是每个团队成员都可以感受到。

请注意，卡上的值顺序是非线性的。 例如，在13到21之间没有任何内容。 为什么这样



首先，这对于避免出现针对大额定值的错误准确性感是必要的。 如果故事的估计大约是17个故事点，那么讨论该故事应该是15个，18个还是21个就没有意义了。我们需要知道的是故事难以评估。 因此，我们将她的评级定为21。

其次，人们倾向于夸大自己的能力，而且在时间和资源的评估上，规模不会有太大的错误。 例如，团队同意6个故事点足以完成一项任务。 但是，如果您不确定5个是否足够，那么最好选择8个。这可以让您设置团队真正适合的实际条件。 此外，它还有助于在参与者之间进行对话，分享您对故事实施的看法，表达风险并达成共识。

非常重要 ：每个团队成员都应进行评估。 怎么了

• 为了进行合理的评估，每个参与者都必须完全理解这个故事的本质。 通过收到团队中每个成员的评估，我们确保每个人都知道风险所在。 这增加了冲刺期间相互协助的可能性。 最重要的是：这个故事中最重要的问题将尽早出现。
• 对问题的全面了解导致评估的广泛传播。 最好尽快识别和讨论此类分歧。 讨论分歧后-重新评估，投票。 通常，两个评估周期足以阐明要点并达成共识。

我们以其中一个故事的估计差异很大的例子来说明这一点。 这个故事叫巴兹 。

重要提示 ：在规划期间，我们通常不知道由谁来执行此或那部分工作。 用户故事的实现需要专家参与不同类型的工作：架构，前端，后端，测试，真实数据的准备。 另外，还有一组设计和用户界面设计。

亮点：嗡嗡声

在学校管理系统中，会发生许多不同程度的重要事件。 例如，一个学生获得了成绩； 替换发生了，代替数学，将有另一位老师与生物学进行交流； 学生发生了一件令人讨厌的事件，应立即通知父母； 老师在DZ上写了重要的评论。

用户通过标准方法将这些数据发送到即时通讯程序或通过邮件发送，甚至昨天都是不方便的。 另外，消息可以一次与几个人相关：教师需要向家长发送学生在课程中离开学校的信息。 在原始文档中，这些规则收集在10页上


嗡嗡声在最终实施中

亮点：嗡嗡声

我们正在开发人员中讨论我们对Buzz历史的工作量有多少估算。



每个人都说出需要多少故事点。原来，我们的意见分歧很大，并引起了人们对极端意见的关注：为什么某人的评分为50，而他的同事对5个故事点有信心。因此，我们立即发现了未被发现的需求，而这些需求被更为谨慎的开发人员注意到。另外，与个性化相关的全局任务也已被揭示。这是团队如何预测困难的一个很好的例子。

我们对评估方法有何结论

1. 是的，对于质量检查和用户体验设计师来说，评估技术历史记录是正常的。
2. story points, «» . , , story points.
3. 2-3 , — 1 story point

story point — , , .

№3: . sprint execution SCRUM

每天的SCRUM会议（或站立会议）和整个SCRUM都是关于有效沟通的故事，可帮助节省团队的时间和精力。这些不只是“会议”和“对话”。他们不会占用可用于工作的时间，但有助于优化工作。 SCRUM的原则之一是：“人与交互比流程和工具更重要。”



根据特别设计的清单，每个团队成员简要地报告了自己的工作，面临的问题以及下一步的工作。一个人不会一个人一个问题，他们会迅速以最有效的方式帮助他们解决问题。因此，工程师不会将时间花费在不成功的尝试上，之后您可能不得不从头开始重做它，从而节省了整个团队的资源。

跨职能：球队准备执行对一个产品的推出任何任务

时形成我们选择的球队T-专业人士谁在许多领域理解和至少一个是专家。由于这种多功能性，所有工程师都非常了解该系统。

每个人的经验对于找到最有效的解决方案都是宝贵的。

在团队中，一个人可能没有特定任务所需的经验，但是很有可能会拥有他的同事。客户方面也是如此：一个人可能不知道某些细节，但另一个人知道。

, : , , sprint backlog , , , , . , , , , . .

, Scrum Master

sprint running

1. , , , .
2. 有必要转移重点，并了解每天的SCRUM对于通信而不是管理是必需的。
3. 随后的每个冲刺都应考虑先前的冲刺经验。

如何进行每日SCRUM会议

步骤4：我们如何进行结果演示。我们对sprint演示的改编

开发人员轮流展示真实数据上的新功能。重点是我们做了什么，而不是我们怎么做。通常，我们会不断努力使我们的演示面向业务，而不提及技术细节。

如何找出解决方案是否适合客户

在这里，冲刺目标再次脱颖而出。我们的演示经常由没有计划的特邀老师和校长参加。他们只是一般性地了解产品。我们总是欢迎在每个故事都展示出来之后，客户自己尝试在系统中做某事。然后，最终用户检查接受标准的每个项目。他说什么适合，什么不适合，哪些方面可以改进。如此-针对此Sprint计划的每个用户故事。





我们在论证结果的方法论上得出了什么结论

1. 演示的必选组成：产品所有者，Scrum负责人，客户代表和将与工具一起使用的最终用户，团队。
2. , .
3. , . -.
4. , . .
5. . , ,

—

№5: retrospective

对我们来说，回顾是sprint演示之后的重要事件。回顾很有用，特别是当出现问题时。如果不进行回顾，结果可能是团队一次又一次地踩着相同的耙子。



如何确保避免重复犯错

最常见的情况是，实际球队的表现与预期的表现有很大出入。实际表现是根据对每个故事的初步评估得出的。在冲刺过程中，我们意识到故事的完成时间（通常估计为5个故事点）与任务通常需要13个故事点并且远未完成一样，并且如果它也是一个阻碍故事，则其他故事将无法开始，因为未准备好有问题。当冲刺目标受到威胁时，回顾是不可避免的。

我们的回顾具有绝对清晰的结构和目标：团队聚在一起。Scrum Master阅读sprint积压，要求团队中的每个成员发表讲话并从他的角度评估sprint的结果。团队中的每个成员都表达了自己的观点，认为可能做得好，出了什么问题，最重要的是为什么。继续做什么和拒绝什么。但是，没有人打扰他。他将他的结论记录在标签上的其中一列中：

• 好吧
• 可能会更好
• 需要修复

基于回顾的改进示例

• 当开发人员制作前端并开始实施时，有必要使设计师100％可访问。
• 与采购订单讨论方法学小时的内容。
• 在人体工程学中，获取最多的文档很重要。
• 不应累积技术债务，将技术案例的10％与PO对齐。
• 应该有一个专家来解决出现的技术问题。
• 在每次冲刺计划之前，必须进行冲刺修饰。

“在团队就所有有问题的贴纸进行头脑风暴之后，我将进行“现场投票”：每个团队成员都有3票（贴纸上有3个标记点）。 他可以一次投票解决一个问题，也可以分配不同的票。 基于团队投票，我们选择了2-3个增强功能，这些增强功能将在下一个冲刺中重点关注。 在下一次回顾展开始时，我们将检查发生了什么。 可以这么说，“检查作业” ：）“

敏捷教练Pavel Kamyshov

是的，SCRUM需要所有团队成员的积极参与。 对于诸如修饰，计划，每日SCRUM之类的活动，我们花费了大约12％的带薪时间-这是一种透明度，可预测性和降低风险的价格。

一周的工作可以节省一小时的计划。

乌克兰Scrum敏捷教练Pavel Kamyshov

12％的收入很多，但值得，因为在经典的“瀑布式”中，使用方法论的价格是项目经理的单独职责。 在我们的市场领域中，平均约有15％的开发成本用于管理。

我们对回顾性方法得出了哪些结论

1. 对我们来说，回顾是SCRUM中仅次于冲刺计划的第二重要事件。
2. 每个团队成员都说出来，以便每个人都在同一个信息字段中。
3. 每次更改都有价格。 您必须同意PO才能在sprint积压订单中包括技术故事和方法学时数。
4. 方法学时间由客户支付。

Sprint回顾为团队提供了一个针对自己进行检查并制定计划以改进下一个Sprint团队合作的机会。

步骤6：我们如何调整产品待办事项列表的细化或修饰

许多熟悉IT细节的同事对此表示怀疑：团队在sprint计划中如何如此清晰，以至于可以对所有用户案例进行评估。



是的，的确，没有这种连贯性的准备是行不通的。 为了使这种方式工作，有一个特殊的SCRUM活动：产品待办事项细化。 要执行此操作，您需要让产品负责人给出一个计划范围：概述哪些故事可以作为下一个冲刺的候选对象。 如果其中有些故事需要团队没有的深入研究或特殊能力，则称为会议-梳理/预先计划。


修饰结果

我们的产品负责人非常有能力，因此我们对系统的开发方式始终有足够的了解，并定期进行改进。 实际上，透明度是SCRUM的基本原则之一。


它看起来像一个美容计划

我们对提炼方法学有何结论

1. 这是一项重要的事件，它使我们能够弄清我们不知道的东西，缺乏的能力。 因此，一旦决定在特定问题上吸引第三方开发人员顾问，那是我们当时没有的解决方案。
2. 这些讨论对我们非常有效，我们考虑了许多替代方案和选项，这使我们能够牢记问题，而对于sprint计划，最复杂的故事已经“被提出”了。
3. 复杂的，看似无法解决的问题找到了明确的解决方案。 有时候，仅仅购买图书馆就够了，而不是自己开发一个复杂的网站。

优化是准备在sprint计划期间评估不同实施条件下的故事复杂性的基础，因为我们需要了解它们的数量和复杂性。

失败

是的，坦率地说，我们对SCRUM方法的开发感到高兴，但这并不意味着一切顺利。 如果我们事先知道这样做的话，我们将在这三点上做草。

处理熟悉的模式

在一项回顾中，我们在涉及设计师的所有故事中详细分析了团队“实际生产力”异常偏离的原因。 实际绩效通常使用以下公式计算：预计绩效/实际绩效。

我们出于习惯将他们组织成熟悉的顺序瀑布。

结果是：任务是按顺序执行的，开发人员花了一些时间在不同阶段按顺序打开，由于需要完成已经开始的任务而导致延迟。

结论：也许这对我们来说是最痛苦的故事，它造成的伤害最大，并且没有立即披露。 有必要定期检查所有团队成员是否都已按照新标准工作。

多余功能方面的额外工作

在第二次冲刺中，产品负责人屈服于一位班主任的意见，这位班主任认为“策展人日记”是一项极为重要的功能。 我们以冲刺的方式处理了这个故事，并为此付出了很多努力。

为什么会出错：该工具只能在以后的阶段进行测试，因为它需要积累的数据，而当时还不存在。

结果：未测试，未使用，未开发。 通过完全不同的工具，以不同的方式解决了必要的功能，而根本没有解决班主任认为的方式。 结论：仅将立即开始使用的内容投入工作。

等同于高级用户

在一个阶段，我们将故事与“替换编辑器”一起开发，然后由一位经验丰富的计算机用户的老师参与了开发。 结果，我们得到了一个很好的工具，但是没有那么先进的普通学校教师无法使用它。

结论：向常规客户确认这个故事。

一般结论

结论数字1

专业的灵活性：SCRUM使您成为有效的团队

每次冲刺的结果取决于入门任务，效率，协调，团队责任和质量反馈。

输入由产品负责人提供。 他还负责使用功能的上下文，需求制定的质量，并提供了足够的细节深度。

SCRUM要求团队完成一项完全有形的工作，这使他们能够获得价值，即可以在每次迭代结束时提供给用户的工具。 这有助于查看解决方案的工作原理和初始阶段，以了解需要进行哪些更改才能继续进行。

结论2

关于最有效地利用资源

SCRUM-一种对客户和承包商有利的工作组织形式。 什么啊
在早期阶段使用迭代就可以了解发生了什么问题，这意味着您需要及时进行调整。 每个冲刺的准备工作及其组织的具体细节每次都只能帮助完成客户需要的事情，而不是抛开它们。 它极大地提高了所用资源，时间和精力的利用率。
在初始阶段，客户会收到系统的一个工作部分：在第一次冲刺之后，他将自己完成的功能投入工作并在实践中进行了测试。

SCRUM-当双方都为风险投保时

了解客户和承包商之间如何分担责任
障碍消失了，承包商和客户都在经典项目管理中的两侧。 原则上，客户和承包商的职位消失了，团队仍然存在。 而且没有可能发生对抗的条件。

顾客

仅当所有冲刺目标均已实现时，客户才付款。 如果未开发出让客户明天可以在实践中使用的工具，则冲刺将不会计入。

客户为每个冲刺支付固定的金额，从而使他的业务更高效

表演者

承包商有兴趣在每次冲刺期间为客户准备新工具和新价值，因为这将提供新一轮的反馈和信息/经验。 可用于进一步的产品开发。

每个冲刺都会提高表演者的能力水平，并在项目实施过程中加快执行速度。

总体而言，在短短7个月内，我们制作了一个对客户有效且完全令客户满意的系统，经过客户的实践测试并反映了所有愿望，并且没有给出根据TOR理论设计的系统，该系统需要再花几个月的时间才能完成，因为这种做法不可避免地会自行进行更正。

在全球范围内，这种情况涉及在高度不确定性和启动前有限的时间条件下正确选择的项目管理技术。

对于这样一个要求苛刻的客户，以及高质量的标准，这有时对我们来说很困难，但同时也很有趣。 我们克服的挑战，所犯的错误，及时，有意识地纠正，所得出的结论永远改变了我们团队的文化

可能是很长一段时间以来，每个人都有兴趣了解产品本身，结果。

客户收到了出色的产品：一套用于现代化学校的工具，可以迅速将其转变为未来的学校