敏捷最佳实践列表[已关闭]

我正在尝试定义我们将要使用的敏捷实践，并且我很难定义敏捷最佳实践列表。我希望我的列表更多地从技术角度（工程师的角度来看），并且应该定义SW工程师应该如何处理开发。该清单应尽可能与管理层相关。 如果重要，我们用c ++编程。 找到许多最佳实践相当容易，这是我迄今为止设法形成的列表： 重构 发布周期小 编码标准 集体所有权 系统隐喻 刨游戏 整队 Scrum每日会议 结对编程 测试驱动设计 行为驱动的发展 持续集成 代码和设计评论 活跃的利益相 文件迟到了 广泛使用设计模式 我们已经在使用列表中的一些实践。有些我们不打算用。 是否有可以添加到列表中的良好敏捷实践？ PS我可以根据要求添加一些小的实践描述。 编辑 正如我所说，我们已经在使用一些敏捷实践（主要是被证明是最好的实践）： 持续集成 - 这是非常好的做法。获得有关最新签到的快速反馈非常有用。因为有人打破了构建而导致停工时间非常令人沮丧，特别是如果它持续时间更长。 系统隐喻 - 它几乎没有帮助，因为具有描述性的类和函数名称有助于更好地理解代码 代码标准 - 我们在进入编码之前创建了编码标准。使用统一的代码样式是很好的，因为任何人都可以使用另一个代码并像它自己一样处理它。 TDD - 在开始编码之前，我们设置环境以便轻松创建单元测试，但直到最近我们才开始采用TDD原则。几年前我亲自尝试过它，并没有那么顺利，但现在我喜欢它。不幸的是，并非所有团队成员都这样做 - 只有半个团队。 Scrum每日会议 - 我们每天都在尝试会议，但是他们并没有那么顺利。除了我以前的工作，每天的会议通常会变成30多分钟的讨论。我想我们错过了好的scrum大师（或者领导者，怎么称呼？） 重构 - 我们进行了重构，但仅限于团队中的某个人创建了更改请求。我们并没有故意这样做：“让我们坐下来，减少我们的技术债务”。 小的发布周期 - 现在我们有很大的发布周期（6个月），而对于下一个版本，我们正计划将周期分解为4-6个内部版本。 代码和设计评审 - 我们进行了初步的设计评审（如5年前），并且在此期间很少有设计评论一些次要子组件。我们对某些课程进行了代码审查 文件迟到 - 我们为此版本做了。只需要的文档就意味着编写文档的编码越来越少。开发人员喜欢它:) 使用设计模式 - 我们已经在适当的地方使用了设计模式。 由于我们组织的结构，我们不能使用其他做法，但正如您所看到的那样，列表很长，而且您无法选择所有内容。 此外，现在我们只有4个软件开发人员，每个开发人员维护大约80千万卢比并开发新东西。因此，我们不能做例如结对编程或集体所有权。