现在敏捷开发在互联网界，基本算是主流思想，大家都在不断强调小步快跑、快速试错，于是敏捷开发被大家大力提倡，究竟为什么要提倡敏捷，敏捷开发的流程与原则是怎样的。
下面我一一来详解，先从什么是敏捷开发讲起@mikechen
什么是敏捷开发
敏捷开发的起源
2001年2月，Martin Fowler，Jim Highsmith等17位著名的软件开发专家齐聚在美国犹他州雪鸟滑雪圣地，举行了一次敏捷方法发起者和实践者的聚会。
在这次会议上面，他们正式提出了Agile(敏捷开发)这个概念，并共同签署了《敏捷宣言》。
敏捷开发的定义
敏捷软件开发又称敏捷开发，是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。
它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用。
敏捷开发宣言(价值观)
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
也就是说，尽管右项有其价值，
我们更重视左项的价值。
你可以从上面定义中，不断提炼出好几个关键词：面对面、沟通、快速、变化、以人为本。你再逐渐回味你工作中的敏捷开发，你会发现大量的工作都是围绕以上维度。你再结合如今的互联网的发展节奏，快速试错、小步快跑、不断调整..你会发现，敏捷开发的确有它存在的土壤。
于是，你发现我们公司落伍了啊，为什么我们公司不加快转到敏捷开发呢，我们应该快速跟上啊。然后你就像如获至宝一样，告知你的boss，我们应该快速跟上。这个场景非常的典型，看见一个好东西，就像如获至宝一样，恨不得马上用上。这与如今大量的传统企业转型一样，恨不得马上把互联网这个工具配置上。
敏捷开发流程
敏捷开发流程一般包括8个步骤，具体如下：
1、目标制定，目标对齐：通过市场调研、业务思路、风险评估制定公司规划和目标，根据这一目标产生所有部门的目标并实现对齐；
2、产品规划：产品研发部门根据目标制定产品关键路线图，这个路线图中分布着不同的产品特性和其完成时间；
3、组织产品待办列表：产品规划产生的需求、客户需求、市场人员收集到的缺陷等将组成产品待办列表；
4、需求梳理：然后产品负责人(Product Ower)对这个列表进行梳理，并在需求梳理会(Backlog Grooming Meeting)讲解具体每一个需求，团队成员根据需求的复杂程度评估每个任务的工作量，输出本次迭代的待办事项列表，完成优先级排序等工作；
5、迭代规划：通过Sprint计划会，明确要执行的工作、冲刺目标等，
6、迭代开发：期间会进行每日站会、性能测试、CodeReview、Demo、测试等工作；7、Sprint评审：由每个任务的负责人演示其完整的工作，由PO确定Sprint目标是否完成，版本什么时候对外发布，新增bug的紧急程度等等。
8、开回顾会议：回顾会议由Scrum团队检视自身在过去的Sprint的表现，包括人 、关系、过程、工具等，思考在下一个Sprint中怎么样可以表现得更好，更高效，怎么样可以和团队合作地更愉快。
敏捷开发的原则
1：我们的最高目标是通过尽早和持续第交付有价值的软件来满足客户
2：欢迎对需求提出变更 – 即使在项目开发后期，要善于利用需求变更，帮助客户获得竞争优势
3：要不断交付可用的软件，周期从几周到几个月不等，越短越好
4：项目过程中，业务人员与开发人员必须在一起
5：要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务
6：无论是团队内还是团队间，最有效的沟通方法是面对面的交谈
7：可用的软件是衡量进度的主要指标
8：敏捷过程提倡可持续的开发，项目方，开发人员和用户应该能够保持恒久稳定的进展速度
9：对技术的精益求精以及对设计的不断完善将提升敏捷性
10：要做到简洁，尽可能减少不必要的工作，这是一门艺术
11：最佳的架构，需求和设计出自于自组织的团队
12：团队要定期反省如何能够做到更有效，并相应调整团队的行为。
敏捷开发实践经验
关于敏捷开发的适用性。
敏捷只是一种产品开发的步骤，它背后传递的内容价值度高于形式，如果你只抓形式，有点本末倒置。
团队至上，以人为本
把人的价值提到第一位，产品人、技术人…产品的提炼和收集在产品经理，如果在第一个环节，产品经理跟不上(综合素质不行)，在源头上就遇见了问题，再往下传递到技术的执行的时候，问题会不断叠加到产品发布..（灾难）。
如果你真打算用敏捷，第一个建议，好钱用到刀刃上。找一个靠谱的产品，多1-2倍的钱，这个钱你会获取跟多的回报。
举一个例子，一般产品和技术衔接的时候，会有如下场景。产品最先调研市场需求MRD(技术、测试不参与)->调研完后出PRD(技术、测试不参与)->PRD给打技术做需求评审(技术、测试参与)->需求评审(产品很希望一次通过)->技术方案…,1/2场景一般技术等不参与，PRD一般给到只对需求细化，如果理解没有什么问题就通过。
然后，敏捷里建议的方法，调研等步骤大家应该一起，出PRD的时候要非常详细，特别是流程图一定要画全(这点大部分的产品做得不太好)..
你发现了吗，整个流程里，好的产品在整个过程的重要性。敏捷对人的要求其实蛮高的，很多玩的不好的都在抱怨，其实对人的要求还是蛮高的。
敏捷其实在不断加强源头的重要性，不管是人还是产品，还是需求调研，还是市场分析。倘若有部门提出开发质量0 bug的要求，你也不要太吃惊。
适合你的才是最好的
产品本身就需要快速迭代(创业、创新..)。
例如，特别是启动的新项目、新产品，要求更加灵活的产品。创业公司早期，需要一个精简的产品demo试错。
还有很多成熟型公司，对一部分产品不太满意的，可以单独拉出来一个小团队去做敏捷实践。
团队的组成成员要精简，尽量不要太多。
陈睿mikechen
10年+大厂架构经验，资深技术专家，就职于阿里巴巴、淘宝、百度等一线互联网大厂。
关注「mikechen」公众号，获取更多技术干货！
后台回复【面试】即可获取《史上最全阿里Java面试题总结》，后台回复【架构】，即可获取《阿里架构师进阶专题全部合集》