用户故障与敏捷方法

最新推荐文章于 2024-08-31 09:02:34 发布

OS_Net_DCE

最新推荐文章于 2024-08-31 09:02:34 发布

阅读量169

点赞数

分类专栏：敏捷方法学

本文链接：https://blog.csdn.net/cllcsy/article/details/112502063

版权

敏捷方法学专栏收录该内容

2 篇文章 0 订阅

订阅专栏

Kent 序

用户故事是一种需求管理方法，它和需求规格分析，用例，场景分析等方法一样。都是为了解决如何更好的确定系统需求及如何与人沟通需求的问题。不同需求分析方法的差异点在于写什么及何时写。

用户故事是一种敏捷的需求管理方法，它仅在一开始确定系统目标及实现该目标的大致成本。在真正实现需求时才去确定具体细节。这种方式带来的好处是： 1. 让你首先关注价值最高的需求 2. 早期评估成本助力合理安排故事的优先级

译者序

软件失败通常最主要的根源在于软件需求识别错误。这导致需求文档往大而全，更加细致的方向发展。进而导致冗长，涉及诸多细节的需求文档。而这通常带来的是难以阅读且过时的需求文档。难以阅读是因为文档太厚了，读起来枯燥无味而且因为信息太多阅读者通常也无法完全吸收。过时是因为早期涉及了过多的细节会发现在实现是通常不会按照设计去走。

用户故事提供的是另外一种解决方法。它朝着让需求更加简单的方向去走。先开发最重要，最具价值的需求，通过与客户不断交流来快速获得反馈。并通过演进式过程来实现需求。

这和敏捷宣言倡导的精神是一致的。因此用户故事是敏捷方法学里面很重要的实践。

InfoQ 序

用户故事方法的优势：

大脑认识角度
3C原则（Card, Conversation, Confirmation）
Card: 用卡片记录用户故事，避免故事细节。通过白板管理故事。
Conversation: 在不断交流中明确故事细节
Confirmation: 在反复确认中明确故事交付标准。避免遗漏或错误理解
3C原则从各个方面去调度大脑认识需求。更加符合人脑认识过程
软件开发角度
让开发人员一开始就站在用户视角去思考问题
按照功能维度而不是架构维度实现需求，避免项目后期出现较大偏差
用户故事，TDD, 持续集成，重构技术是一套完整体系，孤立地实践其中一项往往并不能得到好的软件质量

前言

介绍了传统需求规格分析的弊端：
文字表达力欠缺，不同的人理解偏差大。用户故事试图通过不断的交流来弱化文档，强化交流来解决问题

介绍了书籍大纲：

介绍用户故事概念，如何使用用户故事方法，如何编写用户故事
介绍了用户故事估算和计划
介绍用户故事和需求规格分析，用例，场景分析区别及用户故事特有的优点及如何在Scrum中使用用户故事
一个完整实例阐述用户故事分析方法

第一章概览

软件需求本质是沟通问题，需要利益各方能力合作才能做好。任何一方占主导地位容易导致项目失败。比如开发团队占主导可能导致用户需求得不到正确的实现。业务方（比如出资，项目经理）占主导可能导致软件质量低，需求裁剪（因为它们通常会忽略开发团队的实际情况）。
用户故事方法通过根据当前手头确定的需求做决策，并将决策过程延迟到项目中各个阶段。建立信息的获取通道，越早越频繁沟通越好。

什么是用户故事

定义：用户故事描述对用户，系统、或软件购买者有价值的功能。由故事描述，有关故事的对话，对故事的测试（3C）组成。

注：这里的用户并不一定是人，也可以是软件系统。

用户故事三部份关系：故事描述代表客户需求，整体描述一个需求概览，在对话中明确故事细节，通过对故事的测试记录需求细节。

故事粒度：通常以普通程序员能够在半天到两周能够完成的粒度为准。

第七章优秀用户故事准则

编写端到端故事，确保故事完整性。
优点：实现完整故事时通常会涉及到架构的各个层面，有利于及早发现架构层次问题。另外，及早交付可用软件。符合敏捷宣言精神。
编写封闭故事：即执行这个故事后就完成了。比如招聘者可以管理他发布的广告。这就不完整。因为管理既不具体也不是立即就能完成的。将其改为：管理者可以删除他发布的广告，更新他发布的广告等多个具体封闭的故事。
卡片约束：将约束写成故事卡片，并编写为具体测试用例。
根据实现时间确定故规模，详细程度
越早实现的故事应该更加明确具体，粒度适合于迭代。越久远实现的故事越粗层级越高。
需求不应该涉及用户界面。不要过早编写涉及用户界面的故事，界面是细节，应该延迟到后面
一个故事里面包括用户角色，且一个故事仅为一个用户角色编写。
用户故事的目标是促进开发者和客户团队沟通的。因此必须简洁