关于设计的可扩展性。

项目经理如何将客户的模糊需求变为可行的方案

如何将需求分解成数个小的任务

如何将一个整体划分成数个组件并把握好度

这些不是简单的理论就能解决的 更象是艺术.

如果连客户说什么都听不懂 如何将模糊的需求变为可行方案 ? 只有你比客户都专业 这才有可能.

TO一蓑烟雨任平生：

那么谁来做业务到技术实现的转换？

在XP中，这个过程是由客户代表来实现的。
在XP中，客户代表是要将需求转换为UAT的人。

在XP中，
客户代表：我要做A；
开发：没问题，请出UAT；

于是客户代表就要写：
输入A，若B成立，则应得到输出C，否则输出E。

然后才是程序员的事。他只要能程序过UAT就可以了，
不需要知道任何业务知识。

对客户需求产生误解  UAT一样能出

UAT只能避免低级错误

To DDD:

看了年初你们的讨论，有关现场客户部分我十分支持clamp的观点。

现场客户不一定要是真正的用户，
比如说我们现在正在开发的产品，UAT是由CTO出的。
而且，我们自信是最正宗的XP了，
因为我们的XP是CTO在UNCLE BOB的培训班学来的  ：）

其实，我们开发的是产品，只有行业专家才能弄明白，
就算是来十个用户也不可能全明白的。

这是当然的事。
不过，在XP中，这种错误完全是由写UAT的人负责的，
与程序员就没有关系了。
这种机制可能让程序员全心进入编程中，使开发效率大大提高。

因此也可以说，在XP的团队中，负责写UAT的人才是最重要的。
对程序员的要求反倒可能降低很多。
好比我们的团队，大部分都可以是应界毕业生。

嗯 原来这样能逃避责任啊.

谁写UAT谁倒霉 这么具体 客户需求一变 可惨了. 这样的开发有可扩展性才怪 ! 除非写UAT的是巫师 能预测未来.

1. 客户需求变了，改UAT就是了， XP最大的长处就是适应需求的变化。

2. XP本来就不提倡无谓的可扩展性。

哈哈 真逗 

改UAT就不用改程序吗 ?

这不是饶个圈子又回到起点了 ?

还有啊 标题是设计的扩展性 没有谈xp

哈哈 真逗 

改UAT就不用改程序吗 ?

这不是饶个圈子又回到起点了 ?

还有啊 标题是设计的扩展性 没有谈xp

设计的可扩展性是建立在对业务的理解基础之上的，我举的那个例子的意思是说用户往往只是从他自己手上的业务来出发，并不知道实际上要什么，项目开发成功的关键要素是对业务的充分理解和分析，最好是能以业务咨询顾问的角度来做项目的业务调研和分析。

可扩展性是基于业务的要求来定的，比如库存管理方式在两年内会转向第三方物流来管理，那么业务流程要考虑到今年会怎么做，并预留新的业务模式的扩展接口，这些在设计时就必须考虑，这些也是要有行业的业务经验。

如果没有行业经验，那只能不考虑什么扩展性设计了，能完成项目交工不亏本就是成功。

至于XP，感觉那玩意跟禅一样，拿禅比喻可能有些玄，象李小龙的截拳道做比方好了，一千个人就有一千个人的XP，很多地方都是师傅自己明白但无法言传的手艺活，师傅用的好是他自身的能力，徒弟未必能做到，想学好除了悟性，还要跟着师傅干很长时间去体会，李小龙一死，截拳道就成了一个符号，没有什么正宗不正宗，我不信这些。