在敏捷开发的世界中，重点往往 heavily 落在功能性需求。我们问：“系统做什么？”以及“用户如何与它交互？”虽然这些问题推动了功能交付，但常常留下一个关键缺口：系统履行其职责的效率如何？。这个缺口正是非功能性需求（NFRs）存在的地方。忽视它们会导致技术债务、系统缓慢以及用户沮丧。
本指南探讨如何将质量属性直接整合到您的用户故事中。通过将质量视为功能而非事后考虑，团队可以在不牺牲速度的前提下构建稳健、可靠且可扩展的软件。
理解差异 🧠
在深入整合之前，我们必须先定义这些术语。用户故事从用户的角度描述功能。
- 功能性需求： 定义行为。示例：“作为一个用户，我希望能重置我的密码。”
- 非功能性需求： 定义约束和质量。示例：“密码重置链接必须在15分钟内过期。”或“页面必须在2秒内加载完成。”
功能性需求告诉你要构建什么。非功能性需求告诉你应该如何表现。当两者被分开时，NFRs 常常被推到冲刺的末尾，甚至被完全忽略。这会导致一个“能用但很慢”或“能用但不安全”的产品。
为什么NFRs会被忽视 ❌
理解团队为何在NFRs上遇到困难，有助于预防该问题。
- 无形价值：用户很少在性能尚可时抱怨，直到它变得太慢。他们会在功能缺失时注意到，但通常会容忍一段时间的低质量。
- 技术复杂性：开发人员更倾向于构建新功能。测试加载时间或安全协议需要专门的努力，这感觉与用户故事脱节。
- 定义模糊： “快”或“安全”之类的术语是主观的。没有度量标准，验收标准就无法客观达成。
- 团队孤立： 架构师设计系统，但产品负责人定义故事。如果他们不沟通，质量标准就会被忽略。
整合策略 🛠️
有三种主要方法可以确保在开发过程中处理NFRs。使用这些方法可以确保质量被融入到流程中。
1. 完成的定义（DoD） 🏁
完成的定义是一份检查清单，适用于每个用户故事。它确保待办事项列表中的一致性。无需为安全问题单独创建工单，而是将安全检查包含在完成的定义中。
- 所有代码必须通过静态分析。
- 所有单元测试必须通过。
- 代码审查必须由至少两名同事完成。
- 非功能性需求检查： 该功能是否达到性能基线？
- 非功能性需求检查： 可访问性合规性是否已验证？
这种方法可防止在质量标准未达标前将故事标记为“完成”。它将责任在整个团队中分担。
2. 嵌入验收标准 ✅
某些非功能性需求仅针对单一功能。这些应放在用户故事的验收标准部分。这使得该特定故事的质量要求变得可见且可测试。
示例故事： 作为一名购物者，我希望可以根据价格范围筛选产品。
功能标准： 滑块调整价格范围；结果动态更新。
非功能性需求标准： 筛选结果必须在滑块移动后500毫秒内出现。
通过将此内容放入标准中，开发人员清楚地知道需要优化哪个性能指标，测试人员也清楚地知道需要测量什么。
3. 独立的非功能性需求故事 📋
有时，一个非功能性需求太大，无法放入单一的功能性故事中。如果需要改进数据库架构以支持新功能，可能需要单独创建工单。这通常被称为技术故事 或赋能故事.
- 何时使用： 重构代码、升级基础设施或实施新的安全框架。
- 目标： 这些故事提供了更快、更安全地交付未来功能故事的能力。
- 平衡： 不要让技术故事主导待办事项列表。它们应该推动业务价值，而不是孤立存在。
非功能性需求的关键类别 📊
并非所有非功能性需求都同等重要。以下是最重要的类别及其处理方式。
| 类别 | 需要提出的问题 | 示例指标 |
|---|---|---|
| 性能 | 它的响应速度有多快？ | 页面加载时间 < 2秒 |
| 安全性 | 数据是否受到保护？ | 需要端到端加密 |
| 可靠性 | 它多久会失败一次？ | 可用性达到99.9% |
| 可扩展性 | 它能否应对增长？ | 支持10,000个并发用户 |
| 可用性 | 它是否易于使用？ | 任务完成率 > 90% |
| 可维护性 | 代码是否容易修改？ | 环路复杂度 < 10 |
深入探讨：性能 ⚡
性能类非功能性需求通常对用户最为明显。系统缓慢会导致用户流失。为此，需要：
- 设定基线： 使用现有系统的指标作为基线。如果旧系统需要3秒，新系统应该更快，而不是更慢。
- 定义阈值：区分“可接受”和“关键”情况。200毫秒的延迟对于报告可能可以接受，但对于实时聊天则不可接受。
- 自动化监控：将性能测试集成到持续集成流水线中。如果提交导致性能下降，构建应失败。
深入探讨：安全 🔒
安全不是功能，而是前提条件。然而，随着功能的增加，特定的安全需求也会随之出现。
- 认证：该故事是否需要多因素认证？
- 数据隐私：该功能是否存储个人身份信息？如果是，如何进行掩码或加密处理？
- 审计日志：是否需要记录操作以满足合规要求？
确保开发人员了解新功能适用的数据分类。这决定了所需保护的级别。
深入探讨：可扩展性 📈
可扩展性关注系统如何扩展。这通常是一个架构决策。
- 垂直扩展与水平扩展：该功能是否需要单台服务器的更强性能，还是需要更多的服务器？
- 瓶颈：识别负载增加的位置。是数据库？API？前端渲染？
- 未来适应性：问自己：“如果下个月流量翻倍，这个功能还能正常工作吗？”如果答案是否定的，那么该故事就需要包含可扩展性组件。
验收标准的作用 📝
验收标准（AC）是业务与团队之间的契约。它定义了成功。非功能性需求（NFR）必须编写为可测试的验收标准。
不良示例
验收标准：系统应该很快。
问题：“快”是主观的。一个人认为的快，另一个人可能觉得慢。
良好示例
验收标准： 搜索结果页面必须在95%的请求中于1.5秒内加载完成。
优势： 这是可衡量的。测试可以根据这个数值通过或失败。
编写非功能性需求验收标准的技巧
- 使用数字： 尽可能量化所有内容（时间、数量、大小）。
- 使用条件： 明确说明该指标适用的条件（例如，“在4G网络下”）。
- 定义失败： 明确说明当非功能性需求未达成时会发生什么。
非功能性需求测试 🧪
功能测试验证行为。非功能性需求测试验证质量。两者都必不可少。
- 单元测试： 开发人员编写这些测试以验证逻辑。它们通常不用于衡量性能。
- 集成测试： 验证组件是否协同工作。非常适合进行API延迟检查。
- 负载测试： 模拟用户流量。对于性能和可扩展性相关的故事至关重要。
- 安全扫描： 自动化工具可以扫描代码中的漏洞。对于敏感功能，可能需要手动渗透测试。
- 可访问性测试： 自动化工具检查对比度和结构。使用屏幕阅读器进行手动测试可验证实际使用中的可用性。
不要仅依赖开发人员来测试非功能性需求。质量保证工程师应参与规划，以确保测试环境能够支持所需的负载或配置。
协作与沟通 🤝
管理非功能性需求是一项团队工作。它需要来自不同角色的输入。
产品负责人
- 优先处理提升质量的故事。
- 确保待办事项列表反映业务风险（例如，安全合规）。
- 定义快速系统与慢速系统之间的“价值”差异。
开发团队
- 在细化过程中识别技术限制。
- 提出架构变更以满足非功能性需求。
- 执行代码以达到指标要求。
质量保证
- 为非功能性需求设计测试（例如负载脚本）。
- 在发布前验证指标是否达标。
- 报告质量指标的退化情况。
架构/技术负责人
- 设定可维护性和安全性的标准。
- 审查设计以确保可扩展性。
- 在业务速度与技术质量冲突时，提供权衡建议。
常见陷阱，需避免 🚫
避免这些错误，以保持功能与质量之间的健康平衡。
- 过度设计：为一百万用户设计，而实际上只有100个用户。这会浪费时间。应根据当前情境合理设定非功能性需求，并留有增长空间。
- 忽视遗留系统：新功能通常与旧代码交互。非功能性需求必须考虑对现有系统的影响。
- 瀑布式思维：不要等到项目结束才测试性能。应逐步进行测试。
- 忽视用户体验：性能非功能性需求很重要，但可用性同样重要。一个运行快速但令人困惑的网站仍然是失败的。
衡量成功 📉
如何判断你的非功能性需求管理是否有效？请持续跟踪这些指标。
- 交付周期：非功能性需求故事是否拖慢了交付进度？如果是，请优化标准。
- 缺陷率：与性能或安全相关的缺陷是否在减少？
- 客户满意度：用户关于速度或崩溃的投诉是否减少了？
- 构建稳定性：由于质量门禁导致的构建失败次数是否减少了？
持续改进依赖于数据。在回顾会议中审查这些指标，以调整你的方法。
实际示例：登录功能 🔐
让我们来看一个包含非功能需求的完整用户故事。
用户故事
标题：安全用户登录
描述：作为一名注册用户，我希望能够安全登录，以便访问我的账户。
验收标准
- 功能：用户输入邮箱和密码。系统验证凭据。成功后重定向到仪表板。
- 功能：如果凭据不正确，系统将阻止访问。
- 非功能需求（安全）：密码必须使用行业标准算法进行哈希处理。会话令牌在30分钟无活动后必须过期。
- 非功能需求（性能）：登录响应时间必须低于1秒。
- 非功能需求（安全）：账户在连续5次失败尝试后必须锁定，以防止暴力破解攻击。
- 非功能需求（可访问性）：登录表单必须仅通过键盘导航。
请注意，这些非功能需求具体且可测试。它们不是事后补充的，而是成功定义的一部分。
处理技术债务 💣
即使规划得再好，技术债务也会积累。当为了赶进度而牺牲非功能需求时，这种情况就会发生。
- 记录它：在待办事项列表中明确记录技术债务。不要隐藏它。
- 定期重构：每个冲刺中都要留出一部分时间来提升代码质量。这通常被称为“重构冲刺”或“质量冲刺”。
- 偿还债务： 当一个故事的完成需要承担重大技术债务时，应分配时间在开发功能的同时修复债务。
- 防止新增债务： 严格执行完成定义（DoD）。如果可以避免，就不要让债务累积。
忽视技术债务就像忽视贷款利息一样。它会不断增长，直到无法偿还。主动管理非功能性需求（NFR）能让债务保持可控。
结论：质量作为默认选项 🏆
将非功能性需求融入用户故事，并非增加官僚程序，而是确保技术实现与用户期望保持一致。当性能、安全性和可靠性被视为明确需求时，所产生的软件将更加稳定且具有价值。
通过使用完成定义（DoD）、编写可衡量的验收标准，并促进跨角色协作，团队可以持续交付高质量的功能。目标不是完美，而是持续改进。每个故事都是构建更优系统的机会。将质量视为产品核心组成部分，用户会明显感受到差异。
从审查下一个冲刺待办事项开始。找出非功能性需求（NFR）缺失的地方，补充它们，测试它们，改进它们。系统会感谢你的。
