3. 敏捷项目类型选择

在Jira中创建敏捷项目时，第一个真正影响后续所有配置的决策，不是“项目叫什么名字”，而是“选Scrum还是Kanban”。这两个模板在Jira里并不是两套皮肤，而是两种不同的工作模型：Scrum以“时间盒”为核心组织单位，Kanban以“持续流动”为核心组织单位。选错模板，后面会不断用变通手段去弥补，比如在Kanban里硬造Sprint，或在Scrum里强行取消所有Sprint，最终导致看板、报表和权限配置都变得别扭。

一、两种模板的本质差异

Scrum项目模板围绕Sprint构建。它默认提供Backlog、Sprint、Board三层视图，工作项必须被放入某个Sprint才会出现在活跃看板上。Jira会为Scrum项目启用Sprint字段、燃尽图、Sprint报告、速度图等报表，这些报表都依赖“Sprint开始—结束”的时间边界。换句话说，Scrum模板假设团队按固定节奏交付，每个Sprint有明确的承诺范围和结束时间。

Kanban项目模板围绕持续流动构建。它默认提供Backlog和Board，但没有Sprint概念，工作项直接进入看板列，按列状态推进。Jira为Kanban项目提供累积流图、控制图、周期时间与前置时间报表，这些报表关注的是“一个工作项从进入到完成花了多久”，而不是“一个Sprint完成了多少故事点”。Kanban模板假设团队按拉动方式工作，没有固定迭代边界，重点是限制在制品并缩短流动时间。

从配置层面看，两者最关键的差异集中在几个字段和功能上：Scrum项目默认启用Sprint、故事点、燃尽图、速度图；Kanban项目默认启用列约束（WIP限制）、累积流图、控制图，但不启用Sprint。Scrum的看板通常按Sprint过滤，Kanban的看板展示所有未完成工作项。Scrum的Backlog需要做Sprint规划，Kanban的Backlog更像一个待拉动的队列。

二、创建时的关键决策路径

在Jira中点击“创建项目”后，选择Scrum还是Kanban，建议按以下顺序判断。第一步，问“团队是否有固定迭代节奏”。如果团队已经按周或双周做计划、评审和回顾，选Scrum；如果团队是持续接单、按优先级随时调整，选Kanban。第二步，问“需求是否可估算、可承诺”。如果产品负责人能提前梳理出Sprint Backlog，并且团队愿意对Sprint范围做出承诺，Scrum更合适；如果需求经常插单、无法提前锁定范围，Kanban更自然。第三步，问“团队想度量什么”。如果关注“每个迭代交付多少故事点、速度是否稳定”，选Scrum；如果关注“一个需求从开始到完成平均花几天、在制品是否过多”，选Kanban。

需要特别注意的是，Jira项目类型一旦创建，后期虽然可以通过市场应用或配置调整来模拟另一种模式，但原生报表和字段支持不会完全对齐。例如，Kanban项目无法原生启用燃尽图和速度图；Scrum项目虽然可以隐藏Sprint字段，但累积流图和控制图不会像Kanban项目那样默认可用。因此，创建时的选择应尽量一次做对。

三、一个可执行的判断示例

假设某研发团队负责一个企业级SaaS产品的迭代开发，产品路线图已经拆到季度级别，每两周做一次版本发布，团队有明确的产品负责人和Scrum Master，需求以用户故事形式进入Backlog，团队习惯用故事点估算。这种情况下，选择Scrum模板。创建后，Jira会自动生成一个Scrum看板，团队需要配置Sprint长度（例如2周）、故事点字段、Backlog优先级排序，并启用燃尽图和速度图。

再假设另一个团队负责线上系统的运维与故障响应，工单随时到达，优先级由SLA决定，团队不按固定迭代交付，而是持续处理请求。这种情况下，选择Kanban模板。创建后，团队需要配置看板列（例如“待处理—分析中—处理中—待验证—完成”），并为“处理中”列设置WIP限制（例如3），然后启用累积流图和控制图来观察流动效率。

四、创建后的最小配置清单

无论选择哪种模板，创建后都应完成以下最小配置，否则看板和报表无法反映真实工作状态。

最后需要强调，Scrum和Kanban不是“高级与初级”的关系，而是两种适配不同工作形态的工具。选择的核心依据是团队的工作到达方式、计划习惯和度量目标，而不是个人偏好。在Jira中，创建项目时选对模板，后续的看板、报表和权限配置都会顺理成章；选错模板，则会在每一次Sprint规划或流动分析时付出额外的配置成本。