你熟悉Scrum，对吧？ 我猜是的，考虑到Scrum联盟有超过40万名成员，其中大多数成功地在他们的组织中使用它。
但是，它并不是以敏捷方式构建软件的唯一方法 - 严重！ 你听说过看板吗？
对于一些背景信息，它最初应用于精益生产，作为在工厂流动时可视化工作输入和输出的一种方式。 这种可视化呈现在一块名为a-wait for it-Kanban的板上。 最近和更相关的是，它被用作管理软件开发的方法。
神经学家David J. Anderson首先概述了它，它是一种组织软件开发和规划的方法，可以让您发现过程问题，并始终如一地为您的产品提供有价值的改进 - 我知道这听起来很理想。 简而言之，在任何时间点，您都可以看到工作（以卡片为代表）在开发过程中的位置。
这个怎么运作
基本看板基板使用六列显示产品开发周期中每项工作的位置。 下面是一个粗略的样子。
在Trello上查看此Kanban板示例。
第1栏：积压
Backlog列应包含优先级的想法，错误或业务需求列表。 该卡还没有大量细节，但它应该有足够的信息，让您的团队成员了解其重要性。
第2栏：规划
在本专栏中，产品经理将通过与业务利益相关者，工程师和设计人员会面来填写该功能的规范。 准备就绪后，他或她会将其移至“Ready for Engineering”栏目。
第3栏：准备工程
在这个阶段，所有卡都应该有详细的规格。 虽然您可能仍然对技术细节有疑问，但业务要求应该是明确的。
第4栏：进展中
您可以随时将卡片移动到“进行中”。 这种自我驱动的“拉动”系统建立了个人责任感和好奇心的文化。
第5栏：测试
当您完成卡上的工作后，将其移至“测试”，其他工程师（或QA团队中的某个人）将接收该卡。
第6栏：部署
另一个定义特征是应该不断地将工作交付给临时或生产环境。 此列允许团队中的任何人查看最近发布的工作。
优势和权衡
当您在看板和更常见的方法（如Scrum或瀑布）之间做出决定时，请记住这些好处和挑战：
好处：改善协作
在我工作过的一些开发团队中，工程师都是专家。 每个团队都有几位前端工程师和后端工程师。 这意味着工作经常被阻止，因为工程师正在忙于其他事情。
另一方面，看板限制了正在进行的工作并阻止了阻塞。 每个团队成员一次只能处理一个项目，任何不忙的人都可以从“准备工程”专栏的顶部开始工作。 这鼓励了工程通才和团队成员之间的协作。
提升效益：在准备好之前不要让事情通过
只有当您等待将卡片移动到下一列时才会使用看板，直到它们完全结束。 （额外奖励：这极大地减少了缺陷。）
挑战：劝阻时间反思
默认情况下，没有时间框冲刺，具有明确的目标，日期目标和发布周期。 相反，将每张卡视为可以随时完成和发布的独立工作。
通过这种持续的工作流，没有“等到下一个冲刺”选项。 您需要不断检查电路板，拉出下一个项目，然后将完成的项目向下游移动。 除非你及时建立回顾和站立，否则团队成员可能很难跟上他们的工作方式。
解决它：借用Scrum的功能
我已经使用每日立式和回顾与看板，发现它们增加了价值。 如果有定期会议或模式适合您的团队，请不要将其更改为教条地遵守看板。 预算时间，讨论优先级以及它们如何变化，以便每个人都知道产品开发周期中发生了什么。
好处：增加透明度
每个开发人员必须主动将卡移动到“进行中”列。 这意味着，在任何时候，团队的经理都可以看看谁在忙，谁不忙，以及任何工作持续多久。
当生产减慢或停止时，看板允许您查看确切原因。 无论是因为业务团队没有优先考虑积压项目，产品团队还没有完成规范，开发团队的移动速度比预期慢，或者QA团队无法测试某些东西; 瓶颈很明显。
提高效益：让进步成为公众
其中一个优点是看板非常直观。 即使是非技术团队成员也可以查看看板，并告知过程中的工作内容。 利用这一优势，通过将您的董事会放在公共场所，让团队的成就大放异彩。
挑战：不允许进行长期规划
担心截止日期和估算不是最有效利用你的时间，所以你可能会意识到看板更多的是日常输出。 也就是说，仅凭它并不能提供制定长期计划的制度。 这可能会导致您偶尔处理项目，而不是长期关注一件事。 很难在项目A上花一天时间然后在项目B上花一天时间然后切换回项目A.
解决它：当您的优先事项可能发生变化时使用它
您董事会中的每一列都独立于其他列，因此团队成员可以随时移动。 这可能会使开发人员陷入Scrum环境（预测sprint的预测），但Kanban在这种快速变化的环境中茁壮成长。
每个人都想要更多的产品，但如果你甚至不确定从哪里开始，可能很难尝试新的东西。 我发现看板很有帮助，希望你也发现它对你的个人工作流程有用（甚至对整个团队都有用！）。
如果你决定试一试，我会发信息！
