“ 到底，什么是真正的敏捷开发？”
这大概是很多技术同学都想了解的问题，那么到底什么才是真正的敏捷开发呢？我们来听听鹅厂程序员们的看法：
1. 从敏捷宣言和原则出发
@Timo.
敏捷宣言有四项价值陈述：
- 个体和互动高于过程和工具。(Individuals and interactions over processes and tools.)
- 可工作的软件高于详尽的文档。(Working software over comprehensive documentation.)
- 客户合作高于合同谈判。(Customer collaboration over contract negotiation.)
- 响应变化高于遵循计划。(Responding to change over following a plan.)
敏捷开发宣言
但事实证明这四项都存在局限：
- 优先考虑个体和互动是一个很难推广的概念。销售过程和工具要容易得多；比起不切实际的计划和堆积如山的文件，工作中的软件更难生产；与客户合作需要信任和脆弱性，而这在业务环境中并不总是如此；对于那些想要控制局面、同时又需要为自己的业务制定长期计划的高管来说，应对变化往往显得不够重要。
- 从个人在前司的经历来看：敏捷是个契约，需要参与其中的人不断磨合、思考和迭代，一成不变的敏捷始终不能作为万金油，但要使团队运行在最合适的状态下，需要所有参与者和你一样努力思考和探索，迭代敏捷自身的过程，但这很难。
- 而不恰当地“敏捷”，便容易产生很多缺点，例如：很容易导致开发人员进度被干扰，缩短工作时间，增加压力，并且要求“更快地开展工作”，产生“被剥削感”。最终使开发更不敏捷，且容易导致更多的缺陷和进展缓慢，最终企业效率甚至比敏捷推行之前还低。
最终便成为，所有人都希望自己“敏捷”，但敏捷的那些革命性思想与现实相差甚远。
@Gallen.
认识敏捷要从敏捷宣言和它的12条基本原则理解，然后再看几个主流的敏捷方法Scrum,SAFe,Less, SoS。
敏捷宣言遵循的原则
连基本定义和原则都没看过就胡咧咧敏捷的大有人在。在我看来大多数团队所谓的敏捷研发都是小瀑布。而且把敏捷方法理解成只需要开发参与也偏得太多。实际上敏捷方法支撑的是快速迭代交付产品。完整的产品团队具备所有角色。所谓的没产品由开发自己负责玩的比较转的团队，实际也承担这产品的职责。
顺便提几个问题供大家思考：需求需要拆分吗?拆分的意义是什么？怎么做好迭代规划？响应变化和变更控制是矛盾的吗？
用最终结果来描述敏捷带来的变化：
- 敏捷团队支撑的产品：细心的用户会发现产品渐进式的变化;粗心的用户看不到产品变化，但体验感觉越来越好。但如果产品掌握不好节奏，用户也会吐槽怎么总是变来变去。
- 瀑布式团队支撑的产品：用户明显发现产品阶梯式变化，如常说的改版，焕然一新;用户有时候会失去耐心。
2. “敏捷”强调的是响应变化的能力
@Like.
敏捷本身是为了面对需求的不断调整，帮助开发自己把握节奏，以给自己定迭代和mvp形式尽早呈现给用户，让用户反馈能尽早get到，避免无用功。这是“开发”要的敏捷，不是需求要“敏捷”。
但是在国内，这事情搞反了，变成了产品搞出“敏捷产品”这概念，把需求搞成了随时随地都要调整修改，完全没有规划的形式，美其名曰“敏捷”，开发变为外包。
我个人很同意这点，无论是过去做产品还是现在负责工具，其实让我感受到成就的不是某个功能被开发或者被我自己实现了，而是这个功能被用户用起来，而且用户反馈和我预期相符(得到了验证)，这时候我才会觉得这个需求/功能完成了。
写《人月神话》那本书作者后来又写了本
The Design of Design
的书，里面提到一个思路很不错。他说他最早也是跟着需求走，别人给什么需求他就怎么做，但是发现需求是做不完的。于是他停下来思考，认识到其实需求方真正的诉求并不是要他“完成需求”，而是要他帮助“验证需求”。
《人月神话》作者新作：The Design of Design
也就是说，实际上需求方/产品想做的东西一定是在不断调整变化的，作为开发，实际上你要做的并不是去完成需求，而是帮对方实现后并验证对方的想法。
但要做到开发+产品=共同设计验证需求思路，开发要有足够的(产品)结果导向意识，主动去改进产品设计和实现，产品自己也要足够open，认识到自己的需求文档并不是那么“天经地义”，而是在开发过程中和开发同学一起调整改进。
在这个基础上，才能去谈产品迭代和敏捷开发，不然还是走waterfall形式靠谱些。
这事也可能和项目规划有关，如果要总结的话，我认为敏捷是个纯粹开发者自己安排工作的事情，产品和pm都别掺合。需求走waterfall，任务走每周迭代。或者说对产品来说，考虑的是一个需求需要几个sprint(迭代)来实现，而每个sprint做什么，开发自己把握。
@Ferry.
敏捷开发强调的是响应变化的能力，在敏捷的模式里面我们提倡简单开发，以最快的速度实现功能，投入给用户使用并快速获得反馈来进行下一步的优化改进。
那么在快速实现的过程中必然会产生一些技术债务，因此在敏捷中另一个强调的点就是重构，两者相辅相成才能使速度与质量同时得到保证。
所以在一个迭代中除了业务需求之外也应该包含一定比例的技术需求，至于技术需求的占比可以与项目管理者进行协商，比如80%业务20%技术。否则当技术债务挤压到一定程度的时候，势必要付出更大的成本与代价。
3. “敏捷”需要多方共同努力
@Willy.
软件开发的本质是对知识建模，把我们对知识的理解，在虚拟世界里建模。建模的核心角色是我们开发人员，敏捷开发最初也是由一群软件开发人员提出来的。
但是我们现在提到敏捷开发，大家更多想到的是流程和会议，这会让我们觉得离开发人员很远。这主要是因为，在国内引入敏捷开发，更多的是由PM、QA这些角色主导的，他们更容易接受Scrum、kanban这些敏捷开发方法。Scrum和kanban入门比较容易，但是难以精通。所以很多情况下，给大家的印象只有流程和会议了。
有没有以开发人员为主导的敏捷开发方法呢？有的。那就是极限编程(extreme programming)，该方法更偏重于工程实践：简单设计、结对、TDD、重构。相对于Scrum和kanban，极限编程很难推广，因为工程实践太硬核了，入门比较难。但是好处是入门之后，就是一片坦途。
极限编程(extreme programming)
简单设计让我们可以快速开始，有了TDD和重构可以保持代码架构的整洁，结对让知识传递更容易，知识保存在团队中而不是个人的脑袋里。更有大家目前都号称在用的持续集成，让我们的代码可以快速上线，获得用户反馈。
欢迎广大程序员加入敏捷开发，从刻意练习极限编程的工程实践开始。
@Zoker.
基础设施决定上层建筑。
从个人经验来看，敏捷的缺点就是包含了一个隐含条件：标准的 2pizza 团队中，每个成员都是有所积累的、积极主动的、富有爱心的、乐于成事的。
纵观那些成功和失败的敏捷 case 中，除了外界因素的影响，很少有人提起团队配置，我们看到的都是海贼王中的草帽团、LOL 中的 IG、FPX、EDG，这都是高配团队，所以在考虑推进敏捷的时候，一定不要忽略了「人」这个最核心的因素。
我一直认为一个公司「最」骄傲的不应该是他们有什么厉害的产品，而是他们培养出了一批富有战斗力、创造力的团队，能够凝聚团队的力量解决任何事情，产品只是过程目标，优秀的团队才是最终目标。
@Chao.
真正敏捷的开发，很多时候恰恰建立在团队认可的规范的基础中，这个规范，不只是包括代码规范，还有流程规范。
举一个简单的例子，代码规范中第一个约束的就是缩进和缩进的空格数以及用tab还是whitespace。如果连这个都没有很好的约束的话，code review、code merge就会很成问题。更不用说其他的了。
目前公司内的一些开发流程也逐渐向一流的科技公司靠拢，而且公司内部也提供了非常好的代码平台，大家可以善用工具。
