主题：【原创】闲聊敏捷开发——SCRUM（一） -- 哈酷

传统模型对待需求变更的解决方案是--“商务谈判”，在开发前你得把需求定下来，如果中途有变更，要么排到下一版本开发，要么加钱加时间（这里的钱和时间会让客户有肉痛的感觉，呵呵）。

敏捷模型拥抱变化，积极响应需求变更，期待以小步快走的方式及时满足客户所需。这在web开发和很多应用程序开发方面确实做的很好。但在一些规模稍大的项目中，如果用户的需求变更影响到架构需要重新设计或做大的修改怎么办？大需求分解为小需求，小需求再由小组进行敏捷开发。这些小组间的同步和管理怎么办？个人感觉在国内这种开发环境下，只有靠开发人员的水平和经验了。而国外那种几个人十几个人完成个比较大的项目或创意的团队，那更是个人能力的体现。好像敏捷模型也就是从这类小团队的开发方式中总结出来的吧？

当然，在时间或效率不是第一位的情况下，这种方式我还是比较喜欢的。