看了知乎上的帖子，查阅资料，下面是有关于敏捷开发的定义。
……………核心角色………………………
产品设计：负责产品设计，将产品需求转化为DEMO和设计文档，交付开发和测试。同时，验收产品功能。
开发：将设计转化为实际产品，交付给测试。
测试：测试产品，测试通过的交付给产品设计人员。不通过的踢回给开发。
Leader:负责下达任务，另外重要职责就是，当团队成员中出现意见不合时，负责拍板！
………………………………………………………………
敏捷开发的核心就是团结，敏捷开发追求效率，将一个大的产品功能划分成小的，然后一块块的迭代开发。在这个过程中，大家之间采用一种互相容易理解的方式表达产品需求，可能一些特别细节方面的不会在设计文档中体现（如果要达到非常细的程度是非常耗时的），在开发和测试过程中，互相的沟通讨论是非常多的，这时如果发现产品描述中缺少的或者错误的，大家会口头协调好处理方法，再由产品经理一点点得补进去，如果这个时候团队之间不够团结，互相斤斤计较“你写的文档有问题！”“你理解能力太差！”等等，将会很难推行。开发和测试之间也是一样。
产品设计：负责产品设计，将产品需求转化为DEMO和设计文档，交付开发和测试。同时，验收产品功能。
开发：将设计转化为实际产品，交付给测试。
测试：测试产品，测试通过的交付给产品设计人员。不通过的踢回给开发。
Leader:负责下达任务，另外重要职责就是，当团队成员中出现意见不合时，负责拍板！
………………………………………………………………
敏捷开发的核心就是团结，敏捷开发追求效率，将一个大的产品功能划分成小的，然后一块块的迭代开发。在这个过程中，大家之间采用一种互相容易理解的方式表达产品需求，可能一些特别细节方面的不会在设计文档中体现（如果要达到非常细的程度是非常耗时的），在开发和测试过程中，互相的沟通讨论是非常多的，这时如果发现产品描述中缺少的或者错误的，大家会口头协调好处理方法，再由产品经理一点点得补进去，如果这个时候团队之间不够团结，互相斤斤计较“你写的文档有问题！”“你理解能力太差！”等等，将会很难推行。开发和测试之间也是一样。
……………核心角色………………………
产品设计：负责产品设计，将产品需求转化为DEMO和设计文档，交付开发和测试。同时，验收产品功能。
开发：将设计转化为实际产品，交付给测试。
测试：测试产品，测试通过的交付给产品设计人员。不通过的踢回给开发。
Leader:负责下达任务，另外重要职责就是，当团队成员中出现意见不合时，负责拍板！
………………………………………………………………
前面说了，敏捷开发的核心就是团结，敏捷开发追求效率，将一个大的产品功能划分成小的，然后一块块的迭代开发。在这个过程中，大家之间采用一种互相容易理解的方式表达产品需求，可能一些特别细节方面的不会在设计文档中体现（如果要达到非常细的程度是非常耗时的），在开发和测试过程中，互相的沟通讨论是非常多的，这时如果发现产品描述中缺少的或者错误的，大家会口头协调好处理方法，再由产品经理一点点得补进去，如果这个时候团队之间不够团结，互相斤斤计较“你写的文档有问题！”“你理解能力太差！”等等，将会很难推行。开发和测试之间也是一样。
产品设计：负责产品设计，将产品需求转化为DEMO和设计文档，交付开发和测试。同时，验收产品功能。
开发：将设计转化为实际产品，交付给测试。
测试：测试产品，测试通过的交付给产品设计人员。不通过的踢回给开发。
Leader:负责下达任务，另外重要职责就是，当团队成员中出现意见不合时，负责拍板！
………………………………………………………………
前面说了，敏捷开发的核心就是团结，敏捷开发追求效率，将一个大的产品功能划分成小的，然后一块块的迭代开发。在这个过程中，大家之间采用一种互相容易理解的方式表达产品需求，可能一些特别细节方面的不会在设计文档中体现（如果要达到非常细的程度是非常耗时的），在开发和测试过程中，互相的沟通讨论是非常多的，这时如果发现产品描述中缺少的或者错误的，大家会口头协调好处理方法，再由产品经理一点点得补进去，如果这个时候团队之间不够团结，互相斤斤计较“你写的文档有问题！”“你理解能力太差！”等等，将会很难推行。开发和测试之间也是一样。
敏捷开发包括了哪些内容
敏捷开发总的流程如下：
1.需求规划和分期
2. 需求评审
3. 需求讲解
4. 方案评审
5. 每日晨会
6. 性能测试
7. CodeReview
8. Demo
9. 测试阶段
10.线上Bug修改流程
跟我说哪些东西不应该包含在敏捷开发流程里，如果你不喜欢，跟你的观念有冲突，你可以把敏捷开发这四个字换成任意四个字。总之，如果要解决这些问题，这是我目前看到的最佳实践，每一个节点都非纸上谈兵，而是经过无数个尝试和失败总结出来的。
如果你是一个IT公司的管理者，如果你不知道该怎么去管理自己的团队，我强烈安列你按着我说的这种标准化方式去做，放心，出了问题我保证不会负一点责任。
确切的说，我说的敏捷开发流程，并不仅仅是开发团队的事情，它背后隐藏着更多的理念。
1.产品和开发必须是一个Team，大家只是分工不同，角色不同，并不是两个对立的团队。
如果你的公司是把产品和开发分成两个部门，那么恭喜你，产品和开发之间的纠纷一定无限多。
在所有我带的Team中，自始至终强调的理念就是：出了问题，别跟我说这是产品设计出来，这是开发团队实现不了的。我只知道这是你们一个开发小组所有人的责任，这个后果是所有的人都需要承担的。如果我们认真的区分这是什么问题，那么也只是为了避免下次出现同样的情况，用户只会知道是一个公司出了一款垃圾产品，没有人关心到底是产品还是开发的锅。
这是做敏捷开发的大前提。或者不仅仅是产品和开发，责任共担，One Team这个理念是贯穿始终的。这并不是说，大锅饭，而是说，面对不好的结果，所有Team的人都必须共同承担。出现问题的原因仅仅是为了追溯和重现当时的场景，以避免后续会出现同样的情况。
产品和开发必须是一个Team还体现在需求分期上。这一点在讲到需求分期的流程的时候，会提高的。实际上，需求分期如果没做好，敏捷开发只能流于形式。
需求分期怎么做，这是MVP的事情，另一个话题。简单来说，每一期都要有一个提前的预测，这一期里要做的所有的功能都只为了检测自己的预测是否正确。并根据结果去不断的调整开发规划。
2.职责明确，每个人要负责的事情必须清晰无误，谁该做哪些事情，必须要提前讲清楚。
开发团队的推荐角色应该是这样的。
PM 1个
UI 1个
CSS/js 1~2个
Java 2~4个
Android 1~2个
IOS 1~2个
QA 1个
这是一个相对平衡的模板，这样的一个8~10人的小Team，是可以复制的。敏捷开发支持多个Team并行开发。理论上来讲。这种方式，可以支持五到六个小Team同时启动。
在讲到最后多Team并发协作的时候，我也会提到的。
除了这些项目小组的角色，还有各个Team的Leader。我比较推荐小组分成如下几种：
1.产品Team 产品团队
2.用户体验 Team 传统的UI团队升级为UE，升级为整个系统甚至是公司的用户体验师。
3.后端Team 苦逼的后端
4.前端Team Android/IOS/JS 表问我为什么把这三个放到一起，我就是认为一个前端工程师应该三者通吃。可以在某一个客户端上了解的更深入，但是普通的项目上手还是应该没有问题的。
5.QATeam QA只需要做功能测试，回归测试，边界测试，并不需要做性能测试。
敏捷开发总的流程如下：
1.需求规划和分期
2. 需求评审
3. 需求讲解
4. 方案评审
5. 每日晨会
6. 性能测试
7. CodeReview
8. Demo
9. 测试阶段
10.线上Bug修改流程
跟我说哪些东西不应该包含在敏捷开发流程里，如果你不喜欢，跟你的观念有冲突，你可以把敏捷开发这四个字换成任意四个字。总之，如果要解决这些问题，这是我目前看到的最佳实践，每一个节点都非纸上谈兵，而是经过无数个尝试和失败总结出来的。
如果你是一个IT公司的管理者，如果你不知道该怎么去管理自己的团队，我强烈安列你按着我说的这种标准化方式去做，放心，出了问题我保证不会负一点责任。
确切的说，我说的敏捷开发流程，并不仅仅是开发团队的事情，它背后隐藏着更多的理念。
1.产品和开发必须是一个Team，大家只是分工不同，角色不同，并不是两个对立的团队。
如果你的公司是把产品和开发分成两个部门，那么恭喜你，产品和开发之间的纠纷一定无限多。
在所有我带的Team中，自始至终强调的理念就是：出了问题，别跟我说这是产品设计出来，这是开发团队实现不了的。我只知道这是你们一个开发小组所有人的责任，这个后果是所有的人都需要承担的。如果我们认真的区分这是什么问题，那么也只是为了避免下次出现同样的情况，用户只会知道是一个公司出了一款垃圾产品，没有人关心到底是产品还是开发的锅。
这是做敏捷开发的大前提。或者不仅仅是产品和开发，责任共担，One Team这个理念是贯穿始终的。这并不是说，大锅饭，而是说，面对不好的结果，所有Team的人都必须共同承担。出现问题的原因仅仅是为了追溯和重现当时的场景，以避免后续会出现同样的情况。
产品和开发必须是一个Team还体现在需求分期上。这一点在讲到需求分期的流程的时候，会提高的。实际上，需求分期如果没做好，敏捷开发只能流于形式。
需求分期怎么做，这是MVP的事情，另一个话题。简单来说，每一期都要有一个提前的预测，这一期里要做的所有的功能都只为了检测自己的预测是否正确。并根据结果去不断的调整开发规划。
2.职责明确，每个人要负责的事情必须清晰无误，谁该做哪些事情，必须要提前讲清楚。
开发团队的推荐角色应该是这样的。
PM 1个
UI 1个
CSS/js 1~2个
Java 2~4个
Android 1~2个
IOS 1~2个
QA 1个
这是一个相对平衡的模板，这样的一个8~10人的小Team，是可以复制的。敏捷开发支持多个Team并行开发。理论上来讲。这种方式，可以支持五到六个小Team同时启动。
在讲到最后多Team并发协作的时候，我也会提到的。
除了这些项目小组的角色，还有各个Team的Leader。我比较推荐小组分成如下几种：
1.产品Team 产品团队
2.用户体验 Team 传统的UI团队升级为UE，升级为整个系统甚至是公司的用户体验师。
3.后端Team 苦逼的后端
4.前端Team Android/IOS/JS 表问我为什么把这三个放到一起，我就是认为一个前端工程师应该三者通吃。可以在某一个客户端上了解的更深入，但是普通的项目上手还是应该没有问题的。
5.QATeam QA只需要做功能测试，回归测试，边界测试，并不需要做性能测试。
3.每个人必须学会主动去为自己的事情负责
当有了第二条，你很快就能发现团队中，谁是能够尽守职责，更主动的人。第3条很难做到，特别在很多公司，并不注重对于团队凝聚力的培养，也不会注重和他们之间的交流，不知道他们想要什么。
所以这也是我一再强调的，敏捷开发并不仅仅是一个开发流程，更是一种管理的方式，他牵涉到绩效考核，公司福利，上下班制度等等你看不到的东西。
如果说你的团队成员并不能做到为自己的事情负责，那么你需要的就是，要么就是去更换团队，要么就是想办法去激励团队。
当有了第二条，你很快就能发现团队中，谁是能够尽守职责，更主动的人。第3条很难做到，特别在很多公司，并不注重对于团队凝聚力的培养，也不会注重和他们之间的交流，不知道他们想要什么。
所以这也是我一再强调的，敏捷开发并不仅仅是一个开发流程，更是一种管理的方式，他牵涉到绩效考核，公司福利，上下班制度等等你看不到的东西。
如果说你的团队成员并不能做到为自己的事情负责，那么你需要的就是，要么就是去更换团队，要么就是想办法去激励团队。