Project Board使用引导

[leopoldchen]

@LiXizhi @azothli

为了让之后的团队协作更明确清晰，我参考了Gitlab的board使用方式和自己以前的管理经验，新增了一些board，在介绍这些board之前，我先简单介绍一下我的思路。

通过观察Gitlab项目的board设计，发现issue是可以关联多个project board的，请查看当前页面的右侧，可以看到如下的一个区域： 这里的project board其实是为了方便团队中的不同成员通过不同的视角去查看issue，以及呈现issue在不同工作流程中的状态，当然，让团队成员可以更好的过滤出和自己相关的issue。比如programmer看到的是在研发中的issue，而pm看到可能是早期的产品需求。又比如，当程序员在研发的时候只要关注dev board，而当准备解决技术反馈问题的时候，就可以切换到feedback board里去看一看有哪些待处理的issue.

以下我来仔细介绍一下每个board的用途

• Documentation 文档任务管理Board 主要用于纯项目文档编写的任务，即任务的产出是一些文档。 场景有需求分析文档，技术方案文档，产品功能文档，产品计划文档等等。 目前我把board状态分为四栏：

  1. Backlog 待处理
  2. TODO 当前迭代周期计划完成的Issue
  3. In Progress 进行中
  4. Presentation 给同事讲解，这个过程很重要，文档需要能被看懂，这样才有价值。
  5. Closed 关闭

• Overview 总览Board 这是项目经理/产品经理主要关注的board，可以观察到整个产品的Issue状态进展。 Board分为七栏：

  1. Backlog 待处理需求
  2. TODO 当前迭代周期计划完成的Issue
  3. PM Design 产品设计
  4. UI UX
  5. Development
  6. QA
  7. DevOps
  8. Closed

以上其实是一个常规的新功能开发流程，产品经理做好产品设计，UIUX设计师做好高保真，之后程序员开发，QA测试，最后有运维人员负责新版本发布。

• Production 产品任务管理Board 这是产品经理的任务board，用于产品设计的周期管理。 Board分为：

  1. Backlog 待处理需求
  2. TODO 当前迭代周期计划完成的Issue
  3. Requirements 需求分析，整理用户故事，补充产品文档
  4. Design 设计功能草稿
  5. Review 与程序员和美术设计师一起讨论新功能，确保大家理解新功能，也确保功能流程是合理无误的。这一步非常非常重要。一方面，可以以很小的代价挽回一些错误的产品设计，也有助于在早期就做设计优化。另一方面，让相关人员更早的了解将来需要开发的产品功能，可以提供团队成员的产品思维和主人翁感。
  6. Closed

• UI UX 美术设计任务管理Board 用于美术设计的周期管理 Board分为：

  1. Backlog 待处理需求
  2. TODO 当前迭代周期计划完成的Issue，产品经理&项目经理在sprint开始前把issue放入，并排好优先级，执行者按优先级选择完成这些issue。
  3. In Progress 设计中。美术设计师根据PM提供的草稿做进一步的设计。
  4. PM Review 设计稿需交与PM做review，确保没有违反产品设计。
  5. Closed

• Development 程序设计任务管理Board 用于程序开发的周期管理，目前没有做前后端划分，之后如果需要，可以加入frontend和backend board Board分为：

  1. Backlog 待处理需求
  2. TODO 当前迭代周期计划完成的Issue，产品经理&项目经理在sprint开始前把issue放入，并排好优先级，执行者按优先级选择完成这些issue。
  3. In Progress 程序员根据issue，创建开发分支，在开发分支上做开发，一般情况下一个分支只解决一个issue。分支上的代码要确认通过CI的所有测试。 如果发现DEV分支已经被更新，请及时rebase开发分支，并提交最新代码。
  4. PM Review 程序员实现好的功能需交与PM做Review，保证功能符合需求。
  5. Code Review 功能实现无误后，提交PR，由其他程序员或相关人员做代码Review，在代码被approve后，将branch合入dev分支。
  6. Staging 当DEV分支被更新后，请自动将最新的DEV代码部署到内部测试服务器。QA需要对每个在测试服务器上的Issue做测试。
  7. Pending Release 当QA测试好Issue后，将其拖入Pending Release一栏，等待运维人员做部署处理。
  8. Closed

• QA 测试任务管理Board 用于测试开发的周期管理，QA Team需要对自动化测试的开发流程做管理

  1. Backlog
  2. TODO 当前迭代周期计划完成的Issue，产品经理&项目经理在sprint开始前把issue放入，并排好优先级，执行者按优先级选择完成这些issue。
  3. In Progress 测试开发中
  4. Review QA组内代码Review，也可以让程序员帮忙Review 5 Closed

• DevOps 运维任务管理Board 用于运维开发的周期管理

  1. Backlog
  2. TODO 当前迭代周期计划完成的Issue，产品经理&项目经理在sprint开始前把issue放入，并排好优先级，执行者按优先级选择完成这些issue。
  3. In Progress
  4. Staging
  5. Pending Release
  6. Closed

• Feedback 用户反馈管理Board 用于管理用户反馈，追踪用户反馈的处理过程。

  1. Backlog
  2. Analysis 这一步要区分情况来指派人员做处理。如果反馈的是一般bug，那么由QA做重现，之后由项目经理将Issue排进开发流程；如果是产品设计问题，有产品经理和美术设计师先做修改，之后再交与程序员开发；如果是技术问题，可能需要安排程序员做排查，并和反馈人员沟通。总之，需要根据具体情况做处理。
  3. To Schedule 在确定问题归属的情况下，准备安排时间解决，项目经理需要安排具体事宜。
  4. In Progress 说明Issue已经进入处理流程
  5. Closed

• Improvement 优化改进提议Board 用于管理和追踪一些产品架构或者是技术架构相关的Issue，团队成员可以在这边积极地提出自己的想法。产品经理和技术主管会对相关问题做分析探讨，再做之后的安排。

  1. Backlog
  2. Analysis 由Issue负责人发起讨论，确定解决方案
  3. To Schedule 在有明确讨论结果和方案的情况下，有项目经理来做具体时间安排
  4. In Progress 表明Issue已经进入处理流程
  5. Closed

[leopoldchen]

添加了TODO一栏，用来放置当前迭代周期计划完成的任务事项。 考虑到平时团队成员在开发过程中可能会自己添加一些Bug issue，而后直接开始开发，这时候最好是让成员把这个issue关联到overview中，否则总览时就无法正确查看到。

[leopoldchen]