As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened,
visit the help center提供指导。
已关闭8年。
我正在尝试定义我们将要使用的敏捷实践，并且很难定义敏捷最佳实践的列表。我希望从技术 Angular (从工程师的 Angular )出发，列出更多信息，并应定义软件工程师应如何进行开发。该列表应至少与管理层相关。
如果重要的话，我们正在用c++编程。
找到许多最佳实践很容易，这是我到目前为止设法形成的列表:
重构小发布周期编码标准集体所有权系统隐喻平面游戏整个团队 Scrum日常 session 配对编程测试驱动设计行为驱动的开发持续集成代码和设计评论积极的利益相关者文件后期广泛使用设计模式我们已经在使用列表中的一些做法。一些我们将不使用。
我可以添加到列表中的良好敏捷实践吗？
附言:如果需要，我可以添加一些实践描述。
编辑正如我所说的，我们已经在使用一些敏捷实践(大多数实践证明是最好的):
持续集成-这是非常好的做法。获得有关最新签到的快速反馈非常有用。由于某人破坏了构建而造成的停机时间可能会非常令人沮丧，尤其是持续时间更长的时候。 系统隐喻-毫无用处，因为具有描述性的类和函数名有助于更好地理解代码代码标准-在开始编码之前，我们创建了编码标准。使用统一的代码样式是很好的，因为任何人都可以拿别人的代码并像独自操作一样对其进行处理。 TDD-在开始编码之前，我们设置了易于创建单元测试的环境，但是直到最近我们才开始采用TDD原理。几年前我亲自尝试过，但效果并不理想，但现在我喜欢它。不幸的是，并非所有团队成员都在这样做-只有一半团队。 Scrum每日 session -我们尝试了每日 session ，但进展不太顺利。和我以前的工作一样，日常 session 通常变成30分钟以上的讨论。我想我们错过了优秀的Scrum Master(或领导者，怎么称呼它？)重构-我们已经进行了重构，但前提是团队中的某人创建了变更请求。我们并非故意这样做:“让我们现在坐下来，减少我们的技术债务”。 较小的发布周期-现在我们有巨大的发布周期(6个月)，对于下一个发行版，我们计划将其分成4-6个内部发行版。 代码和设计审查-我们进行了初始设计审查(例如5年前)，在此期间，很少对一些次要组件进行设计审查。我们做了一些类的代码审查
文档太晚-我们在此发行版中做到了。仅需要的文档意味着编写文档越来越少而有趣。开发人员喜欢它:) 设计模式的使用-我们已经在适当的地方使用设计模式。 由于我们组织的结构，我们不能使用其他实践，但是您可以看到列表很长，您不能选择所有内容。
而且，现在我们只有4个SW开发人员，每个开发人员维护大约80 kLOC并从事新工作。因此，我们不能执行例如配对编程或集体所有权。