敏捷作为一种业务方法

敏捷是一种通过短周期学习、紧密协作和频繁交付价值来管理不确定性工作的方式。它的出现是为了替代这样一类项目模式：在一开始就试图定义完整解决方案，并将后续变更视为失败。敏捷并不意味着无需计划地开展工作，而是意味着在多个层面进行规划，尽早验证假设，并在证据发生变化时调整决策。

《敏捷宣言》提出了四组价值偏好：个体与互动高于流程和工具，可工作的解决方案高于全面的文档，客户协作高于合同谈判，响应变化高于遵循计划。右侧的内容仍然重要，但应当服务于成果，而不应本身成为成果。例如，项目计划在帮助利益相关者协调工作时是有用的；但如果团队仅仅因为某项范围出现在最初计划中，就持续交付低价值范围，那么项目计划便会产生负面作用。

敏捷的十二条原则将这些价值观转化为具体的工作指导。重要主题包括尽早并持续交付价值、欢迎需求变化、频繁交付、业务与技术人员的日常协作、可持续的工作节奏、技术卓越、简洁、自组织团队以及定期反思。从业务角度看，这些原则缩短了投资决策与获得可靠证据之间的时间，使组织能够判断该决策是否创造了价值。

Scrum 框架与经验主义

Scrum 是一个轻量级框架，用于将敏捷理念应用于复杂的产品交付。它采用经验主义，即基于观察和经验做出决策，而不是依赖缺乏依据的预测。Scrum 的三大支柱是透明、检查和适应。工作、目标、质量期望和问题必须足够可见，才能进行检查。当结果与预期不符时，检查必须及时促成变更。

Scrum 将工作组织为 Sprint，即持续时间固定且不超过一个月的周期。每个 Sprint 都是一个完整的学习周期，Scrum 团队在其中追求 Sprint 目标，并至少创建一个可用的增量。较短的周期能够降低风险，因为利益相关者无需等待数月才发现某项功能解决的是错误的问题。例如，为期两周的 Sprint 可以验证简化的客户引导流程是否能够减少用户流失，然后公司再决定是否投入资金开发更高级的自动化功能。

Scrum 有意保持不完整。它规定了最低限度的职责、活动和工件，但不规定详细的项目流程、职位名称或 Jira 配置。只要这些实践不削弱透明度、团队自主权或适应能力，组织就可以在 Scrum 之外结合使用预测、研究、服务级别指标和治理控制。

Scrum 团队职责

Scrum 团队由一名产品负责人、一名 Scrum Master 和开发人员组成。团队是跨职能的，这意味着团队整体具备创造价值所需的技能；同时也是自管理的，这意味着团队成员自行决定由谁在何时以何种方式完成什么工作。利益相关者可以定义约束条件和预期结果，但不应在团队成员之间分配日常任务。

产品负责人负责最大化产品价值，并有效管理产品待办事项列表。这包括传达产品目标、创建或澄清产品待办事项、确定其排序，并确保待办事项列表保持透明。产品负责人可以委派相关活动，但仍然承担最终责任。例如，在客户门户项目中，如果支持数据表明访问失败会造成更高的成本和更大的客户挫败感，产品负责人可能会将密码恢复功能排在个人资料定制功能之前。

开发人员负责在每个 Sprint 中创建可用的增量，规划 Sprint 工作，通过完成的定义维护质量，并根据每日获得的信息调整计划。Scrum Master 负责按照既定定义建立 Scrum，并提升 Scrum 团队的有效性。Scrum Master 会进行指导，在有益时提供促进，并帮助移除系统性障碍。这不是命令与控制式的项目经理角色，Scrum Master 不会分配任务，也不会批准已完成的工作。

Scrum 活动及其决策

Sprint 计划通过回答 Sprint 为什么有价值、可以完成什么以及如何完成所选工作来启动 Sprint。由此形成的 Sprint 目标为团队提供了连贯的目标，而不是一份彼此割裂的工单列表。开发人员会结合可用产能、过往表现、依赖关系和完成的定义，预测能够完成的工作量。产品负责人提供价值和优先级方面的背景信息，但不会强迫团队作出范围承诺。

每日 Scrum 是一个 15 分钟的活动，供开发人员检查实现 Sprint 目标的进展并调整计划。它不是向 Scrum Master 提交的状态报告，也不是必须逐一回答三个固定问题的会议。有效的每日 Scrum 会确认当前工作是否仍然支持目标，暴露协作需求，并触发后续讨论，同时避免将该活动变成冗长的问题解决会议。

Sprint 评审与利益相关者一起检查 Sprint 的成果，并确定未来的调整方向。它应当是围绕证据、市场变化和下一步优先事项展开的工作会议，而不只是演示或审批关卡。Sprint 回顾会聚焦于团队效能，包括协作互动、流程、工具和质量。团队会为下一个 Sprint 选择切实可行的改进措施。Sprint 本身包含所有其他活动，并形成固定节奏，使检查变得可预测。

Scrum 工件及其承诺

产品待办事项列表是一个有序且持续演进的清单，列出改进产品所需完成的事项。它的承诺是产品目标，即指导待办事项决策的长期目标。越接近实施的事项通常比距离较远的可能事项包含更多细节。待办事项梳理是一项持续开展的活动，用于拆分和澄清事项，但它不是正式的 Scrum 活动，也不意味着所有不确定性都会消失。

Sprint 待办事项列表包含 Sprint 目标、为本次 Sprint 选定的产品待办事项，以及开发人员制定的可执行交付计划。它的承诺是 Sprint 目标。开发人员会随着认知的增加更新 Sprint 待办事项列表，并且可以与产品负责人重新协商范围，而不会危及目标。这种灵活性区别于固定合同所体现的承诺，体现的是预测而非刚性约定。只有产品负责人可以取消 Sprint，通常是在 Sprint 目标已经失去意义时进行取消。

增量是已完成工作的集成且可用的成果。它的承诺是完成的定义，即对工作必须满足哪些质量标准才能算作完成的共同描述。不符合完成的定义的工作不能作为增量的一部分进行展示，也不能被视为已完成。在一个 Sprint 期间可以创建或发布多个增量；发布时机属于业务决策，无需等待 Sprint 评审。

使用 Jira 应用基础原则

Jira 可以让 Scrum 工作变得可视化，但工具配置本身无法创造敏捷性。一个实用的设置应将产品待办列表项映射到业务成果，使用看板展示当前工作流，并让团队共享冲刺进度视图。冲刺目标应与已选择的问题并列可见，以免利益相关者将工单完成误认为冲刺的真正目的。工作流状态应代表有意义的阶段，而不是记录每一次细微的交接。

设想一个试图减少未完成账户申请的金融服务团队。产品负责人根据客户证据和预期影响对待办列表项进行排序。在冲刺计划期间，团队选择支持某一目标的工作，例如减少身份验证环节的放弃率。Jira 记录已选择的项目和工作流，而每日 Scrum 利用这些信息识别受阻工作。在冲刺评审中，团队检查可用的增量以及早期完成数据。在回顾会议中，团队可能会决定更早邀请合规专家参与，因为发现审批延迟反复发生。

成功不应仅根据速率、故事点数、资源利用率或已关闭问题的数量来判断。这些指标可以支持预测，但无法证明价值。团队应将周期时间和可预测性等交付指标，与质量指标、客户行为和业务成果结合起来。核心决策标准是：每个冲刺是否都创造了可用成果、增进了知识，并为下一项投资决策提供依据。