alm模型
这是有关重新启动ALM的系列文章中的第一篇。 我将在一周后在敏捷斯洛文尼亚展示此内容,请不要错过。
我已经开始考虑这些年来应用程序生命周期管理的变化。 这很有趣,因为他们在敏捷课程中教给您的第一件事是什么(我希望如此)?
“流程和工具上的个人和互动”
现在,我不会说这是一个完整的谎言,但是太多的经验表明,人们宁愿拥有流程和工具。 如果我们有这些,那么没有讨厌的人,我们就能解决任何问题。
顺便说一句,今天所谓的ALM是错误的。 现在的应用程序与我们在90年代所认为的完全不同。 我们今天建造的是产品。 不幸的是,PLM已经被采用。 在构建ALM软件之前,我们先构建了PLM软件。 当时,产品与库存,供应链和合同有关。 您可以用来创建产品的所有这些有形东西。 不像A字。
返回ALM。 我们已经开始从事80年代的大型项目,并需要管理工具。 尽管开发工具的范围越来越大,但其他部分却保持不变。
如果我们查看任何产品生命周期,无论是精益启动还是瀑布式生产,它的外观大致如下:
由于其起源和其他因素,ALM工具涵盖了“构建”圈子。 随着时间的流逝,添加了工具以支持测试,错误管理和跟踪需求。 但是它们仍然围绕“构建”区域。
随着时间的流逝,ALM涵盖了越来越多的功能,但从未超出Build部分。
下次,我们将讨论什么使ALM工具成为构建者的有用盟友。 之后,我们将讨论为什么他们可以通过使建造者的生活变得可怕来改善自己。 我们为什么还要重启?
敬请关注。
翻译自: https://www.javacodegeeks.com/2015/12/rebooting-alm-part-evolution.html
alm模型