软件与看板的集成阶段
您将如何在软件集成中使用看板？
团队的基本组成可以是：
- 构建和创建。发布团队、
- 两个专家团队、
- 测试团队。
构建团队从外部接收构建，并尝试构建它们并运行自动化测试。专家团队处理问题（构建问题、集成问题、测试中发现的问题），例如确定问题的原因。
那么最初的任务是否会被称为“发布 X”，然后我们为专家团队生成额外的任务（他们还将承担一些其他职责）？问题是“发布”对于专家团队来说是一项太大的任务，必须分解。但是，如果我们没有“发布 X”任务（而只有子任务），我们如何确定发布的状态？
您是否应该为 b&r 团队和专家团队设立单独的任务板？
How would you use Kanban in SW integration?
A basic composition of teams could be:
- Build & Release team,
- Two specialist teams,
- Test team.
Builds are received from outside by the build team who attempts to build them and run automated tests. Specialist teams deal with problems (build problems, integration problems, problems found in tests), they e.g. determine the cause of the problem.
So would the initial task be just called "release X" and then we generate the extra tasks for the specialist teams (who will also have some other duties)? Problem is that "release" is just too big a task for the specialist teams and has to be breaken down. But if we don't have a "release X" task (rather only the sub-tasks), how do we figure the status of the release?
Should you have separate task boards for b&r team and the specialist teams?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
尽管没有任何严格的规则看板应涵盖哪些内容，但您可以将其作为经验法则：
这意味着我的目标是为所有团队提供一个板，并且我可能还会尝试包含由专业团队完成的其他任务。
然后我们有董事会的组织。想法之一是拥有非常简单的流程（待办、正在进行、已完成）并在板上混合不同的任务，例如在版本上构建和运行自动化测试、运行手动测试等。然后，每次出现问题时，您都需要这是专家团队的一项任务，因此我们添加了一项。这样，只要出现问题，您就可以生成与版本相关的新任务。
现在的问题是如何判断发布是否完成。也许您可以使用几种不同颜色的便签，每个版本一张。您可以说“黄色”版本仍然存在一些未解决的问题，而“绿色”版本已全部完成，而您刚刚开始“橙色”版本。完成发布后，您可以轻松地重复使用颜色。
此外，您还会有一些简单的视觉效果，显示您在特定版本中遇到了多少问题 - 相同颜色的便签越多意味着问题越多。
Although there aren't any strict rules what should be covered by a Kanban board you can say that as rules of thumb:
This means that I would aim for a single board for all teams and I would probably also try to include other tasks done by specialist teams as well.
Then we have organization of the board. One of ideas is having very simple process (to do, ongoing, done) and mixing different tasks on the board, e.g. build and run automated tests on a release, run manual tests, etc. Then, each time when something goes wrong you need a task for specialist team so we add one. This way you generate new task connected with a release as long as something is still going wrong.
Now the question is how you can say whether release is completed. Maybe you can use several different colors of sticky notes, one per release. You'd be able to say that "yellow" release still has some open issues, while "green" one is all completed and you've just started "orange" one. After finishing release you can easily reuse colors.
Also you'd have some simple visuals showing you how many issues you had with a specific release - more sticky notes of the same color means more problems.