一位叫WilliamGibson的网络科幻小说作家曾经说过：“未来是无法Google到的。”虽然这是事实，可是人类总是对未来充满好奇。最近，笔者联系到几位洞悉软件开发的专家，看看他们对2009年的软件开发生命周期有哪些新想法以及可能出现的实践。

众所周知，那些有经验、具有灵活性和交叉功能的团队将更容易渡过这次经济危机。

项目管理与交付速度

被调查的项目管理专家表示，那些经历过经济低迷时期的资深项目经理将成为企业渡过这次灾难的得力助手。

LawrenceOliva是位于科罗拉多州的全球公司CH2MHILL的资深顾问和项目经理。他认为：“这些人将引领公司找出应该进行的方案和项目。公司在招聘项目经理时应该了解他们是否有在不同经济环境下的工作经验。”

他还说，现在是一个充满机遇的时期，从各方面的新闻报道来看，各国政府将要执行一批非常庞大而且复杂的项目，这正是资深项目经理们引领并在预算范围内迅速完成这些项目的绝佳时机。

虽然Oliva认为PMP资格认证将在经济衰退时期获得更广泛的认可，JimJohnson却不以为然。JimJohnson是波士顿项目咨询公司StandishGroup的董事长。他认为人们对PMP资格认证的重视度将下降，而对经验的重视度则会上升。

他说：“人们将开始重视经验而不是理论……我认为交付速度将成为下一年的主要发展趋势——即更快地从项目中提取出能用的东西来，交到用户的手上。”

需求与敏捷

抓准需求仍然是管理项目的关键。EBG咨询公司的咨询负责人EllenGottesdiener认为需求主要包含三个要素：人、项目与过程。

在人力方面，Gottesdiener认为沟通能力将变得更重要，“不协调的人际关系会造成许多时间与金钱上的浪费。需求是项目的一个组成部分，是所有利益相关人的要求。人们需要通过互相沟通来做出正确的决策、并做出清楚的决策制定规则。”

在项目方面，由于诸多的兼并、合并和收购活动，必然会产生许多整合项目，而如何根据需求对软件应用进行整合就成为关键。“这是基于需求的活动如何找到最基本的需求？企业必须仔细地对应用进行评估，确定哪些项目是不该做的，根据生产计划和发布计划做出分析。而所有这些计划都是以需求为根本的。”

在过程方面，Gottesdiener认为主要内容还是敏捷。她说，敏捷开发要求企业甩掉传统的需求采集方式，进行“适时适量的需求采集”。

Go项目管理咨询公司的总裁RobinF.Goldsmith认为，企业还需要需求工具，“那些可以辅助进行需求采集的工具必然会大受欢迎”。

不过，他还提到，使用工具并不能保证你得到的需求就是真正的业务需求。尽管如此，这一领域还是会迅速发展的，因为与其亲自对付那些技术性或概念性的问题，人们应该更喜欢使用工具。这些工具只会以特定的方式提供方便。

QA与测试

即使过了需求这关，应用还要经过质量保证和测试的考验。对于测试人员来说，在经济紧张时期，这意味着更大的压力。软件测试咨询师KarenJohnson早已感受到这股压力。

她说，“各公司纷纷减少人员聘用额，希望用更少的人力做全部的事。经济看好的时候，公司可能会聘用一个测试员、一个自动化专家等等。而现在他们希望能找到一个可以做所有这些事的人。他们寻找那些有一长串工作技能的人，让他们单独工作，或者在小团队配合的情况下工作。”

Johnson还认为，测试人员的压力越大也就意味着缺陷越多，相应的迹象也正在慢慢显露出来。“我在更多的网站上看到了更多的错误，其中不乏一些大型著名站点。我不知道市场会怎么反应——视若无睹并接受，还是会后退呢？人们通常不会想到软件测试，但是如果他们在那些著名的站点上发现错误，他们就会想到了。”

不过，Johnson并没有显得很悲观，“即使经济不景气，软件测试也是无法排除的。在线的人数越来越多，越来越多的网站陷入瘫痪状态，然后人们就会开始重视这方面。现在的问题只是看大家的忍耐力有多高。”

《管理测试人员》一书的著者JudyMcKay则认为，对于QA和测试来说，2009年将是不景气的一年，“不过这也是一个QA和测试人员证明自己可以为企业节省时间和金钱的机会，毕竟大家都在想办法解决时间和金钱的问题。”

敏捷：忧喜参半

专家们几乎一致认为敏捷将继续向主流发展，但是这并不表示企业能够抓住敏捷的精髓。

JamesShore是《敏捷开发技巧》一书的著者之一，也是敏捷宣言的第十位签署人。他对2009年的敏捷发展既表示乐观，又有些许消极。令他担忧的是，“人们总是倾向于循序渐进地接受新事物，所以虽然有更多的开发人员进行迭代开发，但是他们缺少环境与技术上的支持。我们将同时看到敏捷开发的大范围采用和大范围失败。当然他们可能会把失败怪罪到敏捷上——虽然我认为他们只是做法稍欠妥当。”

不过，Shore同时还乐观地认为，部分开发组织将开始对敏捷做更深入的了解。“某些公司可能会开始向深层发展，他们会用更多的时间来研究技术问题，特别是迭代方面的技术问题。我希望能看到更多的关于迭代设计和架构，即持续设计的研究。我们应该重视能够实现长期效益的技术。虽然企业不使用迭代也可以实现短期的成功，可问题在于这个架构是否支持持续开发，并且他们会在软件维护方面遇到困难。”（ITPUB）