我看“敏捷”
总体而言，“敏捷”就是一个bizword，几个定制开发项目的公司和技术咨询公司所创造的“蓝海”。
这其中有意无意的忽略了一些关键环节，有些地方很恶劣。比如业务，将因为自己业务经验的匮乏，所带来的项目需求变更和交付期延长等风险，全部转嫁给客户。我们假设自家装修，施工队说你怎么说我怎么做，之所以没有做是因为你当初没有说，如果要改，需要另外付钱，会是什么心情。
同时，除了FDD这样的方法论，有一个完整的过程来支撑外，其它的都是一些成功实践，也就是一些经验之谈，容易让学习的人混乱，角色要哪些，日常怎么来管理？在具体的术上，确实有很多优秀之处，但是所处的层次不是在整个项目上，毕竟开发只是项目实施的一个环节，并不是整个的项目。但是一旦要提过程，我估计是自己打自己耳光。
因为含含糊糊的隐瞒了一些东西，使人无法知道过程优化和改善的方法和指标，这与制造业的敏捷无法同日而语。
想起一个讲咨询培训的策略，“励志、颠覆、速成、炒作”，敏捷方法有点这个意思，我觉得还要加一个“仪式”。过一段时间找个东西出来包装，Scrum把任务和会议管理包了包，不知道下一个目标是什么。
正解 39 楼 RCFans 2010-11-20 mouge，很遗憾，我不会采取你提出的所有建议。 40 楼 一蓑烟雨任平生 2010-11-20 RCFans，架构设计是你这个项目的首要目标么？如果是的，那么你的做法无可厚非。
如果你做的是个业务系统，如你所说领域驱动，我想你应该梳理一下业务的分析设计在你的过程中是什么位置，会是一个什么样的过程，核心业务的设计和开发是如何来做角色组织和协作等等，这样才算完整，单纯讲开发组的工作意义不大。
我是一个唯业务论者，业务的成熟度决定开发采用什么样的过程方法。很多业务的核心项目，不是什么时候都可以边干边改。现在的很多敏捷方法是唯技术论的，比较符合技术人员的口味，但不是项目这个层面，拿着这种方法去做项目，将业务成熟这个条件刻意淡化的后果可想而知。
业务系统项目失败从我的经验看，技术原因的很少，问题最大的是两类，一个是没有业务经验，一个是项目体制混乱。
Mouge，项目实施过程中，要把握好哪些是不能变，哪些可以小变，哪些可以在什么期间变，而不是无所谓，想怎么变就怎么变。
你不是变形金刚，公司掏钱雇你，客户掏钱给公司，不是没有原则和底限的。如果有些环节不先做好整体的规划和设计（业务的分析和关键业务规则的详细设计），你再敏捷，技术能力再强，也还是会项目延期，然后将课题抛给客户，说客户没说清楚或者说客户业务在变。每个人对可控制的变化是很少的，只有能控制住大部分，才能对小部分的变化做调整，否则就是失控。
现在的敏捷方法有价值的部分，是在配置管理上，怎么用很好的技术手段来应对变化，但这只是项目成功实践的一部分。是的，我们可以应对变化，但我们为什么不想想，为什么会有这么多的变化？ 41 楼 RCFans 2010-11-20 我在业务梳理中的地位比较高，直接会议对象是业务部门副总、主管，因为在这里重点是说开发团队的组织，所以其它工作没有提及，这方面的我想还是等项目结束的时候专门开个贴总结。
有一点就是，业务梳理和技术团队的工作是两条线在走，工作项和产出都不纳入Scrum的看板中。 42 楼 JavaInActoin 2010-11-25 把敏捷中的部分实践当作RUP的补充就好了，哪些实践有用，要看具体什么项目。
