敏捷软件开发

前言 本篇文章将对敏捷软件开发的方法论及其应用做基本介绍，将描述团队是如何通过协作来完成共同目标的。本篇文章不仅仅适合软件开发人员阅读，同时也适合于团队负责人、项目经理、产品经理、开发经理、测试人员、QA经理、QA工程师、技术文档专员、用户体验设计师等任何涉及软件交付的人员。文章重点介绍技术团队是如何通力协作来计划、构建和交付软件的。但文中没有具体代码的编写，也没有对特定技术的介绍，并且也不会介绍任何微软技术。希望这篇文章可以帮助你改善专业性和团队的效率。 背景 Winston Royce 瀑布模型 引自 1970 年的 IEEE 论文 "Managing the Development of Large Software Systems" 该论文中阐述了，在计算机程序设计开发过程中，无论软件的规模和复杂度如何，都会经过两个必不可少的阶段：软件分析和编码。而许多其他额外的开发步骤，虽然也是需要的，但却都没有像软件分析与编码一样对最终产品作出最直接的贡献，反而增加的开发过程的支出。 然后，Royce 介绍了需要额外的将 5 个重要的步骤添加到整个开发流程中，用于最大化地消除软件开发中的风险： 步骤1：程序设计优先 一个软件程序的初步设计阶段，将被插入到软件需求和软件分析阶段之间。程序设计人员将在此阶段开始进行软件整体的初步设计，包括设计、定义和指定数据处理模型，定义系统间的接口

上回问题回顾 前文 说到一位用户拿着业界标准开关（一个标准的StandardSwitcher，它依赖IStandardSwitchable接口才能工作，然而目前我们的灯并不支持这个接口）出现在我面前，叫嚣着他的“标准开关”应该能打开我们的灯。好吧，这个需求是合理的，的确应该支持。但是该死的是，为什么没有早一点儿知道这个标准的存在呢？这样就不需要花费时间和人力定义这个接口，现在也不会这么纠结。和上次一样，先讲故事、演进方案，再分析背后的思想。 这回主要讲解Adapter模式，GoF讲解了这个模式是什么，怎么用，用在什么地方。我想来解释一下Adapter模式的要点是什么，对Adapter模式的延展，以及对Adapter模式的误用。顺便得瑟一下我对面向对象设计的理解。 两个方案 现在有两个选择。 让我们的灯直接支持标准开关。也就是让灯实现IStandardSwitchable接口。 好处：成本低，实现方式优雅。 坏处：相当于放弃了已经买了我们的灯，又想用标准开关的用户。 不改变现在的灯，让标准开关能打开我们的灯。标准接口我们改不了，灯也不能改。好在计算机界有句话，叫“加一层可以解决一切问题”。这让我想到了买外国电器附赠的那个电源接口转换器。现在，我们的灯需要个类似的玩意儿。 好处：支持所有的灯。 坏处：这东西都是要附赠的，会降低我们的利润。 第一个方案很简单

敏捷软件开发与传统软件工程概述比较 翁松秀 北京航空航天大学计算机学院 　　摘要： 软件工程的开发过程中有两种截然不同的管理和开发体系，一种是基于 “瀑布模型”的预设性传统软件工程，另一种是轻量级的适应性敏捷软件开发，本文简单阐述传统软件工程的开发方法与敏捷软件开发的异同，并通过“瀑布模型”和 SCRUM 方法的比较来探析传统软件工程与敏捷软件开发的异同。最后得出结论，把传统软件工程和敏捷软件开发相结合，将软件架构“颗粒化”，在简单可快速交付的敏捷软件开发中嵌套系统的传统软件开发方法，实现预见性和适应性折中。 关键词 ：敏捷软件开发；传统软件工程；瀑布模型； SCRUM 方法；嵌套；颗粒化 　　0 前言 　　随着计算机的发展，对软件的需求越来越大，软件的规模也变得越来越大，结构越来越复杂，软件开发管理困难而复杂，在这个 “软件危机”背景下产生的传统软件工程，用工程化的方法构建和维护有效和高质量的软件。暂时解决了软件的兵荒马乱时代，但随着社会和科技的发展，对软件的需求变化越来越快，传统的软件工程很难再适应瞬息万变的客户需求，敏捷软件开发应运而生，其轻量级、简单、可快速交付、适应性强收到开发团队的青睐，与传统软件工程并肩，形成软件工程中的两大开发体系。 　　1 传统软件工程 1.1 传统软件工程概述 　　基于 “瀑布模型”的传统软件开发方法中，以软件架构 (software

这学期的软件工程课，老师一开始就谈到了一个词——敏捷开发。下面来详细谈一下敏捷开发。 就老师课上说讲解的内容，首先说一下敏捷软件开发的核心价值观，它包括承诺（commitment）、专注（focuse）、公开（openness）、敬重（respect）、勇气（courage）。 scrum的框架，它包括三个角色，四个仪式，三个物件。 （一）敏捷开发的起源 敏捷开发是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于"非敏捷"，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用。 （二）敏捷软件开发的原则 对我们而言，最重要的是通过尽早和不断交付有价值的软件满足客户需要。我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势。经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好。业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。可以工作的软件是进度的主要度量标准

敏捷软件开发 　　人与人之间的交互是复杂的，并且其效果从来都是难以预期的，但却是工作中最重要的方面。 　　 -- Tom DeMacro和Timothy Lister 　　敏捷软件开发宣言： 　　① 个体和交互 胜过 过程和工具 　　② 可以工作的软件 胜过 面面俱到的文档 　　③ 客户合作 胜过 合同谈判 　　④ 响应变化 胜过 遵循计划 　　虽然右项也有价值，但是我们认为左项具有更大的价值。 　　敏捷宣言遵循的原则： 　　① 我们最优先要做的是通过 尽早的、持续的 交付有价值的软件来使客户满意。 　　② 即使到了开发的后期，也欢迎改变需求。 敏捷过程利用变化来为客户创造竞争优势。 　　③ 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。 　　④ 在整个项目开发期间， 业务人员和开发人员必须天天都在一起工作 。 　　⑤ 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。 　　⑥ 在团队内部， 最具有效果并富有效率的传递信息的方法，就是面对面的交谈 。 　　⑦ 工作的软件是首要的进度度量标准。 　　⑧ 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。 　　⑨ 不断地关注优秀的技能和好的设计会增强敏捷能力。 　　⑩ 简单是最根本的。最好的构架、需求和设计出于自组织团队。

敏捷软件开发 (Agile development) 敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。 在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。 　　敏捷开发小组主要的工作方式可以归纳为：作为一个整体工作； 按短迭代周期工作； 每次迭代交付一些成果，关注业务优先级，检查与调整。 　　敏捷软件开发要注意项目规模，规模增长，团队交流成本就上去了，因此 敏捷软件开发暂时适合不是特别大的团队开发，比较适合一个组的团队使用 。 与增量开发区别是，敏捷开发需求不明确；与迭代开发区别是，敏捷开发不区分粗细和是否精致。 另：敏捷开发、增量开发、迭代开发区别 传统的 瀑布式开发 ，也就是从需求到设计，从设计到编码，从编码到测试，从测试到提交大概这样的流程，要求每一个开发阶段都要做到最好。特别是前期阶段，设计的越完美，提交后的成本损失就越少。 迭代式开发 ，不要求每一个阶段的任务做的都是最完美的，而是明明知道还有很多不足的地方，却偏偏不去完善它，而是把主要功能先搭建起来为目的，以最短的时间，最少的损失先完成一个“不完美的成果物”直至提交。然后再通过客户或用户的反馈信息，在这个“不完美的成果物”上逐步进行完善。 螺旋开发

敏捷软件开发强调人是最重要的 . 沟通才是王道 . 合作 , 自组织的团队有着更高的效率 , 开发出更优秀的产品 . 人不像即插自适应的产品 , 人与人之间又磨合 , 需要不断的沟通 . 软件开发没有一个统一的模式 , 因此显得特别复杂 . 我们不能完全照搬一套成功的理论不加分析地去应用到当前的情况中 . 软件开发的本质就是一种选择一种折中 . 敏捷软件宣言 : 1) 个体和交互　　 胜过　过程和工具 一个优秀的团队成员可能是一个平均水平的程序员 , 但是却能够很好的和他人合作 . 合作 , 沟通以及交互能力要比单纯的编程能力更为重要 团队的构建比环境的构建重要很多 2) 可以工作的软件　胜过　面面俱到的文档 过多的文档比过烧的文档更遭 . 文档需要不停的同步才有意义 . 文档必须要短小的并且主题突出的 . ”短小的”是指最多一二十页 . ”主题突出的”是指应该仅论述系统的高层结构和概括的设计原理 . 给新的团队传授知识最好的两份文档是代码和团队 . 代码真实的表达了它所做的事情没有二义性 . 直到迫切需要并且意义重大时 , 才来编制文档 3) 客户合作　 　 胜过　合同谈判 成功的项目需要有序的频繁的与客户反馈 . 成功的关键在于和客户之间的真诚的合作 4) 响应变化　 胜过　遵循计划 需求的改变并不一定是坏事 , 至少它让你对系统有了更深的了解 计划不能考虑的过远 .

一、敏捷开发（Agile Development） 　　1) 敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。是一种应对快速变化的需求的软件开发能力。 　　2）敏捷软件开发宣言（核心价值观） 　　　　人和（人与人的）交互 胜过 过程和工具 　　　　可以工作的软件 胜过 面面俱到的文档 　　　　客户协作 胜过 合同谈判 　　　　响应变化 胜过 循规蹈矩 　　3）在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。 　　4）敏捷设计是一个过程，不是一个事件。它是一个持续的应用原则、模式以及实践来改进软件的结构和可读性的过程。它致力于保持系统设计在任何时间都尽可能得简单、干净和富有表现力。 　　5）敏捷方法更适用于较小的队伍，40、30、20、10人或者更少 二、Scrum 　　1) Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。 　　2) 主要角色 　　　　产品负责人（Product Owner）：负责维护产品订单的人，代表利益相关者的利益。 　　　　Scrum主管（Scrum Master）：为Scrum过程负责的人，确保scrum的正确使用并使得Scrum的收益最大化。 　　　　开发团队（Team）：

请阅读我们的热门文章，这些文章着重讨论了敏捷的过去、现在和未来。-- Leigh Griffin（作者） 对于 Opensource.com 上的敏捷主题来说，2019 年是非常棒的一年。随着 2020 年的到来，我们回顾了我们读者所读的与敏捷相关的热门文章。 小规模 Scrum 指南 Opensource.com 关于 小规模 Scrum 的指南（我曾参与合著）由六部分组成，为小型团队提供了关于如何将敏捷引入到他们的工作中的建议。在官方的 Scrum 指南 的概述中，传统的 Scrum 框架推荐至少三个人来实现，以充分发挥其潜力。但是，它并没有为一两个人的团队如何成功遵循 Scrum 提供指导。我们的六部分系列旨在规范化小规模的 Scrum，并检验我们在现实世界中使用它的经验。该系列受到了读者的热烈欢迎，以至于这六篇文章占据了前 10 名文章的 60%。因此，如果你还没有阅读的话，一定要从我们的 小规模 Scrum 介绍页面 下载。 全面的敏捷项目管理指南 遵循传统项目管理方法的团队最初对敏捷持怀疑态度，现在已经热衷于敏捷的工作方式。目前，敏捷已被接受，并且一种更加灵活的混合风格已经找到了归宿。Matt Shealy 撰写的 有关敏捷项目管理的综合指南 涵盖了敏捷项目管理的 12 条指导原则，对于希望为其项目带来敏捷性的传统项目经理而言，它是完美的选择。 成为出色的敏捷开发人员的

《敏捷软件开发》读书笔记（1） 概述 验收测试 在开始编码之前，可以用需求意图的方式写验收测试。 测试最重要的好处是对于架构和设计的影响。为了一个模块或应用程序可测，必须要对他进行解耦合。 什么是设计 遵循敏捷实践发现问题 利用设计原则诊断问题，并且： 应用适当的设计模式解决问题 设计的坏味道 僵化性，很难改动，牵一发而动全身 脆弱性，修改很容易引入问题，而且可能是无关的概念 牢固性，和某些细节牢牢绑定，很难作为可复用组件 粘滞性，保持设计比破坏设计做起来更困难麻烦，或者环境很麻烦，一修改就要花很长时间 不必要的复杂，存在有些不必要的组成，常因为开发人员预测不存在的需求 不必要的重复，就是重复、类似逻辑的代码了 晦涩，代码难以理解，不够清晰。 设计原则： SRP：单一职责 一个类或者组件、模块，只有一个原因让其变化。但是特别要注意，仅当变化实际发生的时候，分离变化才有实际意义，这是敏捷的做法。如果没有变化，那么使用任何原则都是不合适的。 OCP：开放封闭原则 面向对象设计的核心所在，如果一个需求要修改很多地方，比如需要switch语句增加判断分支，就打破了这个原则，而且可能需要依赖这个模块的模块全部重新编译部署。遵循这点设计，需要一定程度预测的策略，或者在发生第一次变化的时候修改为抽象。可以用合适的抽象，或者用数据驱动的方式来获取封闭性（控制代码和逻辑代码分离）。 LSP