任务和工单 — 是什么、跟踪系统以及任务处理

什么是任务和工单？

任务 (源自英文 task) — 在跟踪系统中记录的工作单元。包含描述、优先级（Critical、High、Medium、Low）、执行者、截止日期和状态。在移动开发中，任务可以是 “添加带头像的个人资料屏幕”、“实现信息流分页” 或 “将 targetSdk 版本更新到 35”。每个任务都绑定到项目、冲刺以及特定的开发人员或团队。

工单 (源自英文 ticket) — 更广泛的实体。工单可以是错误报告（“应用在 Android 14 上旋转屏幕时崩溃”）、功能请求（“添加深色主题支持”）、技术支持请求（“推送通知未到达”）或经理任务（“准备月度崩溃率报告”）。任务和工单之间的区别很模糊：在 Jira 中，两个概念统一在 Issue 中。关键区别：任务始终是有执行者的工作，工单在分类之前可能没有具体的执行者。

在 Scrum 和 Kanban 中，任务是产品待办列表的主要元素。每个任务都应满足 INVEST 标准（Independent、Negotiable、Valuable、Estimable、Small、Testable）。独立的任务可以按任何顺序实现。可评估的 — 团队可以估算工作量。小型的 — 可在一次冲刺中完成。可测试的 — 有明确的验收标准。大型任务（史诗）被分解成更小的部分，直到满足所有标准。

移动开发中的任务类型

Feature — 应用程序的新功能。例如：“通过生物识别（Face ID / Touch ID）登录屏幕”。Feature 任务始终与用户故事关联，并有验收标准。评估 — 以故事点为单位（1、2、3、5、8、13）。Bug — 在开发或测试过程中发现的缺陷。错误工单的优先级由严重性决定（崩溃 → Critical、UI 错误 → Medium、拼写错误 → Low）。在移动开发中，高于 0.1% 的崩溃率是关键错误，需要立即修复。

Tech Debt / Chore — 对用户没有可见影响的技术任务：更新库（Dependency Bump）、重构（从 ViewPager 迁移到 ViewPager2）、配置 CI/CD、编写测试。Tech Debt 任务经常被低估，尽管根据 Stripe 2025 的数据，移动团队高达 30% 的时间用于维护和偿还技术债务。忽视 Tech Debt 会导致错误数量增加和新功能开发速度减慢。

其他类型：Spike（研究任务 — 学习新技术、编写 POC）、Task（任何与代码无关的工作 — 文档、设计评审）、Improvement（改进现有功能 — 优化屏幕加载时间）。在 Jira 中，问题类型可以根据项目进行配置。移动团队的标准集合：Story、Bug、Task、Improvement、Epic。Epic — 整合多个故事的大型主题。例如：“电子商务：购物车和订单结算”。

任务生命周期：从创建到关闭

Open (To Do) — 任务已创建但尚未开始。包含描述、验收标准、优先级。在此状态下，任务在进入冲刺之前应经过梳理（澄清和评估）。In Progress — 开发人员已开始工作。在移动开发中，将提交和拉取请求链接到任务非常重要：在 Jira 中通过 Smart Commits（APP-123 #comment 修复错误），在 GitHub/GitLab 中通过 PR 描述中的关键词（Closes APP-123）。

In Review — 代码已发送进行审查。自动检查：CI（Gradle build、lint、单元测试）、SonarQube（代码质量）、Danger（变更日志、测试）。在当前任务处于 Review 状态时，开发人员不能开始下一个任务 — 这可以防止多任务处理。QA / Testing — 测试人员在实际设备上检查（Android — 不同操作系统版本和屏幕尺寸，iOS — 不同 iPhone 型号）。如果发现错误，任务将带注释返回 In Progress。

Done (Closed) — 任务完成：代码合并到 main/master，通过测试，准备发布。一些团队添加了 Deployed 状态 — 任务只有在应用商店发布构建后才到达用户。用结果注释关闭任务很重要：什么版本、什么 PR、什么指标发生了变化。根据 Linear (2025) 的数据，用结果描述关闭任务的团队回到相同任务的可能性降低 40%。

生命周期可以包括 Blocked 状态 — 由于外部依赖关系，任务无法执行（等待设计、后端响应、经理批准）。被阻止的任务应有包含原因和下次检查日期的注释。每周审查被阻止的任务有助于识别开发过程中的系统性延迟。超过 2 周的阻塞需要上报到产品经理级别。

任务跟踪系统

Jira — 10 人以上团队的行业标准。支持 Scrum 和 Kanban 看板、高级工作流配置、自定义字段、自动化、与 Bitbucket/GitHub 集成。缺点：对小团队过于冗余、界面缓慢、配置复杂。对于移动项目，Jira 通过以下方式配置：Mobile-specific fields（Platform、OS version、Device model）插件、与 TestFlight 和 Firebase Test Lab 集成、自动创建发布构建。Jira — 具有官僚流程的企业项目的选择。

Linear — 面向产品团队的现代跟踪器。快速界面、一流的键盘快捷键支持、内置 Cycle（类似冲刺）、与 GitHub 和 Slack 集成。优势：通过 CMD+K 快速创建任务、自动分配到阶段（Triaged → Backlog → Upcoming → Current → Completed）、内置文档和路线图。Linear 被重视工作速度的初创公司和产品团队选择。到 2025 年，40% 的新移动项目使用 Linear。

Trello — 面向小团队（2-5 人）的简单看板。带有检查清单、标签、截止日期的卡片。缺点：没有冲刺、分析有限、难以扩展。YouGile — 带有看板、聊天和视频通话的 Trello 俄罗斯版。Asana — 专注于项目和时间线的跟踪器。跟踪器的选择取决于团队规模、预算和偏好：企业用 Jira、产品团队用 Linear、初创公司用 Trello/YouGile。重要：工具应对整个团队统一 — 设计师、开发人员、测试人员、经理都在一个系统中工作。

任务管理最佳实践

编写验收标准 — 验收标准应具体且可验证。不好的例子：“登录屏幕能工作”。好的例子：“用户输入电子邮件和密码，点击登录。如果数据正确 — 转到主屏幕。如果不正确 — 显示 “电子邮件或密码错误” 的错误消息”。验收标准 (AC) 是开发人员、测试人员和产品经理之间的合同。没有 AC，任务不符合准备就绪定义 (DoR)，不应进入冲刺。

链接一切。提交、PR、测试用例、设计稿 (Figma)、Slack 讨论 — 所有内容都应链接到任务。在 Jira 中通过注释中的链接完成，在 Linear 中通过自动链接 PR 完成。一次点击规则：从任务到设计/代码/测试 — 不超过一次点击。开发人员打开任务并立即看到 Figma 中的设计稿、PR 链接和测试用例。根据 Linear (2025) 的数据，这使新团队成员的入职速度提高了 30%。

不要创建幽灵任务。没有描述、没有 AC 和没有优先级的任务是垃圾。如果在每日站会上没有人记得为什么创建了任务 — 应该删除或澄清。48 小时规则：如果任务在 In Progress 状态下没有活动 48 小时 — 开发人员应该留下关于延迟原因的注释。根据 Jira (2025) 的数据，60% 超过 3 天不活动的任务最终在没有执行的情况下关闭。

任务分解：史诗、用户故事和子任务

Epic — 整合多个故事的大型功能区域。例如：“用户引导” 包括 “欢迎屏幕”、“选择兴趣”、“上传头像”、“设置通知”。User Story — 从用户角度出发的任务。格式：“作为 [角色]，我想要 [行动]，以便 [价值]”。示例：“作为用户，我想通过生物识别登录，以便每次都不必输入密码”。用户故事由产品经理或产品负责人编写。

子任务 (Sub-task) — Story / Task 内技术工作的分解。以 Story “个人资料屏幕” 为例：Sub-task 1：创建屏幕 UI (XML / SwiftUI)，Sub-task 2：连接到 ViewModel，Sub-task 3：编写单元测试，Sub-task 4：快照测试，Sub-task 5：UI 测试 (Espresso / XCUITest)。分解规则：每个子任务在 1-2 天内完成。如果开发人员对子任务的评估更长 — 进一步拆分。子任务是团队的内部技术，在产品待办列表中不可见。子任务评估的总和不一定等于父 Story 的评估（部分工作 — 沟通、代码审查、测试）。

分解金字塔：Epic（季度 / 半年）→ Feature / Story（Sprint）→ Task（1-3 天）→ Sub-task（几小时）。INVEST 技术 有助于检查分解质量。如果任务不是独立的（依赖其他任务）— 这表明分解是错误的。如果任务不是小型的（超过 8 个故事点）— 需要进一步拆分。常见模式：Epic → 5-15 Stories → 每个 Story → 3-8 Sub-tasks。史诗的最终评估 = Stories 评估的总和，但首次冲刺通常在评估中有 20-30% 的偏差。

处理任务时的常见错误

错误 1：任务太大。 2 周工作的任务是需要分解的史诗。大型任务不适合日常跟踪，在 In Progress 中挂数周。规则：任务的最大大小 — 2-3 天的工作。所有更大的 — 进行分解。副作用：开发人员通过每周关闭 2-3 个任务而不是一个巨型任务来感受进展。这提高了积极性和截止日期的可预测性。

错误 2：缺乏验收标准。 开发人员完成了功能，测试人员检查了 — 一切正常。经理：“编辑按钮在哪里？” — “任务中没有写”。没有 AC，各方都以自己的方式理解任务。结果：返工、冲突、错过截止日期。AC — 合同：如果任务中没有标准 — 它未准备好进入冲刺。在梳理中，首先检查 AC 的存在。如果没有 AC — 任务将发送给产品经理进行修改。

错误 3：忘记技术债务。 团队一个接一个冲刺只做 Feature 任务。半年后：编译需要 15 分钟，Gradle 过时了 3 个主要版本，测试因弃用在 CI 上失败。解决方案：预留团队 20% 的时间用于 Tech Debt（Google SRE “基于 SLO 的错误预算” 实践）。为每个 Feature 冲刺创建至少一个 Tech Debt 任务。比例：每 3 个 Feature 任务 — 1 个 Tech Debt 或 Bug。这可以防止技术债务积累并保持开发速度。