喜欢这篇文章，请点赞
大白话描述
区别于传统瀑布式开发方法，敏捷反对产品生命周期每个阶段只走一遍，最后一把交付的方式，而是关注小步快跑，持续交付，及时反馈的方式。以往大多数公司是在研发内部时间敏捷，最近的趋势是走向业务敏捷，打造包含了需求，开发，测试，运维，运营所有角色的全业务敏捷生命周期，以业务为导向，将业务人员和研发人员全都纳入到敏捷团队中来。
敏捷是一种软件开发领域的业界实践，包含了价值观5个，原则12个和方法论若干种。
敏捷的价值观最初是由17个行业大拿商讨出来的，也挺有意思，比如最后一项，有点类似与天才是1%的灵感和99%的努力的下一句，但是1%的灵感是最重要的。
价值观5个
个体和交互胜过过程和工具
可以工作的软件胜过面面俱到的文档
客户合作胜过合同谈判
响应变化胜过遵循计划
虽然右项有价值，但我们更重视左项
原则12个
满足客户。通过尽早和持续交付来满足客户
拥抱变化。即使开发尾声时的需求变化也是好事，因为任何变化意味着能够更接近客户的真实需求
频繁交付。交付周期越短越好
在一起工作。业务，技术人员和客户都能一起干活，意味着能交付更有价值的产品
通过提供环境，信任，支持，以人为核心来构建项目，
面对面交谈，高效率传递信息
衡量进度的主要标准是可工作的软件
通过合理的开发节奏，来保障可持续开发
持续关注技术卓越，增强敏捷能力。
保持简洁。可以砍掉没有价值的功能
具有自组织的团队能够产出最好的脚骨，需求和设计。自组织团队可能需要high-level的指导，但是不需要详细的指令
通过及时反馈，提高效率
方法论
敏捷!=Scrum，两者关系是：敏捷包罗万象，有多种方法例如极限编程，scrum，特征驱动开发等，也有技术实践如测试驱动开发，也有规模化敏捷的工具Less和Safe。
scrum框架的“三三五五”的概念
【3 个角色（产品负责人、团队、ScrumMaster)】
【3 个工件 (产品待办事项列表、迭代待办事项列表、燃尽图）】
【5 个会议（迭代计划会议、每日站会、迭代回顾会议、迭代评审会议、产品 Backlog 梳理会议）】
【5 个价值（承诺 、专注、开放、尊重、勇气）】
敏捷的实施步骤
按照顺序有
评估诊断。需要选择代表性项目，进行人员访谈了解项目现状，指定计划以免进度不可收拾，与所有人员沟通保证大家认知一致
团队试点。准备工作包括确定团队，人员，需求，架构，工作环境，敏捷工具
成功后推广。可以使用工具Safe和Less，但更重要的是实现团队间敏捷。
需要解决问题：团队之间分属不同组织架构，需求无法对齐，有各自利益考虑，没有排期等问题，产生互相等待，抱怨甚至敌对氛围
规模化推广badCase：直接将适用于一个小团队里敏捷方法，扩散到多个大团队里
规模化推广的两大经验，1是定制度，具体就是从“项目”负责制，转换为“产品”负责人负责的制度。2是定反馈机制。全生命周期的各个阶段都可以有具体的数据来衡量。当一个迭代周期结束后，下一个迭代能顺利开展。
