一个人的 Scrum：我在硕士毕业设计中的需求分析与每周冲刺

一个人的 Scrum：我在硕士毕业设计中的需求分析与每周冲刺

Scrum 是为团队设计的：产品负责人、Scrum Master、开发人员，还有一块所有人都会更新的看板。而我的硕士毕业设计——一个由 Ionic 客户端和 Laravel 后端组成的跨平台电商应用——所有角色都由一个人承担。尽管如此，我还是按冲刺（sprint）来组织它。回顾当时留下的笔记，真正有意义的问题不是这算不算"真正的" Scrum，而是：当你独自工作时，这个方法中哪些部分依然划算，哪些会沦为为了仪式而仪式。

为什么一份待办清单还不够

迭代方法的对立面是经典的瀑布模型：需求、设计、实现、验证、维护，每个阶段结束后才能进入下一个。对我这样的项目来说，它的问题从一开始就很明显：节奏慢，而且假定需求在一开始就已明确且稳定，而实际上需求会随着开发推进、随着你逐渐看清产品真正需要什么而不断变化。

Scrum 的前提恰恰相反：小步交付、学习、调整。虽然没有客户每周给我反馈，但我自己就是第一个用户，每一周的开发都会改变我对这个应用需求的理解。

需求工程：单人版

在规划冲刺之前，我按照经典的需求分析阶段走了一遍，并针对没有外部客户的项目做了调整：

• 启动：理解问题和解决方案的类型——一个能在手机上使用、并配有像样后台的商店。
• 需求获取：把它转化为明确的功能性与非功能性需求，并划定范围。
• 细化：用图表对功能和场景建模。对我来说，就是数据库设计（我把它搬到了更易读的 dbdiagram.io 上），以及用 Excalidraw 画的后台页面草图。
• 协商：没有客户可以协商，我就和日历协商。放不进去的功能会被移到一份明确的"暂时可选"清单里，而不是直接消失。
• 规格说明：把功能性和非功能性需求写成文档，作为整个项目的参照。
• 验证与管理：对照这份参照检查产品，并在需求演变时跟踪变更。

验证是在没有团队的情况下最受影响的阶段。没有别人会读你的规格说明，也没有人会提出那个让人不舒服的问题。我找到的部分解决办法，是每周对照待办清单进行回顾，下文会具体介绍。

待办清单：四个板块和一份"暂时可选"清单

产品待办清单（product backlog）是一篇单独的笔记，分成几个板块：客户端页面（Ionic）、后台页面（Laravel）、前后端连接，以及测试。在客户端板块下，有一份明确命名为"暂时可选"的子清单：社交网络链接、电话支持、消息栏目、隐私政策和使用条款、多语言翻译，以及把商品分享到社交网络。

这份子清单在控制范围方面的作用，比其他任何东西都大。放进"暂时可选"的功能既没有被否决，也没有被遗忘，而是被有意识地推迟了。它让你可以对自己说"不"，同时又不丢掉这个想法。

每周一个冲刺，而不是两周

Scrum 通常建议冲刺周期为一到四周，最常见的是两周。我采用的是一周一个冲刺，每个冲刺对应一篇以 ISO 周数命名的笔记（2024-05、2024-06 等），并从待办清单中链接过去。我的笔记覆盖了从 2024 年 2 月初到 4 月中旬的冲刺。

每篇冲刺笔记都是一份简短的具体任务清单，带有开始日期和完成日期。早期一个典型的冲刺包括：标签栏、搜索栏、加入购物车和收藏，以及购物车本身。后面的冲刺则包括：创建 Laravel 的模型和 Seeder、路由和控制器、后台的分页和实时筛选表格、PDF 与 Excel 导出，以及服务器端的图片处理。

对一个人来说，一周是合适的长度：足够完成一些看得见的东西，又足够短，使一次错误的估算只损失几天而不是几周。而且冲刺待办清单在冲刺期间保持不变：新想法进入产品待办清单，而不是塞进本周。

哪些仪式保留了下来

Scrum 列出了五种仪式：待办清单梳理（grooming）、冲刺计划会、冲刺评审、回顾会和每日站会。独自工作时，并不是每一种都有意义。

• 冲刺计划完整保留。写下本周的笔记本身就是计划：一份现实、可完成的清单，而不是愿望清单。
• 冲刺评审变成了给任务打勾并记录完成日期。事实证明，日期比勾选更有用：它们能显示哪些任务一天就完成了，哪些拖了很久。
• 梳理发生在任务在产品待办清单、某个冲刺和可选清单之间移动的时候。
• 回顾会缩减成了部分冲刺笔记中的一个"疑问"小节。举个例子：既然订单价格可以根据订单明细计算出来，订单表还需要存储价格吗？把问题和答案（严格来说没必要，但出于效率值得保留）写下来，就是一次微型回顾。
• 每日站会没能保留下来。当每项任务的开始日期已经给出答案时，再问自己"昨天做了什么、今天要做什么"就毫无意义了。

我还建过一个包含"待办""进行中""已完成"三列的看板，但它几乎一直是空的。对一个人的团队来说，每周的清单就是看板。

未完成的工作也是信息

并不是所有事情都完成了。邮箱验证和 API 的邮件配置出现在一个冲刺里，被顺延到下一个冲刺，之后一直没有打勾。在笔记中看到这一点，并不意味着方法失败；恰恰相反，这正是方法在起作用。这项任务始终可见，它被有意识地排在了后台功能之后，也从未在我没有察觉的情况下扩大项目范围。

文档写作同样被纳入了冲刺。撰写论文的理论框架、修改论文、规划章节结构（规划、实现、结果与未来工作），都和其他任务一样是待办清单里的条目。把写作当作有截止日期的工作，而不是留到最后再做，可能是影响最大的一个习惯。

先实践，后学术语

我的笔记里有一个颇具讽刺意味的细节：我写的那份 Scrum 总结（瀑布与敏捷、冲刺、工件、仪式、角色）日期是 4 月，也就是我记录的最后几个冲刺之一，而每周冲刺早在 2 月就开始了。我是先实践了这个方法，之后才把它系统化；而后来的系统化，主要是给已经行之有效的做法起了名字。

这个项目获得了最高荣誉（Matrícula de Honor）。我不会把这归功于 Scrum。但对于一个有固定截止日期的单人项目来说，每周一个冲刺、一份明确的"暂时可选"清单，以及每项任务都标注日期，是我所知道的控制范围最省力的方法。