There can be architectural requirements in addition to user-specified requirements that can muddy this a bit. Thus, one could have a, "You will use MVP on this," that does limit the design a bit.
In my current project, aside from requirements from outside the team, the programmer just figures it out is our standard operating procedure. This can mean crazy things can be done and re-worked later on as not everyone will code something so that the rest of the team can easily use it and change it.
Code, comments and docs cover 99% of where coding details would be found. What's left, if one assumes that wikis are part of docs?
Scrum says absolutely nothing about programming tasks. Up to you to work that out...
Scrum doesn't necessarily have anything explicitly to do with programming - you can use it to organise magazine publication, church administration, museum exhibitions... it's a management technique not explicitly a way of managing software development.
If you do extreme programming inside scrum, you just break your user stories for the iteration down into task cards, pair up and do them.
如何实施任务是在我们评估任务时决定的。团队成员将任务分成更小的项目。如果有必要进行设计，团队必须先进行讨论，然后才能进行拆分。如果设计太复杂而无法在本次会议中完成，我们将简单地创建一个设计任务，敏捷/scrum 不会强制执行此操作（在 wiki 中、在文档中、在您的脑海中、在餐巾纸上、你的选择）除了说尽可能少的文档。在大多数情况下，设计是经过一番辩论后当场决定的，由此产生的较小任务是对如何完成事情的描述。
When I submit tasks to my programming team, the description usually takes the shape of a demo, a description on how the feature is shown in order to be reviewed.
How the task will be implemented is decided when we evaluate the task. The team members split the task in smaller items. If a design is necessary, the team will have to discuss it before being able to split it. If the design is too complex to be done inside this meeting, we will simply create a design task, agile/scrum doesn't force how this should be done (in a wiki, in a doc, in your mind, on a napkin, your choice) aside for saying as little documentation as possible. In most case the design is decided on a spot, after a bit of debate, and the resulting smaller tasks are the description of how things will be done.
Also, sometimes the person doing it will make discoveries along the way that change the design and so, the way to work on it. We may then thrash some cards, make new ones. The key is to be flexible.
You do what you need to do. Avoid designing everything up front, but if there are things you already know will not change, then just capture them. However, corollary to YAGNI is that you don't try to capture too much too soon as the understanding of what is needed will likely change before someone gets to do it.
I think your question sounds more like you should be asking who, not when or where. The reason Agile projects succeed is that they understand that people are part of the process. Agile projects that fail seem to tend to favor doing things according to someone's idea of "the book" and not understanding the people and project they have. If you have one senior team lead and a bunch of junior developers, then maybe the senior should spend more of their time on such details (emphasis on maybe). If you have a bunch of seniors, then leaving these to the individual may be a better idea. I assume you don't have any cross-team considerations. If you do, then hashing out some of the details like DB schema might need to come early if multiple teams depend on it.
If you (as team member) feels the need to talk about design, to so some design brainstorming with other team members, then just do it. About the how, many teams will just use a whiteboard and brain juice for this and keep things lightweight which is a good practice IMHO.
Personally, I don't see much value in writing down every decision and detail in a formalized document, at least not in early project phases. Written documents are very hard to maintain and get deprecated pretty fast. So I tend to prefer face to face communication. Actually, written documents should only be created if they're really going to be used, and in a very short term. This can sound obvious but I've seen several projects very proud of their (obsolete) documentation but without any line of code. That's just ridiculous. In other words, write extensive documentation as late as possible, and only if someone value it (e.g. the product owner).
发布评论
评论（5）
除了用户指定的要求之外，还可能存在架构要求，这些要求可能会使情况变得有点混乱。因此，人们可能会说“你将在这方面使用 MVP”，这确实会限制设计。
在我目前的项目中，除了团队外部的要求之外，程序员只是认为这是我们的标准操作流程。这可能意味着可以完成一些疯狂的事情，并在以后重新进行工作，因为并不是每个人都会编写一些代码，以便团队的其他成员可以轻松地使用它并进行更改。
代码、注释和文档涵盖了 99% 的编码详细信息。如果假设 wiki 是文档的一部分，还剩下什么？
There can be architectural requirements in addition to user-specified requirements that can muddy this a bit. Thus, one could have a, "You will use MVP on this," that does limit the design a bit.
In my current project, aside from requirements from outside the team, the programmer just figures it out is our standard operating procedure. This can mean crazy things can be done and re-worked later on as not everyone will code something so that the rest of the team can easily use it and change it.
Code, comments and docs cover 99% of where coding details would be found. What's left, if one assumes that wikis are part of docs?
Scrum 完全没有提及编程任务。由您来解决...
Scrum 不一定与编程有任何明确的关系 - 您可以用它来组织杂志出版、教堂管理、博物馆展览...这是一种不明确的管理技术一种管理软件开发的方法。
如果您在 Scrum 中进行极限编程，您只需将迭代的用户故事分解为任务卡，配对并执行它们。
Scrum says absolutely nothing about programming tasks. Up to you to work that out...
Scrum doesn't necessarily have anything explicitly to do with programming - you can use it to organise magazine publication, church administration, museum exhibitions... it's a management technique not explicitly a way of managing software development.
If you do extreme programming inside scrum, you just break your user stories for the iteration down into task cards, pair up and do them.
当我向编程团队提交任务时，描述通常采用演示的形式，描述如何显示功能以便进行审查。
如何实施任务是在我们评估任务时决定的。团队成员将任务分成更小的项目。如果有必要进行设计，团队必须先进行讨论，然后才能进行拆分。如果设计太复杂而无法在本次会议中完成，我们将简单地创建一个设计任务，敏捷/scrum 不会强制执行此操作（在 wiki 中、在文档中、在您的脑海中、在餐巾纸上、你的选择）除了说尽可能少的文档。在大多数情况下，设计是经过一番辩论后当场决定的，由此产生的较小任务是对如何完成事情的描述。
此外，有时做这件事的人会在改变设计以及工作方式的过程中有所发现。然后我们可能会破坏一些卡片，制作新卡片。关键是要灵活。
When I submit tasks to my programming team, the description usually takes the shape of a demo, a description on how the feature is shown in order to be reviewed.
How the task will be implemented is decided when we evaluate the task. The team members split the task in smaller items. If a design is necessary, the team will have to discuss it before being able to split it. If the design is too complex to be done inside this meeting, we will simply create a design task, agile/scrum doesn't force how this should be done (in a wiki, in a doc, in your mind, on a napkin, your choice) aside for saying as little documentation as possible. In most case the design is decided on a spot, after a bit of debate, and the resulting smaller tasks are the description of how things will be done.
Also, sometimes the person doing it will make discoveries along the way that change the design and so, the way to work on it. We may then thrash some cards, make new ones. The key is to be flexible.
你做你需要做的事。避免预先设计所有内容，但如果您已经知道的事情不会改变，那么就捕获它们。然而，YAGNI 的推论是，你不要试图太快地捕获太多，因为在有人开始做之前，对所需内容的理解可能会发生变化。
我认为你的问题听起来更像是你应该问谁，而不是何时或哪里。敏捷项目成功的原因是他们明白人是流程的一部分。失败的敏捷项目似乎倾向于按照某人“书本”的想法做事，而不是理解他们拥有的人员和项目。如果你有一个高级团队领导和一群初级开发人员，那么也许高级开发人员应该花更多的时间在这些细节上（强调也许）。如果你有一群老年人，那么将这些事情留给个人可能是一个更好的主意。我假设您没有任何跨团队的考虑。如果这样做，那么如果多个团队依赖它，则可能需要尽早讨论一些细节（例如数据库架构）。
You do what you need to do. Avoid designing everything up front, but if there are things you already know will not change, then just capture them. However, corollary to YAGNI is that you don't try to capture too much too soon as the understanding of what is needed will likely change before someone gets to do it.
I think your question sounds more like you should be asking who, not when or where. The reason Agile projects succeed is that they understand that people are part of the process. Agile projects that fail seem to tend to favor doing things according to someone's idea of "the book" and not understanding the people and project they have. If you have one senior team lead and a bunch of junior developers, then maybe the senior should spend more of their time on such details (emphasis on maybe). If you have a bunch of seniors, then leaving these to the individual may be a better idea. I assume you don't have any cross-team considerations. If you do, then hashing out some of the details like DB schema might need to come early if multiple teams depend on it.
如果您（作为团队成员）觉得有必要谈论设计，以便与其他团队成员进行一些设计头脑风暴，那就去做吧。关于如何操作，许多团队只会使用白板和脑汁来实现这一点，并保持轻量级，这是一个很好的做法，恕我直言。
就我个人而言，我认为在正式文件中写下每个决定和细节并没有多大价值，至少在项目早期阶段是这样。书面文档很难维护并且很快就会被废弃。所以我更喜欢面对面的交流。实际上，只有在确实要使用且在很短的时间内才应该创建书面文档。这听起来很明显，但我见过几个项目对他们的（过时的）文档非常自豪，但没有任何代码行。这太荒谬了。换句话说，尽可能晚地编写大量文档，并且只有在有人重视的情况下（例如产品负责人）才编写。
If you (as team member) feels the need to talk about design, to so some design brainstorming with other team members, then just do it. About the how, many teams will just use a whiteboard and brain juice for this and keep things lightweight which is a good practice IMHO.
Personally, I don't see much value in writing down every decision and detail in a formalized document, at least not in early project phases. Written documents are very hard to maintain and get deprecated pretty fast. So I tend to prefer face to face communication. Actually, written documents should only be created if they're really going to be used, and in a very short term. This can sound obvious but I've seen several projects very proud of their (obsolete) documentation but without any line of code. That's just ridiculous. In other words, write extensive documentation as late as possible, and only if someone value it (e.g. the product owner).