敏捷软件开发团队关于关键原则的26条至理名言

我经常收集各种各样的智慧。最近，我重温了敏捷开发的真正问题是什么？下面列出了指导敏捷软件开发团队的26条关键原则。

　　1.始终在签入前运行测试：本指南有助于您满足&ldquo；不要破坏构建&rdquo；指南

　　2.不断学习如何提高质量：这项工作永远不会结束，所以你应该始终关注可以改进的地方，收集发现和处理质量问题的案例。

　　3.为人而不是为系统设计：开发人员经常因为技术而误入歧途。永远不要忘记，设计的最终目标是帮助人们完成他们的工作。

　　4.测量，测量，测量：敏捷开发有助于处理未来的不确定性，但不应该存在关于过去的不确定性。试验应连续进行，并应测量和记录每次运行的性能。

　　5.完成一件事后，再开始另一件事：在厨房的比喻中，它是“厨房”；先上这道菜，然后开始下一道菜。软件开发的最大问题是同时启动几件事情，这将不可避免地导致一些工作被放弃，造成浪费。专注于一件事，完成它的功能，运行测试，编写文档，全部签入，作为一项工作完成它，然后开始下一件事。

　　6.不要破坏构建：这很明显，但它必须包含在任何软件开发建议列表中。在签入之前采取所有适当预防措施进行测试的程序员永远不会破坏构建。如果一个构建被破坏，通常是因为有人懒惰。

　　7.不要在用例需要之前添加数据成员：同上，但这是从类的数据成员的角度考虑的。似乎很明显；发货地址&rdquo；是&ldquo；客户&rdquo；记录，但在有用的示例明确要求提供发货地址之前，不应实施该功能。

　　8.所有团队成员都应该理解客户的需求：大型复杂项目必须分解成独立的团队，然后分配给开发人员。然而，在这个范围内不应该做的是失去对最终项目真正用户的期望和目标的关注。

　　9.在需要用例之前不要实现程序：当你实现一个特定的类时，你应该记住一个特定的用例，并且只实现用例所需的方法。您可以考虑这个类的潜在功能，并将其写在注释中，但在真正需要用例之前，您不应该实现它。

　　10.在编写代码之前编写测试：测试本身可以用来说明您真正需要的设计。设计缺陷通常是通过测试用例发现的。在编码之前，考虑一下通过这些用例可以节省多少时间。然而，为用例1编写测试，然后编写代码，然后启动用例2。

　　11.不要害怕做决定，不要害怕改变以前的决定：敏捷开发就是要对改变做出反应，并迅速做出反应。关于你最初的发展没有完整的信息。你应该尽可能推迟决定，直到你必须做出决定。没有信息，你就无法支持你的决定。相反，根据有效信息做出最佳决策。有了新的信息，不要害怕改变你以前的决定。（有些“恐龙”称之为摇摆不定，但我称之为响应环境）

12测试是产品的一部分：许多开发人员和经理认为产品就是交付给客户的东西，而其他一切都不那么重要。测试应该被视为产品的一个真实部分，在设计中值得仔细考虑，甚至在许多情况下，与产品一起交付给客户。（后一部分是有争议的，但作为软件交付的一部分，内置测试只占用微不足道的空间，并在必要时提供明显的好处，这应该得到考虑。）