敏捷方法(XP、SCRUM、Feature-Driven Development).docVIP

?1??? 简介现在，即使在IT预算被大幅度地削减的情况下，IT管理人员的压力仍然在不断增大。同时，业务环境正以非常高的速度持续改变，这使IT艰苦奋斗，以便能够跟上这种变化速度。这些变化导致了以“快速发布和灵活而又高质量的维护为承诺”的敏捷软件开发方法论产生了很大的兴趣。敏捷方法（XP、SCRUM、Feature－Driven Development）努力在软件开发过程当中减少变化带来的成本。例如，XP使用快速迭代计划和开发循环尽早地产生最有价值的特性。另外，XP中的持续的、系统化的测试确保高质量，尽早发现缺陷和相应的解决方案。尽管敏捷方法带来了早期的一些成功案例，但还是有很多因素阻碍它们被广泛采纳。敏捷方法的倡导者经常发现：在应用开发中，对动态变更很难得到管理方面的支持。这些方法需要开发者、管理者和用户都改变他们工作和思考的方式。例如，XP实践中的结对编程、TDD、持续集成以及on-site 客户代表等是很难让人接受的。而且，这些方法论更倾向于以开发者为中心，似乎并不太重视管理角色。然而，实践证明，加强管理是敏捷方法被成功采纳并应用的关键，而传统项目管理方法学和工具与这些新的敏捷方法缺少关联。而这种低关联性就是深层次问题的症状。这些深层次问题表现在：对于处理变化、控制、命令、组织、人员以及解决方案等方面的基本假设方面的不同。传统管理理论假设：l???????? 管理变化是需要严格过程的l???????? 分层级的组织结构是建立秩序的途径l???????? 加强控制可以得到更好的秩序l???????? 在“项目组”这个机器中，人员是可以互换的“零件”l???????? 问题主要是通过任务细分来解决l???????? 通过事前详细复杂的计划可以对项目和风险进行充分的预言，并被管理在这个上下文环境中，新方法论所表现出来的无序性、平等性和解决问题的无方向性就没有什么奇怪的啦。在这种传统管理与敏捷开发方法论之间的不重合性中，敏捷方法会被逐渐采纳。同样，这些假设的变化和敏捷方法过程中新的管理框架也是非常重大的需求。在寻找这种新框架的过程中，我们强烈地认识到：出现了基于“复杂性理论”这个新学科的管理原则。“复杂性理论”这个新学科实际上在对现存系统进行研究的过程中产生的，它主要是探寻对人类自治行为的理解。.尤其是，我们已经开始将一种复杂适应系统（CAS）的概念融入到我们的管理假设与最佳实践中。“复杂性理论”的科学家已经研究了现存系统中的集体化行为，如鸟群、鱼群、蚁群和蜂群。他们发现，当这些复杂适应系统中的个体拥有局部的战略原则和能力时，它们的集体化行为比个体的总和表现出更完全的秩序化、自组织性和更高的智慧性。这种ＣＡＳ理论被成功地应用于经济和生命科学，现在也被用于管理方面。这种ＣＡＳ的概念使我们产生一种灵感：在ＸＰ团队中，项目经理也需要一系列的简单的指导实践来提供一种框架，并在这种框架下进行管理，而不是一系列的严格的指令。根据这此实践，管理者成为一名适应性领导者－－确定方向、建立简单的产生式的系统准则，并鼓励持续反馈、适应性改变和协作。这个管理框架为团队提供一系列的内容来实现敏捷方法论，这些内容包括：l???????? 在团队管理中，组员是熟练地有很高价值的stakeholderl???????? 自治性团队的集体能力是解决问题的基本机制l???????? 在不可预言的假设面前尽可能地使事前计划最小化，而加强适应变化的能力2??? 问题：作为传统的任务分配者所面对的项目管理传统软件生命周期开发方法论的产生是因为我们要控制不断增大的开发项目，以及对产生可靠的产品的工作量的评估和管理。这些方法论来源于建筑工程管理中的一些原则。结果，它们是强调可预言性的（在建一座桥时，工程设计师必须设计桥的每一个细节），并且是一个线性开发周期（即需求、分析、设计、开发）。根据这种可预言性，它们沿用了确定性的简化了的方法，这些方法依赖于任务分解，并且是基于稳定性的（即稳定的需求分析和稳定的设计）。作为项目控制的一个手段，这种刚性表现为顺从性。在过去，一些公司使用这些方法，并且现在也可能在使用。对于许多来说，这些方法论只是增加成本和复杂性，却给人们一种错误的安全感――管理就是通过详细的计划、度量和控制来做事。巨大的成本被过早的计划浪费了。我们认识到快速的迭代式开发和从用户那里得到不断的反馈是今天项目达到成功的前提。下面这个例子被公认为是原有方法论失败的代表案例：“伦敦救护系统”和“但佛航空行李系统”，巨大的成本超支和拖期。让我们来看一下Ｓｔａｎｄｉｓｈ组织关于ＣＨＡＯＳ的调查。在第一次调查中，成功项目18％，31％失败，53%挑战。在1998年的调查中有所提高，但也是26％成功，46%挑战，28％失败