1. 讨论：下面的老板犯了什么错误?
只看用户的表面语言或行动还是不够的。我们还要找到用户语言行动背后的动机!
(图像来源: http://www.weibo.com/funnyshoelace)
2. 是否要文档
有人说，我们敏捷的团队，就喜欢直接的面对面的交流，不喜欢搞文档什么的，多好！
其实大多数情况下，留下文字说明是很有好处的，相对于后来的浪费和返工，当初花的时间真的是太值了。看下面的例子:
自习课时，教务主任匆匆走进来，告诉班长“帮我找两个人，我要班花”，同时两手在胸前做了一个抱花的动作，就走了。班长就组织全班投票评选起班花来，闹了一节课，搞了一些大数据，终于统一了意见，选出了班里最漂亮的两个MM。于是俩MM很羞涩的去找主任，主任说：“怎么是你们？男生都哪儿去了？好吧，跟我去后勤，我要搬花……”
可见，面对面直接的交流当然很敏捷, 但是还是要留下文档, 以明确用户的需求。
3. ATM操作界面的用户
团队要设计一个银行自动柜员机 (ATM) 的操作界面, 这个柜员机摆在银行营业厅的外面。你觉得会有多少种用户来使用你的操作界面?
（提示：多于5种用户类型）
4. 练习：
你想写一个游戏，你知道游戏用户有哪些种类么?
参考答案：有些公司根据玩家游戏生命周期特点来划分玩家类型：
- 重度发烧友 (hard core) 玩家根据游戏安排日程
- 中度发烧玩家根据日常生活计划安排游戏时间
- 休闲玩家只在刚好有空的时候，才考虑以游戏作为消遣
这些定义很实用，因为它使我们明确了玩家对游戏的期待是什么。对于休闲的用户，你的游戏就不宜要求用户在开始游戏之前必须完成详细的注册或练习阶段。
5. 别做过头
场景驱动 (scenario driven) 的设计做过了头会是什么情况？一天，大家在讨论“吴小石头上货”这一场景时，二柱叫到：“停，别忙了，我有了场景！”他从桌子底下抽出一个模型，上面摆着用纸糊起来的房子、院子等，中间有几个人形的木头疙瘩，他指着其中一个木头疙瘩说，“这就是吴小石头，我们问他怎么做就行了！”
在你的项目中有做过头的情况么?
5. Spec 写作练习
怎么才能写好Spec？其实也不难，就是要把一件事情描述清楚，下面是一个练习：
如果你要给一个外星人描述怎么系鞋带, 写一个 “系鞋带“ 的spec （用英语）, 你怎么写?
第一, 我们要定义好相关的概念
—what is “shoe”, “shoe laces”, “tied shoe laces”, and “untied shoe laces” 鞋, 鞋带, 系鞋带, 解鞋带都是什么概念
—Benefit of this feature “tie your shoe laces”。 系好鞋带的好处是什么
—The goal of the feature? 系鞋带的目标是什么?
—What does “success” look like? 什么叫系好了?
—Unambiguous steps to achieve from “untied” to “tied” 明确的步骤来演示系鞋带的过程
第二, 规范好一些假设 （assumptions）, 例如, 鞋带是已经穿好在鞋上的么? 什么样的鞋属于我们要处理的?
第三, 避免一些误解， 下面这个从技术上也是 ”鞋带绑紧了“, 但它是 “系好了”么? 打了死结算成功么? 要打多少个蝴蝶结才算好?
第四, 厘清一些边界条件, 下面的情况属于好的系鞋带状态呢, 还是不好的状态呢？ 这需要PM/Dev/Test 协商达成一致意见。鞋带要打多紧才算好? 打好的鞋带能拖在地上么?
第五, 描述主流的用户/软件交互步骤。
本文转自SoftwareTeacher博客园博客，原文链接：http://www.cnblogs.com/xinz/p/3855296.html，如需转载请自行联系原作者
