Martin Fowler：敏捷软件指南
在过去的十年中，敏捷软件开发已经从一种狂热的技术逐渐成为主流。我很幸运地伴随了敏捷运动的始终，早期经历过孕育出极限编程的项目，并且也是敏捷软件开发宣言的作者之一。ThoughtWorks在2000年开始使用敏捷技术，从那以后，我们在全世界的项目中都成功地使用了敏捷技术。我们已经学习了大量关于在企业环境中使用敏捷方法的知识，并致力于分享这些知识以帮助促进它们被明智地采用。
敏捷软件开发的本质
自从敏捷方法的开发者们开始讨论他们的方法以来，已经有十多年了。在这个时候，敏捷思维已经从一个小众活动转变为一个被广泛使用的方法。然而，就像任何流行的技术一样，敏捷软件开发也受到了语义扩散的影响，所以我们在敏捷的名义下看到的很多东西与早期的先驱者所做的事情并没有太多相似之处。所以我认为重新审视敏捷思维的基本要素是很重要的。
我一直认为敏捷思维的本质与传统的计划驱动的软件工程有两个不同之处:
敏捷开发
• 更多是适应性而非预测性
• 以人为本而不是以过程为导向
计划驱动工程期望我们在开发之前提出一个预测计划。该计划为整个项目列出了人员、资源和时间表。软件设计也是预先完成的，实现应该符合这个设计。成功是根据开发如何遵循这个计划来衡量的。
敏捷计划是作为帮助我们控制变更的基线。敏捷团队的计划和传统团队一样仔细，但是计划会不断修改，以反映我们在项目中所学到的东西。成功是基于软件交付的价值。
计划驱动工程寻求的是一种过程，它提供足够的结构来消除人与人之间的差异。这样的工业化流程更容易预测，在人员变动时可以很好地工作，更容易定义技能和职业道路。
敏捷工程将软件开发主要视为的人的活动，其中所涉及的人员以及他们如何连接成为一个团队是成功背后的主要驱动力。过程(和工具)可以提高团队的效率，但影响是第二位的。
参考：
The New Methodology
Manifesto for Agile Software Development
Talk: Agile Essence and Fluency
____________________________________
技术实践
要使敏捷有用，您需要坚实的技术实践。很多敏捷教育都忽视了这一点，但是如果你忽视了这一点，你将无法获得敏捷开发所能带给你的生产力和响应能力(这将你困在敏捷流畅性模型中的第一个区域)。这也是为什么我仍然认为极限编程是敏捷方法中最有价值的核心和起点。
参考：
Refactoring Guide
Continuous Delivery Guide
Self Testing Code
Is Design Dead?
Code As Documentation
____________________________________
协作
改进人的协作是敏捷思维的核心。沟通和反馈是极限编程的两个重要价值，敏捷人希望在他们的项目中找到最大化这些价值的方法。
参考：
It's Not Just Standing Up: Patterns for Daily Standup Meetings
User Story
Conversational Stories
Frequency Reduces Difficulty
An Appropriate Use of Metrics
Remote versus Co-located Work
Using an Agile Software Process with Offshore Development
Customer Affinity
Outcome Oriented
____________________________________
问题
虽然敏捷思维可以帮助许多团队更有效地交付软件，但敏捷软件的世界远非没有问题。与任何流行的方法一样，语义扩散已经开始，导致许多事情以“敏捷”的名义进行，而这些事情与激励我们撰写宣言的想法几乎没有关系。
参考：
The State of Agile Software in 2018
Semantic Diffusion
Agile Imposition
Flaccid Scrum
Feature Devotion
原文：https://martinfowler.com/agile.html
有道翻译：http://fanyi.youdao.com/server/webtrans/share?fileID=f6d638d4be9d3fdad364219ba048d106&salt=1573037160120&product=fanyiguan
真北敏捷社群，求道、连接，汇通天下有识之士、友士之识。