设计及其在看板开发方法中的适用性
设计如何融入看板方法。是否应该有一个专门的柱子来放置设计，或者是高和高？在故事从故事队列移动到 WIP 之前就完成了故事的底层设计？
How does design fit into the kanban method. Should there be a dedicated column for design to be placed in, or is the high & low level design of the story done before it even moves from the story queue into the WIP?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
没有单一的答案。这完全取决于团队如何运作。使用看板的基本做法是将您的工作方式映射到看板中。这意味着您的问题的答案就在您构建软件时遵循的流程中。
为了帮助您一点 - 根据使用看板时应遵循的规则：
您应该可视化工作流程，这意味着在现实生活中以某种方式分离的所有阶段都应该在看板上以这种方式可视化。
您的政策应该明确，这意味着团队中的每个人都应该对流程有相同的理解。如果便签位于特定列中，则应表示某个功能处于这样那样的状态，并且对于团队中的每个人来说都应该是显而易见的。
此外，在处理交接时引入单独的列是一种典型的情况，这意味着功能从一个团队成员移交给另一个团队成员，例如用于开发（由开发人员完成）和测试（由质量工程师完成）的单独列。
在谈论设计时，我看到了不同的方法：整个设计使用单个单独的列，当设计有点广泛时使用更多列，或者当设计与开发合并/混合时根本没有专用列。问问你自己和你的团队，在你的情况下它是什么样子，你就会得到董事会应该是什么样子的答案。
最后的建议是：不要害怕尝试。如果您不确定自己的工作方式（这是可能的），请尝试不同的方法并检查哪种电路板设计最适合您的情况。
There is no single answer. It all depends how a team works. What you basically do with Kanban board is you map the way you work into the board. It means the answer to your question is within the process you follow when you build software.
To help you a bit - according to rules you should follow when you work with Kanban:
You should visualize workflow, which means all stages which are somehow separate in real life should be visualized in such way on the board.
Your policies should be explicit, which means everyone in the team should understand the process the same. If a sticky note is in a specific column it should mean that a feature is in such and such state and it should be obvious for everyone in the team.
Additionally, it is a typical situation that separate column is introduced when you deal with handoffs, meaning a feature is handed off from one team member to another, e.g. separate columns for development (done by developer) and testing (done by quality engineer).
When talking about design I've seen different approaches: either a single separate column for whole design, more columns when design is kind of extensive or no dedicated column at all when design is merged/mixed with development. Ask yourself, and your team, how it looks like in your case and you will have the answer how the board should look like.
And one final advice: don't be afraid of experimenting. If you aren't sure how you work, which is possible, try different things and check which board design works best in you case.