GitHub 团队任务管理流程

注:本篇是针对团队的任务管理,非开发规范。

前言

GitHub 本身是非常推崇和支持团队合作,也有一些帮助项目管理的插件如 ZenHub,但这里我主要记录使用原生 GitHub 功能的团队任务管理模型构想。

在开始之前,我搜索过大量中文资料,但关于基于 GitHub 的团队管理方面资料很少,尝试英文搜索后,发现我所有的问题都能在官方的 GitHub Help 文档中找到答案;

# 再次强调官方文档的重要性 #

所以本篇也不会讲如何操作 GitHub,更不会讲如何使用 Git。

起因

实验室内部需要一套规范化的团队管理方案,总体采用用任务驱动制,因此产生了一套

制定任务 –> 安排任务 –> 分配人员 –> 追踪进度 –> 审核成果 –> 解决任务

的管理需求。

细分来说,制定任务包括建立项目,规划项目的几个进行阶段,每个阶段具体有哪些任务,每个任务有哪些要点。

对整个团队来说,有不同方向的人员分组,制定的各项任务应该安排给适合的分组去完成,并且按照拟定的计划,阶段内的任务应该有时限,有明确的截止期限。

在分组内部,再通过分解步骤拟定各项任务和要点,分配给相应的成员。

审核人员根据各项任务完成进度,及时调整,对完成的任务做审核评估,最终标记任务为已解决。

方案

GitHub 提供的诸多特性都是应对管理模式的,各项概念中,Issues 提出问题与讨论;Milestone 里程碑,用于将 Issues 划分阶段进行追踪管理;Project 规划和管理项目;Organization 组织,下属成员可分为多个 Team,Team 可多层细分,并有不同的权限;对项目开发来说,能建立 Repositories 放置文件代码,人员相互之间形成 collaborator 合作者;以上这些特性完全能胜任我们需求的管理模式。

对应以上需求,实验室所有人员组成一个 Organization;

按不同研究方向将 Organization 划分为多个 Team,每个 Team 中按照小组关系进一步建立二级、三级 Team

实验室需要做的项目按照敏捷管理的方式建立 Organization 的 Project,具体划分的不同模块建立多个 Repositories,Organization 的 Project 能跨不同的 Repositories 管理 Issues

Repositories 没有层级,一个 Repository 能被分配给多个 Team 并赋予不同的权限,但我们可以将一个 Repository 只分配给一个 Team,这样看作是 Team 拥有自己的 Repository。

在 Team 的 Repository 中,通过建立 Milestone 来安排任务目标和截止时间,在 Milestone 中添加 Issues 用作安排具体的任务,Issue 中能建立 Task List,用来表示一个任务的完成步骤和要点;每个 Issue 能指派不同的人员或 Team;Milestone 中会显示所属 Issues 的完成进度,用作任务管理再合适不过了。

Issues 之间能互相提及(关联)这在相互沟通上很有帮助;整个 Issues 面板功能都可以被关闭,但我们更常用的是针对一条 Issue 使用 Locking conversations 功能锁住权限,这样就只有拥有仓库权限的人能在这条 Issue 下评论,通常用于防止 spam,在合作管理中也就防止了不相关的人来捣乱。

一般来说,如果 Team 需要合作完成一项具体的项目,那么可以建一个管理敏捷开发的 Project;如果只是一般的日常任务需求,那么在任务仓库建立几个 Milestone 就够了。两者核心都是 Issues track

审核任务包括 Code Review 和审核 Issues 完成情况;Code Review 可以在完成一个 Issue 或 完成一项 Milestone 时进行;Issues 进度跟踪需要在日常进行,如果 Issue 是考核任务,那么在超时未 Close 后应认为考核失败。

解决任务的表现形式就是 Close,Close Issues、Close Milestone、Close Project。

总结

以上方案就是目前构想的基于 GitHub 的团队任务管理模型,之所以说构想,是因为这套方案未被实施验证,实际进行中肯定会有各种修改和补充的细节。

参考资料