《用户故事与敏捷方法》读书笔记

1. 什么叫用户故事
   描述了对用户、系统或软件购买者有价值功能。
2. 用户故事的组成
   1）一份书面的故事描述，用来作计划和做为提示；
   2）有关故事的对话，用来具体化故事细节；
   3）测试，用于表达和编制故事细节且可用于肯定故事什么时候完成。
3. 如何建立用户故事
   1）用户访谈
   2）问卷调查，不适合做为拖网捕获新故事主要方法
   3）观察
   4）故事编写工做坊：会议，快速捕获故事最有效办法，结合头脑风暴最佳要素和简单原型法
4. 用户故事的特征
   1）独立的
   2）可讨论的
   3）对用户或客户有价值的
   4）可估计的
   5）小的
   6）可测试的
5. 用户故事的优点
   1）用户故事强调口头沟通
   2）人人均可以理解用户故事
   3）用户故事适合于迭×××发
   4）用户故事鼓励延迟细节
   5）用户故事的大小适合作计划
   6）用户故事支持随机应变的开发
   7）用户故事鼓励参与性设计
   8）用户故事传播隐性知识
6. 用户故事准则
   1）从目标故事开始
   2）切蛋糕（slicing the cake）
   3）编写封闭的故事，值那种随着一个有意义的目标的实现而结束的故事，能让用户使用后以为他完成了某个任务
   4）卡片约束
   5）根据实现时间来肯定故事规模
   6）不要过早涉及用户界面
   7）有些需求并非故事
   8）在故事里包括用户角色
   9）只为一个用户编写
   10）以主动语态编写
   11）由客户编写故事
   12）向故事卡编号说“不”
   13）不要忘记意图
7. 用户故事的不足
   1）在用于大量用户故事大型项目中，故事间关系错综复杂，难于捉摸
   2）若是开发过程规定要有需求可追溯性，必然离不开额外文档
   3）不适用特大规模，多团队结构
8. 如何估算故事
   1）不管何时得到有关故事新信息，都容许咱们之间改变想法
   2）适用于史诗故事和小故事
   3）不须要花不少时间
   4）提供进度和剩余工做的有用信息
   5）不太精确的估算也不会有太大问题
   6）能够用来制定发布计划
9. 如何发布计划
   发布计划排列优先级方法：莫斯科（MoSCow）规则
   1）必须有，指系统的基本功能
   2）应该有，指很重要但短时间内有替代解决方法的功能
   3）能够有，指若是没有时间就能够在发布中不予考虑的功能
   4）此次不会有，指客户指望拥有但同时认可须要在后续发布中实现的功能
10. 敏捷项目与传统规范过程区别
    1）传统规范过程：在项目早期正确地获取写出全部的需求
    2）敏捷项目：没有一种理想办法能够在一个单一阶段获取全部用户故事
11. 用户故事与IEE830软件需求规格、用例和交互场景设计的区别
    1）用户故事与IEE830需求规格
    a.IEE830侧重于关注需求的检查清单，而不是用户目标
    b.IEE830在写下全部需求前，每一个需求成本是不可见的
    2）用户故事与用例
    a.范围：故事范围小，对故事大小有限制
    b.完整性
    c.寿命：用例做为永久性工做持续存在，故事不会超过包含他们的迭代
    d.用例容易包括用户界面和细节
    e.目的：编写故事是为了更方便发布计划和迭代计划
    3）用户故事与交互场景设计：范围和细节
12. Scrum
    1）迭代的过程是一种持续改进的过程，相似于雕刻
    2）递增的过程是指团队按照功能点开发和发布软件
    3）Scrum和XP都是基于递增和迭代方式的过程
    4）采用30天为周期迭代，称为Sprint
    5）Scrum没有区分架构师和测试人员角色，而是有产品负责人和ScrumMaster
    a.产品负责人：主要负责管理product backlog内容和排列优先级
    b.ScrumMaster：负责为团队排除障碍
    6）产品backlog：全部待开发产品功能列表
    7）一旦sprint开始，只有团队成员才能向sprint中添加工做
    8）每日scrum短会：
    a.你昨天作了什么
    b.你今天打算作什么
    c.有什么困难
    9）每日scrum短会目的
    让每一个人在本身以及同事面前作出承诺，是团队成员之间的承诺
    10）用户故事、sprint评审会议
    好处就是很容易评估sprint中哪些部分已经完成
    11）用户故事、每日scrum短会
    确保整个团队关注于完成余下面向客户和最终用户的任务
13. XP极限编程
    1）XP的12种实践
    a.短交付周期（small releases）：每轮迭代一般是1-3周时间
    b.计划游戏（the planning game）：发布计划和迭代计划名称
    c.重构（refactoring）：重组或重写代码以改善代码
    d.测试（testing）
    e.结对编程（pair programming）
    f.持续一致的速度（sustainable pace）
    g.团队代码全部权（team code ownership）
    h.编码标注（coding standard）
    i.简单设计（simple design）
    j.隐喻（metaphor）：提供了一个他们如何思考系统的参照体系
    k.持续集成（continuos intergration）
    l.现场客户（on-site customer）
    2）XP的价值
    a.沟通
    b.简单
    c.反馈
    d.勇气
    3）XP的关键原则
    a.快速反馈
    b.假设简单
    c.增量变化
    d.拥抱变化
14. 其它名词定义
    1）史诗故事（epic）
    指故事很大
    2）面向瀑布模型和故事驱动
    a.面向瀑布模型：用户和客户在搜集需求后到验收之间的这段时间几乎都不参与
    b.故事驱动：客户与用户在项目过程当中全程参与
    3）故事卡由客户团队编写
    a.最了解如何表达须要实现需求
    b.共同肯定故事细节和安排故事优先级
    4）速率：是开发人员能够在一轮迭代中完成的工做量
    5）拖网
    描述收集需求的过程，需求像鱼同样，会成长也会死亡，需求会随着时间推移变化，须要一些技巧来发现需求
    6）故事点表明时间的模糊单位，或叫NUT（XP编程）
    7）迭代计划会议内容：
    a.讨论故事
    b.从故事中分解出任务
    c.开发人员承担每一个任务的职责
    d.讨论过全部故事，而且接受全部任务后，开发人员单独估计他们承担的任务，以确保他们不会作出额过于乐观承诺。
    8）迭代计划是发布计划进一步计划，但只在迭代即将开始时才开始作迭代计划9）迭代燃尽图：展现以故事点表示的每轮迭代末剩余工做量10）计算速率时只考虑那些已完成的故事，即经过验收测试的故事，不要计算迭代中团队未所有完成的故事。