《到底什么才是真正的敏捷开发？》这大概是很多技术同学都想知道的问题，那么什么是真正的敏捷开发呢？下面来听听鹅厂程序员的看法：1、从敏捷宣言和原则出发@Timo。敏捷宣言有四个价值陈述：个体和交互高于流程和工具。（个人和交互优于流程和工具。）工作软件优于详细文档。（工作软件优于综合文档。）客户合作高于合同谈判。（客户协作优于合同谈判。）响应变化高于遵循计划。（响应变化胜于遵循计划。）敏捷开发宣言但事实证明，这四个宣言都有局限性：优先考虑个人和交互是一个难以概括的概念。销售流程和工具要容易得多；与不切实际的计划和堆积如山的文档相比，工作软件更难生产；与客户合作需要信任和脆弱，这在商业环境中并非总是如此；对于那些既想控制又需要为企业制定长期计划的高管来说，应对变化往往不够重要。从我个人在前公司的经历来看：敏捷是一个契约，参与其中的人需要不断地调整、思考和迭代。同样的敏捷永远不可能是万能的，但要让团队运行在最合适的状态，需要所有参与者像你一样努力思考和探索，迭代敏捷自身的过程，但是很难。不当的“敏捷”容易带来诸多弊端，例如：容易造成开发人员被打断、缩短工作时间、增加压力、要求“工作速度更快”等，造成“被剥削感”。最终开发不那么敏捷，容易导致缺陷多，进度慢。最后，企业的效率甚至比没有实施敏捷之前还要低。归根结底，每个人都想成为“敏捷”，但敏捷的革命性思想与现实相去甚远。@加伦。理解敏捷，需要从敏捷宣言和它的12条基本原则来理解，然后再看几种主流的敏捷方法Scrum、SAFe、Less、SoS。敏捷宣言所遵循的原则充满了敏捷的人，他们甚至没有阅读基本的定义和原则。在我看来，大多数团队所说的敏捷开发就是级联。将敏捷方法理解为只需要开发参与就太过分了。事实上，敏捷方法支持产品的快速迭代交付。一个完整的产品团队拥有所有角色。所谓自己负责玩的非产品开发团队，其实是负责产品的。顺便提几个问题供大家思考：需求是否需要拆分？分裂的意义何在？如何做迭代计划？响应变更和变更控制是否矛盾？用最终的结果来形容敏捷带来的变化：敏捷团队支持的产品：细心的用户会发现产品的渐变；粗心的用户不会看到产品的变化，但体验感觉会越来越好。但是如果产品没有把握好节奏，用户就会抱怨怎么总是变来变去。瀑布团队支持的产品：用户明显发现产品有一步一步的变化，比如改版，也就是常说的焕然一新；用户有时会失去耐心。2、“敏捷”强调对变化的响应能力@Like。敏捷本身就是面对不断调整的需求，帮助开发者把握节奏，以迭代的形式尽快呈现给用户，为自己做mvp，让用户反馈尽快得到，避免无用的工作。这是“开发”所要求的敏捷性，而不是需求所要求的“敏捷性”。但在中国，这已经被扭转了，“敏捷产品”的概念被发展成产品，需求要随时随地调整修改，完全没有任何规划。成为外包。我个人同意这一点。以前做产品也好，现在做工具也好，让我觉得成功的不是某项功能是自己开发或实现的，而是这个功能是用户使用的，用户的反馈和我的期望是met（验证），才会觉得这个需求/功能完成了。《人月神话》这本书的作者后来写了一本书叫《设计的设计》，里面提到了一个很好的idea。他说，一开始他是跟着需求走的，别人让他做什么他就做什么，但他发现需求是无穷无尽的。于是他停下来思考，发现需求方真正的诉求并不是让他“满足需求”，而是让他帮忙“验证需求”。《人月神话》作者新作：TheDesignofDesign也就是说，其实需求者/产品想要做什么，就必须不断地调整和改变。作为开发者，你真正需要做的不是完成需求，而是帮助对方实现并验证对方的想法后。但是要做到开发+产品=需求思路的联合设计和验证，开发要有足够的（产品）结果导向意识，积极改进产品设计和实现，产品本身要足够开放，意识到自己的需求文档是不太好。“天经地义”，而是在开发过程中和开发同学一起调整和完善。只有在这个基础上才能谈产品迭代和敏捷开发，否则走瀑布形式更靠谱。这件事也可能与项目规划有关。如果要总结的话，我觉得敏捷就是开发人员自己安排工作的事情，products和pm不应该混在一起。需求经历瀑布，任务经历每周迭代。也就是说，对于产品来说，考虑的是一个需求需要经过若干个sprint（迭代）来实现，而每个sprint干什么是由开发本身决定的。@渡船。敏捷开发强调应对变化的能力。在敏捷模式中，我们提倡简单的开发，以最快的速度实现功能，投入用户使用并快速获得反馈，进一步优化和改进。那么在快速实施的过程中，难免会产生一些技术债，所以敏捷的另一个重点就是重构，两者相辅相成，既保证速度又保证质量。因此，在一次迭代中，除了业务需求，还应该包含一定比例的技术需求。至于技术要求的比例，可以和项目经理协商，比如业务80%，技术20%。否则，当技术债被挤压到一定程度时，势必付出更大的成本和代价。3.“敏捷”需要多方共同努力@Willy。软件开发的本质是对知识进行建模，对我们在虚拟世界中对知识的理解进行建模。建模的核心角色是我们的开发人员，而敏捷开发最初是由一群软件开发人员提出的。但是我们现在讲敏捷开发，更多的是想到流程和会议，这让我们感觉离开发人员很远。这主要是因为敏捷开发在中国的引入更多以PM、QA等角色为主，他们更容易接受Scrum、看板等敏捷开发方式。Scrum和看板相对容易上手，但很难掌握。所以很多时候，你得到的唯一印象就是流程和会议。是否有开发人员主导的敏捷开发方法论？一些。即极限编程（extremeprogramming），方法更偏向于工程实践：简单设计、结对、TDD、重构。与Scrum、看板相比，极限编程很难推广，因为工程实践太硬核，上手难度大。但好处是上手之后，一路顺风。极限编程的简单设计让我们可以快速上手。通过TDD和重构，代码结构可以保持干净。结对使知识转移更容易。知识保存在团队中，而不是在个人的头脑中。还有就是持续集成，大家号称在用，让我们的代码能够快速上线，得到用户的反馈。欢迎程序员加入敏捷开发，从刻意练习极限编程工程实践开始。@佐克。基础设施决定上层建筑。从个人经验来看，敏捷的缺点在于它包含了一个隐含的条件：在标准的2pizza团队中，每个成员都是积累的、积极主动的、有爱心的、愿意完成事情的。纵观成功和失败的敏捷案例，除了外部因素的影响，很少有人提到团队配置。我们看到的就是海贼王里面的草帽一伙，LOL里面的IG，FPX，还有EDG。这些都是高端团队，所以在考虑推进敏捷时，一定不能忽视“人”这个核心因素。我一直认为一个公司最“最”值得骄傲的不应该是他们有什么强大的产品，而是他们培养了一群有战斗力和创造力的团队，可以凝聚团队的力量去解决任何事情。产品只是过程的目标。一个好的团队是最终的目标。@超。真正的敏捷开发往往是基于团队认可的规范。这个规范不仅包括代码规范，还包括流程规范。举一个简单的例子，代码规范中的第一个约束就是缩进和缩进空格的个数以及是使用tab还是whitespace。如果连这点都约束不好，codereview和codemerge就会出很大的问题。其他的就更不用说了。目前公司内部的一些开发流程正在逐渐向一流技术公司靠拢，公司也提供了非常好的代码平台，大家可以好好利用工具。
