If you must have a multitude of boards, wouldn't it be better to have a board per project rather than a board per developer ? Maybe in time some natural groupings of projects (and therefore consolidation of boards) will emerge, maybe not.
One purpose of the boards is to serve as "information radiators". A large number of project boards progressing at a snail's pace broadcasts the message "we are seriously overloaded" and/or "someone needs to set some priorities". A large number of per-developer boards just radiates the message "we don't do teamwork around here".
Kanban is actually as system for restricting flow through a system, which is why we have WIP (Work In Progress) limits on kanban boards, and as a person can do only one job at once I don't think this could work.
Having one board per developer really doesn't give any advantages (And I'd argue it's not really kanban). One board per project is a better idea.
Then if another developer joins in for some tasks you can still see the overall progress of the project.
I think it might be worthwhile to have another discussion with your group. Before adopting any kind of new technique/practice/methodology, one should be very eyes-open about why you want to adopt it, and what problem you're trying to solve. It almost sounds to me that you've stumbled upon Kanban Boards and want to adopt it without really knowing what problems you're tryying to solve.
My advice would be to try do some more thinking or analysis on the problems you see in your environment, do some root-cause analysis if you can (something like the 5-whys), and then try find some practice that will help you solve those problems.
The very fact that people in your group suggested using a board-per-developer implies to me that a. they don't understand the kind of problems they have, and that you're trying to solve, and b. they don't understand what Kanban boards are trying to achieve. I.e., your problems are such that using Kanban boards will not solve them.
It's not wrong to have a board per developer. The board is there to visualize the work. If the developers work on different projects, then it would be easier to visualize project-specific work with separate boards (which is usually the case). If your developers work on separate projects, then they work on separate projects. Technically, they're not really a single team, but more of a "practice". From that perspective, it might be a more natural approach to have them working separate boards.
When I work on personal projects on my own I still use a Heijunka Box - what software developers in the west often (mistakenly) call a "Kanban Board" - and I do this to visualize work, work scheduling, and to help limit the number of things I'm working on at once.
I've implemented Kanban for my team which does Operations Automation (more or less half Ops work and half Dev work). Here's what we found worked best for our team. We have a common column for INBOX/Backlog.. Then a 'in development' column broken down into 5 sections, one per developer, with a per-developer WIP Limit. Then another common column for 'to integrate', and finally a common column for 'release to production'.
The advantage of Kanban is that the WIP limit ensures developers can focus on what they are doing - in our case each developer is fairly autonomous in working on their project, but we have the common columns for INBOX where a developer can pull any new task, and for 'integration' / 'production' where the team-lead is involved in shepherding the change through the remaining steps.
So my recommendation is to have some common columns (perhaps your backlog and your release) and have some columns that are per developer (like 'in development'). That way each developer can manage what they are working on, and at the same time the board can help visualize the state of all work that is flowing through the pipeline.
如果每个项目或团队只有一个董事会，则取决于是否存在共享资源，即，人们在多个项目或团队中工作。如果是这样，如果您的人员正在处理多个板上显示的内容，您就会失去一些概览以及限制 WIP 带来的一些好处。 F. 前。瓶颈更难发现。
The two most important reasons to apply Kanban to a process is to visualize that process and limit work in progress (WIP).
If you have one board per developer it's more of a personal kanban mechanism, and you get to visualize and limit WIP for one person at a time, but no overview at team level.
If you have one board per project or team it depends if there's shared resources, i.e., people working on more than one project or team. If so, you loose some overview and some of the benefits from limiting WIP if you have people working on stuff shown on more than one board. F.ex. bottlenecks are harder to see.
如果您使用的是 Microsoft TFS，那么您可以使用 Telerik 工作项管理器。我自己用过这个，非常棒。每个开发人员在他们的 PC 上运行该工具的副本，他们可以在可视任务板上（带有彩色便利贴）查看他们的工作项目。该板可以通过各种方式进行分组和过滤，因此开发人员可以查看自己的所有任务，然后他们可以更改过滤器以查看项目上的所有任务。
（如果您不使用 TFS，请为无趣的子注释道歉：）
My feeling is that it might be better to use one Kanban board, with all the developer tasks on it, rather then one board per developer. Reason I think this is because the idea is that Kanban is a visual tool for all team members, and if each dev has their own board, then I think it misses the idea a bit.
Subnote
If you're using Microsoft TFS, then you could use use Telerik Work Item Manager. I've used this myself and it's great. Each developer runs a copy of the tool on their PC, and they can view their work items on a visual task board (with colour post-it's). This board can grouped and filtered by various ways, so a developer can see all their own tasks, but then they can change the filter to view all the tasks on the project.
(If you're not using TFS, apologies for the uninteresting subnote :)
Indeed, create at least 2 or 3 teams, affect only one project to each of them and so one board by project. Then an another board to manage projects status.
To resume: One by project with every tasks, one to follow project status it will help the developers and also you to communicate with the managers.
发布评论
评论（8）
如果您必须拥有多个董事会，那么每个项目拥有一个董事会而不是每个开发人员拥有一个董事会不是更好吗？也许随着时间的推移，一些自然的项目分组（以及因此的董事会合并）将会出现，也许不会。
这些板的目的之一是充当“信息辐射器”。大量进展缓慢的项目委员会广播着“我们严重超负荷”和/或“有人需要设定一些优先事项”的信息。大量的开发人员委员会只是传达这样的信息：“我们在这里不进行团队合作”。
If you must have a multitude of boards, wouldn't it be better to have a board per project rather than a board per developer ? Maybe in time some natural groupings of projects (and therefore consolidation of boards) will emerge, maybe not.
One purpose of the boards is to serve as "information radiators". A large number of project boards progressing at a snail's pace broadcasts the message "we are seriously overloaded" and/or "someone needs to set some priorities". A large number of per-developer boards just radiates the message "we don't do teamwork around here".
看板实际上是一个限制流经系统的系统，这就是为什么我们在看板板上有 WIP（正在进行的工作）限制，并且由于一个人一次只能做一项工作，我认为这行不通。
每个开发人员拥有一块板确实没有任何优势（而且我认为这并不是真正的看板）。每个项目一块板是一个更好的主意。
然后，如果其他开发人员加入执行某些任务，您仍然可以看到项目的整体进度。
Kanban is actually as system for restricting flow through a system, which is why we have WIP (Work In Progress) limits on kanban boards, and as a person can do only one job at once I don't think this could work.
Having one board per developer really doesn't give any advantages (And I'd argue it's not really kanban). One board per project is a better idea.
Then if another developer joins in for some tasks you can still see the overall progress of the project.
我认为与您的小组进行另一次讨论可能是值得的。在采用任何一种新技术/实践/方法之前，人们应该非常清楚为什么要采用它，以及您想要解决什么问题。在我看来，您偶然发现了看板并想要采用它，但并不真正知道您要解决什么问题。
我的建议是尝试对您在环境中看到的问题进行更多思考或分析，如果可以的话进行一些根本原因分析（例如 5 个为什么），然后尝试找到一些可以帮助您解决问题的实践那些问题。
你们小组中的人建议使用每个开发人员的董事会这一事实对我来说意味着：他们不了解他们所面临的问题以及你正在努力解决的问题，b．他们不明白看板想要实现的目标。也就是说，您的问题是使用看板无法解决的。
I think it might be worthwhile to have another discussion with your group. Before adopting any kind of new technique/practice/methodology, one should be very eyes-open about why you want to adopt it, and what problem you're trying to solve. It almost sounds to me that you've stumbled upon Kanban Boards and want to adopt it without really knowing what problems you're tryying to solve.
My advice would be to try do some more thinking or analysis on the problems you see in your environment, do some root-cause analysis if you can (something like the 5-whys), and then try find some practice that will help you solve those problems.
The very fact that people in your group suggested using a board-per-developer implies to me that a. they don't understand the kind of problems they have, and that you're trying to solve, and b. they don't understand what Kanban boards are trying to achieve. I.e., your problems are such that using Kanban boards will not solve them.
每个开发人员都有一个董事会并没有错。董事会的作用是可视化工作。如果开发人员从事不同的项目，那么使用单独的板来可视化特定于项目的工作会更容易（通常是这种情况）。如果您的开发人员在不同的项目上工作，那么他们就在不同的项目上工作。从技术上来说，他们并不是真正的单一团队，而更多的是一种“实践”。从这个角度来看，让他们在单独的董事会工作可能是更自然的方法。
当我自己处理个人项目时，我仍然使用 Heijunka Box - 西方软件开发人员经常（错误地）称之为“看板” - 我这样做是为了可视化工作、工作安排，并帮助限制数量我正在做的事情。
It's not wrong to have a board per developer. The board is there to visualize the work. If the developers work on different projects, then it would be easier to visualize project-specific work with separate boards (which is usually the case). If your developers work on separate projects, then they work on separate projects. Technically, they're not really a single team, but more of a "practice". From that perspective, it might be a more natural approach to have them working separate boards.
When I work on personal projects on my own I still use a Heijunka Box - what software developers in the west often (mistakenly) call a "Kanban Board" - and I do this to visualize work, work scheduling, and to help limit the number of things I'm working on at once.
我已经为我的团队实施了看板，该团队负责运营自动化（或多或少一半是运营工作，一半是开发工作）。这是我们发现最适合我们团队的方法。我们有一个用于 INBOX/Backlog 的公共栏。然后是一个“开发中”栏，分为 5 个部分，每个开发人员一个，每个开发人员的 WIP 限制。然后是另一个用于“集成”的公共列，最后是一个用于“发布到生产”的公共列。
看板的优点是 WIP 限制确保开发人员可以专注于他们正在做的事情 - 在我们的例子中，每个开发人员在他们的项目上都相当自主，但我们有 INBOX 的公共栏，开发人员可以在其中提取任何新任务，对于“集成”/“生产”，团队负责人参与通过剩余步骤引导变革。
因此，我的建议是拥有一些常见的专栏（可能是您的待办事项和发布），并拥有一些针对每个开发人员的专栏（例如“开发中”）。这样，每个开发人员都可以管理他们正在做的工作，同时董事会可以帮助可视化流经管道的所有工作的状态。
I've implemented Kanban for my team which does Operations Automation (more or less half Ops work and half Dev work). Here's what we found worked best for our team. We have a common column for INBOX/Backlog.. Then a 'in development' column broken down into 5 sections, one per developer, with a per-developer WIP Limit. Then another common column for 'to integrate', and finally a common column for 'release to production'.
The advantage of Kanban is that the WIP limit ensures developers can focus on what they are doing - in our case each developer is fairly autonomous in working on their project, but we have the common columns for INBOX where a developer can pull any new task, and for 'integration' / 'production' where the team-lead is involved in shepherding the change through the remaining steps.
So my recommendation is to have some common columns (perhaps your backlog and your release) and have some columns that are per developer (like 'in development'). That way each developer can manage what they are working on, and at the same time the board can help visualize the state of all work that is flowing through the pipeline.
将看板应用于流程的两个最重要的原因是可视化该流程并限制在制品 (WIP)。
如果每个开发人员都有一个看板，那么它更像是一种个人看板机制，并且您可以一次可视化并限制一个人的 WIP，但没有团队级别的概述。
如果每个项目或团队只有一个董事会，则取决于是否存在共享资源，即，人们在多个项目或团队中工作。如果是这样，如果您的人员正在处理多个板上显示的内容，您就会失去一些概览以及限制 WIP 带来的一些好处。 F. 前。瓶颈更难发现。
The two most important reasons to apply Kanban to a process is to visualize that process and limit work in progress (WIP).
If you have one board per developer it's more of a personal kanban mechanism, and you get to visualize and limit WIP for one person at a time, but no overview at team level.
If you have one board per project or team it depends if there's shared resources, i.e., people working on more than one project or team. If so, you loose some overview and some of the benefits from limiting WIP if you have people working on stuff shown on more than one board. F.ex. bottlenecks are harder to see.
我的感觉是，最好使用一个看板，上面包含所有开发人员任务，而不是每个开发人员使用一个看板。我认为这是因为这个想法是看板是所有团队成员的可视化工具，如果每个开发人员都有自己的看板，那么我认为它有点错过了这个想法。
子注释
如果您使用的是 Microsoft TFS，那么您可以使用 Telerik 工作项管理器。我自己用过这个，非常棒。每个开发人员在他们的 PC 上运行该工具的副本，他们可以在可视任务板上（带有彩色便利贴）查看他们的工作项目。该板可以通过各种方式进行分组和过滤，因此开发人员可以查看自己的所有任务，然后他们可以更改过滤器以查看项目上的所有任务。
（如果您不使用 TFS，请为无趣的子注释道歉：）
My feeling is that it might be better to use one Kanban board, with all the developer tasks on it, rather then one board per developer. Reason I think this is because the idea is that Kanban is a visual tool for all team members, and if each dev has their own board, then I think it misses the idea a bit.
Subnote
If you're using Microsoft TFS, then you could use use Telerik Work Item Manager. I've used this myself and it's great. Each developer runs a copy of the tool on their PC, and they can view their work items on a visual task board (with colour post-it's). This board can grouped and filtered by various ways, so a developer can see all their own tasks, but then they can change the filter to view all the tasks on the project.
(If you're not using TFS, apologies for the uninteresting subnote :)
事实上，创建至少 2 或 3 个团队，每个团队仅影响一个项目，因此一个项目一个委员会。然后是另一个委员会来管理项目状态。
恢复：一个项目一个任务，一个跟踪项目状态，这将有助于开发人员以及您与经理的沟通。
Indeed, create at least 2 or 3 teams, affect only one project to each of them and so one board by project. Then an another board to manage projects status.
To resume: One by project with every tasks, one to follow project status it will help the developers and also you to communicate with the managers.