在上一篇文章中，我谈到了敏捷的第一步——每日站立会议，也谈到了我们平时是如何召开站立会议的，其实15-30分钟就够了，绝对不是那种让你想拄拐杖的那种。 在本文中，我们将从敏捷开发中的看板开始。 在董事会之前，我们实际上是在董事会上画车道，写卡片，移动卡片，并在董事会前举行站立会议。 现在支持任务看板的产品越来越多，大家开站立会议也很方便，所以没有必要真的站在白板前，只要大家围成一圈，拿着令牌轮流就行了。 今天，我想分享一下我如何使用任务板。
任务板有很多好处，但对我来说最大的好处是以下三个。
进度可视化：每个人都可以从看板看到每个任务的状态，包括负责人、优先级、进度、交付日期等。
透明的团队合作：信息充分共享，很多时候大家一目了然的项目情况，省去了很多询问式的沟通。 许多问题的确认和跟进也会在卡片中传达，所有的背景和背景信息都会直接落入卡片中。
任务跟进和梳理：项目通常有各种各样的任务需要处理，具有不同的优先级。 通常我要求每个成员写一张卡片，上面写着他们正在做的所有工作，一方面是他们工作量的反映，另一方面，它也有助于每个人了解你在做什么，最重要的是，它有助于在做之前仔细了解任务的内容。 如果不能清楚地描述要完成的工作，则工作的内容在很大程度上是模糊的，边界不明确，完成的定义（DOD）也不明确。
今天的任务板通常支持不同的视图，这使我们能够从不同的维度看待我们的项目、团队和人员。
任务视图：最基本的就是做->做-做->做，看看已经完成的任务数量，测试中的任务数量，开发中的任务数量等等。 在这种尝试下，最有意义的是那些高质量任务卡的状态。 如果高优先级卡始终处于待办事项状态，请小心并立即询问其背后的原因。
如今，许多产品已经支持自定义状态，链接各种系统，自定义工作流，自动通知等，这些都是一些高级游戏玩法，第一步也是最重要的一步是首先使用看板。
人观：从人的角度看任务，可以看到每个人的工作量，如果一个人手里的牌太多，他们通常会问。 这里可能出现的问题是，如果在这次迭代中涉及一个模块的卡太多，可能会有大量的模块相关伙伴的工作负载。 也许团队成员负责的内容会稍后调整，模块太大而无法拆解，或者问题太多而无法重构等等。
迭代视图：上一次迭代的剩余问题是什么，本次迭代中正在开发的功能以及本次迭代的进度，以及将安排在下一次迭代中的功能列表。 通常每次迭代都有很多指标报告，如进度图、燃尽图、趋势图、速度速度等。 这些敏捷指标仍然有用，但它们只在团队内部有意义，与其他团队相比没有那么多意义。
任务看板更擅长跟进任务多且复杂的情况，即任务数量多、类型不同。 至于任务量大但类型单一的情况，任务看板也可以管理，但可能有更好的解决方案，比如工单系统、BPM等。
任务看板只是一个工具，它不挑剔任务的属性，高复杂度和高不确定性的任务可以管理，低复杂度和低不确定性的任务也可以管理，通常一个项目会具有多种属性的工作。
例如，我们自己构建的很多工具都是从0到1，一行一行的，可以说是非常复杂和不确定的。任务看板用于创建、拆卸和跟进任务，至于任务的复杂程度，如果卡片无法携带，我们通常会在卡片上附加文档。 例如，将需求的标题粘贴在卡片的标题上，然后在卡片中粘贴 PRD 链接，例如模块重构，然后是整体修订;另外，我们的看板里还有很多低复杂度、低不确定性的工作，有时候只是做个记录，提醒别忘了按时完成，比如和会议室预约、更新文档、不迟到、及时MR、下班前提交**、记得周六加班：）以及一些只在构思阶段的想法， 比如请唐长老分享SBOM，参观韩先生的公司，说不定有一天我真的会去。在实践中，我们真的把大大小小的都放进了卡片里，把小学老师教给我们的好记忆力发挥到了极致。
我个人认为，作为领导、PO、业务领导，除了招募和面对用户之外，我还需要每天花很多时间给任务面对面。
我有一个习在早上每天站立会议之前要翻阅任务板的内容，让自己清楚，看到需要提醒的地方，直接在卡片上对应的负责伙伴，看到需要注意的时候再打开另一张卡片。
对于那些尚未安排的工作，请仔细考虑与这些卡片对应的问题是否已经明确，优先级是否合适，是否有更好的计划等。
对于那些已经安排好的作业，看看前提条件是否到位，进度是否符合预期，是否有阻塞，何时测试，谁在测试，是否启动，是否有bug......
有些朋友每年总结自己的OKR都会头疼，想不起来这季度做了什么做到这一点的一个好方法是翻阅任务板，看看你每天完成的卡片OKR 总结完毕后，不知道下个季度该做什么，应该去任务板看看上面积压的哪些卡片还没有完成。
本文主要讲授任务看板的好处、应用场景、多维度尝试复盘项目以及通过看板的注意事项。 就我个人而言，我还是喜欢使用任务板的，它管理项目或者管理自己的待办事项都非常高效，也可以试试。 研发效率。