我们有一个棕地项目，该项目最近遭受了灾难的打击（许多人出于无关的原因离开，新客户太多，积压的订单太多，以至于很少有人）。管理支持仍然很好。谢谢鲍勃，产品所有者（数十年的知识）仍然在这里。开发人员已经从一个广受好评的DevOps同事那里瞥见了DevOps的好处，他既从事实际工作又进行传福音，因此在这方面也没有阻力。

目前，我们正在吸引来自各地的新人（例如，虽然讲不同的语言，但分布在不同城市甚至国家），并掌握专有技术等。在开始之前，我们也非常关注自动化再次实现实际发展，因为每个人都看到了如果我们不这样做会发生什么。此外，我们将每个人（开发人员，操作人员，测试人员）捆绑在一起，以利用每时每刻的知识并避免将来出现孤岛。因此，这是一个非常动态的情况。

我的主要目标是：


让人们去工作而不是惊慌失措，即使各个开发人员专注。
屏蔽开发人员和操作人员惊慌失措的管理层和利益相关者。
让利益相关者更加透明，以了解他们的任务/事件正在发生什么，从而减少恐慌的零警告状态呼叫。

大多数人和我一样，习惯于Scrum（或更可能是Zombie-Scrum或Scrum-But;）），但是我认为现在在这里进行适当的Scrum还为时过早。因此，我很可能会实施看板（在Jira中）。

您在这里的最佳做法是什么？


每人/每对一列？还是每个阶段都有一栏用于任务（即“开发中”，“测试中”等）？我想我更喜欢第一个，因为它可以很清楚地显示一个人/一对是否全力以赴-我们可以很好地使用一整列来告诉经理离开。此外，我们在团队中扮演着非常不同的角色（例如，将专注于CI / CD管道等的DevOps专家；或者是测试人员）。
在通常的Scrum流程中，P.O不会是实际的sprint板的一部分，但会在积压中尽力而为。您是否建议在P.O.这样他就可以专注于一次充实一些任务吗？这将使邮政局我很想在团队内部这是个好主意吗？ （是的，我知道看板实际上并没有标注这些角色，但我希望您明白我的意思...。）
或者，替代上一篇：我相信IT怀疑论者有一篇关于拥有两个委员会的文章-一个侧重于利益相关者的史诗，另一个侧重于实际的短期任务。你有经验吗？根据您的经验，在这种情况下会有所帮助吗？

这似乎是三个不同的问题，但是在我看来，这是一个问题：如何构建围绕人或围绕任务的看板委员会？ br />

#1 楼

我们是一家产品开发商店-实际上，除其他工具外，我们还开发了看板工具（SwiftKanban）。我们在看板和DevOps以及用于史诗/故事详细信息与开发/ ps跟踪的单独面板方面拥有丰富的经验。我们的DevOps设置仍然是完全自动化的，并且正在逐步完善。自2010-11年以来，我们就一直在旅途中-我们已经获得了您所期望的那种显着的商业收益。

我们从一个看板开始，但是有两个独立的泳道产品经理和开发团队的信息-请参见以下内容-

产品所有者的规划通道


Dev Lane的主要开发活动


由于我们只有一个团队来进行开发以及维护/与客户相关的工作，还包括重构工作，所以我们还有其他一些途径可以帮助他们可视化整体工作量-


在过去的6年中，我们不断发展，我们的开发/工程实践也在不断发展。虽然我们从未使用过Scrum-并且没有sprint，但我们每4-6周会发布一次产品发布，然后将其部署到内部登台服务器（我们将其用作内部生产服务器，在其中我们将产品用于开发以及其他功能（例如营销，销售，支持，实施服务等），每周或更短的时间，而开发人员和运营人员之间只有一个工作流程，如下所示。

，我们已经发展成为一个完整的上游看板板-这是我们的路线图规划板，我们在其中跟踪主题，史诗和故事-并在多达4个版本中布置故事。我们这样做是因为我们逐渐弄清需要做多少工作来识别和详细说明要完成的工作以及与利益相关者保持一致，因此每个人都同意我们正在做正确的事情。

路线图规划委员会


该板的故事被拉到开发板。内部和客户报告的缺陷直接添加到该板的“就绪”队列中。

开发板


可以看出，产品负责人（产品经理）负责路线图板，而高级开发经理负责开发委员会。开发团队成员依赖于Staging服务器时，Ops团队确保他们拥有正确的CI / CD环境来执行此任务。开发/验证后，一旦完成足够有价值的工作（通常4-6周），运维团队的工作便会部署到生产中。

所有高级利益相关者和CEO都可以访问这两个董事会，销售和市场营销，因此每个人都可以跟踪正在发生的事情以及即将发布的版本的优先事项。

同时，我们确保我们遵循一些建议的看板节奏，包括每日站立会议，每周补货会议（对故事/缺陷优先级进行微调），以及发布回顾和季度战略审查会议。

看板董事会和节奏确保每个人都知道并保持一致;如果有冲突，则可以在其中一次会议中解决（每日站立会议除外）。

除了重要的看板惯例（包括合理严格地遵守WIP限制）之外，我们当然也有，对工程实践进行了大量投资，以实现真正的连续交付/部署环境-而且这一过程仍在继续。我们是一家Test Driven Dev商店，开发人员负责JUnits，Functional Automation和Peer Review。我们的代码存储库是Subversion，并且使用Jenkins进行了集成/部署。 Subversion与我们的看板工具集成在一起，因此卡上的每个阶段的所有工作也都会更新（通过卡上的注释）。

总体来说，要回答您的一些具体问题，请


是的，在产品所有者和开发人员团队之间提供一块单独的板，并根据需要链接各个板卡是很有意义的。
按任务/工作流程阶段而不是人员来组织董事会是有意义的，因为这使您在工作流程的不同阶段使用跨职能人员具有更大的灵活性。
最重要的是，它使您可以轻松地可视化并衡量哪些工作流程阶段可能是瓶颈（而不是哪些人-通常是不准确的）以及可能需要进行哪些调整以改善流程和吞吐量并减少交货时间。

过渡到看板，一切顺利！如果您需要有关看板的更多帮助，我强烈建议您阅读David Anderson关于看板方法的书，并参考我们全面的《看板指南》。

希望有帮助。

评论

感谢您发布我在SE上见过的最棒的;）答案之一。我仍然无法在手机中查看您的屏幕截图，但是会在接下来的几天中消化您的描述。

– AnoE
17-10-29在17:35
谢谢您的客气:)-欢迎您。如果您有任何问题，请告诉我。

–马赫什·辛格（Mahesh Singh）
17-10-29在21:26

#2 楼

看板的优点在于，它可以让您看到团队中每个人的工作；如果工作相关，则应该在共同的董事会上（我认为）。但是，处理团队专业化的一种方法是使用泳道，尤其是在任务具有相同阶段的情况下。

以一块简单的木板为例，其中有待办事项桩，待办事项桩和做桩。为您的每个子团队创建泳道，并相应地限制其在制品；

当阶段更加复杂时，我认为两块板才有意义。如果您必须在团队之间进行某些事情的沟通（即，在为史诗完成一项任务之前，在开发人员完成代码之后需要质量检查），而对于其他事情则不需要（修复），那么两个具有不同阶段的不同董事会将感。但是，您必须处理板之间转移的复杂性。