Scrum，幸福来得挺突然

严重赞同，楼主成功的因素：团队成员的高度认同敏捷，一个理想（都希望改进当前困境，希望系统更好的发展）

兄弟你说的励志，最重要的办法本身靠谱。

楼主的slide根本看不了

强烈恳求楼主将ppt以附件形式分享

已经将PPT以附件形式上传了，请ls两位看看能否下载。

我觉着一个基本条件应该是团队成员都很开发，愿意接受新事物。
我也在一个团队内实施敏捷，有一些进展，但也有一些困难，主要是原来的开发习惯的根深蒂固，对新方法没信心。

团队成员的接受固然是个很好的起点，我觉得Scrum Master的作用同样不可忽视。虽然我当时的团队很open，我还是花了不少时间给大家吹风，渲染敏捷开发的好处，打消大家的疑虑，群发邮件也好，组织大家座谈也好。
另一方面，团队是要看到好处的，而且时间越短越好，如果某些实践很快就见到了效果，大家会很快跟上来，走下去。我们第一天开完Sprint meeting就见效果了，共享一下第一天结束后我们产品负责人的邮件在下面 ：

scrum我们也实施了，感觉上不过是分工更细了，责任明确了，还有一个是，，QA和PM的需求得有一个人来确认，我们是项目总监来确认的，确认了，就不再更改，如果客户有更改，要加到下一个迭代中，本次软件开工后不再更改。。。。。

有两点跟兄台有不同的见解：
1. Scrum没有让分工更细，相对于其他开发流程如RUP定义的大量角色，Scrum只定义了产品负责人，Scrum Master和团队三个角色，我这样认为：传统的重量级的开发流程，方法和模型认识到大规模软件开发的复杂性，它们通过细分开发任务，细分流程和角色来应对，强调各个环节和团队的专业化；敏捷开发也承认软件开发的复杂性，它通过拆分需求和开发周期，迭代交付等把风险控制在可接受范围内，在此基础上模糊人员角色，以目标为导向进行软件开发。
2. 对付需求变更，我们采取的做法是：在可控的范围内，任何阶段都可以更改需求，只要保证总的需求评估规模不超过剩下的可用人天数就可以，否则就像你们那样，拆分需求或者推迟其他重要性低的需求。
不管怎么做怎么理解，抓住老鼠就是好猫，见效的就是好方法

同样是需求，为什么在之前的流程里需要13人天，而现在的sprint计划会议计里只需要一个下午？
是因为大家的主动积极性，还是其他什么原因呢？