今天阅读了《用户故事与敏捷方法》的介绍，了解了本书中对用户故事的定义描述。
总体来说，用户故事描述了对用户/系统有价值的功能，用户故事包括如下三个部分组成（摘述如下）：
1 一份书面的故事报告，用来做计划和作为提示。
2 有关故事的对话，用户具体化故事细节。
3 测试，用于表达和编档故事细节且可以用于确定故事如何完成。
文章提到了用户故事可以用三个字母C来描述：卡片（Card），对话（Conversation）和确认（Confirmation）。 “卡片”代表客户需求而不会记录需求，“卡片”只是包含对故事的文字描述，需求细节需要在“对话”中获取，并在“确认”部分得以记录。
基于我现在对敏捷的认识，我们一直在强调敏捷的过程需要客户参与，从早期的用户故事编写，到每一个迭代版本的发布验收。 对于一个项目型的SC来说，其实这是最困惑我的地方，在现有的流程体系下也几乎是不可能存在的事情。
两个block点是一直让我比较困惑的：
1 我们很难在每一个项目上跟客户签订一份敏捷合同，客户无法保证在整个项目周期中都进行参与，无法及时有效的参与测试。
2 基于一些甲乙方利益的考虑，甲方总是希望以最少的价格购买最多的功能，在整个迭代交付的过程中不停的进行讨论和发散，有可能会无限或者极大有限的扩大项目范围，增加项目的成本。
在这两个问题解决之前，我一直很难从内心上接受对实施性的交付项目运用敏捷。所以今天在书中看到了如下的一些内容，心里就更加对推行敏捷打鼓了。
“与其写下这些故事细节，还不如让开发团队和客户讨论细节”？
在现有的流程模式下，如何让开发团队和客户讨论细节？
“故事并不具有契约性质”？
故事不具有契约性质，难道可以让客户随意的扩展需求和需求反复？ 成本如何控制，交付周期如何控制？
怎么搞？ 不知道，继续看吧，困惑~~
很关键的一句话：客户团队包括哪些确保软件符合潜在用户需求的人，可以包括测试人员，产品经理，实际用户和交互设计师。
此处我发现了两个概念，客户团队和实际用户。 客户团队并不仅仅是实际用户。如果根据这个事情推断的话，在我司的当前大环境下，让SC或者是SC+测试同事来作为客户团队，是否可以解决我的问题呢？
场景1 需求调研阶段，SC/测试同事通过足够的user case（包含界面原型，业务流程概述等）跟客户达成一致，在需求调研完毕后，就由SC/测试同事代表最终用户的角色，组成客户团队。
场景2 研发阶段，由SC/测试同事组建客户团队并完成用户故事，在研发过程中与开发人员进行充分的细节讨论，在每个迭代版本发布之后进行验收，以保证最终的结果可以满足用户的需求。
以此看来，好像我的困惑部分被解答了（需求到研发看起来还是瀑布式的），下周跟教练交流一下吧。
