-
Plane
-
- Plane 是开源的项目管理工具，目前还是非常好用的，而且开源版本还没有为了商业版做各种恶心人阉割的操作，目前还是值得推荐的
- 最近 Plane 的版本号从 0.28 直升到了 1.0，意味着官方认为多数功能已经做完了，只是这个 1.0 版本到底更新了啥内容没有详细介绍，目前更新日志还对不上。
- Plane 也接入了各种语言，目前中文也可以使用，虽然还有一点点没翻译到位
-
最佳实践
- 还是以团队形式来说，如果只是小团队，每个人可能都身兼多职，没有生产等环节，单纯做软件开发，那么这个工具按照我之前的流程使用基本就够了。
- 但是如果团队规模比较大，涉及到实际生产，那么之前介绍的用法就有一些过于简单了。
- 以下都是基于社区版的 Plane 进行的项目管理，社区版本缺少任务流转、模板、细化权限等内容（商业版有），但用下面的方式可以一定程度上人为补全缺少的功能。
- 下面的实践都是基于一个小项目组，比如 10 人以内。超过 10 人以后就应该再拆分一个项目组，对于整个项目来说可能还得有各组之间对齐的项目面板。
-
敏捷开发
- 如果只是敏捷开发，那么只需要在整个 workspace 做好工作规划即可，然后把规划后的内容逐步放入每个周期中。周期排得够多以后，每个周期都有一定的工作范围、实现目标，那么基本上整个项目规划自然而然就串起来了
- 整个项目的完成时间或者节点就可以通过周期视图来看出来了，只不过Plane的这个周期稍微有点不适合而已。
- 对应的就可以用Plane中的module模块或者Label来把各个模块打上标记，从而通过筛选后看到各个阶段完成的目标是什么。
- 到这里只是规定好了Plane每个部分怎么用，但是具体到每个人他应该怎么用Plane，哪些事情应该由他来做，哪些事情应该由别人来做，其实很多时候就是这个没定义清楚，导致大家不知道什么是他要做，什么是别人要做的，就会觉得这个东西有点难用了
-
完善状态
- 在开始之前，还需要完善一下 Plane 中工作项的状态
-
- 需求完善：需求细节还没有，但是已经有这个方向的想法了
- 待做：需求细节已有，产品主动切换到这个状态
- 开发中：研发进行中，研发主动切换到这个状态
- 等待测试：研发完成，等待测试进行，研发主动切换到这个状态
- 测试中：测试进行中，测试主动切换到这个状态
- 完成：产品和测试同时确认完成，产品主动切换到这个状态
- 延期完成：产生了任务延期，产品主动切换到这个状态
- 取消：取消任务，产品/研发/测试主动切换到这个状态
-
实操
- 先设定一个团队组成：
-
- 产品经理 1
- 研发负责人 1
- 研发若干
- 测试若干
- 首先是产品经理做好需求和规划，将这个部分全部建立对应的工作项。如果长期需求还没写好，那可以先把近期内的都先建好，任务状态是需求完善。
- 第二步研发负责人将需求进行分解，拆解成若干研发任务，这部分任务就自然地建在需求下面，作为子项，任务状态是待做
- 第三步测试负责人提出测试计划、测试用例，可能还有对应的自动化测试任务，也作为子项，任务状态是待做
- 完成以后类似此图，依此类推，就可以建立出来若干个产品需求
- 第四步需要所有人一起核对排期，任务时间，确定这个需求总时间大概是多，比如七天或者八天，近期打算做的任务都需要这样大概排期一下。
- 第五步产品将需求排入周期中
-
- 这里对需求的大小有一些管控，如果需求过大超过周期，需求需要分两步去做
- 同样如果一个周期填不满，那么需要补充一部分下一个需求的内容到这个周期，等下个周期来了，再使用周期迁移把未完成的部分整体移动到新周期内
- 第六步周期正式开始了，此时研发开始填他各自的任务，时间，将每阶段完成情况回复到任务内，同理测试，任务状态是开发中或者是测试中
- 第七步开发基本完成，测试需要额外建立一个测试 Bug，并且一一指定到对应研发，任务状态是开发中或者是测试中
- 第八步，产品确认是否需求一一完成，符合预期，任务状态是完成或者是延期完成
- 到这里基本一个小循环、小周期就完成了，后续基本按照这个模式继续往下走就行了。
-
制造业的流程管控
- 上面说完了纯软的，但是到软硬都有的制造业，这里又有很多不一样的东西，导致上面的流程不足，需要额外再利用 Plane 中的模块和视图内容
- 这里借一张图，制造业的时候，就不止一两个团队在项目中了，光是研发中就有5个团队介入了，这个时候Plane要怎么管理才能显得不乱呢。
- 研发过程类似上述的敏捷开发，这里不再重提，主要是说一下，在整个项目过程中各种职能的人要关注的内容如何用Plane实现
-
项目经理
- 项目经理需要关注各个阶段的内容，各个项目组是否按照预期完成
- 所以项目经理需要建立几个大的模块，这个模块就按照项目阶段来分，比如 EVT、DVT、PVT、MP
- 具体的任务就需要项目经理和各个项目负责人（产品/研发）确认这个内容属于哪个模块
- 后续项目经理就要关注各个阶段的任务是否有完成，要协调各个组的事宜。
-
研发
- 研发这个部分就比较简单，按照敏捷开发流程来就行了
-
测试
- 此测试非各个小项目组内的测试，这个是做可靠性、产品方案验证等内容的测试，是对批量的测试，而不是简单单体级别的测试
- 测试在这个过程中也依赖研发的支持，有些内容需要先开发完成才能进行测试，这个过程也需要项目经理进行协调、统筹
- 可靠性测试的内容，报告需要上传进Plane，Plane需要放开附件上传大小的限制，否则很多报告不够
-
生产
- 到了生产阶段，基本前面的流程都跑完了，这里关注的就是研发交接给生产的内容是否 OK，生产发现的问题追踪，改版改款的变更等内容
- 每个生产批次也一样可以建立一个模块，具体的变更或者交接内容都存放在这里即可
-
质量
- 当批量出货或者在各个阶段出现质量问题时，质量就需要单独建立自己的质量追踪面板
- 在量产过程中发生的各种问题，质量就可以通过质量追踪面板去管理或者查看各个任务的情况
-
Summary
- Plane 目前是这么玩的，可能有一些理想化，要把整个项目组的人都协调进去，教会他们使用 Plane 需要花一些时间，跑几次流程以后大家熟悉了，走起来就顺了。
- Plane 的商业化进度真的是挺慢的，甚至我写的插件和我们开放出来的 Plane，Plane 销售都认为我是在二次销售免费版 Plane，有点搞笑了。
- Plane 取消了本地部署的商业版本，只保留在线版本，有点可惜了，很多商业环境是不允许使用这种在线版本的，更何况服务器还在国外。Plane 销售甚至还想拉我做中国区代理，结果被我拒了。
- Plane 的商业化实际还是会走向 Jira 等软件的老路，从简洁变复杂，最终年轻的勇者也会成为巨龙，再等下一个勇者。Plane 目前看起来距离飞书的项目管理还有不小的差距，目前只能赢在免费、轻量，大家用起来简单而已。
