万物有归处：我的工作追踪之道

# 万物归位：我是如何追踪工作的 来源：https://mikezornek.com/posts/2026/7/a-place-for-everything 当我在某个项目中承担管理职责，并且有能力影响工作流程时，这是我管理问题（Issue）和拉取请求（Pull Request）的惯用方式。这并非唯一正确的方法——它只是我逐渐形成的系统，我觉得把它写下来对自己和喜欢这类内容、想改进自己流程的博客读者都很有用。 补充说明：如果我加入一个已有成熟软件生命周期的团队，我不会凭空引入这套东西。我可能会多问一些关于他们流程的问题，了解他们为什么选择这样，但任何改变都会通过团队讨论和选择逐步进行。 ## 问题跟踪 我喜欢把问题放在 GitHub Issues 里，并通过 GitHub Projects 展示进度/排期。我选择 GitHub 是为了尽可能贴近代码/仓库。两个原因： - 知识紧邻它涉及的代码，而不是漂移到另一个容易丢失的独立工具中。（我发现人们频繁更换文档工具，而脱离 GitHub 似乎不太可能——尽管最近风向可能有所变化。） - 干系人可以获得可见性——他们能看到哪些在进行中，查看史诗级别的进度，并根据时间表评估风险。 ## 问题状态 我倾向于按状态组织问题，并且比大多数人使用更多的阶段。额外的粒度可以让人一眼看清工作的确切位置： - **机会（Opportunities）**——尚未成型的工作想法 - **待命中（On Deck）**——已排优先级、成型且理解清楚 - **进行中（In Progress）**——已开始 - **待审核（Needs Review）**——已完成（未合并）但等待同行评审 - **完成（已合并）（Done (Merged)）**——已合并但未部署 - **已部署（已发布）（Deployed (Shipped)）**——已部署给客户 - **待验证（To Be Verified）**——已部署但明确等待业务审查后才能视为完成 - **已验证（Verified）**——业务干系人已评审并通过，认为正确完整 - **已取消（Canceled）**——放弃，不再考虑 这里命名是经过斟酌的。我用“机会”而不是“积压”（Backlog），因为“积压”暗示一堆你必须完成的工作。而“机会”可以无期限地放着，可能永远不会被排优先级——这样完全没问题。它为想法提供了一个公开讨论和考虑的地方，而没有积压不断增长的无声负罪感。风险在于“机会”列可能变得太大而难以浏览。遇到这种情况时，你可以清理它，关闭一些 Issue，这是允许的。 ## 问题类型，用于浏览大量机会列表 状态告诉你工作*在哪里*；类型帮助你了解它*是什么*，尤其当机会列表变长时。 - **任务（Task）**——需要做的具体事情，包括非代码类工作 - **缺陷（Bug）**——意外的问题或行为 - **功能（Feature）**——新功能 - **增强（Enhancement）**——对现有行为的改进 - **增强：UI（Enhancement: UI）**——改善可用性的界面更改，不涉及新行为 - **安全（Security）**——与平台安全相关的工作 - **代码重构/DevOps（Code Refactor / DevOps）**——代码质量变更和开发者体验改进 - **文档（Documentation）**——对已有知识的改进或补充 ## 讲故事的拉取请求 拉取请求是实际解决问题的场所，所以我喜欢将两者明确地联系起来。一个 PR 应该引用它修复的 Issue（具体方法见 GitHub 文档（https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword）），这样在合并时能自动关闭。如果任务是推动进展但不应关闭 Issue，我会说 `Related to: #123`。 我坚持的几点： - **使用 PR 模板。**模板有助于每个人记住审查者通常需要的内容。这是默认值，不是规则——如果某个变更有更好的呈现方式，忽略模板，用更好的方式呈现。 - **把 PR 塑造成一个故事。**解释问题或增强请求，然后逐步说明变更内容以及它如何解决问题。给出清晰的验证方法——如果默认开发环境没有演示所需的数据，包含代码来填充该场景。 - **尽早以草稿形式打开 PR。**我在自己的开发周期早期就会推送一个 PR，以便其他人可以看到我在做什么。“草稿”状态表示我尚未请求审查。只有当标记为“开放”并正式请求审查时，我才真正需要他人审阅。 ### 一个示例模板 模板可以非常简洁。以下是我使用的最简单的模板之一： ``` Fixes # / Related to # ## How to test/verify Please include instructions for manually reviewing this changed behavior. ``` 我合作过的其他团队更喜欢一个模板，在交给他人之前促使作者先自查——在请求别人时间之前，问自己几个问题： ``` Fixes # / Related to # ## Problem Statement ## About the Change ## How to Test and Verify ## Author checklist - [ ] 代码是否经过了充分测试？ - [ ] 类型规约是否明确？或者新类型过于泛化吗？ - [ ] 是否考虑了新代码的性能特征？ - [ ] 是否记录了任何新决策？ - [ ] 是否有普适语言或命名上的变化，其他人应该知道？ - [ ] 是否需要更新文档或变更日志？ - [ ] 是否有任何后续问题值得在遗忘之前提出来？ ``` 确切的问题本身不重要，重要的是它们鼓励的习惯：在 PR 成为别人责任之前进行一次自我审查。不要浪费同事的时间。尊重他们，给他们提供做好审查所需的上下文和工具。而且不用说，PR 要尽量保持小规模。学会拆分你的变更。 --- **关于作者。**Mike Zornek 是一位专注于产品设计和开发的开发者及教师，尤其侧重于 Elixir 和 LiveView。在项目间隙，Mike 通过咨询（https://mikezornek.com/elixir-consulting/）为其他团队提供帮助。业余时间，他喜欢看费城人队的棒球比赛和玩放松的电子游戏。希望你喜欢我的随笔。如果你有评论或回应，我很乐意听听你的想法（https://mikezornek.com/contact/）。