并且，要获取更多图片，请使用 scrum+board 尝试使用 Google 图片，< a href="http://images.google.com/images?q=kanban" rel="noreferrer">看板、scrumban、scrum+kanban。
We use something inspired by the famous Scrum and XP from the Trenches from Henrik Kniberg, the columns being adapted depending on the context (often: TODO, ON GOING, TO BE TESTED, DONE):
Product Backlog Items (PBIs) are printed as "physical cards" (A5 format) for the Sprint Planning Meeting (at least the most important). Once the team has picked up PBIs for the next iteration, items are break down into tasks/activities (on sticky notes). After the meeting, everything goes on the Scrum Board and I suggest to use tape or thumbtacks or magnets. PBIs are ordered by importance, most important at the top of the board, less important at the bottom. The team should work on the most important item first until it gets done. First, activity post-its move from the left to the right. Then, the PBI jumps to Done. Unexpected tasks are added to an "Unplanned items" zone (to take them into account in the burndown chart). Future PBIs stay visible in a "Next" zone (if all items are completed during the iteration, we pick a new one from there). Pretty simple.
These practices allow to detect smells visually, for example:
stucked tasks (i.e. tasks that are not moving) that show a potential impediment
team doing things in the wrong order and not focusing on top-priority items, like on your sample :)
Here is our Kanban Board that we use at TargetProcess. We do not work on Tasks level, just on User Stories and Bugs level. Sometimes we create tasks, but they are not tracked explicitly on the board.
We do not estimate User Stories and Bugs, but try to split Stories into smaller (with mixed success). Columns are self-explanatory. We accumulate items in Tested column, then create a branch , smoke test it and release new build. Usually we release new build every two weeks.
Also the board shows developers and testers load and classes of services via color coding.
UPD. Now we have several small teams and use a single board to track progress of all teams in http://www.targetprocess.com/3
I suggest you to take a look on Eylean board. http://www.eylean.com/?utm_source=geffort&utm_medium=content&utm_campaign=geffort
it can fit all your needs because of intuitive interface, statistics, dashboard. Also it fits any process and the most important thing it is very easy to use. This board allows you to represent several projects on one board using rows. All the rows may be visible at a time or you can remove selected ones from the scope.Another solution may be task grouping and filtering by categories - then all the tasks can be represented on one board and row, but attached to different categories.
In practice the organisation of the work-in-progress board is best left for the team to determine depending on your circumstances and environment. (Agile == selfmanagement.)
That said, here's what we did in my previous team, part of a 300+ developer effort that was relatively new to Agile and Scum:
We had two boards - one with index cards for forthcoming stories so we could tell what was coming up, and one with the current sprint's work. Our columns on the current sprint board were simply
Not Started
Under Development
Dev Done
In QA
Complete ("Done Done")
and a box in the corner for Blocked.
A post-it note represented each story.
Developers each had a little magnet which they used at the standup each morning to signify who was working on what. Our team was quite big (~ 12 at one point) so this really helped figure out who was paired with whom.
We didn't bother with an electronic version (no point), although our Product Owner did have a Scrumworks system that he needed to keep up to date. We kept as far away from that as we could!
I'm pretty keen on Lean/Kanban and we've been iterating on our process for a while, initially through a customized workflow in JIRA, but that's not exactly frictionless given the admin complexity in the enterprise version. We've now expanded our use of a whiteboard and have decided to iterate our process using the whiteboard for a while before re-codifying it in JIRA. Here is an example of our layout:
We are 6 developers
When a story is in dev, it's on a dev's desk. Likewise with being reviewed, being QA'd, etc. This means every card on the board represents and actionable item, and also provides a decently accurate snapshot of iteration progress. The rule is that only in exceptional circumstances do you have more than one card on your desk.
We've agreed not to have more than two cards "pile-up" in the Awaiting Review column. This maintains a degree of "flow".
This is pretty close to mapping the value stream except for the awaiting deployment part, which is a hack to fix the problem where QA can't QA an item until we've deployed it on their server - we deploy 3/4 times during a 2 week iteration.
One thing I have noticed from mapping the value stream on an "information radiator" is that it does magically focus people on the actual value-add work that needs to be done, and that seems to up the pace of business-value development and keep up momentum.
We're experimenting with a couple of different board structures across a few different projects that we're running. One project has the most basic structure we can use:
| (Sprint) Backlog | In Progress | Done |
As much as possible, we try to have a single post-it to represent both the Dev and QA activities for a story.
The above structure has seemed to work ok for the developers on the project, but the QA members have struggled to know when a story had the development work complete such that they could execute their tests for that story. We found ourselves moving the stories to the "far side" of the In Progress section to indicate that the Dev work was done and that QA could pick up that story. This very quickly became quite unmanageable as the In Progress section filled up.
This led to the second iteration of board structure for another project which is:
| (Sprint) Backlog | In Progress | Ready for Test | Done |
The newly added section Ready for Test essentially became a formal section of the board that was previously the "far side" of the In Progress section. On the surface of it, this should have made things clearer for the QA members, but this still caused some confusion as people had different interpretations of what Ready for Test meant (I'll not bore you with the different interpretations here).
This has then led to the latest iteration of board structure we're using on another project:
| (Sprint) Backlog | Dev in Progress | Dev Done | QA in Progress | Done |
This is certainly quite a far way from the simple Backlog, In Progress and Done sections of the first iteration, but this appears to be working well for the team. They have a clear understanding of what it means to move a story through various sections of the board and for any one story, it gives a clear picture of where in the life cycle that particular story is. We've only been using this structure since the start of the current sprint (we're 9 days into a 10 day sprint), so we'll be exploring this structure in more detail in our retrospective tomorrow. Not perfect I'm sure, but if it continues to work for the team that is piloting it, we'll try to roll it out across other teams in our organisation.
Story, Not Started, Req/Des/Dev*, Peer Review, QA, Done
The highest priority stories go from top to bottom.
Each story can have multiple tasks so we use a big postit for the story and smaller ones for the tasks. Tasks move from left to right. Every day we check to make sure we're working on the highest priority stories.
We use a sticky white tab on each task where the person working on it puts their initials. When they're done and move it along a new white tab is placed over the old one to show it's available to anyone to pick up. When all the tasks are done, the story is moved to the Done column also and at the standup, all Done work is tallied up and moved up the board to make room at the bottom for more stories.
We also have colored tabs for the stories and tasks to indicate blockages to progress (blue indicating a blockage from another team, red requesting scrum master assistance). We talk about the roadblocks at each standup.
We can see when there is too many tasks in one particular column and shift emphasis to get more to Done. We deliberately added the review column to emphasize that the work needed reviewed by someone other than the person doing it before it got to QA.
Ours looks fairly similar. Each developer has a column and we have rows for 'Done', 'In Testing', 'Work in Progress', 'Backlog'.
And we use actual post-it style notes that we physically move as it goes through each phase.
Personally, I find the system to be lacking...
Manually moving post-its gets to be a pain after a while. Our QA team mostly manages the ticket moving - and it's a constant effort to keep them synched with TFS.
The post-its can really only be moved so many times before they aren't sticky anymore. If a ticket is sent-back from testing and placed into 'In Progress' and then moved back to testing, etc, etc...it doesn't take much for it to end up on the floor.
Sometimes, the sheer volume of notes is overwhelming. Notes have to be stacked to be even remotely visible - we layer them such that we can see each notes unique identifier (as best as we can)...but then you've got a stack of 10 notes and you need to get the 5th out of the stack and you are rapidly contributing to the decrease in stickiness that will end with the notes on the floor.
When the tickets do end up on the floor it's reasonably annoying to find out where they should go. Was that Developer A's ticket? Or B? And was it in Testing? Or was it done? Let's go back into TFS, look up those tickets and then move the post-its accordingly.
Personally, I don't think post-it notes are the appropriate tool here. There are a handful of digital tools that make this sort of thing completely trouble free. We use Team foundation server - and I've seen a couple of really great, robust, free, and even open source tools that will interface with Team foundation server and manage all of that for you, in real time.
Our boards tend to evolve overtime as we progress as a team. I tend to favour physical card boards if you have a collocated to team as it encourages better face to face communication generally from my experience. Obviously there is more overhead, but it's worth it to get the team working together. Another advantage I have seen with physical boards is that it helps with business engagement. Remote stakeholders can't just sign in and see progress within the current sprint and take things out of context as sometimes cards don't tell the full story. They have to have a conversation and come to the board which can be beneficial as things can get explained and it also means that they can be encouraged to help resolve with impediments. However this is not exclusive to physical boards but it helps.
As mentioned our boards evolve overtime with the teams needs. Often we start with textbook scrum, but encourage continuous improvement and usually end up with a scrumban solution. These changes are reflected by visualising the new workflow through the boards. I recently wrote a post on our latest change if your interested have a look at our hourglass scrum / Kanban board
I think the team should get involved in making the boards as it helps the team understand the workflow and not become silo's. Also if the team have had a hand in making the board they police their own processes better which helps with self organisation as it's a product they have had input to.
We went with following board structure in our company.
Backlog | Next sprint | Current sprint | Done
Buffer | Working
Lanes are assigned to specific members. Each member has different job at our office so the tasks vary. We add what we have to work on to our Backlog, then move it into Next Sprint if it approaches the deadline. Blocked green tasks are used for continuous tasks that have to be worked on daily. Red cards indicate importance of the task and have to be finished as soon as possible.
Our board allows us to collaborate freely and add tasks to each others swimlanes if we need something to be done by different department.
We use KanbanTool (Kanbantool.com) to visualize our workflow and manage projects. It's really intuitive and easy to use. Our team communication has improved tremendously.
发布评论
评论（11）
我们使用的灵感来自著名的 来自战壕的 Scrum 和 XP来自 Henrik Kniberg，根据上下文（通常：TODO、ON GOING、TO BE TESTED、DONE）调整列：
替代文本 http://blog.realcoderscoding.com/wp-content/uploads/2008/09/hk.png
产品待办事项 (PBI) 打印为Sprint 计划会议的“实体卡片”（A5 格式）（至少是最重要的）。一旦团队为下一次迭代选择了 PBI，项目就会分解为任务/活动（在便签上）。会议结束后，所有内容都会记录在 Scrum Board 上，我建议使用胶带、图钉或磁铁。 PBI 按重要性排序，最重要的位于板的顶部，不太重要的位于底部。团队应该首先处理最重要的项目，直到完成为止。首先，活动海报从左向右移动。然后，PBI 跳转到“完成”。意外任务将添加到“计划外项目”区域（以将其纳入燃尽图）。未来的 PBI 在“下一个”区域中保持可见（如果在迭代期间完成所有项目，我们会从那里选择一个新项目）。很简单。
这些做法可以通过视觉检测气味，例如：
效果很好。
如果您正在寻找更多“面向看板”的内容，也许可以看看 看板与 Scrum，看板之地的一天以及来自同一 Henrik Kniberg 的看板和 Scrum - 实用指南 。也很棒的东西。
并且，要获取更多图片，请使用 scrum+board 尝试使用 Google 图片，< a href="http://images.google.com/images?q=kanban" rel="noreferrer">看板、scrumban、scrum+kanban。
We use something inspired by the famous Scrum and XP from the Trenches from Henrik Kniberg, the columns being adapted depending on the context (often: TODO, ON GOING, TO BE TESTED, DONE):
alt text http://blog.realcoderscoding.com/wp-content/uploads/2008/09/hk.png
Product Backlog Items (PBIs) are printed as "physical cards" (A5 format) for the Sprint Planning Meeting (at least the most important). Once the team has picked up PBIs for the next iteration, items are break down into tasks/activities (on sticky notes). After the meeting, everything goes on the Scrum Board and I suggest to use tape or thumbtacks or magnets. PBIs are ordered by importance, most important at the top of the board, less important at the bottom. The team should work on the most important item first until it gets done. First, activity post-its move from the left to the right. Then, the PBI jumps to Done. Unexpected tasks are added to an "Unplanned items" zone (to take them into account in the burndown chart). Future PBIs stay visible in a "Next" zone (if all items are completed during the iteration, we pick a new one from there). Pretty simple.
These practices allow to detect smells visually, for example:
Works great.
If you are looking for more "kanban oriented" stuff, maybe have a look at Kanban vs Scrum, One day in Kanban Land and Kanban and Scrum - a practical guide from the same Henrik Kniberg. Great stuff too.
And, for more pictures, give Google Images a try with scrum+board, kanban, scrumban, scrum+kanban.
这是我们在 TargetProcess 使用的看板。我们不在任务级别工作，只是在用户故事和错误级别工作。有时我们创建任务，但它们没有在板上明确跟踪。
我们不估计用户故事和错误，而是尝试将故事分割成更小的故事（效果好坏参半）。列是不言自明的。我们在已测试列中积累项目，然后创建一个分支，对其进行冒烟测试并发布新版本。通常我们每两周发布一次新版本。
该板还通过颜色编码向开发人员和测试人员显示负载和服务类别。
UPD。现在我们有几个小团队，并使用一个面板来跟踪 http://www.targetprocess 中所有团队的进度。 com/3
Here is our Kanban Board that we use at TargetProcess. We do not work on Tasks level, just on User Stories and Bugs level. Sometimes we create tasks, but they are not tracked explicitly on the board.
We do not estimate User Stories and Bugs, but try to split Stories into smaller (with mixed success). Columns are self-explanatory. We accumulate items in Tested column, then create a branch , smoke test it and release new build. Usually we release new build every two weeks.
Also the board shows developers and testers load and classes of services via color coding.
UPD. Now we have several small teams and use a single board to track progress of all teams in http://www.targetprocess.com/3
Scrum / 极限编程故事板。
http://www.flickr.com/photos/dafydd_ll_rees/4138686549/
作品出现在左数第二个列，并通过不同的完整性阶段全面进展。
列名称： 未开始、刚刚开始、中途、即将完成、准备展示（通过 QA）
第一行专门为错误修复保留 - 就像已修复、优先清除错误一样。
辛普森一家的角色代表了团队中的每个成员。它们被移动，这样我们就可以看到谁在做什么。
Scrum / Extreme programming storyboard.
http://www.flickr.com/photos/dafydd_ll_rees/4138686549/
Work appears on the second-from left colum, and progresses across the board through different stages of completeness.
Column names: Not Started, Just Started, Half-Way, Almost Done, Ready for Showcase (passed QA)
The first row is specially reserved for bug fixing - like a fixed, priority for clearing bugs.
The Simpsons characters represent each member of the team. They're moved around so we can see who's working on what.
我建议你看看Eylean board。 http://www.eylean.com/?utm_source=geffort&utm_medium =content&utm_campaign=geffort
由于直观的界面、统计数据、仪表板，它可以满足您的所有需求。它还适合任何流程，最重要的是它非常易于使用。该面板允许您使用行在一个面板上表示多个项目。所有行可能一次可见，或者您可以从范围中删除选定的行。另一种解决方案可能是按类别进行任务分组和过滤 - 然后所有任务都可以在一个板和行上表示，但附加到不同的类别。
I suggest you to take a look on Eylean board. http://www.eylean.com/?utm_source=geffort&utm_medium=content&utm_campaign=geffort
it can fit all your needs because of intuitive interface, statistics, dashboard. Also it fits any process and the most important thing it is very easy to use. This board allows you to represent several projects on one board using rows. All the rows may be visible at a time or you can remove selected ones from the scope.Another solution may be task grouping and filtering by categories - then all the tasks can be represented on one board and row, but attached to different categories.
在实践中，进行中工作委员会的组织最好留给团队根据您的情况和环境来确定。 （敏捷 == 自我管理。）
也就是说，这就是我们在我之前的团队中所做的事情，这是 300 多名开发人员努力的一部分，这对于敏捷和 Scum 来说是相对较新的：
我们有两个板 - 一个带有索引即将发生的故事的卡片，以便我们可以了解即将发生的事情，以及当前冲刺的工作。当前冲刺板上的专栏很简单
，角落里有一个“已阻止”的框。
每个故事都有一张便利贴。
开发人员每个人都有一个小磁铁，他们在每天早上的站立会议上用它来表明谁在做什么。我们的团队相当大（一度约 12 人），所以这确实有助于弄清楚谁与谁配对。
尽管我们的产品负责人确实有一个需要保持最新状态的 Scrumworks 系统，但我们并没有费心使用电子版本（没有意义）。我们尽可能远离它！
In practice the organisation of the work-in-progress board is best left for the team to determine depending on your circumstances and environment. (Agile == selfmanagement.)
That said, here's what we did in my previous team, part of a 300+ developer effort that was relatively new to Agile and Scum:
We had two boards - one with index cards for forthcoming stories so we could tell what was coming up, and one with the current sprint's work. Our columns on the current sprint board were simply
and a box in the corner for
Blocked.A post-it note represented each story.
Developers each had a little magnet which they used at the standup each morning to signify who was working on what. Our team was quite big (~ 12 at one point) so this really helped figure out who was paired with whom.
We didn't bother with an electronic version (no point), although our Product Owner did have a Scrumworks system that he needed to keep up to date. We kept as far away from that as we could!
我非常热衷于精益/看板，我们已经迭代我们的流程一段时间了，最初是通过 JIRA 中的自定义工作流程，但考虑到企业版本中的管理复杂性，这并不是完全无摩擦的。我们现在扩大了白板的使用范围，并决定在 JIRA 中重新编码之前使用白板迭代我们的流程一段时间。以下是我们的布局示例：
这与映射价值流非常接近，除了等待部署部分，这是一个黑客攻击为了解决 QA 无法对项目进行 QA 直到我们将其部署到他们的服务器上的问题 - 我们在 2 周的迭代中部署了 3/4 次。
通过将价值流映射到“信息辐射器”的一点是，它确实神奇地让人们专注于需要完成的实际增值工作，这似乎加快了业务价值开发的步伐并保持势头。
希望有帮助！
I'm pretty keen on Lean/Kanban and we've been iterating on our process for a while, initially through a customized workflow in JIRA, but that's not exactly frictionless given the admin complexity in the enterprise version. We've now expanded our use of a whiteboard and have decided to iterate our process using the whiteboard for a while before re-codifying it in JIRA. Here is an example of our layout:
This is pretty close to mapping the value stream except for the awaiting deployment part, which is a hack to fix the problem where QA can't QA an item until we've deployed it on their server - we deploy 3/4 times during a 2 week iteration.
One thing I have noticed from mapping the value stream on an "information radiator" is that it does magically focus people on the actual value-add work that needs to be done, and that seems to up the pace of business-value development and keep up momentum.
Hope that helps!
我们正在运行的几个不同项目中尝试几种不同的董事会结构。一个项目具有我们可以使用的最基本的结构：
我们尽可能地尝试用一张便利贴来代表一个故事的开发和 QA 活动。
上述结构对于项目的开发人员来说似乎工作正常，但 QA 成员很难知道一个故事何时完成开发工作，以便他们可以对该故事执行测试。我们发现自己将故事移至“进行中”部分的“远端”，以表明开发工作已完成并且 QA 可以拾取该故事。随着进行中部分被填满，这很快就变得非常难以管理。
这导致了另一个项目的董事会结构的第二次迭代，即：
新添加的部分准备测试本质上成为董事会的正式部分，该部分以前是的“远端”进行中部分。从表面上看，这应该会让 QA 成员更加清楚，但这仍然引起了一些混乱，因为人们对“准备测试”的含义有不同的解释（我不会让您感到厌烦）这里有不同的解释）。
这导致了我们在另一个项目中使用的董事会结构的最新迭代：
这肯定与简单的待办事项、进行中和相去甚远。 >完成第一次迭代的部分，但这对于团队来说似乎运作良好。他们清楚地了解将故事移动到看板的各个部分意味着什么，并且对于任何一个故事，都可以清楚地了解该特定故事在生命周期中的位置。自当前冲刺开始以来我们才使用此结构（10 天的冲刺已进入第 9 天），因此我们将在明天的回顾中更详细地探讨此结构。我确信它并不完美，但如果它继续适用于正在试点的团队，我们将尝试将其推广到我们组织中的其他团队。
We're experimenting with a couple of different board structures across a few different projects that we're running. One project has the most basic structure we can use:
As much as possible, we try to have a single post-it to represent both the Dev and QA activities for a story.
The above structure has seemed to work ok for the developers on the project, but the QA members have struggled to know when a story had the development work complete such that they could execute their tests for that story. We found ourselves moving the stories to the "far side" of the In Progress section to indicate that the Dev work was done and that QA could pick up that story. This very quickly became quite unmanageable as the In Progress section filled up.
This led to the second iteration of board structure for another project which is:
The newly added section Ready for Test essentially became a formal section of the board that was previously the "far side" of the In Progress section. On the surface of it, this should have made things clearer for the QA members, but this still caused some confusion as people had different interpretations of what Ready for Test meant (I'll not bore you with the different interpretations here).
This has then led to the latest iteration of board structure we're using on another project:
This is certainly quite a far way from the simple Backlog, In Progress and Done sections of the first iteration, but this appears to be working well for the team. They have a clear understanding of what it means to move a story through various sections of the board and for any one story, it gives a clear picture of where in the life cycle that particular story is. We've only been using this structure since the start of the current sprint (we're 9 days into a 10 day sprint), so we'll be exploring this structure in more detail in our retrospective tomorrow. Not perfect I'm sure, but if it continues to work for the team that is piloting it, we'll try to roll it out across other teams in our organisation.
我们的白板分为以下几列：
故事、未开始、需求/设计/开发*、同行评审、质量保证、完成
最高优先级的故事从上到下排列。
每个故事可以有多个任务，因此我们为故事使用一个大的便利贴，为任务使用较小的便利贴。任务从左向右移动。我们每天都会检查以确保我们正在处理最高优先级的故事。
我们在每项任务上都使用一个白色的粘性标签，负责处理该任务的人员在上面写上他们的姓名缩写。当他们完成并沿着它移动时，一个新的白色标签会放置在旧标签上，以表明任何人都可以拿起它。当所有任务完成后，故事也会移至“完成”列，在站立时，所有已完成的工作都会被统计出来，并向上移动到面板上，以便在底部为更多故事腾出空间。
我们还为故事和任务提供了彩色选项卡，以指示进展的障碍（蓝色表示来自另一个团队的障碍，红色表示请求 Scrum Master 协助）。我们在每次站立会议上都会讨论障碍。
我们可以看到某一特定列中何时有太多任务，并转移重点以完成更多任务。我们特意添加了审核栏，以强调工作在进入 QA 之前需要由负责人以外的其他人进行审核。
*需求/设计/开发
Our whiteboard is broken down into these columns:
Story, Not Started, Req/Des/Dev*, Peer Review, QA, Done
The highest priority stories go from top to bottom.
Each story can have multiple tasks so we use a big postit for the story and smaller ones for the tasks. Tasks move from left to right. Every day we check to make sure we're working on the highest priority stories.
We use a sticky white tab on each task where the person working on it puts their initials. When they're done and move it along a new white tab is placed over the old one to show it's available to anyone to pick up. When all the tasks are done, the story is moved to the Done column also and at the standup, all Done work is tallied up and moved up the board to make room at the bottom for more stories.
We also have colored tabs for the stories and tasks to indicate blockages to progress (blue indicating a blockage from another team, red requesting scrum master assistance). We talk about the roadblocks at each standup.
We can see when there is too many tasks in one particular column and shift emphasis to get more to Done. We deliberately added the review column to emphasize that the work needed reviewed by someone other than the person doing it before it got to QA.
*Requirements/Design/Development
我们的看起来很相似。每个开发人员都有一个列，我们有“完成”、“测试中”、“正在进行的工作”、“待办事项”的行。
我们使用实际的便利贴风格的笔记，我们在每个阶段都会移动这些笔记。
就我个人而言，我发现该系统存在缺陷...
就我个人而言，我认为便利贴在这里不是合适的工具。有一些数字工具可以使此类事情完全无障碍。我们使用 Team Foundation Server - 我见过一些非常出色、强大、免费甚至开源的工具，它们可以与 Team Foundation Server 交互并实时为您管理所有这些。
http://www.telerik.com/community/labs/tfs-work-item-manager-and-tfs-project-dashboard.aspx" telerik.com/community/labs/tfs-work-item-manager-and-tfs-project-dashboard.aspx
Ours looks fairly similar. Each developer has a column and we have rows for 'Done', 'In Testing', 'Work in Progress', 'Backlog'.
And we use actual post-it style notes that we physically move as it goes through each phase.
Personally, I find the system to be lacking...
Personally, I don't think post-it notes are the appropriate tool here. There are a handful of digital tools that make this sort of thing completely trouble free. We use Team foundation server - and I've seen a couple of really great, robust, free, and even open source tools that will interface with Team foundation server and manage all of that for you, in real time.
http://www.telerik.com/community/labs/tfs-work-item-manager-and-tfs-project-dashboard.aspx
随着我们作为一个团队的进步，我们的董事会往往会随着时间的推移而发展。如果你有一个团队，我倾向于使用物理卡片板，因为根据我的经验，它通常鼓励更好的面对面沟通。显然会有更多的开销，但为了让团队合作，这是值得的。我看到实体董事会的另一个优势是它有助于业务参与。远程利益相关者不能只是登录并查看当前冲刺中的进度并断章取义，因为有时卡片无法讲述完整的故事。他们必须进行对话并来到董事会，这可能是有益的，因为事情可以得到解释，这也意味着可以鼓励他们帮助解决障碍。然而，这并不是物理板所独有的，而是有帮助的。
如前所述，我们的董事会随着团队的需求而不断发展。我们通常从教科书 scrum 开始，但鼓励持续改进，通常最终会得到 scrumban 解决方案。这些变化通过看板可视化新工作流程来反映。我最近写了一篇关于我们最新更改的文章，如果您有兴趣，请查看我们的 沙漏 scrum/看板
我认为团队应该参与制作看板，因为它有助于团队理解工作流程而不是成为孤岛。此外，如果团队参与了董事会的建设，他们就会更好地监管自己的流程，这有助于自我组织，因为这是他们已经投入的产品。
Our boards tend to evolve overtime as we progress as a team. I tend to favour physical card boards if you have a collocated to team as it encourages better face to face communication generally from my experience. Obviously there is more overhead, but it's worth it to get the team working together. Another advantage I have seen with physical boards is that it helps with business engagement. Remote stakeholders can't just sign in and see progress within the current sprint and take things out of context as sometimes cards don't tell the full story. They have to have a conversation and come to the board which can be beneficial as things can get explained and it also means that they can be encouraged to help resolve with impediments. However this is not exclusive to physical boards but it helps.
As mentioned our boards evolve overtime with the teams needs. Often we start with textbook scrum, but encourage continuous improvement and usually end up with a scrumban solution. These changes are reflected by visualising the new workflow through the boards. I recently wrote a post on our latest change if your interested have a look at our hourglass scrum / Kanban board
I think the team should get involved in making the boards as it helps the team understand the workflow and not become silo's. Also if the team have had a hand in making the board they police their own processes better which helps with self organisation as it's a product they have had input to.
我们公司采用以下董事会结构。
车道被分配给特定的成员。每个成员在我们的办公室都有不同的工作，因此任务也有所不同。我们将需要完成的工作添加到待办事项列表中，然后在接近截止日期时将其移至下一个冲刺。阻塞的绿色任务用于必须每天执行的连续任务。红牌表明任务的重要性，必须尽快完成。
如果我们需要不同部门完成某些事情，我们的董事会允许我们自由协作并向彼此添加任务。
我们使用 KanbanTool (Kanbantool.com) 来可视化我们的工作流程并管理项目。它非常直观且易于使用。我们的团队沟通得到了极大的改善。
We went with following board structure in our company.
Lanes are assigned to specific members. Each member has different job at our office so the tasks vary. We add what we have to work on to our Backlog, then move it into Next Sprint if it approaches the deadline. Blocked green tasks are used for continuous tasks that have to be worked on daily. Red cards indicate importance of the task and have to be finished as soon as possible.
Our board allows us to collaborate freely and add tasks to each others swimlanes if we need something to be done by different department.
We use KanbanTool (Kanbantool.com) to visualize our workflow and manage projects. It's really intuitive and easy to use. Our team communication has improved tremendously.