当IT变得越来越敏捷，商业上的变化率需要更快地采用敏捷技术。
IT行业不止是有软件开发。我们不仅为我们的投资商创建基于软件的解决方案，也将解决问题的方案发行到生产环境中，一旦发布到生产环境里以后，我们还在生产环境里操作和维护那些方法。也有如企业架构，原型管理，数据管理还有其他跨解决问题方案的结构功能点并行发生在软件开发和运行中。最近，我决定研究这个问题：这些IT功能有多有效？我发现这其中有很多改进的空间。
从2014年的9月份到11月，我做了一个线上的调查，探寻几个常见的IT功能的有效性。该调查有117个回应者，其中大概一半的人在IT行业有20年或20年以上的经验（88%的人有10年或10年以上经验。）。这个调查探索了两个基本问题：与那些完成多种IT功能的人一起工作有多容易，那个功能又给该组织提供了多大的价值。表1归纳了一些这个调查探索的对六个IT功能的调查结果。打分是在+10到-10之间，+10分代表该组人十分易于共事或提供高价值，-10表示该组人很难共事或对组织贡献较少。
表1.不同的IT功能怎样打分（分值-10到+10，分值越高越好。）
如你在表1中看到的，平均分数都在中心点附近---因为在英国他们会这样说：平均来看，该组人是糊里糊涂地混日子。对每个IT功能，有一些被调查者反映说提供那个功能的组人易于共事，有些人表示该组不易共事。类似地，每个功能都有人说该组人给组织提供高价值，而其他人说该组人没有提供什么价值。基于表1中归纳的平均分值，我们来探讨一下你们公司会怎样看待将敏捷技术应用到软件开发中来提高每个IT功能。
改善数据管理
在过去20多年里，我为10几个机构工作，帮助他们改善他们的IT流程管理，而不变的是数据管理团队证明了其是该机构中的害群之马的事实。这来源于脱离IT行业 的其他部分的数据管理知识库，他们的大部分"思想领袖"仍然坚持的是上个世纪70年代重手工的系列策略方法。这个文化的阻抗不匹配的主要影响已经给我至少两代数据操练者以在物理数据模型化和数据库管理上很少具体的详尽的技巧。有两点要注意的情况---数据管理知识机构实际上已经与数据库测试无关，而且跟实际的解决数据库上的问题如通过数据库重构技术解决问题关系更少。
好消息是敏捷社区已经在敏捷数据技能上有了大的跨步。越来越多的人在做测试驱动的数据库开发工作，持续数据库集成工作，敏捷数据模型化和数据库重构工作。我也在看着兴趣敏捷数据仓库/商业智能（DW/BI）里涌现的健康的一股浪潮，如数据花瓶DV2.0，我怀疑这是由传统方法的破旧追踪记录激发出来到这种付出和由大数据推出的动态挑战。一个由现存数据从业者面临的重要的任务，你可以轻易地从这个新技能表单上推测出来，正在将需要的技术技能用来运用这些惯例做法。在过去几年中，我们已有一系列有关这些话题的书出版了，包括测试驱动数据库开发，作者马克思.顾尔赛三世，由普拉莫德.撒德拉格著作的持续数据库集成方法集，由肯.克拉尔著作的敏捷分析和由普拉莫德.撒德拉格和我著作的重构数据库。
提升企业架构
在过去十年内，我在一个企业架构社区内见到过逐渐的、零碎的不完全的敏捷策略的接收。成功的企业架构团队在采用轻量的、灵活的和高度合作的敏捷策略。敏捷方法将企业架构从成为架构文档的评审者搬进主动投入到业务风险承担上和软件开发团队的角色中。 残酷的现实是不撸起袖子干活的企业架构师最有可能不是被开发团队忽略就是被生产架构模型的团队屏蔽掉，他们只需要去通过架构的"质量大门"。
作为编辑，安德鲁.宾斯道科熟练地在探索敏捷架构一文中观察到，敏捷架构空间母亲遭受几个基本的挑战。首先，一个围绕着Scrum的因素标准化的副作用是关于软件架构和设计技巧的整个软件开发者的沉沦。对，的确有一些亮点在如吉姆.可普列所著的书《靠向架构》中有体现和在如《软件工艺宣言》和《敏捷模型化》书有体现。令人伤心的是，这些话题很少被提及，让单独地在那些到处都是的两天Scrum证书工作商店里充分阐述吧。
其次，敏捷社区仍然受限于经常反模型化和反自上到前思维方式的文化。这让很多敏捷使用者甚至连考虑敏捷架构惯例而不管这些技术有多轻都做不到。第三，大多数敏捷方法认为领导者们更喜欢关注其他话题--如阐述文化问题，持续发布和DevOps-所有这些都是重要的话题。然而，这样做有一个副作用，即让敏捷架构在面向会议时，在博客中和在以开发者为中心的出版物中处于饥饿困顿的位置。
加强IT监管
如你在表1中看到的，IT监管的组织功能显效很差。随着数据管理社区面对的挑战，大部分IT监管的文字看起来都建立在20世纪70年代的瀑布思考方式基础上。这种监管方式是建立在一种命令加控制的习惯做法上，这种习惯做法推行一系列质量之门在项目产出（代表性地是文档）被评审过的项目里。这种管控项目的一个大的讽刺是他们自己本身不受管制而且几乎总是失控---这是那种监管项目很少有标准或者其他反馈机制能够关注项目自身的效率的案子的一个确定的标志。另一个代表你的管制策略是无效的过程标记是当监管者声称他们的方法是具体到范例的。现实是用一种比迭代团队差异很大的方式和比敏捷或者瘦团队不同的方式管制传统团队。
敏捷和瘦管制策略相反是建立在动机，可行性和短期回馈循环基础上的。目标是激励那些开始被管制去做"正确的事情"的人，不管这样做对组织意味着什么，而不是去尝试在事后再来评审。为了增加正确的事情发生的几率，管理工作就是要让做管制这些事情变得尽可能的容易，去启动他们，有力地让做错事变得困难。最后，被管的和管理者都应当能够看到提供现在正发生什么事情的有意义和有焦点的衡量标准，因而能够启动这些度量来采取相应地调节行为的行动。
改善档案管理
档案管理包括一系列活动，典型地有产品和项目标识，团队启动和业务路图创建。有时候它包含进行中项目的管制，甚至有操作付出管制。将IT管制的某些方面放在档案管理团队手中会证明这对很多企业来说是有问题的，尤其是那些订阅项目管理机构PMI教学的机构。PMI的挑战是两面的。首先，太仍然在识别号的档案管理管理的进程中，这种管理惯例PMI是很明确的。其次，PMI倾向于推动基本的项目管理策略，这些管理策略常常证实是棘手的，并且更适合于物理建造行业中（这些行业中他们用物理法则处理）而不是IT行业（在IT行业里我们用人类行为模型处理）。
幸运滴是，档案管理敏捷策略的确存在，他们关注在高水平的规划，项目标识和业务路图开发的合作性的轻重量技术上。敏捷档案管理技术关注跨团队一起共事的人力方面，关注伴随在"瘦启动"的 埃里克.瑞尔斯技术线上启动、指导以价值为驱动的实验，关注将不同敏捷项目和产品团队工作做匹配的工作和关注激励投资方简化生产或操作环境问题。用IT管制技术，敏捷档案管理需要从命令加控制的团队精神转换到更需要合作的团队精神上。这常常说起来容易，做起来难。
改善操作和发行管理
大多数组织中的操作功能都是倾向于把工作做好，尽管这里总有提升的空间。主要的挑战是不相干的生产环境，年复一年的架构上不协调的软件开发项目结果和软件开发人员的对操作现实差得可怜的理解能力。我的猜想是90%到95%的所有的组织都遭遇到此问题。另一个挑战，尽管幸运滴不是常见的问题，是过渡地使用官僚手续，经常是来自于缺乏务实地采用如信息技术基础架构库ITIL或信息和相关技术控制目标COBIT这样的框架。
目标发行管理是成功地指导基于软件的解决方案的部署到生产环境中去。很多组织的发行流程依然太过瀑布式，有许多检反映对传统团队的质量惯例有质疑的检查和配余表。当你们组织的开发团队转向更敏捷，更以质量为焦点的方法时，你们的发行管理团队会发现它会反过来简化其在敏捷部署上设置的限制。
好消息是今年来在敏捷社区里有两股健康的及其趋势：持续发行CD和DEVOPS。持续发行的目标，如名字所意，是为了让软件开发团队定期地、有规律地将软件部署到生产环境中。而不是一年部署一次或两次到生产环境中，开发团队是由一种CD方法跟随策略，这种策略让他们能够每月做发行，然后改善到每周做一次发行，然后每天发行一次，有时甚至一天发行几次。注意他们不仅仅是将软件发行到测试环境中去，与之相反是将软件发行到实际的生产环境中。公司如Netflix，Etsy和Salesforce据报道说是一天做很多次将软件发行到生产环境中的。这使得他们能够对市场的需求快速地反应，因此增加了他们的整体竞争力。Devops关注在如何流水线化我们的软件开发和操作流程。这个会包含如持续部署，配置应用程序这样的策略以便新功能在生产环境中运行的时候可以被栓牢或卸下。配置应用程序如此他们可以提供实时操作度量，标准化生产环境（这个被早些时候描述的敏捷企业架构策略支持），和有意地撤掉技术的债务来做这些工作。看我的文章10个首要的高效Devops惯例使用获取更多详细见解。
该项调查的主要发现是在很多组织机构中，对于怎样发行常见的ＩＴ功能都有很大的改进空间。我们需要这么做，是因为我们的组织的业务方面常常运行得更快或至少想要走得比我们的IT部门现在所能支持的更快一些。在本文中，我分享了一个敏捷策略集帮助解决很多ＩＴ部门今天所面对的常见挑战。这些敏捷信息技术策略在有纪律的敏捷发行DAD架构中迅速被捕捉和自由共享。请保持关注。
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
