在 Jira 中规划你的第一个软件项目
从明确的项目目标开始
在创建 Jira 事项之前，先写下一句简短的成果陈述，说明用户、问题和预期结果。例如，一个由两人组成、正在开发预订应用的团队，目标可以是让客户选择服务、选择可用时间，并收到确认邮件。这比“构建一个现代化的预订平台”这类模糊目标更有用，因为它能为后续决策划定边界。
为首次发布版本增加一个可衡量的成功条件。一个切实可行的条件可以是：测试客户能够使用手机浏览器在三分钟内完成预订。该条件不需要预测收入，而是要帮助团队判断某项功能是否应纳入第一个版本，还是可以推迟。
设置合适的 Jira 项目
对于第一个软件项目，如果工作将在固定的规划周期内交付，请创建一个 Jira Software 项目并选择 Scrum 模板。如果优先级可能每天变化，并且团队希望只有在完成当前工作后才提取下一项任务，请选择 Kanban。一个为期三周的学生项目通常适合采用 Scrum，因为明确的截止日期会让短期且可见的承诺更有价值。
保持初始工作流简单：对于许多小型团队来说，“待办”“进行中”“代码审查”和“已完成”已经足够。之后可以考虑增加测试、设计审查、部署和审批等独立状态，但前提是有人会积极使用每个状态。每增加一个状态，就多了一次产生过期工单和职责不清的机会。
尽早设置权限，确保每位贡献者都能创建和更新事项，同时由一名项目负责人管理看板设置和发布版本。如果团队使用 GitHub、GitLab 或 Bitbucket，也应将项目连接到对应的源代码仓库。将分支和拉取请求关联到 APP-14 之类的事项键后，可以更轻松地查看计划中的用户故事是否确实有对应的实现工作。
将项目范围转化为史诗和用户故事
为面向用户的主要能力创建史诗，而不是按技术部门创建。在预订应用中，合适的史诗包括账户访问、服务目录、预订流程和通知。史诗应描述产品中一个有意义的组成部分，该部分可以包含若干较小的工作项，而不是使用“前端”这类宽泛标签。
将每个史诗拆分为从用户视角撰写的用户故事。一个有用的故事可以是：“作为一名客户，我希望查看所选服务的可用时间段，以便选择合适的预约时间。”这能让设计师、开发人员和测试人员了解所需行为，同时不会规定每一个实现细节。
直接将验收标准添加到 Jira 故事中。对于时间段故事，验收标准可以要求：不可选择不可用时间；所有时间均使用业务时区；当没有剩余时间段时显示空状态。这些细节可以避免一个技术上能够运行但界面并不完整的工单进入评审阶段。
让待办事项达到可开发状态
待办事项列表不只是一个很长的功能愿望清单。靠近顶部的每个事项都应包含简洁的描述、验收标准、优先级，以及足够的上下文，使队友无需开会就能开始工作。如果附上一张粗略的界面草图、API 示例或设计文件链接能够回答实际问题，就应当附上；避免附加没人会阅读的文档。
将无法在一个迭代内完成的过大故事拆分开。“构建用户身份验证”通常隐藏了注册、登录、密码重置、验证、会话处理和错误消息等工作。对于为期一周的迭代，应将注册和登录拆分为独立的故事；只有在技术子任务能够帮助人员跟踪具体步骤时，才创建技术子任务，例如数据库迁移或电子邮件模板设置。
谨慎使用标签，将其用于无障碍、缺陷、安全性或移动端等跨领域关注点。不要同时用标签取代史诗、组件和优先级。新团队应能够筛选待办事项列表，并快速回答首个版本计划包含哪些内容、由谁负责，以及当前有哪些阻碍。
在避免虚假精确的前提下估算工作量
使用故事点估算相对工作量，而不是为每个工单猜测精确的小时数。团队可以将 1 点定义为非常小且熟悉的变更，将 3 点定义为包含少量决策的标准故事，将 8 点定义为可能需要拆分的工作。这个尺度之所以有用，是因为它能够暴露不确定性，而不是因为一个点对应某个普适的时间值。
为首个迭代开展一次简短的规划讨论。询问哪些内容尚不明确、存在哪些依赖，以及有什么证据可以证明故事已经完成。如果一名开发人员认为某个故事是 2 点，而另一名开发人员认为是 8 点，这种分歧通常会暴露出缺失的需求，例如支付沙盒访问权限或必需的迁移路径。
在第一个 Sprint 中采取保守的提交策略。如果有两个人可以工作五天，不要用任务填满每一个小时；会议、评审、修复缺陷和环境搭建都会消耗团队产能。完成一到两个 Sprint 后，使用团队实际完成的点数作为自身的速度，而不是照搬其他团队的目标。
围绕可用的最小产品切片规划 Sprint
一个好的第一个 Sprint 应该交付一条精简但可用的产品路径。对于预订应用，这可以包括显示硬编码的服务、选择一项服务、选择一个模拟时间段，以及查看确认页面。这比单独完成一个精致的登录页面、一个数据库架构和一个尚无法协同使用的电子邮件集成更有价值。
在 Sprint 规划期间，只将已准备就绪的用户故事移入当前 Sprint，并检查它们的依赖关系。如果预订页面依赖一个尚不存在的服务 API，就应先规划 API 的开发工作，或者使用经过明确规划的临时数据源。在 Jira 中记录这一技术性权宜方案，使其保持可见，避免意外演变为永久依赖。
根据工作归属和学习目标分配任务，但不要把负责人字段当作交接机制。每天简短查看一次看板，并在分配新工作之前讨论受阻的问题。一张卡片如果连续四天处于 In Progress 状态，就值得引起关注，即使其截止日期尚未到来。
使用 Jira 报告改进下一个 Sprint
在 Sprint 结束时，应将已完成的工作与 Sprint 目标进行比较，而不只是统计已关闭任务的数量。如果团队完成了九个小任务，但客户仍然无法完成预订，那么计划可能偏重于容易完成的技术性工作，而不是可用的结果。演示实际运行的流程，并准确记录它在哪个环节停止。
把燃尽图作为讨论的起点。连续几天保持水平的曲线，可能意味着用户故事规模过大、工作正在等待评审，或者团队成员只在周末才更新 Jira。它不是绩效评分，也不应被用来施压，迫使成员关闭尚未完成的工作。
进行一次简短的回顾，并将一到两项改进转化为实际的待办事项。例如，如果代码评审拖延了每个用户故事，就制定团队约定：在开始另一个任务之前先发起评审，并创建一个小任务来配置评审通知。规划通过这一反馈循环不断改进，因此第一次 Jira 规划应被视为一个可验证的起点，而不是永久性的契约。
延伸阅读
标签 :
- 敏捷项目管理
