我们应该首先实施敏捷开发的哪个方面来改进我们的开发过程，为什么？
我的处境需要我“调整”我的流程，而不是重新设计它，而“敏捷”似乎是当今的口头禅。如果我们只能做出一项改变来改善某些东西——质量、上市时间、文档、透明度等，那么什么会产生最明显、最积极的影响？
如果我们选择正确，我们将能够做出第二选择。:-)
更新： 您当前的 SDLC 是什么？
环境：本质上是“重启”。少数开发人员；具有 10^5-10^6 LOC 并在全球部署数万个的遗留产品；产品具有很强的相互依存性；多年来添加的重要功能，包括许多一次性的，没有重构；时间紧迫；表面质量保证；没有验尸或“过程大师”。
典型流程：
感谢您提供这么多有用的建议和见解！
迭代构建
当我们开始在一致的基础上进行构建时（在我们的例子中是每周或每周两次），我们看到了最大的改进。
每次构建完成后，我们都会与开发团队、QA 团队和产品管理团队坐下来，并创建一个包含在新构建中的工作列表。
然后每个人都帮助回答了下一个构建中应该包含什么的问题。
从那以后，我们添加了敏捷开发的许多其他特性（包括尝试实施 Scrum），但没有什么比迭代构建更能“物有所值”了。
迭代开发。在小迭代中工作（比如 2 周），在每次迭代结束时“准备好”应用程序，即您的测试人员应该乐于将结果发布给您的客户。
这是核心。你可以以此为基础。
请参阅有关管理测试驱动和/或敏捷开发的最佳具体“操作手册”？.
我的建议是先从 TDD 开始。这很容易做到，并且对质量有深远的影响。
这有几个部分。
每个人都必须获得工具（JUnit 或其他任何东西——这在某些文化中可能很难。）
经理必须要求完成测试。他们绝不能（永远）规避单元测试。一旦有人说“那些测试无关紧要，无论如何都要发布它”，你就破坏了 TDD 带来的所有好处。
你必须通过测试用例来管理：写了多少，通过了多少。您必须通过测试用例定义功能：特性 [X] 有 [n] 个测试用例，其中一些已经完成，一些正在处理中。
我非常喜欢混搭，以及开发过程的增量变化。我同意迭代开发应该是你的首要目标，但我认为你可以更小的步骤来实现它。
根据我的经验，我会推荐以下顺序 - 选择你还没有做的第一个：
首先修复错误。我希望我不必这么说。这是理智的召唤，也需要更短的周期。
小步骤。培养实现最小更改的习惯，这是迈向下一个功能的明显步骤，然后编译和测试。在开始编码之前，将所有任务分解为小于 1 小时的单元。至少每 15 分钟编写一次可构建的功能代码。这不需要太多的基础架构更改 - 除了可能修复增量构建并拥有快速机器。
是的！首先确保开发人员拥有快速的机器。能得到多少更好的建议？！
每日构建一切。设置从源代码管理到安装介质的双击完整版本，最好是在单独的 PC 上。这是频繁构建的第一步，但它们本身已经有很大帮助。对我们来说，这是获得可靠、可重现的构建结果的关键一步。
开始编写单元测试。不要为覆盖而烦恼，不要强制“先编写测试”，而是将框架放在适当的位置。为新代码和更改编写测试。然后使用您的日常构建运行它们。
短周期。现在是时候了，您拥有所有工具，可以每周或每两周进行一次内部发布：代码库每天多次处于可交付状态，只需双击即可进行构建，至少有些东西正在工作.
与程序员、测试人员、技术作家和可能的销售/服务人员一起组成一个跨职能团队。让他们意识到“完成”的概念，即要完成的东西是经过编写、测试、记录、安装、部署并准备好供客户使用的东西。
这很重要，因为除非来自不同职能领域的每个人都聚在一起并专注于为客户提供东西的单一目标，否则您无法实现敏捷框架的任何其他方面。
敏捷现在是一个流行词，但请记住，它不是灵丹妙药；它不会像那样修复您的开发过程。您可能想阅读Steve Yegge 关于敏捷开发的优秀文章以平衡炒作。
如果您不掌握敏捷的核心，那么“挑选”敏捷开发的某些方面可能会很困难。敏捷最重要的是一种思考方式：保持灵活性，接受事情会发生变化，在短期迭代中编写代码，专注于完成一个或几个功能。与获得一个单一的、完整的、单一的规范、编写所有代码、文档然后发布它相反。
如果你想证明敏捷开发是有效的，我可能会投票支持使用 sprint 来展示“尽早发布，经常发布”的含义。
完全取决于你现有的流程，但我会告诉你，我们所做的最好的举措之一是了解项目积压和每日 3 个问题的概念（自从我们上次见面以来你做了什么？你打算做什么？今天继续工作？阻碍你前进的障碍是什么？）早上开会，看看我们在哪里以及我们可以做些什么来朝着我们的短迭代周期终点前进。
很高兴能够看到要完成的动态积压工作以及现在正在处理的工作以及将使其进入下一次迭代的工作。能够了解各个开发人员的位置并帮助他们消除前进的任何障碍是件好事。它可以防止开发人员陷入困境。
无论如何，这是我的想法。它对我们有用。
如果您还没有这样做，请从单元测试开始。如果您进行单元测试，请切换到测试驱动开发。这些都很容易添加到现有流程中，并且会立即获得回报。当您准备好应对流程变更时，请引入迭代开发。如果您当前的流程已经是迭代的，那么开始频繁地向客户发布您的迭代以获得反馈。
如果我必须总结“敏捷”的方式，我会说尽早并经常提供高质量的商业价值。上述做法将使您在这条道路上走得很远。
[编辑] 我想我的建议是采用敏捷方法来采用敏捷方法，并从立即提供大量价值的简单事物开始。
在自动化构建中运行的自动化测试。
我会尝试使用测试驱动开发。这会给你很多东西：
[*] - Kent Beck 在这个领域提到了影响图。在影响图中，节点之间的箭头表示第一个节点的增加意味着第二个节点的增加。带圆圈的箭头表示第一个节点的增加意味着第二个节点的减少。
-----> [Stress] <--o-- / --o--> [RunTests]
你感到的压力越大，你做的测试就越少。你做的测试越少，你犯的错误就越多。你犯的错误越多，你的压力就越大。重复...
如何解决这个导致压力过大的开发人员一段时间后不信任自己的代码的循环？
测试先开发改变影响图：
[TestFirst] <--o-- / --o--> [Stress]
你做的第一次开发测试越多，你感受到的压力就越小。您感到的压力越小，您进行的首次开发测试就越多。
这可以更好地测试由信任其代码的开发人员开发的代码。
除了已经提供并且我同意的所有好的建议之外，我建议通过自动、可重复的测试来加强 QA。投资自动化将使您在更改已部署的代码时更加自信。
在实现新功能的同时为新功能创建回归套件。
QA 可以使用探索性测试作为替代方法来查找开发过程中的漏洞。
我认为敏捷的两个最有价值和最容易实现的方面是
每日站立会议 - 与团队进行简短的每日会议以审查状态。使用 3 个问题。避免串音、喋喋不休和唠叨。保持快速和准确。
有时间限制的迭代——将项目分成两到三周的周期，迫使你在合理的期限内努力实现可管理的目标