概述
废话连篇：
前段时间连着看了许多有关提高工作效率的书籍（我管它叫工具书），比如说《金字塔原理》《刻意练习》《番茄工作法图解》《麦肯锡方法》《麦肯锡工作法：麦肯锡精英的39个工作习惯》《麦肯锡工作法：个人竞争力提升50%的7堂课》等，主要是觉得自己在工作效率方面有待提升，再往之前看了一些有关数据分析基础以及和运营方面的书籍比如《谁说菜鸟不会数据分析系列》《SQL必知必会》《精益数据分析》等以及《参与感》《增长黑客》之类的，当然也有一些有关产品思维和创业的书籍，如《互联网独孤九剑》《失控》《必然》《让大象飞》《精益创业》等，越往后越觉得需要读一些很前沿的书籍，最近想阅读一些有关用户和设计层面的书籍，还真别说，PM最吸引我的地方就是你每天都可以如新生婴儿一样不断的汲取更多领域外的知识，包括思维、沟通、设计、前瞻性，最重要的是可以读书啊！小嘚瑟一把，最近加入了一个3年读书圈，想继续自己记笔记的习惯，已经坚持了2年，当然除了和思维有关的也读了一些文学类的书籍，偏技术一些，基本上都记录在博客里面了，但文学类的书籍适合交流分享感悟，都记录在自己的有道云笔记了，让我们继续下一个3年哦！今天废话多了些（打心里不觉得是废话^_^）~共勉！！！
导言
如果果要开始一个敏捷项目，应该如何开始和逐步进行下去呢？有没有一些套路是我们可以学习和借鉴的呢？其实在之前了解项目管理的时候，有认真了解了一下敏捷开发，也做过相应的笔记，回头可看《Scrum敏捷开发》，无论在项目管理还是在日常事务管理中，其实一些方法论真的是很有必要的，当然如果自己已经形成了很好的习惯就没必要去改变了，前提是他真的很有效的帮助到你！今天就来和大家分享一下这本我一晚上看完的书o(*￣︶￣*)o
目录
一 识别用户
二 与用户代理合作
三 搜集故事
四 编写故事
五 估算故事
六 确定故事优先级
七 确定团队工作速率
八 创建发布计划
九 验收测试
十 迭代计划
十一 测量并监控速率
补充
一 识别用户
识别尽可能多，全方位全维度的各类型用户。
- 头脑风暴、整理角色、整合角色、提炼角色
具体操作方法为：让尽可能多的干系人先各自在卡片上写下自己认为的用户。然后将卡片贴在墙上，经过一轮又一轮的讨论，最终达成一致的意见。
- 两个额外的技术
虚拟人物：用户的假象代表。注意：虽然是假象的，但要将这个用户尽量的具体，尽量的真实。
极端人物：一些平时不太容易出现，但确实存在的人物。（在极端人物上花费大量时间是不值得的，切忌拣了芝麻丢了西瓜。）
二 与用户代理合作
- 当我们识别用户后，理想的情况当然是想跟真正的用户开展接下去的工作。然而，在大部分情况下，真正的用户（就是真正使用这款产品／软件的人）是可望而不可及的。
实际情况下，愿意跟我们这些技术人员联系的是他们：用户的经理、开发经理、销售人员、领域专家、市场营销团队、以前的用户、客户、培训师、技术支持、业务分析师或系统分析师。
这些人我们统一称为：用户的代理。应该如何处理用户代理的情况呢？
让我们分两种情况进行讨论：
能接触到用户代理但访问受限时：
对策: 邀请几个到几十个真正的用户成立"用户顾问团队"，顾问团队能够提出意见和建立，但真正的决定依然有用户代理来做。
实在不能接触到用户时：
- 使用多个用户代理，博采众长，也能规避一定的风险。
- 尽早发布产品，尽早让真正的用户能够使用产品，也就能够尽早得到真正用户的反馈。
三 搜集故事
方法:
- 用户访谈
- 问卷调查
- 观察
- 故事编写工作坊：会议，快速捕获故事最有效办法，结合头脑风暴最佳要素和简单原型法
金句:
- 搜集需求要像拖网（Trawling）一样：不同大小的网用来捕获不同大小的需求；需求会像鱼一样，会成长，也可能会死亡；捕获的过程中，也可能捞到一些废弃的货物
- 确定需求是一个渐进明细的过程。一开始无法给出一个明确的需求，但是依然可以给出一个故事来作为"占位符"。
四 编写故事
INVEST
- I：Independent（独立的）
- N：Negotiable（可讨论的）
- V：Valuable to Purchasers Or Users（对用户或客户有价值的）
- E：Estimatable（可估计的）
- S：Small（小的）:对于无法做估计的复杂故事，将它分解成一个做调研的故事（用探针实验）和一个开发的故事。
- T：Testable（可测试的）：尽量用自动化测试。
故事的套路：我作为（角色），想要（功能），以此实现（商业价值）。。。
五 估算故事
- 用故事点进行估算，常用一个理想工作日的工作来表示一个故事估算点。
- 估算是团队估算的结果，不是个人的。（可以采用头脑风暴的方法）
- 通过和其他估算进行比较来进行三角测量。
六 确定故事优先级
故事的优先级由客户决定，但也要考虑开发人员的意见。
敏捷项目与传统规范过程区别
1）传统规范过程：在项目早期正确地获取写出所有的需求
2）敏捷项目：没有一种理想办法可以在一个单一阶段获取所有用户故事，先做最有价值的东西
如何发布计划
发布计划排列优先级方法：莫斯科（MoSCow）规则
1）必须有Must，指系统的基本功能
2）应该有hould，指很重要但短期内有替代解决方法的功能
3）可以有Could，指如果没有时间就可以在发布中不予考虑的功能
4）这次不会有Won't have this time，指客户期望拥有但同时承认需要在后续发布中实现的功能
七 确定团队工作速率
- 速率：团队在一个迭代周期内完成的故事点数（或期望完成的故事点数）。
如何确定团队速率
- 使用历史值执行一轮初始迭代，使用那轮迭代的速率。
- 猜测：考虑到各种各样因素的干扰，一般我们把i 轮迭代改进的1/3到一半的开发日作为预计速率。如一个团队6个人，十个工作日为一个迭代周期，则总的工作日为60,计划的速率则应该为20~30个故事点。
八 创建发布计划
- 根据故事的点数，故事的优先级，团队的速率，创建发布计划。
- 理想情况下，开发人员和客户可以谈一个日期范围，而不是一个具体日期。
- 诚实的把发布期限告知开发人员，而不是故意告诉一个提前的日子。
- 开发人员和客户共同选择迭代长度，难以确定时，请选择短迭代而不是长迭代。
九 验收测试
- 为什么需要验收测试？
验收测试将用户与开发人员之间交流的部分更加的明确化和细化，从而保证了开发人员的设计满足用户的要求。
- 什么时候写验收测试呢？
- 编写用户故事的时候（将测试要点纪录在故事卡的背面）
- 在一轮迭代的正式编码前。
- 在开发中或之后的任何时候发现新的测试的时候。
切忌：在正式编码要有验收测试的ＣＡＳＥ．
金句：
- 一个优秀的开发团队会为很多详细的用例写单元测试。
- 测试的是缺陷，而不是覆盖率。如果一个团队一直强调我们的测试覆盖率是多少多少，那么很有可能他们做了很多用户并不需要的工作。如果测试对产品是有价值的，不管他的覆盖率是多少，都要继续测试下去。反之，一旦测试没有价值，就立即停掉。（问题是，怎么判定测试是否还有价值呢？）
十 迭代计划
- 其实就是sprint planning meeting
- 在迭代开始时进行这个会议，会议中团队讨论每个故事，然后从故事中分解出任务。每个任务需要有一个对应的负责人，以及每个任务所需的估算时间。
- 团队中需要有人记录下上述讨论的内容，可以记录在项目的白板上。
- 在整轮迭代中，负责监控自己剩余的工作，同时也需要监控队友剩余的工作。如果很快就能完成自己的工作，就有责任帮助队友承担部分工作。
十一 测量并监控速率
- 用集中全部力量完成一个故事的方法会提高团队的意识，好过所有的故事都只完成一部分。也建议一个故事完成后再做下一个。
- 让程序员觉得增加剩余时间估算和减少是一样正常的。
- 在公共区域的一个地方，挂上白板，用黑胶布作为固定的坐标轴线，这样在修改图的时候不会被擦掉。接着就定期更新下面这三个图：累计故事点、剩余故事点燃尽图、剩余小时每日燃尽图。
补充
- 用户故事 ：描述了对用户、系统或软件购买者有价值功能。
- 用户故事的组成
1）一份书面的故事描述，用来做计划和作为提示；
2）有关故事的对话，用来具体化故事细节；
3）测试，用于表达和编制故事细节且可用于确定故事何时完成。 - 用户故事的特征
1）独立的
2）可讨论的
3）对用户或客户有价值的
4）可估计的
5）小的
6）可测试的 - 用户故事的优势
1）用户故事强调口头沟通
2）人人都可以理解用户故事
3）用户故事适合于迭代开发
4）用户故事鼓励延迟细节
5）用户故事的大小适合做计划
6）用户故事支持随机应变的开发
7）用户故事鼓励参与性设计
8）用户故事传播隐性知识 - 用户故事准则
1）从目标故事开始
2）切蛋糕（slicing the cake）
3）编写封闭的故事，值那种随着一个有意义的目标的实现而结束的故事，能让用户使用后觉得他完成了某个任务
4）卡片约束
5）根据实现时间来确定故事规模
6）不要过早涉及用户界面
7）有些需求并不是故事
8）在故事里包括用户角色
9）只为一个用户编写
10）以主动语态编写
11）由客户编写故事
12）向故事卡编号说“不”
13）不要忘记意图 - 用户故事的不足
1）在用于大量用户故事大型项目中，故事间关系错综复杂，难于捉摸
2）如果开发过程规定要有需求可追溯性，必然离不开额外文档
3）不适用特大规模，多团队结构 - 如何估算故事
1）无论什么时候获得有关故事新信息，都允许我们之间改变想法
2）适用于史诗故事和小故事
3）不需要花很多时间
4）提供进度和剩余工作的有用信息
5）不太精确的估算也不会有太大问题
6）可以用来制定发布计划 - 用户故事与IEE830软件需求规格、用例和交互场景设计的区别
1）用户故事与IEE830需求规格
a.IEE830侧重于关注需求的检查清单，而不是用户目标
b.IEE830在写下所有需求前，每个需求成本是不可见的
2）用户故事与用例
a.范围：故事范围小，对故事大小有限制
b.完整性
c.寿命：用例作为永久性工作持续存在，故事不会超过包含他们的迭代
d.用例容易包括用户界面和细节
e.目的：编写故事是为了更方便发布计划和迭代计划
3）用户故事与交互场景设计：范围和细节 - 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短会
确保整个团队关注于完成余下面向客户和最终用户的任务 - 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.拥抱变化 - 其它名词定义
1）史诗故事（epic）：指故事很大
2）面向瀑布模型和故事驱动
a.面向瀑布模型：用户和客户在搜集需求后到验收之间的这段时间几乎都不参与
b.故事驱动：客户与用户在项目过程中全程参与
3）故事卡由客户团队编写
a.最了解如何表达需要实现需求
b.共同确定故事细节和安排故事优先级
4）速率：是开发人员可以在一轮迭代中完成的工作量
5）拖网
描述收集需求的过程，需求像鱼一样，会成长也会死亡，需求会随着时间推移变化，需要一些技巧来发现需求
6）故事点代表时间的模糊单位，或叫NUT（XP编程）
7）迭代计划会议内容：
a.讨论故事
b.从故事中分解出任务
c.开发人员承担每个任务的职责
d.讨论过所有故事，并且接受所有任务后，开发人员单独估计他们承担的任务，以确保他们不会做出额过于乐观承诺。
8）迭代计划是发布计划进一步计划，但只在迭代即将开始时才开始做迭代计划
9）迭代燃尽图：展示以故事点表示的每轮迭代末剩余工作量
10）计算速率时只考虑那些已完成的故事，即通过验收测试的故事，不要计算迭代中团队未全部完成的故事。
最后
以上就是无辜大门为你收集整理的产品读书《用户故事与敏捷方法》的全部内容，希望文章能够帮你解决产品读书《用户故事与敏捷方法》所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。
发表评论 取消回复