我正在尝试定义我们将要使用的敏捷实践，并且我很难定义敏捷最佳实践列表。我希望我的列表更多地从技术角度（工程师的角度来看），并且应该定义SW工程师应该如何处理开发。该清单应尽可能与管理层相关。
如果重要，我们用c ++编程。
找到很多最佳实践相当容易，这是我到目前为止所形成的列表：
我们已经在使用列表中的一些做法。有些我们不打算使用。
我是否可以添加到列表中的敏捷实践？
PS如果需要，我可以添加一些小的实践描述。
修改
正如我所说，我们已经在使用一些敏捷实践（主要是那些被证明是最好的实践）：
由于我们组织的结构，我们不能使用其他做法，但正如您所看到的那样，列表很长，而且您无法选择所有内容。 此外，现在我们只有4个软件开发人员，每个开发人员维护大约80千万卢比并开发新东西。因此，我们不能做例如结对编程或集体所有权。
答案 0 :(得分：20)
首先，请阅读Twelve Principles of Agile Software。
其次，从你所知道的如何实现对你最重要的原则中找出答案。
人们经常犯错误，希望敏捷开发成为一个Silver Bullet或一套严格的流程，您需要遵守这些流程才能使您的软件开发成功。
这不是它的意思。您已经拥有15个“最佳实践”列表这一事实让我感到有些害怕。不要太认真，不要过度思考。如果你发现你错过了什么......在下一次迭代中得到它。
答案 1 :(得分：16)
This text总结了所有敏捷最佳实践（带链接）：
的要求
- 产品愿景/愿景声明
- 产品Backlog
- 用户故事
- 用例
- 使用场景
- 人物角色
- 规划扑克
要求优先顺序
的设计
- 建筑尖峰/尖峰解决方案
- 领域驱动设计
- 紧急设计/进化设计
- CRC卡
- 按合同设计
- 系统隐喻
的构建
- 编码风格/编码指南/编码标准
- 测试驱动开发
- 行为驱动的发展
- 配对编程/配对
- 重构
- 集体代码所有权
- 每日构建/自动构建/十分钟构建
- 持续集成
- 代码评论/同行评审
- 软件指标/代码指标＆amp;分析
- 源控制/版本控制
- 问题跟踪/错误跟踪
- 配置管理
- 频繁交付/频繁发布
的测试
- 单元测试
- 烟雾测试/构建验证测试
- 综合测试
- 系统测试
- 探索性测试
- 测试自动化
- 故事测试/验收标准/验收测试
<强>过程
- 时间框/固定短跑/固定迭代长度
- 发布计划
- 迭代计划/规划游戏/ Sprint计划
- Sprint Backlog
- 任务委员会
- 完成/完成的定义
- 每日站立会议/每日Scrum
- 速度
- Sprint评审/迭代演示
- 价值流图制作
- 根本原因分析/ 5为什么
- 烧毁图表/烧毁图表
- 大型可见图表/信息散热器
- 回顾/反思研讨会
<强>组织
- 小团队
- 跨职能团队
- 自组织团队/ Scrum团队
- 共同团队/坐在一起/共同工作区
- 现场客户/产品负责人
- Scrum Master
- 可持续发展的步伐
- 让人们四处移动
- Scrum of Scrums
答案 2 :(得分：14)
我现在正在阅读“成功与敏捷”。在第2章中，Mike Cohn对建立任何类型的“最佳实践”提出了可怕的警告：
“当转换到Scrum时...收集最佳实践是危险的。就像警报器从岩石中向我们唱歌一样，最佳实践诱使我们放松并停止对Scrum必不可少的持续改进的努力......尽管团队成员应该总是希望彼此分享他们新发现的良好工作方式，他们应该抵制将它们编成一套最佳实践的冲动......“
他继续引用丰田的大野太一：
“...有一种称为标准作品，但标准应该不断改变。相反，如果你认为标准是'你能做到的最好'，那就完全...... [如果我们确定]最好的方式，改善[持续增量改进]的动机将会消失。“
归因：Succeeding with Agile: Software Development Using Scrum, Mike Cohn, 2010
答案 3 :(得分：4)
您可以添加的一些非常重要的事情是：
自我管理团队 - 指“最佳架构，要求和设计 从自组织团队中脱颖而出“
回顾 - 指的是“团队定期反思如何 变得更有效，然后调整和调整 相应的行为“
简化设计解决方案，最大限度地减少工作量
答案 4 :(得分：4)
制定最佳实践列表似乎是BDUF的敏捷过渡。如果你想变得敏捷，那就试着以灵活的方式到达那里。
您当前流程的最严重问题是什么？你可以改变什么来解决这个问题？试一试，看看它是如何运作的。
冲洗并重复。
并以团队的形式完成所有这些工作。
编辑：
有些事情在评论中难以理解，所以我会在这里扩展一些评论：
我认为问题在于有些人拒绝编写单元测试，但在我看来，单元测试提供了更大的安全网。不知道该怎么办。
测试覆盖率差实际上是一个负面的解决方案而不是实际问题。
如果您的测试覆盖率不佳，那么您可能会提供带有错误的软件，或者在不引入错误的情况下进行更改很困难且耗时。这些都是问题。
如果人们拒绝写测试，他们或者不相信有问题，他们不相信写单元测试会解决它，或者他们不关心。
要做的最好的事情就是与团队聚在一起，决定问题是什么，并就试图改进的事情达成一致。
如果您的团队成员对改进不感兴趣，那就是一个更大的问题。您仍然应该尝试将其作为一个整体团队来解决，但这很困难，您可能需要一些管理帮助。
正如我已经提到的，我们已经成功地使用了一些敏捷实践，但也许有新的更好的方法。我要做的是重新评估我们的工作方式。
好。这基本上就是我建议你应该做的事情，但是作为一个团队来做，并专注于解决已发现的问题，而不是试图列出最佳实践。
答案 5 :(得分：2)
我相信你的清单相当完整。您可以为每次迭代添加“清晰且固定的范围”，因为我经常在实践中看到问题 - 尽管有人可能认为它只是“小发布周期”的一部分。
另外，我会将“小发布周期”和“重构”列为单独的点 - 它们相当独立。
无论如何，我不会过分担心“缺少”敏捷的一部分。敏捷方法的一个重要特性是它们不是全有或全无 - 你可以从一个适合你的部分开始，然后逐渐增加。有些做法确实相互依赖（例如重构和集体代码所有权），但大多数可以独立使用。
答案 6 :(得分：2)
要添加的其他一些想法，尽管有些想法可能隐含在其他实践中：
请记住，每个都可以按照自己的方式进行自定义，这是一个重要的方面，因为如果对您的情况没有用，那么对于练习过于虔诚并不一定是好事。
Sprint评论与Sprint Retrospectives不同，至少在我看来。审核是向其他人（通常是利益相关者）展示sprint中完成的内容，以获取反馈并使用可能来自产品的新项目更新产品待办事项。回顾展是团队开会讨论什么进展顺利以及下一个冲刺可以改进的地方，这与我的想法略有不同。
答案 7 :(得分：0)
Scrums以及因此而发生的冲刺。
不是模糊，但无论如何都值得链接到解释。
答案 8 :(得分：0)
“敏捷”或“敏捷软件开发”不是一种单一的方法。这是一个总括性术语，涵盖了您可能选择持有的“价值”集合。两种不同的方法既可以“敏捷”又可以在你应该或不应该做的实践中相互冲突。
“敏捷”没有明确的定义 - 所以不可能制定明确的“敏捷实践”清单。
a definitive list of the basic Extreme Programming Practices （即您必须采取的措施才能满足“执行XP”的基本定义。）
做Scrum还需要做很少的事情（虽然这不是很有用，因为对于特定的工程实践完全没有任何意义。）