Requirement Specification vs User Stories

Continuous Delivery

10 Aug 202217:34

Summary

TLDRDave Farley 在视频中探讨了软件开发中常见的问题，包括过度依赖手动测试和错误的需求获取。他强调了清晰定义软件需求的重要性，并解释了用户故事与需求之间的关系。Farley 认为，用户故事是一种有效的方法，可以帮助团队从模糊的愿望转变为具体的计算机程序。他建议开发团队应该拥有责任，不仅要关注技术细节，还要理解并引导产品开发的方向。此外，他还讨论了如何正确地使用用户故事来避免技术细节，从而更好地满足用户需求并提高软件开发效率。

Takeaways

🔍 软件开发中最常见的问题是过度依赖手动测试和需求定义错误。
📝 需求定义错误是软件开发中问题频发的主要原因之一，需要通过有效沟通来明确软件要实现的功能。
👥 大多数团队采用敏捷方法，通过用户故事来定义需求，但用户故事与需求并不等同，而是需求定义方式不当。
📚 IEEE定义需求为用户解决问题或实现目标所需的条件或能力，这与常见的实施导向的需求描述不符。
🛠️ 开发团队不应期望产品所有者或用户能精确定义需求，因为需求本质上是猜测，需要通过开发过程来明确。
💡 优秀的开发团队不仅负责技术细节，还应负责产品的开发方向，基于对问题的理解来引导产品发展。
🤔 用户或产品所有者通常只知道他们想要的大致方向，而不是具体需求，需求过程的目的是将这些模糊的愿望转化为计算机可执行的描述。
📈 将需求过程分为两个独立步骤：明确用户想要什么（需求），以及如何实现（解决方案）。
📘 用户故事是有效定义需求的方法，其真正价值在于帮助我们关注用户的目标，而不是系统的具体实现。
🏄‍♂️ 以用户的角度思考，可以发现用户的真实需求和问题，从而设计出更好的软件解决方案。
📖 用户故事应该描述用户的目标和系统在不同情况下的行为，而不是具体的用户界面或技术实现。
🔑 用户故事的目的是使用户、开发人员和其他利益相关者能够用共同的语言讨论软件的目标和功能。
📝 良好的用户故事应该是高层次的，足够精确以捕捉目标，同时足够模糊以允许多种实现方式。

Q & A

软件开发中常见的两个问题是什么？
-软件开发中常见的两个问题是过度依赖手动测试和最初就错误地获取需求。
为什么需求获取会成为一个棘手的问题？
-需求获取成为一个棘手的问题，因为很多团队对需求的理解是错误的，他们将需求视为复杂、以实现为中心的系统描述，而不是用户需要解决的问题或实现目标的条件或能力。
IEEE对需求的定义是什么？
-IEEE定义需求为用户为解决一个问题或实现一个目标所需要的条件或能力。
为什么说许多团队没有真正的需求？
-许多团队没有真正的需求，因为他们没有将需求传达给开发团队，而是提供了实际上是解决方案的高级描述。
开发团队在需求误解中扮演了什么角色？
-开发团队在需求误解中常常是共犯，他们有时会拒绝接受工作，除非需求被更精确地指定，这通常发生在初级团队或官僚组织中。
软件开发的真正任务是什么？
-软件开发的真正任务是将模糊的愿望转化为足够具体的描述，使其能够在计算机上执行。
为什么说用户故事是解决需求问题的有效方式？
-用户故事是解决需求问题的有效方式，因为它们帮助团队专注于用户想要什么，而不是系统如何工作，从而允许团队在找到更好的方法或用户不喜欢早期尝试时尝试不同的解决方案。
如何理解用户故事的真正价值？
-用户故事的真正价值在于它们迫使我们从用户的角度思考，关注用户的目标，并使用用户的语言来捕捉这些目标，从而使非技术团队成员能够更清楚地了解每个故事的含义。
为什么说用户故事应该避免包含技术规格？
-用户故事应该避免包含技术规格，因为它们应该描述用户想要软件做什么，而不是系统如何实现它。这样可以保持故事的通用性和灵活性，允许开发团队选择最合适的解决方案。
如何测试一个用户故事是否写得好？
-要测试一个用户故事是否写得好，可以想象一个完全不同的系统提供相同的客户成果，如果故事仍然有意义，那么它就是一个好故事。
用户故事的目的是是什么？
-用户故事的目的是故意保持高层次，准确捕捉目标，同时足够模糊，以允许多种不同的实现方式。

Outlines

00:00

😀 软件开发常见问题及用户故事的重要性

Dave Farley在视频中讨论了软件开发中常见的两个问题：过度依赖手动测试和需求错误。他强调了需求文档的重要性，并指出许多团队对需求的理解存在误区，将其视为具体的解决方案而非用户解决问题的条件或能力。Dave提出，需求应简洁明了，指导软件开发，而非详细描述系统如何工作。他还提到，开发团队往往参与到这种错误的思维方式中，他们要求需求被精确定义，这在初级团队或官僚组织中尤为常见。Dave认为，软件开发的本质是将模糊的愿望转化为计算机可执行的描述，而优秀的开发团队应该承担起产品开发的责任，而不是仅仅依赖于产品所有者或用户的精确指导。

05:01

🤔 用户故事与需求分离的重要性

Dave Farley在本段中继续探讨了用户故事的价值，他认为用户故事是将需求从解决方案中分离出来的有效方法。他强调，需求过程的目的是将模糊的愿望转化为计算机上可行的解决方案，但这需要分两步进行：首先明确用户想要什么，然后探索解决问题的不同方案。Dave指出，将需求固定在解决方案上是一个糟糕的主意，因为这限制了开发团队的灵活性和创新能力。他通过一个科学仪器的案例说明了如何从用户的角度思考问题，并提出了改善用户体验的设计思路。Dave认为，用户故事应该关注用户的目标，而不是用户界面或技术细节，这样可以帮助团队更好地理解问题并设计出更符合用户需求的系统。

10:01

🏄‍♂️ 从用户角度出发设计软件

Dave Farley通过一个科学仪器的案例，展示了如何从用户的角度出发来设计软件。他提出了一个假设，即用户在使用该仪器时，他们的目标是完成工作，而不是进行长时间的校准过程。Dave建议，如果从用户的需求出发，可能会发现校准时间过长的问题，并思考如何缩短这个过程。他还提出了一些用户故事，如用户在开始校准后去冲浪，但回来后发现校准失败，这启示开发团队需要提供反馈机制，让用户知道校准已经开始，并在失败时及时通知用户。Dave强调，用户故事应该描述用户的目标和他们需要知道的信息，而不是系统的具体工作方式。通过这种方式，可以激发开发团队思考问题和解决方案，从而设计出更好的软件。

15:03

📚 用户故事的撰写与价值

在视频的最后部分，Dave Farley讨论了如何撰写有效的用户故事，并强调了它们在软件开发中的价值。他认为，用户故事应该简洁、以用户为中心，并且避免包含任何技术细节。Dave提供了一些撰写用户故事的指导原则，比如使用非技术性的语言，确保故事在不同系统下仍然有意义，以及测试故事是否能够被非技术团队成员理解。他还指出，好的用户故事应该是高层次的，足够准确以捕捉目标，同时又足够模糊以允许多种实现方式。Dave总结说，通过关注用户想要的结果，并使用他们的语言来捕捉这些结果，可以提高项目的清晰度，并帮助团队成员更有效地沟通和协作。

Mindmap

Keywords

💡软件测试

软件测试是软件开发过程中的一个重要环节，它用于验证软件是否满足特定的需求并且能够正常运行。在视频中，提到过度依赖手动测试是软件开发中出现问题的一个常见原因，因为它可能导致测试不充分和效率低下。

💡需求错误

需求错误指的是在软件开发过程中对用户需求理解的偏差或错误。视频中强调，需求错误是软件开发中问题频发的另一个主要原因，正确的需求管理对于避免这些问题至关重要。

💡用户故事

用户故事是一种敏捷开发中用来描述用户需求的简短文本模板。视频中提到，用户故事经常被误用，其实它们是需求的一种形式，并且是引导开发团队理解用户需求的有效工具。

💡可执行规范

可执行规范是指可以自动验证的软件需求描述，它允许开发团队通过自动化测试来确保软件满足这些需求。视频中提到，通过用户故事可以帮助团队向可执行规范迈出下一步。

💡敏捷方法

敏捷方法是一种迭代和增量的软件开发方法论，它强调适应性、协作和快速响应变化。视频中提到，大多数团队认为自己正在应用敏捷方法，并且在定义需求时使用用户故事。

💡需求重定义

需求重定义是指重新思考和定义软件需求的过程，以更准确地反映用户的实际需要。视频中指出，许多团队对需求的处理方式是错误的，导致了需求的重定义，这与IEEE对需求的定义相悖。

💡技术团队的责任

技术团队的责任不仅仅是实现功能，还包括对产品的所有权和方向的引导。视频中强调，优秀的开发团队应该承担起从理解问题到指导产品开发的责任。

💡用户视角

用户视角是指从用户的角度出发来考虑问题和设计解决方案。视频中通过一个科学仪器的例子说明了从用户视角出发可以带来更好的设计和用户体验。

💡需求与解决方案的分离

需求与解决方案的分离是指在软件开发过程中明确区分用户需要软件做什么（需求）和软件如何做（解决方案）。视频中提到，将这两者分离可以提高软件的灵活性和适应性。

💡用户故事的价值

用户故事的价值在于它们能够帮助团队集中关注用户的需求，而不是过早地陷入具体的实现细节。视频中解释了用户故事如何作为一种有效的手段来固定问题，而不是解决方案。

💡用户故事的字面意义

用户故事的字面意义是指用户故事应该像讲述一个真实的故事一样，有角色、背景、情节和结局。视频中强调，用户故事应该用来描述用户的目标和需求，而不是系统的具体工作方式。

💡技术规格

技术规格是指详细描述软件系统应该如何工作的文档，通常包括数据库、输入字段或用户界面等技术细节。视频中提到，好的用户故事不应该包含技术规格，以避免限制解决方案的可能性。

Highlights

软件开发中最常见的两个问题是过度依赖手动测试和初始需求错误。

需求问题之所以棘手，以及如何修复它们，用户故事究竟是什么。

大多数团队采用敏捷方法，用用户故事来定义需求。

用户故事实际上就是需求，但许多团队对需求的处理方式是错误的。

软件中对需求的常见理解与IEEE定义的需求相悖。

需求应是用户解决问题或实现目标所需的条件或能力。

开发团队常常与产品所有者一样，对需求的错误理解负有责任。

软件开发的本质是将模糊的愿望转化为计算机可以执行的具体描述。

优秀的开发团队不仅负责技术细节，也负责他们构建的产品。

用户故事的目的是开始将模糊的愿望转化为计算机上可行的解决方案。

需求过程的职责是帮助我们清晰地理解用户想要什么。

用户故事是有效的方法来解决固定需求与解决方案的问题。

用户故事的真正价值在于它们迫使我们分离关于“什么”和“如何”的思考。

用户故事应关注用户目标，而非用户界面或技术实现细节。

用户故事帮助我们从用户的角度思考，从而得出更好的设计。

用户故事应描述用户可见的结果，帮助我们集中精力在真正的目标上。

用户故事应使用非技术性语言，以便所有相关方都能理解。

优秀的用户故事足够精确以捕捉目标，足够模糊以允许多种实现方式。