我们应该首先实施哪些敏捷开发的单一方面来改进我们的开发过程,为什么？
我处在一种情况,要求我"调整"我的过程,而不是重新设计它,而"敏捷"似乎是当时的口头禅.如果我们只做一个可以改进某些事物的改变 - 质量,上市时间,文档,透明度等,那么最明显的积极影响是什么？
如果我们选择正确,我们将能够做出第二选择.:-)
更新: 您目前的SDLC是什么？
环境:基本上是"重启".一个小的开发商屈指可数; 传统产品,10 ^ 5-10 ^ 6 LOC,全球部署数万台; 产品是相互依存的; 多年来增加的重要功能,包括许多一次性,不进行重构; 紧张的时间表; 表面质量保证; 没有验尸或"流程大师".
典型流程:
感谢您提供了许多有用的建议和见解!
迭代建筑
当我们开始建立一致的基础(在我们的情况下每周或每周两次)时,我们看到了最大的改进.
在生成每个构建时,我们与开发团队,QA团队和产品管理团队坐下来,并创建了新构建中包含的工作列表.
然后每个人都帮助回答了下一个版本中应包含的内容的问题.
我们已经添加了敏捷开发的许多其他功能(包括尝试在字母中实现scrum),但没有任何东西给我们带来像迭代构建一样多的"砰砰作响".
我非常喜欢混合搭配以及开发过程的渐进式改变。我同意迭代开发应该是您的首要目标，但我认为您可以通过更小的步骤来实现它。
根据我的经验，我会推荐以下顺序 - 选择您尚未执行的第一个：
首先修复错误。我希望我不必这么说。这是理智的呼唤，也要求更短的周期。
小步骤。培养实现最小更改的习惯，这是迈向下一个功能的可见步骤，然后进行编译和测试。在开始编码之前，将所有任务分解为 <1 小时的单元。目标是至少每 15 分钟编写一次可构建的功能性代码。这不需要太多的基础设施改变——除了修复增量构建和拥有快速机器之外。
是的！首先确保开发人员拥有快速的机器。还能得到多少更好的建议？
每日构建一切。设置从源代码管理到安装介质的双击完整版本，最好是在单独的 PC 上。这是频繁构建的第一步，但它们本身已经有很大帮助。对于我们来说，这是获得可靠、可重现的构建结果的关键一步。
开始编写单元测试。暂时不要担心覆盖率，不要强制执行“首先编写测试”，而是将框架放在适当的位置。为新代码和更改编写测试。然后在日常构建中运行它们。
周期短。现在是时候了，您已经准备好所有工具来每周或每两周进行一次内部发布：代码库每天多次处于可交付状态，只需双击即可进行构建，并且至少有一些功能正在运行。