敏捷团队三大特点
特点一：自组织自管理
自组织管理在上文中的十二原则里提及过，是指当团队遇到问题的时，团队成员需要自己研究解决方案，自己解决问题，不需要领导的监督，实现自我驱动。
这听起来比较理想主义，但在实际的敏捷实践过程当中， 一个比较成熟的敏捷团队确实可以做到这一点。
体现为：一个commitment就是一个承诺，如果一个团队成员承诺八个小时完成某一项后端开发的任务，并且将其认领了，基本就不需要任何其他人去督促他了。这就是自组织和自管理。
尽管目前绝大部分团队都做不到这样的成熟度，但团队里的项目经理或是产品经理可以去思考如何激发团队成员的积极主动性，如何提升自主性和自管理性。
特点二：完全透明
团队执行项目时，每天在做什么、遇到什么问题、需要哪些支持，都是透明、可视的。
比如我们在每日的站会中，团队所有成员都需要更新自己的项目进展或提出协助需求，让团队之间能够了解彼此的任务及状态。
这不仅可以把控整体进展，也能在团队成员遇到困难时，那些有经验的成员可以主动、精确地提供帮助，降低功能开发的难度。
特点三：自适应
从对敏捷的解释里我们也可以看到，一个自适应的团队是可以响应变化的团队。
这个团队可能是在做产品，也可能是在做项目，不论是从产品经理来的新的需求，还是从客户反馈过来需要进行的变更，团队都能对相应的产品和项目进行反思，以适应新的这种变化。
另外值得一提的是对流程的回顾和反思。在Scrum敏捷团队中，很多流程是团队自己确定。如开站会的时间和流程，为什么“站会”不叫“早会”？这意味着每日站会不一定非要是在早上开 。只要团队内部协商达成一致，在合适的时间开就可以
这三个特点看似比较理想化，但正是因为具体项目中的变化太多了，使得团队必须具备这样的这种素质。
四、敏捷迭代和Scrum
现在从“迭代”和“Scrum”2个方面来聊聊敏捷实践。
1.迭代开发
在前文对敏捷的常见误解中提到，“我们是迭代开发，所以我们是敏捷的”，下面就用一个造车的例子来澄清这个误会~
模式一
在这样一个造车的过程里，迭代1做了轮子，迭代2做了底盘，随后在迭代3做了外壳，最后终于在迭代4造出了整车。
那这样的开发模式属于迭代开发吗？
可以看到，从功能的角度，这其实属于一种增量的开发模式。
就比如在软件开发中，四个月的时间里需要完成四个模块。我们就在第一个月做了第一个模块，第二个月做了第二个模块，第三个月做第三个模块，第四个月做了最后的模块，这就是一种从功能性上来讲的增量式开发。
模式二
相较于增量式开发，迭代式的开发更关注尽快地达到用户的预期。
比如说，用户的需求是一个从a点到b点的交通工具，按照迭代开发的模式，我们就可能会在第一个迭代做出一个滑板车来。
这个时候用户显然不大可能满意，毕竟用户想要的是一辆汽车，但是滑板车至少是一个交通工具，从可以从a点到b点。
在第二个迭代我们再优化升级，做出一辆自行车来，这比滑板车更轻松一点，速度更快一点。
第三个迭代再进一步造出摩托车来，跑的更快，动力更强。最后在第四个迭代终于交付出一辆完整的汽车来，
