客户职责：确认需求，桥接用户和it。包括，捕捉市场、用户的变化，将其转化为需求；对it提出的需求分析进行确认；对it提交的系统进行确认。
简单的说，客户就是提需求的。但提需求这件事就不简单。首先，提什么需求？这是对客户的业务能力和市场捕捉能力的考验。有市场价值的需求才能创造价值，乱提一气只会浪费人力物力，丧失市场。其次，需求的表述。知道咬做什么未必能清楚说明白。而说不明白，或者叫沟通有问题，需求同样是个废品。怎么叫明白？准确、清楚。
所以客户要准。对市场的变化和价值点要准确把握，对需求的描述也要准确。客户，市场，需求，这是项目的整体方向。方向都不准，怎么可能走到目的地。
在敏捷开发小版本需求前，市场的细微变化能够快速的转化为需求；客户提出的需求也能够得到快速的响应；并且，客户不需要对市场或用户有多么完善、深刻的计划之后再付诸需求、开发，而完全可以通过一两个小版本进行尝试、探测。同时，小版本可以允许客户更加关注产品的细节，将细节作为小版本需求提出来。而为了做到小版本，客户需要提高对市场变化的敏锐程度，并保持对产品改进的持续关注。
项目负责人：调配资源，掌控投入和产出，把握项目进度与质量。
把握项目进度和质量是项目负责人的主要职责。用以前的话说就是按时按质。掌控投入和产出是方法，需求少资源多当然理想，最要命是项目中途发生变化。调配资源是实现途径。负责人一般不直接参与开发。
项目负责人挺可怜的。权利往往只限于开发团队，却要对客户、项目和老板负责。他们只能去争。跟客户争需求，少一个需求就少一份成本。跟老板争资源，其实就是争成本，多一份成本就能多做一份需求。还要跟开发人员争进度，利用有限的资源按时完成需求。不容易。
小版本需求带给项目负责人的，是项目计划的细化。从而，项目进度能够更加的清楚。但是这有个问题，即一个地方的计划发生变化，此后的整个进度计划可能都要重做。当版本因小而多时，这个问题尤其明显。另外，版本小而多也需要负责人更加持续和敏锐的关注项目进度中的变数。
开发人员：实现需求，保证项目质量，推动项目进度。
开发人员要求有较高的执行力。这是将需求变为实际系统的能力。
小版本给开发人员带来的好处是不言而喻的：人们可以专注于一个点，一个需求带来的修改也可以限制在一个较小的范围内。但是这个要求其实也不小：架构和设计应该有足够的弹性以便于扩展。虽然我们提倡简单设计，反对过早优化，但是如果完全没有设计，那极有可能造成一个小需求的变化会影响一大片代码！这简直是无法想象的灾难！
测试人员：开发与客户之间的桥接人，协助开发理解需求，协助客户验收把关。
测试人员要求细致。在高层级上，要求深入
，这样可以增进开发人员对需求的理解，改进后续需求的开发质量和进度。
也许最烦小版本的就是测试人员吧！频繁的做一些小功能的测试，想来也不是什么很爽的事情。
============================================
2012年09月25日 编辑记录
这是我在手机的一个笔记本工具上积累的一些点滴记录。所以最初粘贴上来的时候，除了分段，几乎没有任何的格式。并且，关于测试人员和小版本之间的关系，我也没有收尾——事实上是我不知道如何收尾。我没有系统的做过测试，只和测试组天天打交道。
这样也被选作推荐博文，我受宠若惊。于是编辑一下，增加了一点文本样式。内容上没有任何修改。
希望以后越写越好。
============================================
2012年09月25日 编辑记录
这是我在手机的一个笔记本工具上积累的一些点滴记录。所以最初粘贴上来的时候，除了分段，几乎没有任何的格式。并且，关于测试人员和小版本之间的关系，我也没有收尾——事实上是我不知道如何收尾。我没有系统的做过测试，只和测试组天天打交道。
这样也被选作推荐博文，我受宠若惊。于是编辑一下，增加了一点文本样式。内容上没有任何修改。
希望以后越写越好。
本文转自 斯然在天边 51CTO博客，原文链接：http://blog.51cto.com/winters1224/1001540，如需转载请自行联系原作者
