process - 小口敏捷 : most bang for the buck

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

3年前关闭。




Improve this question




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

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

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

更新:您当前的 SDLC 是什么？
环境:本质上是“重启”。少数开发人员；具有 10^5-10^6 LOC 且在全局部署的数以万计的遗留产品；产品具有很强的相互依存性；多年来添加的重要功能，包括许多一次性的，无需重构；紧张的日程安排；肤浅的质量保证；没有验尸或“过程大师”。

典型工艺:

创 build 计/规范。由所有利益相关者审查。

编码一项或多项功能/修复。

修改设计/规范以应对意外情况。

测试功能，记录缺陷。

优先处理新的和剩余的任务。

修改设计/规范/时间表。

根据需要返回到步骤 2。

发布测试版，记录反馈。

根据需要返回到步骤 2。

正式发布。

感谢这么多有用的建议和见解!

Answer 1

迭代构建

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

每次构建完成后，我们都会与开发团队、QA 团队和产品管理团队坐下来，创建一份包含在新构建中的工作 list 。

然后每个人都帮助回答了下一个构建中应该包含什么的问题。

从那以后，我们添加了敏捷开发的许多其他功能(包括尝试实现 Scrum)，但没有什么比迭代构建更能让我们“物超所值”了。