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: 需要填入明确的版本目标
例如:
版本 CardTrello 可以为每一个 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 看上去如下:
产品 BoardFeedback
所有来自 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 />
在假期里对这个新的工作流做了一些模拟测试,暂时没有发现问题。不过实践起来肯定还有要调整的地方。我会不断更新这篇文章,记录下工作流的变化情况。
-EOF-
网友评论