这周末上了两天的敏捷项目管理的课程培训。把我体会比较深的写下来，供大家参考，若对敏捷有兴趣的话，可自行找相关资料进行深入系统的研究。

一、敏捷适用场景

首先需要定义一下敏捷适用的场景，敏捷并不是万能的，敏捷对应的是cynefin模型中的复杂(complex)场景，即面对未知未来，需要敏捷，动作要快，得到的反馈要快。

二、敏捷的由来

随着软件行业的发展，软件越来越大，越复杂，传统的工程开发方法变得不再适应这个需求快速变化的时代。于是2001年就开始有一个敏捷联盟出现。制定了敏捷宣言、敏捷原则（自行网上查找）。

敏捷宣言：

个体和互动高于流程和工具；工作的软件高于详尽的文档；客户合作高于合同谈判；相应变化高于遵循计划。尽管每句话的后者有其价值，但敏捷更注重前者的价值。

三、敏捷的好处

1、以前开发一个软件，都是整体把一个软件开发出来，再拿到市场上去卖，如果一个很大的软件，开发周期是10个月，那么等产品开发完后，10个月前的用户需求和现在的用户需求可能已经发生变化，产品就不能很好的满足当下用户的需求，即其价值就不大。若通过敏捷来做，把产品分成10个可单独运行的小功能上线，那么1个月就能先上一个小功能，那么一个月的时间可以得到用户的反馈，从而及时调整产品的方向。所以有时方向和选择比努力重要。

2、以前的项目经理要先写完厚厚的整本说明文档后，才移交给下一阶段，然后开发也要写厚厚的开发文档，然后测试也要写厚厚的测试文档，如此花在文档上的时间也很多，因为大家写了文档，那么大家就都看文档了，就不会有面对面的沟通。若如果通过敏捷来做，变成一个小需求后，不用写那么详细的文档，简略的文档+面对面沟通，就能把问题讲清楚。这里可能会有疑问，为什么文档不要写那么详细？这里我得到的答案是，要区分什么是系统性框架文档，这类文档需要详细且及时更新，但还有一类文档是用完即弃的一次性文档，那么就没必要写这么详细，也不需要更新，能完成信息传递的目的即可。

3、从价值上来讲，一个产品花10个月上线，上线后卖100元，和我第一个月上一个小功能，卖10元，第二个月又上线一个功能，这时产品就可以卖20元，以此类推，第10个月的时候，就已挣到很多钱。

4、如果是以前的开发模式，开发一个新产品与运维一个产品，需要的人是不一样的，以前的话，一个产品开发完就可能需要解散团队成员。要知道一个团队的磨合也是有成本的，一个团队刚磨合好，就解散了，就很浪费。若敏捷的话，首先把需求拆小，一个敏捷的团队不需要这么多人，就不存在开发完一个产品就解散团队的情况，敏捷的团队的合作就更默契，互相信任，效率也会更高。

先写到这，后续再补充心得体会。

以上是我的分享，希望有用！