3. 项目交付模型选择

在Jira中落地研发协同，第一步不是建项目，而是选对交付模型。Scrum、Kanban、Scrumban三者并非“新旧替代”关系，而是对应三种不同的工作节律：Scrum用固定时间盒驱动承诺，Kanban用流动与在制品限制驱动吞吐，Scrumban则在流动中保留节奏感。选错模型，后续的看板列、字段、报表都会别扭；选对模型，Jira的配置会自然贴合团队的真实工作方式。

三种模型的核心差异

Scrum把工作切成固定长度的Sprint（通常1～4周），每个Sprint有明确的Sprint Goal和承诺范围，团队按Story Point估算容量，通过Sprint Backlog管理承诺，用Burndown Chart观察剩余工作量。它的关键约束是“时间盒不可变、范围可协商”。

Kanban不设固定迭代，工作项从Backlog持续流入、经过各状态列、最终交付。它的核心机制是WIP（在制品）限制和流动效率度量，关注的是Cycle Time（周期时间）和Throughput（吞吐量），用Cumulative Flow Diagram（累积流图）观察队列堆积。Kanban允许随时插入新工作，但要求显式管理容量。

Scrumban是两者的混合：保留看板列和WIP限制，同时引入可选的迭代节奏（如每两周一次回顾与计划），但不强制每个周期承诺固定范围。它适合从Scrum向Kanban过渡、或工作性质介于“项目制”与“持续流”之间的团队。

在Jira中如何配置：从项目类型到字段

Jira Cloud中创建项目时，Scrum和Kanban是两种独立的项目模板，选择后系统会自动生成对应的面板结构。Scrum模板默认带Backlog和Active Sprints两个视图，Kanban模板只有一个持续看板。Scrumban没有独立模板，通常以Kanban项目为基础，手动添加Sprint字段和迭代管理。

具体配置差异体现在四个层面。第一，面板结构：Scrum有Backlog区与Sprint区分离，Kanban只有一列式看板。第二，估算字段：Scrum默认启用Story Points，Kanban默认关闭，Scrumban可选择性开启。第三，迭代管理：Scrum强制Sprint起止日期，Kanban无迭代概念，Scrumban通过“Epic/版本”或自定义字段模拟迭代。第四，报表：Scrum用Burndown和Velocity，Kanban用CFD和控制图，Scrumban两者可混用。

一个常见的实操细节是：在Kanban项目中启用Sprint字段，需要在“项目设置→字段”中把Sprint字段添加到对应屏幕，并在面板配置中开启“迭代”显示。这样既保留了WIP限制，又能按迭代周期做回顾。

选择判断：用三个问题定位模型

面对一个具体团队，可以用三个问题快速判断。问题一：需求是否能在固定周期内被“冻结”？如果能，Scrum更合适；如果需求持续到达且优先级频繁变化，Kanban更合适。问题二：团队是否需要“承诺”机制来驱动交付？如果组织要求可预测的交付节奏，Scrum的Sprint Goal能提供这种承诺；如果更关注流动效率和响应速度，Kanban的WIP限制更直接。问题三：团队是否处于模型迁移期？如果从Scrum转向Kanban，或反之，Scrumban是低风险的过渡形态。

配置示例：Scrumban在Jira中的最小可行设置

假设一个8人团队，工作内容包括产品迭代和线上问题处理，决定采用Scrumban。在Jira中可按以下方式配置：

项目类型：Kanban 软件项目
看板列：待办 | 分析中(WIP=3) | 开发中(WIP=4) | 测试中(WIP=3) | 待发布 | 已完成
泳道：按“工作类型”分组（需求 / 缺陷 / 运维）
迭代字段：启用 Sprint 字段，周期设为2周
估算：启用 Story Points（可选）
报表：累积流图 + 周期时间控制图 + 每迭代回顾

这样配置后，团队日常按看板流动工作，每两周做一次迭代回顾，检查Cycle Time趋势和WIP超限情况。既保留了流动的灵活性，又有了定期反思的节奏。

常见误区与排障

第一个误区是“Scrum项目里随意加Kanban列”。Scrum的Sprint面板列应保持简洁，通常为“待办→进行中→待验证→完成”，过多列会稀释Sprint的聚焦感。第二个误区是“Kanban项目里强行塞Sprint”。Kanban的核心是流动，如果硬加Sprint承诺，会退化成“没有时间盒的Scrum”，两头不靠。第三个误区是“Scrumban变成什么都不像”。Scrumban的关键是“流动为主、节奏为辅”，如果WIP限制形同虚设、迭代回顾也不开，就只是换了个名字的Kanban。

排障时优先看两个信号：一是WIP是否经常超限，如果经常超限说明容量被高估或工作项粒度太粗；二是Cycle Time是否持续上升，如果上升说明队列在堆积，需要检查上游需求进入速度或下游验收瓶颈。这两个信号在Jira的累积流图和控制图中都能直接观察到。

选型决策表

最后需要强调：模型选择不是一次性的，团队可以在项目进行中调整。Jira允许在Kanban项目中启用Sprint字段，也允许在Scrum项目中关闭Sprint改用持续看板。关键是让配置服务于团队的真实工作方式，而不是让团队去适应配置。选型之后，下一步才是看板列设计、工作流状态和字段规范——那是第4章要展开的内容。