问敏捷最佳实践列表

EN

我试图定义我们将要使用的敏捷实践，而且我在定义敏捷最佳实践列表时遇到了困难。我希望我的清单更多地从技术的角度(工程师的角度)，并应该定义SW工程师应该如何处理发展。这份清单应尽可能至少与管理层有关。

如果重要的话，我们正在用c++编程。

找到许多最佳实践是相当容易的，这就是我到目前为止所形成的列表：

1. 重构
2. 小释放周期
3. 编码标准
4. 集体所有制
5. 系统隐喻
6. 划船游戏
7. 全队
8. Scrum每日会议
9. 对编程
10. 测试驱动设计
11. 行为驱动发展
12. 连续积分
13. 代码和设计评审
14. 积极的利益相关者
15. 文件迟交
16. 设计模式的广泛使用

我们已经在使用列表中的一些实践。有些是我们不会使用的。

有什么好的敏捷实践，我可以添加到列表中吗？

如果需要的话，我可以添加一个关于实践的小描述。

编辑

正如我所说的，我们已经在使用一些敏捷实践(主要是证明是最好的实践)：

1. 持续集成--这是非常好的实践。获取最新签入的快速反馈是非常有用的。有一个停机时间，因为有人破坏了一个构建可能是非常令人沮丧的，特别是如果它持续更长时间。
2. 系统隐喻-它没有多大帮助，因为有描述性的类名和函数名有助于更好地理解代码。
3. 代码标准-我们在进入编码之前创建了编码标准。使用统一的代码风格是很好的，因为任何人都可以拿走他人的代码，就像自己的代码一样工作。
4. TDD --在开始编码之前，我们建立了一个环境，以方便地创建单元测试，但直到最近我们才开始采用TDD原则。我几年前就试过了，结果没那么顺利，但现在我喜欢了。不幸的是，并不是所有的团队成员都这么做--只有一半的团队。
5. Scrum每日会议--我们尝试了每天的会议，但没有进行得很好。和我以前的工作一样，每天的会议通常会变成30+分钟的讨论。我想我们错过了优秀的scrum大师(或者领导者，它是怎么称呼的？)
6. 重构--我们进行了重构，但前提是团队中的人创建了更改请求。我们并没有故意这么做：“让我们坐下来，减少我们的技术债务”。
7. 小版本周期-现在我们有大量的发布周期(6个月)，下一个版本我们计划将这个周期分解为4-6个内部版本。
8. 代码和设计评审--我们做了最初的设计评审(就像5年前)，在这段时间里很少对一些次要的子组件进行设计评审。我们对一些类进行了代码评审。
9. 文件写得太晚了-我们是为了这个版本才这么做的。只有所需的文档意味着编写文档越来越少，编码也越来越有趣。开发人员很喜欢它:)
10. 设计模式的使用-我们已经在适当的地方使用设计模式。

由于我们组织的结构，我们不能使用其他的实践，但是正如您可以看到的那样，列表很长，而且您不能选择所有的东西。另外，现在我们只有4名SW开发人员，每个开发人员都维护了大约80 kLOC，并且正在开发新的东西。因此，我们不能做例如对编程，或集体所有权。