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