软件工程1-4.敏捷视角下的过程.ppt

敏捷含义：轻巧、机敏、迅捷、灵活、活力、高效…… 2001年Kent Beck和其他16位知名软件开发者、软件工程作家、软件咨询师（被称为敏捷联盟）共同签署了“敏捷软件开发宣言” 敏捷方法：为了克服传统软件过程中认识和实践的弱点而生。 敏捷方法能带来许多好处，但它并不适用于所有项目、所有人、所有情况；并不完全和传统软件工程实践对立；也不能作为超越一切的哲学理念而用于所有软件工作。 现代生活中，市场情况变化快，用户需求不断变更，很多情况下我们必须足够敏捷地去响应不断变化、无法确定的商业环境。 这样，我们需要完全抛弃软件工程的原理、概念、方法和工具吗？ Alistair Cockburn认为惯例过程模型存在主要缺点：忘记了开发计算机软件的人员的弱点。 Alistair Cockburn认为过程模型可以“利用纪律或者宽容来处理人的这一共同弱点”。 大多数惯例过程模型选择了纪律。 显而易见，宽容易于被接受，但可能导致工作效率低下。 普遍存在的变化是敏捷的基本动力，软件工程师必须加快步伐以适应快速变化。 敏捷不仅仅是有效地响应变化，它还信奉宣言中的理念： 鼓励组员之间、技术和商务人员之间，所有与项目有关的人之间有效沟通； 强调快速交付而不是中间产品； 将客户作为开发组成员； 计划是有局限的，它必须是可以调整的。 敏捷联盟为希望达到敏捷的人们定义了12条原则： 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。 可工作的软件是首要的进度度量标准。 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。 不断地关注优秀的技能和好的设计会增强敏捷能力。 简单——使未完成的工作最大化的艺术——是根本的。 最好的构架、需求和设计出自于自组织的团队。 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。 敏捷过程强调的3个关键假设： 提前预测哪些需求是稳定的和那些需求会变化非常困难。同样，预测项目进行中客户优先级的变化也很困难。 对很多软件来说，设计和构建是交错进行的。事实上，两种活动应当顺序开展以保证通过构建软件来验证设计模型，而在通过构建验证之前很难估计应该设计到什么程度。 从制定计划的角度看，分析、设计、构建和测试并不像我们设想的那么容易预测。 那如何建立能解决不可预测性的过程？ 答案：过程的自适应性，即敏捷过程必须具有自适应性。 敏捷开发和传统软件工程的关系： 对立？ Jim Highsmith对传统软件工程的评价“传统方法学家陷入了误区，乐于生产完美的文档而不是满足业务需要的可运行系统” Jim Highsmith对敏捷开发过程的评价“轻量级方法者或者说敏捷方法学家是一小撮自以为了不起的黑客，他们妄图将其手中的玩具软件放大盗企业级软件而制造出一系列轰动”。 敏捷开发和传统软件工程的关系： 兼容两派的优点则双方都能得到很多好处，而相互毁谤则两者都将一无所获。 敏捷软件开发的拥护者花费了很多精力强调“人的因素”在成功敏捷开发中的重要性。 敏捷软件开发团队成员及团队自身必须具备以下特点： 基本能力。和传统软件工程中一样，敏捷开发中，能力指个人内在才能、特定的软件相关技能、对所选过程的全局知识。 共同目标。虽然任务不同，但同一个目标是在一定时间内向用户提交可运行的软件增量。 精诚合作。与项目有关的人员必须合作。 决策能力。应赋予项目组在技术和项目问题上的自主决策权。 模糊问题解决能力。 相互信任和尊重。 自我组织。三重含义：①敏捷团队组织自身以完成工作；②团队组织最能适应当前环境的过程；③团队进行最好的进度安排以完成软件增量交付。 软件工程的历史：类似春秋战国百花齐放百家争鸣。 每一种软件工程过程、技术、方法都是轰轰烈烈地出现，接着被新的（期望是）更好的所替代。敏捷运动也如此。 下面介绍的敏捷方法都遵循“敏捷软件开发宣言”和12条原则。 极限编程、自适应软件开发、动态系统开发方法、Scrum、Crystal、特征驱动开发、敏捷建模 极限编程（ExtremeProgramming，简称XP）是由KentBeck在1996年提出的。KentBeck在九十年代初期与Ward Cunningham共事时，就一直共同探索着新的软件开发方法，希望能使软件开发更加简单而有