什么是ALM及可追踪性？
如果你是一个软件开发者，很多公司（包括本人的）都会想向你推销东西。
如果平时翻阅杂志、参加会议或者浏览网站，你多半曾经看到过他（我）们的推销手段。
那些广告中往往都会有一个词叫做"ALM"，可曾想过它代表什么含义？
它的全称是应用程序生命周期管理（Application Lifecycle Management）。
我这样解释了以后你是不是感觉好多了？ :-)
ALM正是一个我所谓的“绝境”缩写词。就像所有的缩写词一样，如果你没有看到它的全称，你永远不知道它的含义。但如果它是“绝境”缩写词，就算你找到了全称，可你却仍然不能明白其含义。无路可走，陷入绝境。
我们这些软件开发者往往倾向于创造“绝境”缩写词。比如，SOA的全称是"Service Oriented Architecture"（面向服务的架构），但我还是不能理解这是什么意思。
窃以为，“绝境”缩写词都是某些人强行捏造出来的。他们违背了单词的“意愿”硬生生创造出来一个缩写词。Indigo并不希望成为WCF，它只想继续做Indigo。（译注：Indigo是微软响应SOA所提出的开发框架，主要基于其.net技术，后被更名为Windows Communication Foundation，简称为WCF。原因多半是微软在同一时期推出了几个的Windows xxx Foundation，试图形成一个响当当的WxF系列）
“绝境”缩写词，我们所献给这个世界的“特殊”礼物。
回到正题，ALM到底是什么？深入一点来看，它的全称给我们提供了一些线索：
所以，我们可以把ALM翻译为“对整个软件开发过程进行管理”（Managing The Whole Software Development Process）。
我看"MTWSDP"这个缩写或许都没"ALM"这么饶舌吧。
糟糕的是，我们仍然没能对其含义有更多了解，怎样才能走出这个困境呢？
什么是ALM?
从现在开始，可以朝两个方向对ALM进行定义。
我相信ALM的精华一定在于其宏观角度，在于项目经理通过使用真正完全整合的一系列工具来管理软件的整个开发周期，而从中得益。我选择森林方向对ALM进行定义，也就是全局视角。
到现在为止写了有500个字了吧，但好像什么也没说清楚。现在我该说的更明白一些了。
在此之前，我首先要告诉你本文并不会给出ALM的完整定义。我接下去所将要关注的只是其中某一点：可追踪性。
我们来看一个例子。
Joe是"糟糕软件公司"的技术支持代表，他们公司销售CRM解决方案。一个客户正在说他们的系统从6.0版升级到7.0之后就变得很慢。为了解决这个问题，Joe拜访了Sally，项目经理。
Joe: 有客户说7.0版比6.0慢很多。
Sally: “很多”是多少？
Joe: 打开首页原先只要1秒，现在需要30秒。
Sally: 那真的挺多，有多少客户发生这个问题？
Joe: 有一些，大概12个左右，目前为止。
调查开始，Sally打开了集成开发环境开始寻找，她发现数据库结构有些问题。
Sally: 这里有点奇怪。
Joe: 是什么?
Sally: 有人在7.0开发版本中修改了数据库的表结构。在6.0和之前的版本里，每个“人”只能和一个“公司”关联，事实上人员信息表(People)有一列外键对应到公司表（Company）。但7.0里面有人增加了一个叫PersonCompanyAssoc的表，这样每个“人”就可以关联多个“公司”了。
Joe: 哦，那么会怎么样？
Sally: 问题是很多代码都假设每个人只能和一个公司关联，所以有人修改了一系列的索引、触发器和表约束来修复这个问题。但某些修改的性能不是高。大多数客户不会受到影响，但是某些情况下会遭遇到系统大幅变慢的情况。
Joe: 什么样的情况?
Sally: 嗯，比如说，如果某个公司在位置表（Location）中有很多记录的时候就会出问题了。
Joe: 没错，那个客户常常和虚拟公司打交道，他们数据库中有个公司分散在30个洲和5个欧洲国家。
Sally: 那就是了。
Joe: 那这个修改不是有点傻么？ 谁会需要把一个“人”关联到好几个“公司”？
Sally: 我不清楚，但多半有原因的，我们来找找看。
Sally打开版本控制的历史记录，开始寻找谁做了那些改动，及其修改原因。
Sally: 看起来PersonCompanyAssoc表是一个叫Tony的人增加的。签入操作的注释里面写明了他做了哪些操作，但并没有说明原因和修改的依据。
Joe: 那么，既然你已经在查看代码了，能不能把它改回去？如果这个修改没什么用，反而造成性能问题，为什么不干脆撤销这个修改呢？
Sally: 我想还是等把整件事的来龙去脉搞清楚再说吧，我们去找Tony问问看。
版本控制提供一些可追踪性，但很多情况下，那还不够。
版本控制能够告诉你代码被修改的情况，能指出谁、在什么时候、修改了什么。但是追踪中最困难的问题是“为什么”，而版本控制往往没有足够的信息来回答。即便开发人员在签入时完整填写了修改的原因，调查工作也会因为线索中断而搁置。
很少有开发人员在签入代码时填写足够完整的信息，其实他们也无需这样做。我们需要的是将整个软件开发过程中的元素联系到一起。
Sally和Joe穿过“糟糕软件公司”的园区，来到71号大楼一间满是隔间、一眼望不到边的大房间。一位经理坐在门口，桃木桌上放着他的名牌，他叫Biff。
Biff: 有什么事么？
Sally: 我们在找一个叫Tony的开发人员，他在这里么？
Biff: 找他有什么事么？
Sally: 他修改了一段代码，我们想来询问一点具体情况。
Biff: 哦，我明白了，嗯，他的隔间编号是19-346-B。
Joe: 19-346-B？
Biff: 你们大概以前没来过这里吧？好吧，隔间19-346-B。沿着19号走廊，一直走到第346个隔间，Tony应该在左手边。
Joe和Sally找到了正在玩“魔兽世界”的Tony。
Tony: 你们有事么？
Joe: 你为什么在7.0开发版本中增加了PersonCompanyAssoc表？
Tony: 我哪知道？那都是差不多9个月前的事了，我后来还修改了不下两处其它代码，我可记不得那么早的事情了。
Sally: 那你知道有谁可能还记得么？
Tony: 去问问品管（QA）的Phil吧，他的bug追踪数据库中或许有点什么。
Joe: Phil在哪里？
Tony: 老天，你们以前没来过这里？Phil的隔间是61-842-A，你们先走到61号走廊，然后左转，一直...
Joe: 好、好了，我们知道了，谢谢。
Sally和Joe在一大片隔间中找到了Phil。在寻找的路上，Joe发现有一个交叉口四面都看不到墙。好在他们最终找到了Phil。
Sally: Phil，你知道9个月前Tony为什么要增加一个PersonCompanyAssoc的表么？
Phil: 唔，我想应该是为了修正一个bug。
Joe: 哪个bug？
Phil: 我可说不上来。
Sally: 你现在能找找么？
Phil: 好的，嗯，bug编号是8675309。
Sally: 有没有记录说明为什么要做改动？
Phil: 没有，不过这里有条销售团队的人留下的注释，你找过他们了么？
Joe: 哈，我们马上去问他们！
ALM工具往往用于非常大型的项目和企业开发，显然，参与的人员越多，管理复杂度就越大。
如果你在破解谜团的时候卡住了，你就需要更多线索，你或许会逐个检查邻居们，看看哪个比较可疑。但当这个“邻居”是一个有5000员工的软件开发部门，那得花不少时间呢。
不过在团队达到这么大的规模之前，混乱就已经发生了。可跟踪性对于50人团队而言或许没有相对于5000团队那么重要，但仍然非常必要。人们总是会忘记发生过的事情，没有那个团队希望人们“健忘”。
你可能会想，“我的团队很小，不会有这些问题，不过这个谜团倒是有点似曾相识，如果我们只有10个人，为什么还会发生那样的事呢？”
你确定把每个人都算进去了么？ :-)
你的客户们呢？他们也是故事中的一员，当客户问起点什么，往往会带来后续一连串动作，可能有人某天会沿着线索重新追溯回到客户。
SourceGear是一个很小的公司，我们的员工不到50人。
但我们的旗舰产品，Vault，有5万用户。有时我们就有那样的谜团需要解决，侦探工作最后很可能指向那些用户中的某一个。我们的客户增加了软件生命周期的复杂性，也增加了我们对于可追踪性的需要。
飞机降落在Grand Cayman，Sally和Joe受到帅哥靓女们的夹道欢迎，簇拥着走进销售总部，等待他们的是一场party。
Joe: 我们该找谁谈？
Sally: 我们先去找Bill，上次他来总部参加过一次会议，应该还记得我们。
穿过拥挤的人群，他们终于找到了Bill，他左手拿着马蒂尼酒，右手握着手机。
Bill: 我们认识么？哦，等等，你不是在明尼阿波利斯总部上班的嘛？我们去年夏天见过，我当时是去打高尔夫...呃，是销售培训。什么风把你刮到这里来了？
Joe: 我们正在试图解开一个谜团，从6.0版本到7.0，有人修改了数据库结构以使得一个“人”可以和多个“公司”关联，你能帮上忙么？
Bill: 我请你们喝杯马蒂尼怎么样？
Sally: 噢，Bill，这个修改造成了很多问题，我们打算把它撤销，但我们需要先把情况搞清楚。
Bill: 哦，哦，当然。不过我也不是很清楚，去问问Marty吧。
Joe和Sally四处找寻了一阵，在Limbo酒吧的角落里找到了正在打电话的Marty。
Marty: 别担心，包在我身上了，我保证8.0版本会有这个功能的！
Sally: 嘿Marty。我们正在追踪一些信息，有人在7.0开发版本里修改了数据库结构，以关联“人”和多个“公司”，这个改动是由你提出的么？
Marty: 嗯，是我。我需要这个微调，好让我对客户有个交待，有什么问题么？
Joe: 是的！这可远不止是“微调”了。或许它看上去很简单，但是所有的事情都搞砸了!
Marty: 来杯马蒂尼么？
Sally: 说真的，你能告诉我为什么非要做这个修改么？为什么有人需要记录每个“人”和多个“公司”的信息？
Marty: 一个客户使用我们的CRM产品，他们和一个顾问团体打交道，那些顾问的公司关系比较松散。他们今天可能代表XYZ公司，明天或许就在为ABC公司工作。所以我们觉得一个“人”对应一个“公司”不够灵活。
Sally: 那桩生意怎么样？我是说，值得花这么大精力么？
Marty: 我想是的，那个买卖很划算，而且带来了5、6个合同，我已经签了3个了。你瞧，我很抱歉因为这个修改有人搞砸了代码，但是公司业务需要它。
Sally: 好吧，谢谢。
每个软件开发的故事都涉及到各种各样的人。他们大多数并不是编写代码的，进行追踪可完全不是调阅bug报告就完事了。我们需要向后追踪更多，直到规格说明书。
可能还要继续追踪下去，一直到市场调研或者销售部门跟客户敲定的内容。
真正便捷的追踪需要记录、索引、关联每一样东西：
ALM工具的挑战就是要能追踪到软件生命周期的所有阶段。
Joe和Sally回到机场搭航班返回了双子城。
Sally: 那我想这些代码还是需要被保留的。不过我还有个疑问，这些代码可能造成的那些问题在测试的时候为什么没有被发现？
Joe: 我们去问问品管部的人吧。
他们回到了公司总部，径直来到了61-842-A隔间。
Phil: 啥事？
Sally: 我们和销售团队的人了解过了PersonCompanyAssoc表的修改原因。现在想知道那些问题在测试的时候为什么没有被揪出来。
Phil: 嘿，别看我，我只是照章办事。
Joe: 那么，我们的产品能够支持一个“公司”多个“地址”，是吧？
Phil: 呃，我想是的。
Joe: 你们有相关的测试用例么？
Phil: 我不知道。
Sally: 你不知道？你怎么会不知道？
Phil: 的确不知道，测试不是那样子分类的。
Joe: 那是怎么样的?
Phil: 按照数字。
Sally: 数字有含义么？
Phil: 嗯，没有。
Sally: 那有办法知道每个测试对应哪些功能么？
Phil: 呃，也没有。不过你打开测试以后就能看到是关于什么内容的测试了。
Sally: 很好，所以虽然你做了很多测试，但不知道它们是关于什么的？
Phil: 没错！
Sally: 好吧，我想我们可以结束了。
可追踪性不单单让你找出过去遗忘的细节，有时我们还要沿着软件生命周期向“前”追踪，看看它如何发展。
这种时候，我们希望这些内容能够被联系在一起：
这样的可追踪性对于帮助发现漏洞很有帮助。如果没有定义性能测试，ALM工具应该能够帮助我们注意到这一点。如果仅存在需求分析，可能导致根本没有人去开发和实现它，那么ALM工具也应该对此有所反映。
把所有东西联系在一起的能力就是可追踪性。这使得我们可以审视整个软件开发过程，即便：
一个好的ALM系统，每一个项目与项目之间都应该有着联系。代码变更连接到bug报告，bug报告连接到用户响应记录，测试用例连接到需求定义。下次需要做侦探的时候，只要沿着这条线索就可以了。
不可能在每个生命阶段都仅仅用同一个工具来实现可追踪性，所以你往往需要整合各种常用的工具来实现。如果那些工具不能相互整合起来，你就做不到可追踪性，也就不能做到ALM。
这就是ALM么？仅仅是可追踪性？
不，ALM还远不止这些，但是可追踪性是其中关键一点，要实现ALM，必须做到可追踪性。
如果“糟糕软件公司”使用有效的ALM系统，并确保信息完整，Sally和Joe可能几分钟内就解决问题了，不需要几乎跑遍整个公司去问问题。
如果“糟糕软件公司”使用有效的ALM系统，并确保信息完整，Sally和Joe就不能免费去Grand Cayman玩了。 :-)
【本文翻译仅为外语学习及阅读目的，原文作者个人观点与译者及译言网无关】
