alm模型_重新启动ALM，第二部分：电源

alm模型

这是“重新启动ALM”系列的第二部分。 查阅第一部分“ Evolution ”，了解我们如何到达这里。 （看看我做了什么？）。

我认为，启动ALM工具链的第一个工具是源代码控制。 有编译器和一些IDE，但是源代码控制系统是团队合作的解决方案。 如果您考虑一下，“管理”的需求实际上不适合单人项目。 源代码控制是团队合作的第一步，因此是一个机会。

随着开发团队开始合作，ALM工具集在有意义的地方发展了更多。 每当我们需要加快速度时，它就在那里。 自动化是ALM工具的关键。 自动化构建和自动化测试，收集信息并进行报告，如今，自动化部署。 ALM工具确实擅长删除手册并将其变为自动。

但不仅仅是自动化。 代码和测试存储库是开发的核心。 它们是有关产品知识的一部分。 由于ALM工具涵盖了更多的开发操作，例如需求和测试管理，因此它们成为（或希望成为）产品开发知识库的一站式服务。 尚未有工具掌握这一点（但是），但是人们仍然会去寻找表示不同版本，带有注释的提交，需求演变和变更请求的分支和标签。 这些工具现在包括项目管理和跟踪报告。 每条信息都与所有需要的项目相互关联：对代码进行测试以测试状态错误的要求等等。

在头几年，只有工具。 但是，随着供应商了解客户的需求，他们改进了支持他们的工具。 IBM，Microsoft，HP和其他公司拥有庞大的客户群，收集的信息确定了工作模式。 一些模式成为主导。 首先，出现了用于变更请求和错误管理的模板。 后来，由于它们涵盖了开发周期的更多部分，因此我们开始看到项目配方。 起初这些是瀑布式的。 如今，它们以敏捷为中心，我们开始看到“缩放”模板。 这里有一个合理的假设（尽管并不总是正确的），即如果有很多人使用它们，那么逻辑上也应该建议其他用户使用它们。

最后一个难题是，通过在已知模板中处理项目，工具现在不仅可以提供有关如何进行工作的建议，还可以提供如何进行度量的建议。 的确，当系统保存所有这些数据时，很容易跟踪错误和修复之间的时间，在sprint中产生多少项或测试覆盖的代码范围。 剩下的就是报告它，甚至根据ALM工具开发中积累的集体知识提出建议。

一旦供应商在一个大盒子中有了提高生产力的工具，配方，度量标准和所有功能，他们就会获得成功的产品。 谁不想要这个？ 但是，强大的力量会带来极大的烦恼。 我们将在下一部分中讨论这些内容。

（如果您不愿意等待，请访问敏捷的斯洛文尼亚 ，我将在此详细介绍该主题）。

翻译自: https://www.javacodegeeks.com/2015/12/rebooting-alm-part-ii-power.html

alm模型