| 商家名称 | 信用等级 | 购买信息 | 订购本书 |
 |
 |
用户故事与敏捷方法 |  |
 |
|
用户故事与敏捷方法 | |
网友对用户故事与敏捷方法的评论
用户故事是敏捷开发流程中的一个工具，使用用户故事来收集、整理、分析、跟踪需求。
本书比较详细地解说用户故事的用法。以下是书中的一些观点信息的摘抄：
1：如果故事太大以致无法在一轮迭代中完成，可以考虑把它分成两个或更多的小故事；
2：用户故事是很有意思的，因为他们强调口头沟通，客户和开发人员都可以理解，可以用于进行迭代计划，在迭代开发过程中能很好地工作，因为使用用户故事事实上鼓励推迟细节；
3：优秀的故事应该具备以下特点：独立的，可讨论的，对用户或客户有价值的，可估计的，小的，可测试的；
4：理想情况下，故事之间是独立的。有时很难做到这一点，但我们要尽量实现这一目标；
5：故事应该很清晰地体现对用户或客户的价值。最好的做法是让客户编写故事；
6：给故事加上注释的最好的方法是给它编写测试用例；
7：能够引出及捕获需求这一想法是错误的。它有两个有问题的假设：用户知道所有的需求；需求一旦被捕捉，就锁定，不再改变；(p45)
8：使用开放式、与背景无关的提问更容易获得有用的答案，例如，“告诉我你想怎么搜索工作？”就胜于“你要通过职位名称来搜索工作吗？”（p45）
9：让开发经"rest":"理担任用户代理，是最坏的选择之一，除非你们开发的软件就是给开发经理用的；（p48）<br /><br />10：让销售人员充当用户代理是危险的，这会让大家对正在开发的产品没有一个全面的蓝图。对销售人员来说，最重要的故事是那些如果没有实现就会导致他丢单的故事；（p49）<br /><br />11：让领域专家来担任用户代理的另一个潜在问题是，最终开发出的软件可能仅仅针对那些与领域专家有类似水平的用户；（p50）<br /><br />12：如果用培训师充当用户代理，你的系统最终只能成为一个容易培训的系统。类似的，如果你让技术支持来充当用户代理，那么你的系统最终只是使得支持工作变得较为容易；（p52）<br /><br />13：让客户，而不是开发人员，编写故事；（p69）<br /><br />14：故事与用例之间最明显的区别是它们的范围。两者的大小都以交付商业价值为目标，但故事的范围更小，因为我们对它们的大小有限制，以便用于安排工作；（p112）<br /><br />15：相信我们能够写下一个系统的所有需求，然后从上往下想出解决方案，这向来就是一个美丽的陷阱。约20年前，Parnas及Clements（1986）已经告诉我们根本不可能有这样的好事儿。（p124）"
第一次看本书，但是没有项目管理经验，对里面讲述的内容似懂非懂。
第二次看本书，有了一些项目管理经验，开始明白有些内容确实是有用的。
在具有几年项目管理经验之后再回头看这本书，才发现其中的奥妙所在。
如果你是有经验的PM，相信这本书非常适合你。如果你是PM却经验尚浅，不妨买一本用几年时间慢慢品味，而不要着急下结论。
没的说，这种教材要整系列的买，但是注意有很多靠着封面设置看上去一样的滥竽充数的作品。
用户故事是作为特性与任务之间承上启下，具有对需求最为核心的描述和勾勒。值得推荐。
对于理解story和敏捷方法有很大的帮助。
一共买了三本书，其他两本都不错，唯独这本质量感觉不好，像是盗版书。郁闷！
物流真快，昨晚下单，今天下午就收到了！
喜欢用户故事与敏捷方法请与您的朋友分享,由于版权原因，读书人网不提供图书下载服务
