超越敏捷的方法技术与思考

中科院计算所培训中心超越敏捷的方法、技术与思考超越敏捷的方法、技术与思考中科院计算所培训中心谢新华2009年3月中科院计算所培训中心超越敏捷的方法、技术与思考一、经典软件开发过程..............................................................................................-3-二、敏捷模型的提出的原因......................................................................................-5-三、敏捷模型的方法论..............................................................................................-7-四、大型复杂项目中的敏捷模型..............................................................................-9-五、敏捷项目的多维度扩展....................................................................................-12-第二节软件开发规范性与敏捷性的融合...........................................................................-13-一、两种方法论最重要的结论................................................................................-13-二、通过评估项目特征寻求平衡方法....................................................................-14-三、平衡敏捷与规范的步骤....................................................................................-14-第三节敏捷过程对产品设计方法的影响.........................................................................-16-一、重用发布等价原则（REP）............................................................................-16-二、共同封闭原则（CCP）....................................................................................-16-三、包的耦合性原则（ADP）................................................................................-17-中科院计算所培训中心超越敏捷的方法、技术与思考超越敏捷的方法、技术与思考中科院计算所培训中心谢新华今天我们举办“超越敏捷有效开发”技术沙龙，其目的何在呢？是因为在今天我们组织项目的时候，总是认为需求分析、架构设计、编码规范、软件测试做好了，项目就一定会成功，当然这都是重要的要素。但光靠这些是不行的，事实证明项目成功最关键性的因素是良好的过程，大型软件项目是依靠一个组织来完成的，为了确保项目成功，多年来人们对软件工程过程作了深入研究。目前，各种各样全新的方法学理念和生机勃勃的过程实践不断涌现，当然，这中间也会给我们带来各种各样的困惑。我经常听到人们提出这样的问题：1，什么是敏捷方法？敏捷开发是指开发的快吗？不是这样的，敏捷模型最重要的概念是对变化的快速响应，利用一种有效的组织方法，使这种对需求变更的响应成为项目成功的驱动力，团队的整体承诺是敏捷方法成功的关键。2，我们单位已经是CMM3了，我们一直使用的是极其规范的方法，有必要研究敏捷方法吗？有必要的，只要回想一下我们在开发中遇到的种种无可奈何，当需求变更中遇到的种种困难，再想想这些规范性文档是如何写出来的？就可以知道该研究敏捷方法了。3，我们早就使用敏捷方法了？是这样吗？敏捷方法不能等同于游击队方法，更不是作坊式的无序状态，使用迭代不等于敏捷方法。敏捷方法实际上是一种精细的组织方法，有一些列的价值观和方法论作指导。4，敏捷方法的出现几年前就有了，概念也不复杂，有必要坐下来研究吗？有必要的。一个方法论的成功，需要不断地通过项目成功与失败的经验来来不断的丰富自己的知识，跨越前人的经验形成符合自己组织情况的方法论，只有概念是不行的，只有变成行动才有意义。5，技术人员有必要研究敏捷过程吗？有必要的！敏捷方法是把需求变更作为产品成功的驱动力，在这种变更环境下，我们的需求怎么收集？我们的设计怎么来做？软件架构这个概念还要不要？这就需要我们用全新的视野来看待设计问题，也对设计提出了新的要求。下面，我主要从敏捷方法的衍生过程来讨论一下有关问题。第一节敏捷过程产生与发展一、经典软件开发过程软件工程过程描述的是软件构造、部署以及维护的一种方法，早在20世纪70年代，人们就提出了经典的瀑布式软件开发过程。以及早期一系列项目管理原则。这种方法论，被称为计划驱动（或称之为规范式）的过程，也称之为瀑布式过程，如下图所示：中科院计算所培训中心超越敏捷的方法、技术与思考，规范式方法的特点1）基于工程规范的大型软件系统开发计划驱动的方法起源于系统工程和质量规范，由于大型项目的组件未必是同一个公司或者组织生产的，所以需要建立一些系统工程原则，来协调需要精确协同工作的组件的开发。2）引入标准和过程规范为了解决软件开发标准的问题，首先由美国国防部开发了一系列的指导文档，为软件开发提供符合系统工程的标准方法。随着软件工程的重要性日益增强，一些过程规范和组织化技术被开发出来，这些规范既要反映出现有工程过程的需求和规程，也要吻合那种把软件开发看作是数学证明过程的学院派计算机科学中的软件工程分支。经典软件过程的特征如下：重视定义良好的工作产品、验证和确认：软件系统工程认为，从需求到代码的软件过程中，计划驱动的方法非常精确的依赖于明确的步骤，其中每个步骤中文档的完备性非常重要，这种完备性可以保证每个步骤可以验证，文档是可跟踪性的重要保证。产品规范与过程定义和改进具有同等的联系：软件作为一种产品，其可塑性使过程需要经过多次改进，正因为如此，计划驱动总是和过程改进联系在一起。过程需要进行定义、标准化并需要逐步改进以提供对项目的有效控制。这种过程通常包括有：详细的计划、活动、工作流程、角色和职责以及工作产品描述。执行人员应该经过应用过程方面的培训，并且需要有一个过程监督、控制及教育的组织和支持人员。过程提供可预见性、可重复性和基础设施的支持来缓解人员流动问题：计划驱动方法的强势，在于标准化所带来的可比较和可重复性，在组织中接受过培训的人都知道在哪里找信息，以及如何评估日常工作。这种过程的一致性可以使管理人员在项目之间调动人员而不必要重新培训，也意味着关键人员的的流失不再是项目的厄运。2，重要的计划驱动概念计划驱动的开发方法已经形成了一套有特点并证明有效的概念，主要包括：过程改进：用来改进组织过程的执行、成熟度的行为规则以及这种规则的结果，它的目的在于提高工作过程的能力。过程能力：过程产生出计划结果的内在能力，随着过程能力的改进，他会变得可预中科院计算所培训中心超越敏捷的方法、技术与思考测、可度量，而且还可能控制和消除导致质量和生产力低下的根源。通过遵循过程，可以缩小期望和实际结果之间的差距。组织成熟度：一个组织，可以通过持续改进其过程能力而日趋成熟。成熟度不仅包括单个项目的能力，还包括整个组织上下标准过程的普遍适用情况。公共的过程得以维护，并对人员进行应用方面的培训。项目根据需要对公共过程的要素进行剪裁。一旦部署了这些常用的过程要素，组织就可以对它进行有效性度量，并根据这些度量加以改进。过程小组：帮助组织对其使用的过程进行定义、维护以及改进的一组专家。过程小组致力于软件工程过程（softwareengineeringprocess，SEPG）风险管理:一组有组织的、分析式的过程，这个过程识别那些可能导致破坏或者损失的不确定性，对已经识别的风险进行评估和量化，提出并应用一套风险管理计划来防止或者应对可能造成重大破坏或者损失的风险诱因。验证：正式工作产品（例如规格说明、设计模型）是不是反映了指定的需求。确认：进一步证实工作产品对其操作任务的合适性或者价值。软件系统架构：正如我们讨论过的，软件系统架构定义了三点：一组系统组件、连接件以及约束；一组系统相关人员需要的报告；一份原理说明，该说明论证了如果实现了由组件、连接件以及约束所定义的系统，就会满足项目相关人员的需要。3，规范化方法的价值观：在观范性方法学中，强调着以下的价值观：必须加强流程和工具应用，减少个人的作用；必须使用详细的文档保证开发过程的透明性；合同是达到满意交付的必要保证；计划是必须遵循的，它是力量和安慰。这套价值观是与大工业特别是制造业的特征吻合的，因为也被认为是良好的。二、敏捷模型的提出的原因1，规范式过程的问题分析问题是标准化的软件项目过程经过20年的应用，人们发现存在很多问题，下面是很多人做的研究结果：大约2/3的项目会显著超出费用预算（LedererandPrasad1992）。产品中64%的功能很少或者从不会被使用（Johnson2002）。一般项目花费的时间会超出进度表100%（Stndish2002）。这是为什么？为了解决这些问题，这就迫使我们仔细研究项目失败的原因，根据分析，人们归纳起来可以有5个原因。1）初期的估计偏差可能很大下图显示了Boehm所考虑的不确定性在顺序开发过程不同点的范围，这个图称之为不确定性锥形。图上表明，在项目定义阶段，对进度估计的偏差可能达到60%～160%，也就是说一个预期20周完成的项目，实际花费可能在12～32周之间。而在写下需求之后，估计的偏差可能还在±15%，这时的20周预期可能实际上可能会花17～23周。这么大的预估偏差根本就无法实施有效的项目管理。中科院计算所培训中心超越敏捷的方法、技术与思考）活动不会提前完成如果一项工作在甘特图上分配了5天，处理这个活动的员工一定会用满5天，即使能够提前完成，他也会通过增加一些花哨的修饰（镀金需求），或者尝试着用一些新的热点技术。在不少企业文化中，一项活动提前完成，往往被指责为当初他做的估计不准确，或者会另派其它的任务给他，为什么要冒这个风险来提前完成呢？人的本性就是如此：用多余的时间去做一些对自己有价值，但对别人不一定有用的事情。3）延误沿着进度表向下传递由于传统的计划是基于活动的，因此它们主要关注活动之间的依赖性。考察下面的甘特图，它显示了4项活动及它们之间的依赖关系。关键之处在于，即使一个如此简单的案例中，在启动测试之前也有3件事情必须发生，但是下面任何一件事情，都可能导致测试推迟：用户界面编码结束时间延误。对中间层编码花费时间超出计划。中间层编码花费时间符合要求，但是向