我们应该首先实施哪些敏捷开发的单一方面来改进我们的开发过程,为什么？
我处在一种情况,要求我"调整"我的过程,而不是重新设计它,而"敏捷"似乎是当时的口头禅.如果我们只做一个可以改进某些事物的改变 - 质量,上市时间,文档,透明度等,那么最明显的积极影响是什么？
如果我们选择正确,我们将能够做出第二选择.:-)
更新: 您目前的SDLC是什么？
环境:基本上是"重启".一个小的开发商屈指可数; 传统产品,10 ^ 5-10 ^ 6 LOC,全球部署数万台; 产品是相互依存的; 多年来增加的重要功能,包括许多一次性,不进行重构; 紧张的时间表; 表面质量保证; 没有验尸或"流程大师".
典型流程:
创建设计/规格.所有利益相关者审查.
编写一个或多个功能/修复程序.
修改设计/规格以解决意外情况.
测试功能,记录缺陷.
确定新任务和剩余任务的优先级.
修改设计/规格/时间表.
必要时返回步骤2.
发布测试版,记录反馈.
必要时返回步骤2.
官方发布.
感谢您提供了许多有用的建议和见解!
迭代建筑
当我们开始建立一致的基础(在我们的情况下每周或每周两次)时,我们看到了最大的改进.
在生成每个构建时,我们与开发团队,QA团队和产品管理团队坐下来,并创建了新构建中包含的工作列表.
然后每个人都帮助回答了下一个版本中应包含的内容的问题.
我们已经添加了敏捷开发的许多其他功能(包括尝试在字母中实现scrum),但没有任何东西给我们带来像迭代构建一样多的"砰砰作响".
迭代开发.在小的迭代(比如2周)中工作,在每次迭代结束时都有"准备好"的应用程序,即您的测试人员应该乐意将结果发布给您的客户.
这是核心.你可以在此基础上建立.
京公网安备 11010802040832号 | 京ICP备19059560号-6 