Trello 是一个极其灵活的项目管理工具，用户可以按照自己的需求对 Trello 的 Board、List 和 Card 进行组织，从而打造适合自己的项目管理流程。

经过几个月的实践，发现 Trello 虽然灵活性极强，但如果没有一个规范，那么要不了多久 Trello 里的内容就会出问题。所以春节假期这几天，我根据产品和团队的实际情况，对团队 Trelllo 做了一些定制，希望把整个开发工作流程规范化起来，让协作更顺畅。

<br />

角色与职责

任何管理都要基于一些规则和约定，所以我首先明确了团队所有成员的角色及其职责。不过由于我们团队只有几个人，而且没有专职 QA 等成员，所以我只规范了 Project Manager 和 Developer 的职责。

Project Manager

被广大程序猿痛恨的 PM 在产品开发中承担了极其重要的任务。PM 必须确定版本计划和任务列表，并随时跟踪进度和调整开发计划。

具体而言，PM 的职责包括：

• 确定产品的版本计划：版本计划包括这个版本需要达到的目标、开始日期、发布日期。
• 确定每一个版本中需要完成的任务：虽然每一个版本的主要目标和功能都是整个团队讨论的结果，但一个版本到底包含哪些任务，只有 PM 可以决定。
• 跟踪开发进度：在开发进行中，时间是很难精确量化的。所以 PM 要随时跟踪开发进度，然后调整版本计划。例如在 deadline 到达之前将一些优先级较低的任务移动到下一个版本计划中。
• 沟通：PM 日常的主要工作就是沟通。由于我所在团队有三个产品需要和其他团队进行协作，所以 PM 还要负责团队间的沟通。当出现一些突发情况时，PM 要立即提供一个可行的解决方案。

Developer

开发人员的主要工作当然是完成产品开发工作，但实际上还会有一些其他职责：

• 任务评估：在确定版本计划时，开发人员必须提供尽可能准确的任务评估。任务评估包括：可行性、时间消耗、外部资源支持。PM 根据开发人员提供的任务评估来决定版本计划中的任务列表。
• 进度反馈：在与 PM 沟通时，开发人员必须如实反馈开发进度。

<br />

Board - 看板

我将 Board 视为一块白板，然后划分为多个 List。而 List 中每一个 Card 可以在不同 List 中移动。

Roadmap

首先，我定义了一个 Roadmap Board。这个 Board 中，每一个 List 是一个产品的版本计划。每一个列表中的 Card 则代表一个产品版本。

Roadmap 中的每一个 Card 有三个基本要素：

• Title: 产品缩写名称 版本号（开始日期 - 发布日期）
• Due Date: 发布日期
• Description: 需要填入明确的版本目标

例如：

版本 Card

Trello 可以为每一个 Card 设置 Due Date，但却无法设置开始日期。为了一目了然看到版本的开始和发布日期，所以干脆规定将日期写入 Card Title。而目标用于描述这个产品版本必须实现的特征。

Roadmap 看上去如下图：

Roadmap

当 Roadmap 里的一个 Card 即将进入开发阶段时，PM 需要在 Trello 里为这个版本创建一个单独的 Board。

产品 Board

每一个产品版本的 Board 都以该版本的 Title 来命名。然后划分为以下几个 List：

• Next Up：这里放置所有等待开发的 Card，并按照优先级排序。大多数时候，在将 Card 添加到 Next Up 时，就需要为 Card 指定 Members，明确负责这个 Card 的 Developer。
• In Progress：Developer 需要从 Next Up 挑选由自己负责的优先级最高的 Card，然后移动到 In Progress 中。
• QA：当一个 Card 的开发完成后，应该将其移动到 QA。测试人员对该 Card 进行测试。测试未能通过，Card 移动到 Next Up（如果需要立即修复，则设置为高优先级）。测试通过，Card 移动到 Launchpad。
• Launchpad：在版本发布前，所有完成的 Card 都会放置在这里。当版本进行集成测试时，如果发现问题，Card 可能会移动到 Next Up。当版本集成测试通过，可以发布时，所有 Card 移动到 Done。
• Done：在产品发布时，所有 Card 应该都位于 Done 列表。

关于 Card 的优先级，我们规定只有必须立即解决的任务才需要指定红色 Label。优先级只用于标注任务是否应该被立即处理，而不是用于标注任务的重要性。

一个产品 Board 看上去如下：

产品 Board

Feedback

所有来自 QA 和用户的反馈，如果 PM 不能立即确定如何解决，那么都必须添加到 Feedback Board 中。

• Feedback 按照根据产品版本分为多个 List，也可能一个产品的多个版本共享一个 List。
• 当 Feedback 里的一个 Card 确定需要 Developer 解决时，PM 就将该 Card 移动到某个产品 Board 的 Next Up 中。如果某些问题跨越多个版本，那么可以使用 Copy Card 功能复制多份。

Inbox

这个 Board 相当于团队的 Idea 收集器。这里的 List 和 Card 可以自由创建和修改，但所有 Card 绝对不能直接移动到 Roadmap 或产品 Board 中。

<br />

回顾

在确定团队成员角色和 Board 后，我们的工作流就跃然纸上：

Workflow

由于 QA 工作交由协作团队完成，所以实际工作中，PM 还要负责将协作团队 QA 的反馈整理到 Feedback 中。

<br />

在假期里对这个新的工作流做了一些模拟测试，暂时没有发现问题。不过实践起来肯定还有要调整的地方。我会不断更新这篇文章，记录下工作流的变化情况。

参考：使用Trello实现敏捷项目管理

-EOF-