敏捷开发更多指的是一种思想，而不是完全依靠一套现成管理程序，在项目要转敏捷开发时应当要逐渐转变，而不是立即就应用到项目中，根据团队、项目等具体情况做出不同的管理开发方式。
与其他项目管理有相关的管理工具一样，敏捷开发也有敏捷管理工具，但是工具也只是工具，做辅助工作，并不是脱离敏捷管理工具就无法做敏捷开发，因为敏捷开发更多指的是项目开发思想。
简单上线
不同于传统的开发模式（瀑布式），瀑布式采用【需求->设计->开发->测试】大致4个阶段,每个阶段确定后才进行下一个阶段,并且到开发阶段的时候有着较完整的需求和开发文档，这种模式耗时长久，产品上线时间长，无法及时的拉取到用户群体。
敏捷开发主要体现在敏捷上，首先完成基础功能上线，经过短期的不断迭代更新交付来不断完善功能。
敏捷开发讲究的是前期以最简单快捷的方法实现功能，当经过几次迭代后发现当前的框架无法支撑更强大的功能时，此时才进行重构，引入新的框架。
需求灵活，快速迭代
产品在使用过程中会不断的被发现问题，用户有着不同的需求，因此敏捷开发其中一项是拥抱变化。时刻站在用户角度来解决产品问题，并且及时的解决问题迭代产品。
在迭代的过程中不断的收集用户反馈，收集需求变更，并且给需求判定优先级，然后先解决优先级高的需求，以灵活快速的解决需求并在特定的时间迭代交付一次版本。
注重沟通
敏捷开发强调灵活快速迭代，在开发过程中可能没有太过详细的开发文档，因此常常需要经过不断的沟通来解决需求和项目对接问题，同时在沟通过程中不断发现问题并及时处理。
但是在开发的中后期，还是需要维护好开发文档，新人替旧人，人员更替问题是普遍存在的，如果没有相对较完善的文档，新人刚来时无法尽快的对项目进行熟悉，此时需要有老员工花较长的时间来进行引领新员工，这是文档不完善会带来的弊端。
敏捷开发在前期文档不全可能是常态，但是在中后期应该及时的完善文档。
知识积累
在开发的过程中，前期的技术知识应该处于一个相对薄弱状态，经过产品的不断迭代，需求的累加，不断的进行完善，我们的知识才能够得到不断的积累，也能够更好的处理项目问题，以及有更高的技能来对项目进行重构和部分重构。
避免强行敏捷
准备实施敏捷开发的团队，前期要有个过渡阶段，让团队先适应这种开发模式，之后慢慢向着真正敏捷开发的方向推进项目管理方式。最好不要让团队立即进入完全敏捷开发的管理中。
正在实施敏捷开发的团队，应当适当的分配需求任务，即使在冲刺阶段，最好也不要让团队负荷过多的需求任务。因此在需求任务评审时要把握好任务的难度和耗时。
敏捷开发中会遇到的问题
- 强行敏捷
- 伪敏捷
- 团队成员对敏捷开发没有一定的了解
- 对sprint冲刺阶段的预估不准确
- 没有相对较完善的敏捷开发管理规范
