小菜一碟的敏捷:最卖力的

Question

我们应该首先实施敏捷开发的哪个方面来改进我们的开发过程，为什么呢？

我所处的情况要求我“调整”我的流程，而不是重新设计它，而“敏捷”似乎是当今的口号。如果我们只能做一个能改善某些事情的改变--质量、上市时间、文件、透明度等等，什么才能产生最明显、最积极的影响？

如果我们选择正确，我们就能做出第二个选择。:-)

更新：您当前的SDLC是什么？

环境:本质上是“重新启动”。少数开发人员；具有10^5-10^6 LOC的遗留产品和部署在世界各地的数万个产品；产品相互依存；多年来添加的重要功能，包括许多一次性、w/o重构、严格的时间表、肤浅的QA、无死后或“流程大师”。

典型过程：

1. 创建设计/规范。由所有利益攸关方进行审查。
2. 编写一个或多个功能/修复程序。
3. 修改设计/规范，以应对惊喜。
4. 测试功能，记录缺陷。
5. 优先处理新的和剩余的任务。
6. 修改设计/规格/时间表。
7. 必要时返回到步骤2。
8. 发布测试版，记录反馈。
9. 必要时返回到步骤2。
10. 正式释放。

感谢这么多有帮助的建议和见解！

Answer 1

我非常喜欢混搭，也是开发过程的渐进式变化。我同意迭代开发应该是您的第一个目标，但是我认为您可以用更小的步骤来实现它。

根据我的经验，我建议您选择以下顺序--先选择您尚未完成的顺序：

• 先修好虫子。我希望我不必这么说。这是理智的呼唤，也要求有较短的周期。
• 一小步。培养实现最小变更的习惯，这是迈向下一个特性的一个明显步骤，然后编译和测试。在开始编写代码之前，将所有任务分解为<1h单元。目标是至少每15分钟建立一次功能代码。这不需要太多的基础设施改变--除了可能修复增量构建和拥有快速机器之外。

是!首先要确保开发人员拥有快速的机器。有多少更好的建议可以得到？！

• 建立每天的一切。设置从源代码管理到安装介质的双击完整生成，最好是在单独的PC上。这是实现频繁构建的第一步，但它们已经对自己有了很大的帮助。对我们来说，这是获得可靠的、可复制的构建结果的关键一步。
• 开始写作单元测试。不要为覆盖率而烦恼，不要强制执行“先写测试”，而是把框架放在适当的位置。编写新代码和更改的测试。然后用你每天的构建来运行它们。
• 短周期。现在是时候了，你已经有了所有的工具，可以每周或每两周在内部发布:代码库每天都处于可交付状态，构建是双击的，至少有一些东西在工作。

Answer 2

迭代构建

当我们转向在一致的基础上进行构建(在我们的例子中，每周或每周两次)，我们看到了最大的改进。

在生成每个构建时，我们与开发团队、QA团队和产品管理团队进行了协商，并创建了一个包含在新构建中的工作列表。

然后，每个人都帮助回答了下一个构建中应该包含哪些内容的问题。

从那以后，我们增加了许多敏捷开发的其他特性(包括尝试实现scrum )，但是没有什么比迭代构建给我们更多的“物有所值”了。

Answer 3

迭代开发在小的迭代中工作(比如2周)，在每一次迭代结束前准备好应用程序，也就是说，您的测试人员应该乐于将结果发布给您的客户。

这是核心。你可以以此为基础。