PPT构思：
开发软件
最大一个问题
软件需求 理解错误
-》
之前的办法：
需求用：
大部头的需求文档
IEEE 830 软件需求规格Software Requirements Specifications
-》
看不懂 没人看
开发过程用：
瀑布流程Waterfall Model
从需求文档，概要设计，详细设计，编码，测试，部署，上线
缺点太多，效率太低：
版本发布的时间越来越长
无法按时发布
在版本发布的最后阶段让软件稳定的时间越来越长
做计划的时间越来越长，而且不准确
在发布期间很难进行改变
质量持续恶化
拼命竞赛进度使员工士气受挫
所以用 用户故事+敏捷编程
什么是用户故事==用户故事的3C原则
好处
如何写用户故事
典型流程：
编写故事
用户角色建模
搜集故事
与客户代理合作
用户故事验收测试
怎么才算好的用户故事：
优秀用户故事准则
然后开始 敏捷开发Scrum：
迭代计划：
讨论故事，分解任务，认领任务
产品Backlog 排好优先级的列表 Sprint Backlog Daily Scrum 简会 一个Scrum团队通常由4~7个开发人员组成 整个团队，同舟共济，互相帮忙 Scrum团队往往是自组织的 产品负责人：主要负责管理Product Backlog以及排列优先级 Scrum Master：类似于项目经理，但是不是管理者，而像领导者。不是指手画脚，而是为Scrum团队服务，排除障碍。 Sprint计划会议 参加者：产品负责人，ScrumMaster，团队的所有开发人员（其他管理人员，客户代表） 产品负责人：介绍Backlog中的功能 其他人：对功能提出（不懂的需要问的）问题 每日例会：昨天做了啥？今天打算做啥？遇到什么困难？ Sprint结束时：Sprint评审会，团队演示完成的成果 Scrum不要求，甚至也不建议今早维护很大的产品的Backlog TODO： 1.建议每周五下午留出1~2小时，作为评审会： 主要由测试人员去演示产品的功能进展 以便于项目经理，前端人员，后台人员等清楚最新进展 |
用户故事和其他对比：
用户故事不是什么
用户故事的优势
【第一章 概览】
给用户故事排优先级-》先做优先级最高的
在敏捷开发之前：
都是写详细的需求规格说明书、概要设计、详细设计
其中：
需求规格说明书-》内容很多，大量的文字描述-》往往写了没人看
现在，变成：
用户故事：从用户的角度，描述功能
按功能特性，而不是架构层次 -》 降低后期开发的整体风险
（极限编程创始人Ron Jeffies提出的）用户故事的3C原则：
Card=卡片：用卡片的形式记录功能点，放在白板上，方便移动，隐藏细节，以图形方式，易于理解和记忆
Conversation=沟通=交流：鼓励团队和客户之间多讨论和沟通-》促进人际关系，深入理解需求
Confirmation=确认：和用户确认使用场景中关键细节
软件需求是个沟通的问题
-》需要一个协同工作的方法
-》
客户或用户 《-》 （产品经理的）用户故事 《-》 技术团队
前期：获取信息，越早越好，越频繁越好
-》用户故事
【什么是用户故事】
用户故事描述了一些对于用户、系统或软件购买者有价值的功能
描述：书面的故事的描述 -》 Card
对话：具体化故事细节 -》Conversation
测试：何时完成，做成什么样 -》 Confirmation
用户故事不能太大（太大的故事=故事史诗=Epic）
-》需要拆分成小的用户故事
-》一般的话：1-2程序员，0.5天~2周 写完+测试完
沟通和讨论是关键
用户故事的卡片背面：可以考虑用来记录描述信息、测试描述信息-》用于细化预期的输入和输出
项目用户故事初稿：故事编写工作坊workshop
迭代长度，velocity速率：1~4周
由客户团队和开发人员一起确定
【规划发布和迭代】
一个发布由一个或多个迭代组成
故事点 Story Point：相对于其他故事的大小和复杂度
根据团队的速率和故事点去分配每个迭代的故事点
【什么是验收测试】
验证实现了的用户故事是否符合预期
客户团队，最好有专业的测试人员
尽早的写测试用例，更早的让开发人员知道你的预期和需求的细节
【为什么要变】
用户故事：
强调对话交流而不是书面沟通
同时被开发人员和用户理解
大小适合做计划
适用于迭代开发
鼓励推迟考虑细节，直到你非常清楚地了解自己的真正需求
【总结】
故事卡：包含了用户或客户有价值的功能的简短描述
故事卡是故事的可见部分，但是沟通对话更重要-》了解细节
客户团队包含了：确保软件符合潜在用户需求的人员：测试人员、产品经理、实际用户、交互设计师
故事卡由客户团队编写：他们了解需求和优先级顺序
按照价值去安排故事的优先级
速率是开发人员在一轮迭代中完成的工作量
可以把太大的故事拆分成更小的多个小故事
鼓励推迟细节：真正需要去确定要做了，再去了解细节
【第二章 编写故事】
【故事的特点】
INVEST
独立的 Independent
可讨论的 Negotiable
（对用户或客户）有价值的 Valuable（to Purchasers or Users）
故事卡只是提醒之后需要讨论，不是一个正式的承诺或者某个功能的具体描述
可估计的 Estimatable
小的 Small
可测试的 Testable
【小的】
分割故事
史诗故事包含两种
复合故事Compound story
复杂故事Complex story
分解故事的一种方法：
创建，修改，删除
对于不熟悉的领域=缺乏领域知识，可以用：
探针实验：调研熟悉某个xxx领域的相关技术
真正的某个用户故事
【可测试的】
尽量把那些不可测试的，非功能性的需求，去用自动化测试去帮忙发现是否有问题
【总结】
故事尽量独立
故事细节是由用户和开发人员讨论得出
最好的话，让用户去编写用户故事
可以加一些必要的注释去说明细节，但不能太多
最好的故事的注释是，编写测试用例
如果太大，就拆分为多个小故事
如果太小就合并为一个较大的故事
应该是可以测试的
【第三章 用户角色建模】
为何要建模？
以便于更好的编写更好的故事
有些故事并不是针对于系统的一般用户
【用户角色】
建模步骤：
头脑风暴列出初始的用户角色集合
尽量列出更多
整理最初的角色集合
角色重叠的，重叠的放在一起
整合角色
提炼角色
-》为了更加便于讨论需求，可以考虑引入一个 虚拟人物
极端人物
-》可能会带来额外灵感和考虑到之前漏掉的需求
【总结】
大部分项目小组只考虑单一的用户类型-》导致忽略掉原本需要的一些用户类型
给每种用户定义相关的特征，可以清楚地看到不同角色间的不同点
对于有些用户角色，考虑用代表人物去描述，容易理解和记住。
有些情况下，用极端人物，可能会帮助搜集原本被遗忘的故事
【第四章 搜集故事】
trawling 拖网 描述收集需求的过程
不同大小的网用来捕获不同大小的需求
拖网表达的另一个含义：需求会像鱼一样，会成长，可能也会死亡
不可能捕获到所有的需求
技能也是发现需求的一个重要因素
创建用户故事的方法：
用户访谈
问卷调查
观察
故事编写工作坊
开发人员，用户，产品客户，共同参与，写出尽量多的故事
业务分析师
大部分用户不太善于理解，更难于表达他们的真实需求
在了解用户的需求的基础上，要善于引导用户，找到更有效的问题的解决办法。
【总结】
用拖网捕鱼去比喻捕捉需求是很有用的：它说明了需要去有大小的不同，会随着时间变化，需要一些技巧来发现需求
尽量用开放式和背景无关的提问去了解客户的真实需求。
【第五章 与客户代理合作】
用户代理User proxy：
用户的经理
开发经理
销售人员
领域专家
市场营销团队
以前的用户
客户
培训师和技术支持
业务分析师或系统分析师
可能的话，尽量和实际客户接触，而非用户代理
【第六章 用户故事验收测试】
在写代码之前写测试
测试是开发过程中的一部分，而不是在编码完成后要做的事情。
在迭代开始时，项目经理和测试人员共同列出详细的测试。
一个优秀的开发团队会为很多详细的用例写单元测试。
在每轮迭代结束时都应该执行验收测试。
尽量用自动化测试。
测试类型：
功能性测试
用户交互测试
可用性测试
性能测试
压力测试
【总结】
验收测试应在程序员写代码之前就写好
如果新的测试对阐明故事的细节或意图没有任何帮助，就不用再写
【第七章 优秀用户故事准则】
从目标故事开始
从每个角色开始
编写故事的一种方式：每个故事都提供某种程度的完整（end-to-end）
就像 切蛋糕 一样
编写封闭故事：随着一个有意义的目标的实现而结束的故事，能让用户使用后就觉得完成了某个任务
卡片约束
根据实现规模来确定故事规模
不要过早涉及用户界面：
常见问题之一：把需求和解决方案混在一起，即在陈述需求时，也显式说明或暗示了解决方案。
有些需求并不是故事：放心的用其他合适的方式
在故事里包含用户角色
只为一个用户编写
以主动语态编写
由客户编写
尽量不要给卡片编号
不要忘记意图：故事卡片的目的是，用来提醒开发人员和客户团队对功能进行讨论的。
【第八章 估算用户故事】
故事点story point：可能是一个工作日，可能是一周
时间的模糊单位
客户+开发人员 故事卡 额外的空的笔记卡
估算应该包括：开发的时间+测试代码+和客户讨论+帮助客户计划或自动化验收测试+。。。
估算
三角测量：对比评估和确认 故事点不同的工作的工作量的确是和数字总体上是一致的
【第九章 发布计划】
DSDM，另外一种敏捷过程，包括一个排列优先级的方法莫斯科MoSCoW方法：
Must have 必须有
Should have 应该有
Could have 可以有
Won’t have this time 这次不会有
重要性加上：
预估的时间
风险
架构需要
大小后，才能判断出优先级
迭代长度：尽量一致，特殊情况下，可以有个别时候不长度有变
假如 去除了各种干扰后的 一个理想工作日=理想日
实际上的日历上的工作日=日历日 往往只有1/3或1/2的理想工作日
【第十章 迭代计划】
讨论故事，分解任务，认领任务
【第十一章 测量并监控速率】
计算速率，在迭代结束时计算，不把未完成的故事的故事点计算在内
计划速率和实际速率
累计故事点
Burndown Chart迭代燃尽图
敏捷团队都承认客户不可能预先知道所有事情。
【总结】
不要在一两轮迭代后就忙着预测速率趋势
【第十二章 故事不是什么】
其他需求方法：
用例user case
IEEE 830软件需求规格 software requirements specifications
侧重于关注需求列表而非用户的目标
交互设计场景interaction design scenario
【用例】
用例是对系统之间以及一个或多个用户之间交互的一般性描述，使用者是用户或其他系统。
用例 vs 故事：
用例的范围一般都比故事大
故事对应于用例的主要成功场景
故事测试对应于用例扩展
用例在产品开发或维护期间，常常作为永久性的工件持续存在
故事不会超过包含他们的迭代
用例比故事更容易包含用户界面的细节
用例编写者更早的关注软件的实现的细节，而不是去关注商业目标
基本用例：剥离了技术和实现细节的隐藏假设
用户意图=用户故事
目的：
用例：记录客户和开发团队之间的协议
用户故事：更方便的发布计划和迭代计划
结果：
用例一般写成分析活动的结果
用户故事则写成注释，用于启动分析谈话。
【场景】
scenario：用户与计算机交互的详细描述
场景包含的特征性元素：
应用环境
使用者
目标或目的
行动和事件
where
who
what
how
场景中比用户故事包含更多的细节
场景常包含多个故事
【第十三章 用户故事的优势】
用户故事强调口头沟通
人人都可以理解用户故事
用户故事的大小适合做计划
用户故事适合迭代开发
用户故事鼓励延迟细节
用户故事支持随机应变的开发
用户故事鼓励参与性设计
用户故事传播隐性知识
【口头沟通】
要更关注共有的认识，而非一份共享的文档
-》
开发人员知道如何开发
测试人员知道如何测试
客户得到想要的系统
用户故事鼓励延迟细节-》用户故事是个占位符-》在需要开发时再去讨论细节
以为：
写下一个系统的所有的需求，从上到下想出对应的解决方案
-》是不可能的
因为：
用户及客户都不会准确知道自己的实际需求
即便软件开发者知道需求的细节，也只能随着开发进展而变得清楚
即便假设所有细节可以在前面弄清楚，人们也没能力理解这么多的细节
就算我们能理解所有细节，产品和项目也经常会变更
-》人非圣贤，孰能无过
【用户故事的不足】
大项目的用户故事太多，关系太复杂，不太好把握
可追溯：
需要额外写一些必要的文档
不足：
大型项目中难以组织好成千上万的故事
有时候需要额外的文档以实现可追溯性
尽管面对面的沟通大大促进隐性知识的共享，但是大型项目中，单单依赖这种交谈难于实现有效的扩展来完全替代书面文档
【第十四章 用户故事不良征兆一览】
故事太小
经常需要调整估算
故事互相依赖
镀金
细节太多
过早考虑用户界面细节
想的太远
故事划分太过频繁
客户很难为故事安排优先级
客户不愿意写用户故事，也不愿意为故事安排优先级
【第十五章 Scrum与用户故事】
用户故事，一种管理需求的方法
Scrum敏捷过程
类似于 极限编程
迭代递增的软件过程
迭代：一种持续改进的过程
类比：雕刻。选择合适的石头，雕刻出大体轮廓，再区分出头和躯干，在雕刻细节，直至完美作品。
递增：一个递增的软件过程，指团队按照功能点开发和发布软件。
Scrum中，一个迭代Sprint，往往是30天，一个月
产品Backlog 排好优先级的列表
Sprint Backlog
Daily Scrum 简会
一个Scrum团队通常由4~7个开发人员组成
整个团队，同舟共济，互相帮忙
Scrum团队往往是自组织的
产品负责人：主要负责管理Product Backlog以及排列优先级
Scrum Master：类似于项目经理，但是不是管理者，而像领导者。不是指手画脚，而是为Scrum团队服务，排除障碍。
Sprint计划会议
参加者：产品负责人，ScrumMaster，团队的所有开发人员（其他管理人员，客户代表）
产品负责人：介绍Backlog中的功能
其他人：对功能提出（不懂的需要问的）问题
每日例会：昨天做了啥？今天打算做啥？遇到什么困难？
Sprint结束时：Sprint评审会，团队演示完成的成果
Scrum不要求，甚至也不建议今早维护很大的产品的Backlog
TODO：
1.建议每周五下午留出1~2小时，作为评审会：
主要由测试人员去演示产品的功能进展
以便于项目经理，前端人员，后台人员等清楚最新进展
【第十六章 其他话题】
处理非功能性需求：
很多非功能性需求可以视为系统行为的约束；
纸质卡片还是软件村故事卡片？
建议：纸质卡片
优点：
技术含量低，提醒人们故事就是不准确的。
放到软件中的话：容易增加额外的复杂的不必要的细节
有限的大小，给了故事描述很自然的字数的上限
常见做法，可以在卡片背面写部分验收测试的样例
注：
远程工作人员，不太可能用纸质卡片，所以会使用软件去管理用户故事
软件开发完后是否保留用户故事：
建议保留
软件：自然可以归档存储
纸质卡片：用橡皮筋绑在一起
缺陷：
如果所花时间类似于故事，可以考虑当作一个故事去对待
转载请注明：在路上 » 【整理】《用户故事与敏捷方法》读书心得