Training: Agile Requirement Ma... - Google Docs
培训分为三个部分：
第一部分讲解敏捷需求管理的基本知识。测试一。（15'）
第二部分介绍20个具体建议。测试二。（45'）
第三部分练习——新水手书店。（是否需要使用罗枫组的例子？）（30'）
准备：
1.现将客户分为三个小组，尽量每个小组包括：开发、测试和PO等多种角色。
2.准备故事卡，每个小组发10张故事卡。
3.橡皮泥。
开场：
这次培训中间穿插几次考试；这次培训跟绩效挂钩。
第一部分：
INVEST原则。
提问：之前是否参加过需求敏捷需求管理的培训？是否了解INVEST原则？自己在实践中最常用的几个原则是什么？
测试一：请将下面的故事拆分成（至少）5个故事。
作为一名用户，我想要登录，以便能够使用系统提供的服务。（Ftp客户端）
参考答案：
1. 作为一名注册用户，我想要看到登录成功的提示信息（如果我使用了正确的用户名密码），以便我能确定我可以使用系统提供的服务。
2. 作为一名注册用户，我想要看到登录失败的提示信息（如果我使用了错误的用户名密码），以便我能确定我可以使用系统提供的服务。
3. 作为一名注册用户，我想要系统能够保留我上次输入的用户名，以便我只需要再次输入密码即可。
4. 作为一名注册用户，我想要看到提示登录的信息（如果我直接访问系统提供的功能），以便我知道自己应该输入用户名和密码。
5. 作为一名非注册用户，我想要看到提示注册的信息（如果我直接访问系统提供的功能），以便我知道自己应该注册。（？）
6. 作为一名注册用户，我想要在一个命令行内输入用户名（还需要提示我输入密码），以便我能快速的登录。
7. 作为一名（熟悉命令行操作的）注册用户，我想要在一个命令行内输入用户名和密码，以便我能快速的登录。
8. 作为一名注册用户，我想要在本地保存我的用户名和密码，以便我能自动登录。
9. 作为一名注册用户，我想要我在本地保存的用户名和密码是加密过的，以便我的自动登录信息是安全的。
10. 作为一名匿名用户，我想要直接访问匿名权限的服务，以便我能够快速使用系统提供的服务。
请各组派代表贴出并介绍自己组拆分的结果。
请各组点评。
将点评的信息记录在白板上，以备下面介绍20条建议时使用。
第二部分（三个大类A故事分析、B敏捷估计、C迭代计划与跟踪）：
1. 准备栗子。
2. 关注角色。
* 不要使用统一的“用户”。
* 使用典型用户。（用户使用系统做什么？如何使用？用户的背景如何？）
* 用户角色。（姓名、年龄、性格特点...)
* 联系刚才的例子：注册用户、非注册用户、熟悉命令行的用户...
3. 使用客户（至少是测试人员）能听懂的语言描述故事。
* 在一个面向普通用户的项目中“端口”这样的词语可能是不合适的，但是在数通的项目中却是合适的。
4. 通过验收条件帮助拆分故事。
5. 使用斐波那契序列：1、2、3、5、8.
* 以2为基点。
* 不要使用更大的值。
* 不要做平均，尽量使用较大的一个。
* 精确不等于精准。
6. 独立投票。
7. 把未知因素单独考虑。
8. PO和测试有权质疑。
* 故事的内在复杂度是一定的。
9. 对Master Story使用不同的单位，比如大中小。
10. 记录你的假设。
11. 及时更新估计。
12. Burn Stories，Not Tasks。
I heard Mike Cohn, author of User Stories Applied [Coh04], talk about focusing on the role when writing User Stories at the Agile 2006 Conference. The example he gave was that of an airline reservation system, pointing out that the regular business traveler booking a flight wants very different things from such a system than the occasional vacation traveler.
RJ：
What I recommend as a planning process is this:
1. Product owner writes story on whiteboard, and explains it.
2. Briefly discuss how the story will be tested.
3. Developers briefly brainstorm and list technical steps needed.
(Similar to tasks but we’re not going to do the work, nor track it that way.)
4. Repeat until enough stories are on the board.
5. Look at the list, draw the line where you’re confident you can accomplish everything above the line.
6. Commit
7. Do stories as a unit, not broken into tasks.
8. Burn stories, not tasks.
In order for this to work, the stories need to be small enough that the team can understand and estimate them well. One approach to decomposing a story is to list the acceptance criteria, and then look at each of these and find the ones that can be stories themselves. If the particular acceptance criteria adds some value to the product, is user visible, stands alone, and is testable, then it is a good candidate to become its own story.
Precision ≠ Accuracy! [but it feels like it…]
