无服务器架构与Scrum：无需管理基础设施的交付之道

在无服务器模型中，代码以离散函数的形式部署，由事件按需触发——HTTP请求、队列消息、文件上传或定时触发器。云服务提供商管理底层服务器、运行环境和从零到数千并发调用的自动扩缩容。开发团队专注于编写函数，基础设施则基本自我管理。对于Scrum团队而言，这不仅是技术层面的变化——它改变了工作结构、迭代规划方式、「完成」的定义，以及新风险的所在位置。

无服务器架构如何改变迭代规划

基础设施管理工作的减少是真实且显著的。但无服务器架构引入了迭代规划中必须纳入的新工作类别：面向有延迟要求的应用需理解和管理冷启动延迟；函数存在执行时间上限（AWS Lambda最长15分钟），超限工作需分解或重新架构；按调用量计费模型要求团队在迭代规划时建立规模化成本的基本估算模型；平台特定API带来的供应商锁定风险需在设计时做出明确决策。

无服务器场景下的「完成」定义

适配无服务器架构的「完成」定义应在多个维度包含具体标准：迭代结束前须部署监控与告警（调用指标、错误率、持续时间分布）；通过成本分配标签实现每个函数的成本可见性；在预期生产调用量下完成性能测试（冷启动行为、并发限制）；处理队列事件的函数须配置死信队列或等效失败处理机制。

Scrum Master和产品负责人需要了解的内容

Scrum Master需要理解无服务器架构引入了新类别的技术工作——监控配置、成本标签、规模化性能测试——这些都属于「完成」定义和迭代规划的范畴。将其视为可选项或迭代后事项的Scrum Master，无意中在每个迭代中积累技术债务和运营风险。产品负责人需要充分理解成本模型以做出有据可查的优先级决策：在无服务器架构中，每个功能都有随使用量增长的增量运营成本，这与固定基础设施成本结构截然不同。

XNM咨询与Scrum团队合作推进敏捷交付实践、技术工作方式，以及将现代架构模式融入有效交付模型。了解更多关于我们的项目与计划交付服务。