如今，几乎所有 IT 公司都存在敏捷项目管理。 2001 年，开创性的敏捷宣言 (agilemanifesto.org) 诞生了。在过去的 20 年里，这种思维方式发生了很大变化。是不是变得更好了？

根据项目管理协会 1 的数据，超过 70% 的公司采用了敏捷方法，敏捷项目的成功率比传统项目高 28%。大概，您还知道敏捷流行的原则，这些原则是由 Scrum 框架培养的。在做项目时，这种转变需要不同的方法。在本文中，我想重点关注根据 scrum 的细化，它是 sprint 中一个持续的过程。创建、完善和完善产品待办事项的过程。基于我作为前业务和系统分析师以及现在作为解决方案架构师的工作经验，我分享了我的知识，这些知识简单有效，并解释了一些有趣的观察结果。那么，细化在实践中意味着什么？ Scrum 建议如何符合现实？哪一方反映了这种体验——纯粹主义者还是实践者？如果您想知道答案并养成进行有效改进的习惯，请舒适地坐着并继续下一段:)。

在解释了这些先决条件之后，我们将继续前进。我即将从不同的角度来看待细化。对立的两个方面是技术方面>所以我们，技术人员如何在这个细化的基础上玩耍，另一方面，这确实是一种商业观点。

让我们从冲刺时间的观点开始。

一开始，作为一名架构师，我需要确保所有计划好的故事都被明确定义，并且对冲刺的分析已经完成。在两周的冲刺中，应该不会超过 2-3 天。与此同时，业务团队有时间在内部开会并集思广益，讨论即将到来的 sprint 的要求——在我的例子中，他们定义了用户故事和验收标准。然后，我组织了一个预先计划会议，在会议上，企业知道接下来 1-2​​ 个 sprint 的范围，我与产品负责人一起确定优先级和次序。通常，这次会议让我对应该交付的内容有一种高层次的感觉。

完成后，我可以专注于用户故事并将需求分解为更小的部分。有时它发生在同一次会议上，但很难集中注意力超过 90 分钟。这真的很耗费脑力，所以最好的主意是在第二天组织一次单独的会议。

当第一批需求准备就绪时，我与开发团队组织了第一次评估会议（记住——根据新的 scrum 指南，它是开发人员团队），持续时间最长为 60 分钟。细化的结果是估计会议的输入。这不仅给了我估计分数（我的案例中的故事点规则基准），而且我还征求了开发团队的第一批反馈——我忘记问的问题，业务应该澄清。在冲刺的中间，架构师应该处理在预计划会议中讨论的需求。理想情况下，在第一次评估会议的 2 天后，应该进行第二次评估会议。这足以让我准备另一块业务需求。

现在，我们正处于 sprint 的第 7-8 天。双周冲刺有 10 个工作日（包括 Scrum 仪式 1 天）。最后，我需要确保整个范围都已交付并经过良好测试。为了实现这一点，我一直与开发团队保持沟通，并对当前的目标和障碍做出反应——这是我在听每日 Scrum 仪式时的目标。然后，在 sprint 的最后一天，我帮助产品负责人选择范围并接受下一个 sprint 的计划，这样计划会议就容易一点。哪些需求是经过细化和估计的，哪些不是。有时，产品负责人坚持要求您就用户故事达成一致，但这些故事并未做好充分准备——但请记住，最终是开发团队在计划会议期间决定他们是否就 sprint 范围达成一致。平衡这一点至关重要，因为当企业做出决定时，我的意见非常重要。

上述时间表对于团队来说可能是一个很好的起点。我总是从遵循这些规则开始，然后根据环境调整计划。我永远不会忘记预先安排定期举行的会议，以便我和我的团队遵循相同的节奏。产品负责人的日历通常充满约会，因此它也有助于计划一周。

现在，当涉及到与 sprint 时间相关的主题时，我想深入探讨并作为与开发人员打交道的技术人员讨论上述改进。然后，我们将继续前进，我们将戴上与商务人士打交道的人的眼镜。

从团队开始，如果我知道团队不仅充满了自我管理的专家，而且还包括一名测试人员，我就放心了。如此简单，如此真实。一名质量保证人员应该能够测试最多 6-7 名开发人员的工作。在我的例子中，给定 6 名开发人员和 1 名测试人员的团队，当 QA 工程师从团队中移除时，整体 sprint 效率下降了 20%，因为需要其他人来接替他的职责。开发人员和产品负责人充当测试人员，通常没有足够的时间来做这件事，应用程序的质量立即下降。我只想指出，在一个削减成本的团队中，当客户开始认为减少团队可能是一个好的决定时，我付出了很多努力来说服他们不要这样做，因为这绝对是不会还清。感受到持续的压力也会影响团队在日常合作和改进中的行为。开发人员应该做他们的工作，测试人员应该做他们的工作，而我应该做我的工作。因为团队需要 Scrum Master 而将业务分析师转换为 Scrum Master 角色也不是一种选择。不幸的是，我看到这种情况发生了，士气很快就暴跌了——在团队感觉不那么投入并成为工人而不是被聘用的顾问之后不久。

在细化期间有一个小备份怎么样？好点子！你知道“tres amigos”吗？众所周知的实践“tres amigos”是分析的补充方法。它从三个不同的角度来看待需求——业务、测试和交付。它促进了对将要交付的未来增量的共同理解。简单地说，我们可以制造出质量更好的产品。但它不必仅限于三个人。如果我知道在讨论范围内至少有一个与用户界面相关的故事，我也会邀请一位前端开发人员。如果我知道我们将讨论业务逻辑，我还会将一位后端开发人员列入我的邀请名单。为什么？因为：

当然，也可以邀请任何其他人来加速改进过程——Scrum 旨在改进，因此任何事情都可以在回顾会上讨论并在下一个 sprint 中实施，看看另一种方法是否能产生更好的结果。然而，我始终记得将每个必要的观点包含在尽可能小的群体中。我的职责是使分析和架构保持最新。很难“即时”更新分析。我注意到所有必须做的事情。当然，我并不孤单。我将所有“待办事项”指向团队并就职责达成一致——这类似于明确角色分配的问题。例如：他们（业务）更新 JIRA 中的验收标准和需求描述，我更新分析、图表、用户界面和我们保持融合的所有其他内容。

JIRA 中的任务应该链接到汇合页面以便于导航——轻松访问技术、业务分析或用户界面线框非常有帮助。我在 Confluence 上保留了一个直观的页面树，以便有效地浏览内容。说到 JIRA，“IN REFINEMENT”、“REFINED”、“IN BACKLOG”等状态可能会使项目更易于管理和控制。对于团队成员来说，因为他们可以更透明地表达他们当前的状态并管理他们的日常任务，而对于利益相关者来说——因为图表和统计数据更加准确。

我遵循图纸比文字表达更多的原则。它不需要是普通的 UML，但它需要每个人都容易理解。我绘制序列图来显示流程的顺序和组件的职责。对于开发人员来说，当谈到新的集成点时，它是最有趣的工件。每个组件的通信顺序和输入/输出数据帮助我将分析质量保持在高水平。更重要的是，我绘制状态机/活动图以更好地表达需求。此外，我会在每个 sprint 之后更新架构组件图——我不是唯一使用它的人。重点是不要害怕绘图——它既是需求分析，也是未来系统的文档。企业很快就会开始理解所有图表，效率也会提高——值得一提的是实践本身（我真的很喜欢我工作的这一部分:)）。

当我提到架构时，我想问你一个问题——你知道我们为什么要设计反映业务需求的经过深思熟虑的系统架构吗？我们不这样做是因为架构师想要遵循最新的设计模式。有效工作的系统架构也不是最重要的因素。架构师应该设计最好的（对于给定的情况）可能的系统架构，以降低维护成本并使系统易于更改。所有工作组件都应该足够灵活，以适应世界要求的步伐。我们调整得越快，我们获得的竞争优势就越大。另一方面，系统的代码越多，改变其行为的难度就越大。这就是为什么应该在项目一开始就建立开发原则的原因，因为最初不可能注意到一个糟糕的设计。值得一提的是，每一个捷径和变通方法都会有麻烦。客户推动交付更多更快的产品是很常见的。在这种情况下，我会解释这个决定对项目意味着的所有后果，并确保企业理解它们。这并不容易，有时他们会在冲刺之间改变主意。这就是系统架构应该尽可能灵活的原因，因为变化是开发过程的内在特征。尽管如此，不要让系统的每一部分都可配置——它应该成为讨论的主题，了解全局有助于做出正确的决定。如果团队不知道接下来几个月的计划是什么，我会要求提供路线图或帮助进行准备。这是对做出更好的架构决策的巨大支持，这些决策将在未来符合其他系统组件。此外，开发团队了解上下文，这肯定会增加他们的参与度。

不仅上下文很重要，信任也很重要。当我给予自由并且团队成员实际上可以做出架构决策时，他们的动力就会增加。我也直言不讳地表达了我的观点，但我把最后的决定权留给了团队——它通常是有效的，而且决策就像我是一个决策者一样。信任使团队敬业。我永远不会忘记团队由专家组成。一个人不可能熟记系统的每一部分。他们的论点通常也是正确的。分享知识应该是一种日常实践。一个好的团队领导者可以发展团队并使其自给自足。当一切都像瑞士手表一样工作时，这是非常有益的。这也让我和团队的工作更加愉快:)。

在与开发者的合作反思之后，我想顺利地转移到商业环境中。

产品负责人是设定目标并接受评论中提出的增量的人。在更大的项目中，业务团队，除了产品负责人，由业务分析师、运营经理和其他人组成。他们都需要找到相同的节奏才能有效地合作——我也是。最好的办法是亲自与他们见面。我为定期出差做好了准备。如果不幸的是这是不可能的（原文如此！covid），请要求打开相机。在谈判过程中建立业务关系很有帮助。我的观点对企业绝对有影响，他们依赖于我的专业精神和经验。如果我真正关心和理解他人，决策会更准确。记住这非常重要的一句话：首先尝试理解，然后被理解。我的责任是让企业意识到后果。我从不让情绪变得更好——相反，我扮演专业人士的角色。此外，我解释了每个决策对应用程序级别的业务影响——只有这样他们才会知道如何适当地做出选择。我对任何问题和已确定的障碍完全透明。诚实很快就会得到赞赏——其他人会知道他们可以指望我。谁知道，也许多亏了这一点，我会避开即将到来的混蛋？

同样重要的是培养同理心并设身处地为用户着想。这有助于我提供尽可能好的前端。通常，利益相关者根据接口判断应用程序。如果我有足够的时间，我会准备不止一个用户界面线框图。显然，企业只需要选择一个，但我是一个积极主动、有爱心的团队成员。当每个人都看到草稿时，谈论功能会更容易。也许，我们会想出一个比最初计划的更好的想法。毫无疑问，可视化起着重要作用，尤其是在远程工作期间。

有效工作的另一个症状是在细化之前准备好用户故事。企业需要在亲自满足要求之前就要求进行内部会议。我并不是说头脑风暴不合适——确实如此！但是，让我们在单独的会议上这样做。我作为会议的主持人，遵守使细化更容易进行的规则。如果会议朝着错误的方向前进，我也会指导其他人。这就是为什么使用 scrum master 的知识和技术来培养良好实践的原因。当我创建会议时，我会提醒自己一个 GOAL 原则并在描述中写下：会议的目标——我想要实现的目标，目标——我想要如何实现目标以及议程——对会议参与者有用熟悉会议的细节和计划的长度。如果需要研究，我会使用尖峰，当我觉得讨论太长时，我也会使用时间框。应该准备好用户故事，这意味着应该写下验收标准并提供描述。这种方法给了我另一个机会——在会议之前发送与需求相关的主题和问题。这些提出的问题显示了分析中的差距并激发了讨论。如果会议结束并且问题仍然存在，我总是发送它们并推动答复。

我敢肯定，即使是分析中一个未回答的问题或差距也会在开发过程中反弹，我最终需要回答它。我试图让我的产品负责人养成定期审查验收标准的习惯——通常，产品积压是在项目一开始就创建的。当然，积压的项目也可能会发生变化，我的工作是确保所有项目都反映当前的业务需求。说到变化——如果在冲刺期间需求发生变化，我们应该如何行动？这是可能发生的最糟糕的事情，因为它会使开发人员的工作变得复杂。它影响了整个团队的士气——没有人愿意重复做同样的事情。如果发生这种情况是因为没有对某些事情进行足够的分析，我会吸取教训，在下一次会议上，我会更深入地研究这些故事。将故事拆分为更细化的部分可能会有所帮助。但是，如果发生这种情况是因为企业突然改变了决策——我会评估根据新协议交付某些东西所需的工作量。可以做一些小的调整，我表现出团队合作的迹象。然后，企业觉得我尽一切努力满足他们的需求。相反，他们感觉不到可以随时要求改变。如果某些事情已经完成，或者我需要牺牲其他故事来实施更改——我会要求创建另一个用户故事并在下一个 sprint 中进行计划。

当故事细粒度时，更容易避免此类事情。较小的故事也更容易测试。例如，我向业务部门展示了界面的第一个版本，以便他们可以验证他们在线框中看到的内容是否是已构建的。即使在开发过程中也可以测试算法——只需要求业务部门提供测试数据和预期输出——团队可以轻松地根据给定的输入运行算法。它节省了时间，我不需要手动测试所有场景。在时间紧迫的情况下——我建议更改范围。很高兴知道企业心目中的理想解决方案，但在这种情况下，我会验证哪些需求最有价值，哪些可能会被拆分并稍后交付。我写下所有协议，例如会议期间的笔记、错误报告程序等——它还可以节省时间。更重要的是，分析是未来文档的一部分。写得好在冲刺之后不需要任何更新。我把它写成最后的形式，这样我以后就不需要修复它了。

我认为是时候总结并得出结论了。

基本上，准备的用户故事越好，我花在改进上的时间就越少，这会遵循更精确的估计并意味着更容易的计划会议。花费在澄清上的时间更少，工作顺利进行。

很明显，我至少需要提前准备一个 sprint——我是计划会议的主持人。产品负责人只选择最终范围——我和团队正在详细规划工作。我尝试改进 2 个冲刺。为什么？它建立了团队的可预测性。这非常重要，因为它需要计划全年的功能——所以这提高了我在利益相关者眼中的质量。它还会影响团队的稳定性——团队的整体健康状况。

在规划会议期间，我也坚持要留出 15% 的 sprint 容量缓冲用于细化目的。据说它应该花费 - 或多或少 10% 的 sprint 时间，但复杂的项目需要更多时间。我所说的复杂是指当我们创建一个新产品时，一个新的流程或要求是不为人所知的并且被分解的。我们需要有足够的时间来讨论最底层的设计并澄清所有的歧义。这一次也帮助团队提高了团队技能的熟练度——他们互相学习:)。

拥有路线图或影响图显然非常有帮助。我平衡​​了我们在每个需求上使用了多少业务时间。没有必要专注于提前几周计划好的事情。我与业务和利益相关者沟通的方式也很重要——业务并不总是正确的。我应该有足够的勇气和技巧以友好的方式传达这一点。

有一个道理，一个正确答案怎么做细化？我想不是。没有结论——这个问题没有客观的解决方案。它应该是经验性的，基于团队的经验和利益相关者的情况。尝试实施你的想法——Scrum 旨在测试和调整！

原文：https://bluesoft.com/how-to-conduct-the-excellent-refinement/

本文：https://jiagoushi.pro/node/1839