您如何在Scrum中处理设计？对于每次Scrum迭代，您是否还有写得很好的设计文档？您是否只是以UML图为特色进行设计说明？或者，您是否拥有注释良好的代码？
每次迭代都可能涉及更改设计，所以我只想知道人们是如何捕捉到这一点的，因此新开发人员可以轻松地了解领域并尽快入职。
Answers:
关于这个话题，我有很多话要说。我已经看到许多案例，其中公司/团队/人员说他们正在使用敏捷方法进行软件开发，但实际上，他们希望在不遵守原则的情况下获得敏捷方法所带来的回报。
为了使快速迭代生效，您应该进行测试驱动的开发（我不得不说您必须勉强地执行TDD）。在TDD中，您的测试表达了代码的设计和意图（当他们说“代码就是文档”时，他们应该说的是“测试就是文档”）。通过编写表示您对现有功能的理解的单元测试，您可以明确说明您认为代码需要做什么。然后，编写执行此操作的代码。然后，您重构该代码，以便遵循良好的架构原则“ Red-Green-Refactor”。
在每次签入（甚至在每次签入之前）运行单元测试，都可以验证您编写的新代码不会破坏应用程序其他部分的预期功能。这提供了一个安全网，使您可以毫不留情地更改代码。随着对现有需求的了解的增加，您可以修改测试以反映该新知识。真正的设计在于单元测试。其他所有内容（包括未涵盖的代码）都是谎言。
这是一些推荐的阅读
这些是开始学习如何真正实现敏捷开发的好地方。
Scrum是一种项目管理方法，而不是软件开发方法。Scrum通常与敏捷方法结合使用。您的答案就在其中。
Scrum是基于敏捷值的迭代和增量模型。这意味着您没有单独的设计阶段。这个想法是，您应该一直在处理设计，就像在整个项目中一直在处理分析，实现，测试和集成一样。
您需要为此做一些计划。进入sprint计划会议，团队将在此评估未来sprint的任务。大多数人没有意识到这不仅是一次估算会议，还是一项设计工作。例如，一个任务可能是“为新汽车模型添加代码”。您尚无法估计，您需要了解更多。因此，团队讨论了设计并提出了一个广泛的解决方案（“子类Car？”），并将其作为对任务的提醒。您很少需要比这更多的手续。您现在有了解决该问题的想法。您尚不具备所有详细信息，这很好，您对设计足够了解，可以做出合理的估算。无需创建任何图（此时）。
对于实际的物理文档，我建议在墙上创建系统概览图，以供所有人查看。概述只需要包含最重要的类和模块，并且几乎不需要更新。同样，为系统中最重要的类创建一些状态图也非常有帮助。散布一些典型用例的选择序列图，使人们可以轻松快速地了解事物之间的联系。我假设您可以从代码中生成类层次结构图，因此可以轻松解决该问题。
请注意，所有图都是在实际实现之后创建的。这与“通过综合文档工作的软件”和及时设计保持一致。
是的，可读代码绝对是文档。
