敏捷的小叮当:最让人感到震惊

我们应该首先实施哪些敏捷开发的单一方面来改进我们的开发过程,为什么？

我处在一种情况,要求我"调整"我的过程,而不是重新设计它,而"敏捷"似乎是当时的口头禅.如果我们只做一个可以改进某些事物的改变 - 质量,上市时间,文档,透明度等,那么最明显的积极影响是什么？

如果我们选择正确,我们将能够做出第二选择.:-)

更新: 您目前的SDLC是什么？
环境:基本上是"重启".一个小的开发商屈指可数; 传统产品,10 ^ 5-10 ^ 6 LOC,全球部署数万台; 产品是相互依存的; 多年来增加的重要功能,包括许多一次性,不进行重构; 紧张的时间表; 表面质量保证; 没有验尸或"流程大师".

典型流程:

创建设计/规格.所有利益相关者审查.

编写一个或多个功能/修复程序.

修改设计/规格以解决意外情况.

测试功能,记录缺陷.

确定新任务和剩余任务的优先级.

修改设计/规格/时间表.

必要时返回步骤2.

发布测试版,记录反馈.

必要时返回步骤2.

官方发布.

感谢您提供了许多有用的建议和见解!

迭代建筑

当我们开始建立一致的基础(在我们的情况下每周或每周两次)时,我们看到了最大的改进.

在生成每个构建时,我们与开发团队,QA团队和产品管理团队坐下来,并创建了新构建中包含的工作列表.

然后每个人都帮助回答了下一个版本中应包含的内容的问题.

我们已经添加了敏捷开发的许多其他功能(包括尝试在字母中实现scrum),但没有任何东西给我们带来像迭代构建一样多的"砰砰作响".

迭代开发.在小的迭代(比如2周)中工作,在每次迭代结束时都有"准备好"的应用程序,即您的测试人员应该乐意将结果发布给您的客户.

这是核心.你可以在此基础上建立.