obsidian/笔记文件/白日梦游戏/白日梦游戏_2022年6月23日/Pingcode项目管理工具.md

Pingcode项目管理工具

需求

1. 有且仅有一张个人工作表

   1. 问题：每天来有一堆事，有记录的，没记录的，和多个表相关
   2. 预期：每个人有一个工作习惯：每天来先打开一个工作表，表里计划的工作项。

2. 整个部门有且仅有一张本部门关心的需求列表

3. 1. 问题：部门的每个人的工作不掌握，无法掌握部门伙伴的工作
   1. 预期：部门主管每天看一张表可知道本部门的进度信息和跨部门的信息
   2. 首先是列表，可以一屏幕看到部门所需要的简要信息，一行一个需求，一行对应所需信息；不要像tapd那样分层，还要折叠；
   3. 列表操作，不要打开才能修改，直接在行列的空格内就可以修改
   4. 所有修改实时同步

4. 需求可以流动

   1. 问题：外网bug堆积无人推动，热更需要一个人全程推动到发布
   2. 预期：每个人主要关注自己手上的事，需求和bug只需要动一下鼠标即可交给下一个人，不需要全程跟踪和口头去推动
   3. 需求从策划到程序，从程序到测试，从测试到发布，每一个环节的转换应该有通知

5. 时间好规划

   1. 问题：规划写了时间，只是一群数字，需要从数字中去看合理性，效率极低
   2. 预期：主管可以快速可控地分配任务
   3. 可以规划时间
   4. 可以容易发现规划时间的不合理性，如同一天规划了多件事，或事的先后顺序不合理

6. 进度易收集

   1. 问题：部门主管需要组织日会获取本部门情况，程序需要去查阅美术部门的表来获取美术资源的完成信息；
   2. 预期：每天早上大家自动获得最新的进度信息

7. 进度可视

   1. 问题：每个部门只看到自己部门的进度，还有些部门不知道进度，没有人知道整体的状况
   2. 预期：大家可以站在全局视角看到整个项目的进度，卡点
   3. 可以快速看到版本每个需求的进度
   4. 可以看到整个版本的进度

目前的问题

有1，3，5，6的问题，解决了2，4的问题

pingcode的优点和缺点

有4，6的问题，解决了1，2，3，5的问题，4问题比以前弱了，但后续能让pingcode做优化或购买其源码来解决。已经提了需求。

部门试用指导

公共使用要求点

1. 自己今日工作

   1. 每天进入自己的工作台

1. 今天的待做事项

1. 相关人的进度

   1. 目前的表
      1. 策划的：📅 躲猫猫内容规划
      2. 程序的：版本内容进度
      3. 美术的：https://doc.weixin.qq.com/txdoc/excel?scode=ACoA4QdJAAgFr6DRKSAJ4AvwaYAII&docid=e2_AJ4AvwaYAIIO8xKO0ClTVCvMaQ5q5&type=1
      4. 测试的：测试任务计划排期
      5. 运营的：DMM BUG记录反馈表
   2. pingcode的agile可以把以上的表合一
   3. 进入agile

1. 进入迭代

1. 配置显示列

1. 根据需要筛选
   1. 只看程序的

1. 只看美术的

1. 看程序和美术的

1. 流转

   1. ##### 状态和负责人传递
      

1. 状态

   1. 挂起：无时间开发、无法复现的bug；
   2. 其他常规理解；

2. 状态与负责人的对应关系

1、新提交 —— 策划

2、程序开发中——程序

3、策划验收中——策划

4、程序转测中——程序

5、程序优化中——程序

6、测试中——测试

7、测试完成——测试

8、项目经理关闭——项目经理

1. ##### 状态流转
   

1. 其他技巧

   1. 在网页打开
      1. 浏览器打开 https://feishu.pingcode.com/signin ，飞书授权后进入 PingCode
      2. 浏览器打开 https://企业域名.feishu.com/marketplace/applications/all 即可进入应用市
         1. https://vcwd20210111044554663.pingcode.com/marketplace/applications/all
      3. 用chrome来打开，IE支持不好
   2. 通过“编号”进行查找
      1. 在“工作台”里查找

1. 编号前加“#”

程序额外要求点

1. #### 有开发任务的务必加工作项
   

需求讨论结束后，有开发任务的伙伴都应该把自己对应的工作建个任务单，加入到该需求的工作项中。

1. 分解子工作项

   1. 预估开发的所有工作项，尽可能把需求分成约1-2天的任务项（关键）

1. 准确预估开发时间（重要）

1. 最好设置关联关系，可方便其他人了解上下的依赖关系

1. 推动需求方体验

   1. 给出体验包的地址，再将需求把负责人指向需求负责人，状态改为“策划体验中”

1. 内网bug修复

   1. 客户端
      1. pingcode状态流
         1. 处理中 -》已修复 -》提交测试
      2. 解了bug的伙伴需执行以下三步
         1. 向develop流发起提交申请，申请描述里带pingcode的单号
         2. 把pingcode上关于此bug的单的状态改为“已修复”
         3. 在评论里说明原因以及修复方式
         4. 在飞书上通知代码审核人（约克、或阿牛、或火柴）
      3. 代码审核人审核通过后，执行以下两步：
         1. 把代码合并到develop流，在当天把所有该合的合完，BUG修复人负责催促；
         2. 把pingcode上关于此bug的单的状态改为“提交测试”，并把单转给测试对应负责人

测试额外要求点

1. 提交bug

   1. 生成缺陷，找到父需求，指明负责人

1. #### 提交的缺陷一定要挂到功能需求下，找到他对应的父需求
   

有父任务的状态

无父任务的设置方式

1. #### 提交测试用例
   

运营额外要求点

1. #### 提交外网bug
   

1. bug过期关闭

   1. 如果在自己身上“挂起”的bug在一个月内都没有再反馈者，则关闭该bug

策划额外要求点

1. #### 提交需求
   

1. #### 修改状态
   

有两个相关状态

（1）新提交 —— 策划：提交需求的初始状态，该状态要求策划提交需求文档并组织讨论；

（2）策划验收中——策划：此状态由程序开发完成后转过来的，在完成验收后负责人变为程序，并把状态转为“程序转测中”；如果验收有修改意见，则提交修改需求，把状态转为“程序优化中”，负责人变为程序。

1. #### 写配置
   

策划要提交配置，需要在需求下生成一个任务

事务处理

需求开发事务

体验验收事务

1. 推动提交测试或测试中的需求才能进入验收（项目经理）
2. 体验环境构建（功能负责人）
   1. 向测试主管或程序索要体验包
   2. 把体验包地址填到对应需求的“体验包地址中”
   3. 构造必现环境
3. 验收发起（功能负责人）
   1. 通知验收人
4. 验收意见提交（验收人：可可、路飞、286、会长、考拉、袋鼠、小旋）
   1. 验收人设置表头显示字段，加入以下显示列

1. 验收人择时下载体验包进行体验

1. 无法验收的则在需求对应的“xxx验收评价”中填写理由

1. 体验问题以缺陷的形式提交，提交给功能负责人

1. 把验收问题转入开发（功能负责人）
   1. 功能负责人判断需要修改的缺陷，然后转给对应开发人
2. 验收完成（验收人）
   1. 在“xxx验收评价”中填“通过”

现网bug处理事务

外网bug处理流程

常见错误

1. ## 状态转换，负责人没变
   

西瓜把状态改为“开发完成”，需要把这个负责人改成测试伙伴，否则他不知道

1. ## 总需求已经“开发完成”，但子任务项没有完成
   

1. ## 大需求没有分出1-2天的工作项
   

1. ## 状态与负责人的对应关系不对
   

1. ## 缺陷要挂到需求下
   

没父任务的

加一下父任务