agile - 敏捷最佳实践列表

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并从事新工作。因此，我们不能执行例如配对编程或集体所有权。

最佳答案

首先，阅读Twelve Principles of Agile Software。

其次，从知道的知识中找出如何实现对您最重要的原则。

人们经常会犯这样的错误，即期望敏捷开发成为“白银子弹”或您需要遵循的一系列严格流程，这将使您的软件开发成功。

那不是应该的意思。您已经拥有15个“最佳实践”列表的事实使我有些害怕。不要太当真，也不要想得太多。如果发现缺少任何内容，请在下一次迭代中获取它。

关于agile - 敏捷最佳实践列表，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/4078688/