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