我看“敏捷”

RCFans，架构设计是你这个项目的首要目标么？如果是的，那么你的做法无可厚非。

如果你做的是个业务系统，如你所说领域驱动，我想你应该梳理一下业务的分析设计在你的过程中是什么位置，会是一个什么样的过程，核心业务的设计和开发是如何来做角色组织和协作等等，这样才算完整，单纯讲开发组的工作意义不大。

我是一个唯业务论者，业务的成熟度决定开发采用什么样的过程方法。很多业务的核心项目，不是什么时候都可以边干边改。现在的很多敏捷方法是唯技术论的，比较符合技术人员的口味，但不是项目这个层面，拿着这种方法去做项目，将业务成熟这个条件刻意淡化的后果可想而知。

业务系统项目失败从我的经验看，技术原因的很少，问题最大的是两类，一个是没有业务经验，一个是项目体制混乱。

Mouge，项目实施过程中，要把握好哪些是不能变，哪些可以小变，哪些可以在什么期间变，而不是无所谓，想怎么变就怎么变。

你不是变形金刚，公司掏钱雇你，客户掏钱给公司，不是没有原则和底限的。如果有些环节不先做好整体的规划和设计（业务的分析和关键业务规则的详细设计），你再敏捷，技术能力再强，也还是会项目延期，然后将课题抛给客户，说客户没说清楚或者说客户业务在变。每个人对可控制的变化是很少的，只有能控制住大部分，才能对小部分的变化做调整，否则就是失控。

现在的敏捷方法有价值的部分，是在配置管理上，怎么用很好的技术手段来应对变化，但这只是项目成功实践的一部分。是的，我们可以应对变化，但我们为什么不想想，为什么会有这么多的变化？

我在业务梳理中的地位比较高，直接会议对象是业务部门副总、主管，因为在这里重点是说开发团队的组织，所以其它工作没有提及，这方面的我想还是等项目结束的时候专门开个贴总结。

有一点就是，业务梳理和技术团队的工作是两条线在走，工作项和产出都不纳入Scrum的看板中。

把敏捷中的部分实践当作RUP的补充就好了，哪些实践有用，要看具体什么项目。