当你在 Scrum 中有 sprint 任务时，你把你想如何编程的东西放在哪里？例如，假设我正在制作一个俄罗斯方块游戏，并且我想构建游戏中跟踪当前分数和高分表的部分。我有我的功能、我的用户故事和我的任务，但现在我想谈谈如何设计它。
该设计是在某处记录在冲刺中的某处关于如何做到这一点的东西，还是只是程序员想出来的东西。您是否将任务 x 使用数据库某某，创建这些列等？如果没有，你会记录下来吗？这就是 trac 的用途吗？我不是说太高级的设计。
我在这里谈到了它： 在 Scrum 过程中，编程架构是在哪里讨论的？
但我目前的问题是在基础设施之后的项目中。我现在更多地谈论中间。实际输入代码。一些人说他们一路决定，一些团队负责人。除了带有文档和注释的代码本身之外，这是否在任何地方都有记录？
编辑：你的老板只是说，好吧，你做这部分，我不在乎怎么做？
谢谢你。
除了用户指定的要求之外，可能还有一些架构要求可能会使这有点混乱。因此，可以有一个“你将在此使用 MVP”，这确实限制了设计。
在我目前的项目中，除了团队外部的要求外，程序员只是认为这是我们的标准操作程序。这可能意味着疯狂的事情可以在以后完成并重新工作，因为不是每个人都会编写代码，以便团队的其他成员可以轻松地使用和更改它。
代码、评论和文档涵盖了 99% 的编码细节。如果假设 wiki 是文档的一部分，还剩下什么？
Scrum 完全没有提到编程任务。由你来解决...
Scrum 不一定与编程有任何明确的关系——你可以用它来组织杂志出版、教堂管理、博物馆展览……它是一种管理技术，而不是明确的管理软件开发的方式。
如果您在 scrum 中进行极限编程，您只需将迭代的用户故事分解为任务卡，配对并执行它们。
当我向我的编程团队提交任务时，描述通常采用演示的形式，描述如何显示功能以供审查。
当我们评估任务时，将决定如何执行任务。团队成员将任务拆分为较小的项目。如果需要设计，团队必须先对其进行讨论，然后才能对其进行拆分。如果设计太复杂而无法在本次会议中完成，我们将简单地创建一个设计任务，敏捷/scrum 不会强制执行此操作（在 wiki、文档、您的脑海中、在餐巾纸上，您的选择）除了说尽可能少的文档。在大多数情况下，设计是在经过一番辩论后当场决定的，由此产生的较小任务是对如何完成工作的描述。
此外，有时做这件事的人会在改变设计的过程中发现，从而改变设计的工作方式。然后我们可能会打一些牌，制作新牌。关键是灵活。
你做你需要做的事。避免预先设计所有东西，但如果有些东西你已经知道不会改变，那就抓住它们。然而，YAGNI 的推论是不要试图过早捕捉太多，因为在有人开始之前，对所需内容的理解可能会发生变化。
我认为您的问题听起来更像是您应该问谁，而不是何时或何地。敏捷项目成功的原因在于他们明白人是过程的一部分。失败的敏捷项目似乎倾向于根据某人对“书”的想法做事，而不是理解他们拥有的人和项目。如果您有一个高级团队领导和一群初级开发人员，那么高级开发人员可能应该将更多时间花在这些细节上（强调可能）。如果您有一群老年人，那么将这些留给个人可能是一个更好的主意。我假设你没有任何跨团队的考虑。如果你这样做了，那么如果多个团队都依赖它，那么可能需要尽早解决一些细节，比如 DB 模式。
如果您（作为团队成员）觉得有必要谈论设计，与其他团队成员进行一些设计头脑风暴，那就去做吧。关于如何，许多团队将为此使用白板和脑汁并保持轻量级，恕我直言，这是一个很好的做法。
就我个人而言，我认为在正式文档中写下每个决定和细节并没有多大价值，至少在项目的早期阶段是这样。书面文档很难维护并且很快就会被弃用。所以我更喜欢面对面的交流。实际上，只有在真正要使用的情况下，并且在很短的时间内，才应该创建书面文件。这听起来很明显，但我看到几个项目对他们的（过时的）文档感到非常自豪，但没有任何代码行。这太荒谬了。换句话说，尽可能晚地编写大量文档，并且只有在有人重视它的情况下（例如产品所有者）。