一个大型的软件项目，由北京软件开发公司资助的较近经历了巨大的挫折，由于一部分软件方法学不适合的开发方法。

 

也许比任何其他行业，IT部门已经多次发现自己受制于企业领导人为了实现较新的炒作趋势没有适当考虑如何实现将融入现有的业务结构。一旦新的技术进步被释放到市场，C级人员的争夺是一个已经融入他们的企业第一。

 

即使部门深入复杂的工作和日常职责等质量保证团队不受外界干扰。他们可能会被迫采用新的热潮，即使方案不完全满足他们的业务需求。

 

不合适的软件方法的出现促成了较近的斗争，报道了关于英国政府的一个新的软件系统的开发。撰稿马克巴拉德computerweekly报道，英国就业与养老金部已投资超过468000000美元，进入了一个新的系统 将支持通用信用福利项目。据巴拉德，政府内阁办公室和所坚持的计划部署发展敏捷方法，这些过程可以是非常有用的质量管理谁努力跟上不断变化的客户需求或需要协助现场和远程团队同步。

 

“敏捷设计方面软件开发的现实：它不是像其他基础设施–它确实改变你走，因为它是一个活生生的模具从人类活动的复杂性和社会交往的条件，”巴拉德写道。“这是不太一样的建筑一条高速铁路线，甚至当你的帐户nimbies迫使路线的改变。”

 

敏捷不适合的账单

然而，由国家审计署较近进行的一项调查发现，该项目已经落后于时间表，超出预算，缺乏一个适当的框架，监督日常开发和软件测试的操作。官员接近项目告诉巴拉德较早computerweekly块 迫使敏捷开发过程是在这种情况下是不明智的合同和计划都写在一个更线性的方式适合于生产周期一步一步的瀑布。

 

“你可以叫它是灵活的，但如果你不设置合同正确，它不是，”一位不愿透露姓名的人士担任该项目的首席顾问说。“你怎么说都行，但如果它咯咯和产卵，这是一个鸡。”

 

一个大的，长期的项目，与众多的复杂性和考虑的因素被认为是由许多发展专家不适合敏捷测试实施。调研公司Forrester解释在较近的一份白皮书，该方法更好地利用当组织面临 紧迫的期限和交付预期转变。

 

“敏捷支持更小，更快的开发周期，提供功能的软件的话，这反过来又限制了工作的总体进展，”报告称。“这影响了软件测试的假设所需的功能远远早于瀑布方法使开发商和商业赞助商可以很快证明或反驳他们。”

 

当考虑到北京软件开发公司团队的方法或结构的急剧变化，质量管理首先要考虑如果一个给定的方法是他们目前的经营状况良好的配合。全面转向敏捷可能并不总是有益的，所以领导应该把这件事杰出的想想之前的跳跃。在许多情况下，它的更好的实施敏捷方法的增量，缓解当前软件测试人员通过过渡和建立在这些增加的团队成员成为更舒适的方法。