DevOps｜研发提效-敏捷开发之任务看板

上篇文章中，我讲了敏捷第一步-每日站立会，讲了我们平时是怎么开站立会的，其实15-30分钟就够了，绝对不是时间长得让你想拄拐那种。本文我们开始讲敏捷开发中的看板。没有看板之前，我们真的是在白板上画泳道，写卡片，挪动卡片，在白板前开站立会。现在支持任务看板的产品也越来越多了，大家开站立会也方便了，没必要真的站在一块白板前了，只要大家围成一圈，拿个 token 轮流讲就可以。今天我想分享下我是怎么使用任务看板的。

任务看板好处

任务看板有很多好处，但是对我最大的莫过于以下三点

进度可视化：每个人都可以从看板上看到每个任务的状态，包括负责人，优先级，进度，交付日期等
团队协作透明：信息完全共享，很多时候大家看一眼看板，这个项目的情况就了然于胸了，省去了很多「询问式」沟通。很多问题的确认和跟进也会在卡片中进行交流，所有的上下文、背景信息都直接落在了卡片里。
任务跟进和梳理：项目中经常有各种工作需要处理，轻重缓急都不同。通常我会要求每个成员把自己手上的所有工作都建成卡片，一方面是自己工作量的一个体现，另外一方面也有助于大家了解你到底在做什么，最关键的是有助于在做之前认真地把这项任务的内容想明白。如果要做的事情无法描述清楚，很大程度这个工作内容模糊，边界不清，完成的定义(DoD)不明。

多维看板

现在的任务看板通常支持不同的视图，这样就可以让我们从不同的维度去审视我们的项目、团队和人员。

任务视图：最基础的就是「to do -> doing -> done」可以看到已经完成的任务数量，在测试中的任务数量，开发中的数量等。在这个试图下最有意义的是那些高优任务卡片的状态。如果一个高优先级的卡片一直在「to do」状态，这时候就要小心了，应该立刻去问下背后的原因。

现在很多的产品已经支持自定义状态，关联各种系统，自定义工作流，自动化通知等，这些都是些高阶玩法，第一步也是最重要的一步首先把看板用起来。
人员视图：从人的角度去看任务，可以看到每个人的工作量，如果一个人手里的卡片太多，通常都会询问一下。这里可能会出现的问题就是如果这个迭代里涉及某个模块的卡片过多，可能会出现模块相关的小伙伴工作量较大。也许后面会调整下团队小伙伴负责的内容、模块太大了拆开或者问题太多要重构等。
迭代视图：上个迭代有哪些遗留的问题，这个迭代正在开发的功能以及进展，下个迭代将要进入排期的功能列表。通常每个迭代还有很多度量的报表，进度图、燃尽图、趋势图、流速velocity等。这些敏捷度量报表还是很有用的，但是仅限于团队内部环比有意义，和其他团队对比意义不大。

适用场景

任务看板更擅长跟进那种任务多且杂的情况，即任务数量多，类型不一。至于任务数量多但类型单一的情况，任务看板也能管理，但是可能有更优解，比如工单系统，bpm等。

任务看板只是一个工具而已，它不挑任务的属性，高复杂度和高不确定的任务可以管，低复杂度/低不确定性也可以管，通常一个项目中各种属性的工作都会有。

举个例子，我们自己打造的很多工具都是从0到1，一行一行的代码码出来的，可以说复杂度和不确定性都很高。

任务看板用来建立、拆解、跟进任务的，至于体现这个任务的复杂度，如果一个卡片无法承载，我们通常会在卡片上附一个文档。比如把需求的题目贴到卡片标题上，然后把 PRD 链接贴在卡片中，比如模块重构，再比如整体改版；另外就是我们的看板里也有很多低复杂度低不确定性的工作，有的时候仅仅只是做个记录，提醒下不要忘记按时完成，比如约会议室、更新文档、不要迟到、及时 MR、下班前提交代码、周六记得加班 :)。还有一些仅仅是在 idea 阶段的想法，比如邀请唐长老来分享下 SBOM，去韩老师公司拜访，说不定哪天真的就去了。我们实际使用中真的会把大大小小所有的事情都落到卡片里，我们把小学老师教给我们的「好记性不如烂笔头」发挥到了极致。