类型：代码托管平台
简介：只支持Git作为唯一的版本库格式进行托管，故名GitHub。
GitHub Projects可以把Issue、Pull Request和普通任务放在同一个看板里，适合开发团队、开源项目和轻量产品团队使用。但很多小团队刚开始就设计十几个字段、复杂自动化和多层状态，结果成员不愿更新，看板很快失真。任务管理的关键不是字段越多越专业，而是每个字段都能帮助团队做决定。
一、从三个问题开始
搭建Projects前，可以先问三个问题：现在有哪些任务在做，哪些任务被卡住，下一步谁负责。如果看板不能回答这三个问题，再漂亮也没有价值。小团队初期只需要状态、负责人、优先级、截止时间四类信息。等流程稳定后，再增加版本、模块、需求来源或工作量估算。
状态列也不要过细。可以先用待处理、进行中、待确认、已完成。若测试和发布流程较复杂，再增加测试中、待上线。状态越多，成员越容易不知道该放哪一列。
二、字段设计要服务沟通
负责人字段用于明确下一步由谁推动，不代表所有参与者。优先级字段用于排序，不应被所有任务都标成高。截止时间用于提醒关键节点，不应给每个低价值任务都随便填日期。字段如果没有明确用途，就会变成形式负担。
任务描述要写清背景、目标和验收标准。比如“优化首页”太含糊，可以改成“压缩首页首屏图片，让移动端首屏加载时间下降，并确认主要浏览器显示正常”。描述清楚后，任务在看板里流转才有意义。
三、Issue和普通任务要区分
不是所有事情都需要建Issue。Bug、需求、可讨论的改动适合Issue；一次性提醒、会议准备、资料整理可以用Draft Item。
把所有杂事都变成Issue，会污染项目仓库的问题列表。反过来，涉及代码变更的任务如果只写在看板里，没有Issue或PR关联，也不利于追踪历史。
小团队可以约定：需要讨论、复现、关联代码的事项建Issue；纯执行事项用普通任务；代码合并必须关联PR。规则简单，执行成本低。
四、自动化先做最少的一步
Projects支持自动化，例如Issue创建后进入待处理，PR合并后任务完成。但自动化过多会让成员不知道状态为什么变化。初期可以只设置最基础的自动流转，再根据真实痛点增加。比如PR合并后自动移到待发布，而不是直接已完成，因为很多项目合并代码后还需要上线验证。
自动化规则要定期检查。项目流程变化后，旧规则可能把任务移到错误状态。看板如果经常自动错，就会失去信任。
五、每周复盘看板是否真实
任务看板最怕变成展示墙。每周可以花十分钟检查：进行中是否过多，待确认是否无人处理，高优先级是否过多，过期任务是否仍有价值，已完成任务是否符合验收标准。看板反映真实状态，团队才能用它做决策。
GitHub Projects适合小团队，是因为它和代码、Issue、PR天然连接。保持字段轻量、状态清楚、任务描述具体，比一开始追求复杂流程更重要。
六、看板里的任务要有完成定义
很多任务在看板里长期停留，是因为没有写清什么叫完成。比如“优化搜索体验”可以无限延伸，但“搜索结果为空时显示提示，并记录无结果关键词”就有明确边界。每个任务至少应写清目标、交付物和验收方式。否则状态从进行中移到已完成，只是主观判断。
完成定义不需要很正式，可以是一句话。开发任务说明代码合并和测试结果，文档任务说明页面已更新并经过检查，设计任务说明文件位置和确认人。定义越清楚，协作越少争议。
七、优先级要定期重新排序
项目看板不是一次排序后永久不变。需求变化、Bug出现、成员时间变化都会影响优先级。小团队可以在每周开始时检查一次高优先级任务，确认它们是否仍然重要，是否有人负责，是否需要拆分。长期挂在高优先级但没人处理的任务，会让优先级字段失去意义。
如果所有任务都标高优先级，等于没有优先级。可以限制同一时间高优先级任务数量，让团队真正聚焦。低优先级任务也不代表不做，只是暂时不占用主要资源。
八、让PR和任务互相解释
GitHub Projects的优势在于能关联Issue和PR。一个任务进入开发后，应能看到对应PR；一个PR合并后，也应能回到任务看为什么要改。这样几个月后回顾项目时，不会只看到代码变化，却不知道当初的需求背景。
对于不涉及代码的任务，也可以在任务里记录文档链接、讨论链接或交付位置。看板不是替代所有沟通，而是把关键信息串起来，让团队不用反复翻聊天记录。
九、看板要和真实节奏匹配
小团队的Projects不需要模仿大型公司的流程。若团队一周只发布一次，就按周整理任务；若每天都有线上问题，就保留快速处理通道。看板服务于协作节奏，而不是让成员为了更新字段消耗时间。
当团队发现某个字段连续几周没人使用，就应考虑删除；当某类问题反复沟通不清，再增加字段。字段设计从真实问题中长出来，才会被团队长期使用。
