没有合适的资源?快使用搜索试试~ 我知道了~
敏捷视角下的过程要点浏览概念:敏捷软件工程是哲学理念和分享.pdf
1.该资源内容由用户上传,如若侵权请联系客服进行举报
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
版权申诉
0 下载量 71 浏览量
2021-12-31
23:10:22
上传
评论
收藏 341KB PDF 举报
温馨提示
试读
42页
敏捷视角下的过程要点浏览概念:敏捷软件工程是哲学理念和分享.pdf
资源推荐
资源详情
资源评论
第 3 章 敏捷视角下的过程
要点浏览
概念:敏捷软件工程是哲学理念和一系列开发指南的综合。 这种
哲学理念推崇让客户满意和软件尽早增量发布; 小而高度自主的
项目团队; 非正式的方法; 最小化软件工程工作产品以及整体精
简开发。开发方法强调超越设计和分析 (尽管并不排斥这类活动)
的发布及开发人员和客户之间主动和持续的沟通。
人员:软件工程师和其他项目共利益者 (经理、客户、最终用户)
共同组成敏捷开发团队, 这个团队是自我组织的并掌握着自己的
命运。一个敏捷团队能够培养所有参与人员之间的交流与合作。
重要性: 孕育了基于计算机系统和软件产品的现代商业环境, 正
以飞快的节奏不断变化着, 敏捷软件工程提出了可用于特定类型
软件和软件项目的不同于传统软件工程的合理方案。 事实证明,
这一方法可以快速交付成功的系统。
步骤:敏捷开发恰当的称呼应当是“类软件工程” ,它保留了基
本框架活动:客户沟通、策划、建模、构建、交付和评估,但将
其缩减到一个推动项目组朝着构建和交付发展的最小任务集 (有
人认为这是以牺牲问题分析和方案设计为代价而实现的) 。
工作产品: 接受敏捷理念的客户和软件工程师有共同的观点: 唯
一真正重要的工作产品是在合适时间提交给客户的可运行软件
增量。
质量保证措施: 如果敏捷团队认为过程可行, 开发出的可交付软
件增量能使客户满意,则表明敏捷方法已经正确实施。
2001 年, Kent Beck 和其他 16 位知名软件开发者、软件工程
作家以及软件咨询师 [BEC01a] (被称为敏捷联盟)共同签署了
“敏捷软件开发宣言” 。该宣言声明:
我们正在通过亲身实践以及帮助他人实践的方式来揭示更好的
软件开发之路,通过这项工作,我们认为:
个体和交互胜过过程和工具
可工作软件胜过宽泛的文档
客户合作胜过合同谈判
响应变化胜过遵循计划
亦即,虽说上述右边的各项很有价值, 但我们认为左边的各项具
有更大的价值。
一份宣言通常和一场即将发生的破旧立新的政治运动相联系。 从
某些方面来讲,敏捷开发确实是一场运动。
虽然多年来大家一直都在使用着指导敏捷开发的基本思想, 但真
正凝聚到一场运动中还是近十年来的事情。 本质上讲, 敏捷方法
1 是为了克服传统软件工程中认识和实践的弱点开发而成的。 敏
捷开发可以带来多方面好处, 但它并不适用于所有的项目、 所有
的方面、 所有的人和所有的情况, 它并不完全对立于传统软件工
程实践, 也不能作为超越一切的哲学理念而用于所有软件工作。
在现代经济生活中,很难甚至无法预测一个基于计算机的系统
(如基于网络的应用) 如何随时间推移而演化。 市场情况飞快变
化,最终用户需求不断变更, 新的竞争威胁毫无征兆地出现。 在
很多情况下, 项目实施之前, 我们无法充分定义需求。 因此, 我
们必须足够敏捷地去响应不断变化、无法确定的商业环境。
流动性意味着变化, 特别是在其失去控制或疏于管理的情况下,
为这种变化而付出的成本费用是十分昂贵的。 而敏捷方法最具强
制性的特点之一就是通过软件过程来降低由于变化所付出的代
价。
难道说认识到现状我们就完全抛弃那些有价值的软件工程原理、
概念、方法和工具吗?绝对不是。 和其他所有工程原理一样, 软
件工程也在持续发展着, 我们可以通过改进软件工程本身来适应
敏捷带来的挑战。
Alistair Cockburn[COC02a] 在他那本发人深省的敏捷软件开
发著作中,论证了本书第 2 章介绍的惯例过程模型中存在的主要
缺陷:忘记了开发计算机软件的人员的弱点。 软件工程师不是机
器人,许多软件工程师在工作方式上有很大差别, 在技能水平、
主动性、 服从性、 一致性和责任心方面也有巨大差异。 一部分人
可以通过书面方式很好地沟通, 而有些人则不行。 Cockburn 论
证说:过程模型可以 “利用纪律或者宽容来处理人的这一共同弱
点[COC02a] ”,因而大多数惯例过程模型选择了纪律。 他还指出:
“不能一致连贯地做同一件事是人性的弱点, 因而高度纪律性的
方法学非常脆弱 [COC02a] 。”
要想让过程模型可用, 要么必须提供可实现机制来维持必要的纪
批注[h1]:
批注[h2]:
批注[h3]:
律,要么必须向软件工程师以某种方式展示宽容。 显而易见, 宽
容实践易于被接受和保持, 但是(正如 Cockburn 所承认) 可能
产能低下。 正像人生中的大多数事情一样, 两者必须考虑平衡。
3.1 敏捷是什么
在 软 件工 程 工作 这 个环 境 下, 敏 捷是 什 么? Ivar Jacobson
[JAC02] 给出一个非常有用的论述:
敏捷已经成为当今描述现代软件过程的时髦用词。 每个人都是敏
捷的,敏捷团队是能够适当响应变化的灵活团队。 变化就是软件
开发本身, 软件构建有变化、 团队成员在变化、 使用新技术会带
来变化,各种变化都会对开发的软件产品以及项目本身造成影
响。我们必须接受“支持变化” 的思想, 它应当根植于软件开发
中的每一件事中, 因为这是软件的心脏与灵魂。 敏捷团队意识到
软件是团队中所有人共同开发完成的, 这些人的个人技能和合作
能力是项目成功的关键所在。
在 Jacobson 的观点中, 普遍存在的变化是敏捷的基本动力, 软
件工程师必须加快步伐以适应 Jacobson 所描述的快速变化。
“敏捷是动态的、内容独特的、勇于接受变化和面对成长的。 ”
—Steven Goldman 等
但是,敏捷不仅仅是有效地响应变化, 它还包含着对本章开头所
提宣言中哲学观念的信奉。 它鼓励能够在组员之间、 技术和商务
人员之间、软件工程师和经理之间进行更便利沟通的团队结构和
协作态度, 强调可运行软件的快速交付而不是中间产品 (这并不
总是好事情),将客户作为开发组成员以消除持续、普遍存在于
多数软件项目中的 “区分你我” 的态度, 意识到在不确定的世界
里计划是有局限性的,它必须是可以调整的。
敏捷可以应用于任何一个软件过程。 为了实现这一目标, 过程的
设计应使计划团队适应于任务, 并且使任务流水线化, 在了解敏
捷开发方法的流动性的前提下进行计划的制定, 消除所有最基本
软件产品, 精简软件开发过程, 强调这样一个增量传递策略: 尽
可能快的将切实可行的软件产品类型和运行环境交付给用户。
3.2 敏捷及变化的成本费用
软件开发的传统方法中 (有十年的开发经验作支持) 变化的成本
费用随着计划的进展成非线性增长(图 3.1 ,实的黑线)。这种
方方在软件开发团队收集需求时 (计划早期)相对容易适应变化。
一个应用场景需要修改, 一个功能表应该扩充, 或者一个书面说
明书需要编辑。 这项工作的费用是最小的, 所需的时间不会严重
影响计划的结果。 但是,如果我们激增数月的开发时间, 是由什
么引起?团队在进行验证测试当中, 一个重要的共利益者要求变
更一个的主要的功能。这一变更需要对软件的体系结构进行修
改,设计和构建三个新组件, 修改另外五个组件, 设计新的测试,
等等。费用迅速升级, 所需的时间和费用是为了保证变化不会引
起非预期的副作用,这并是件容易的事情。
敏捷的拥护者(例如, 【 Bec00 】,【Amb04 】)探讨,一个设计
合理的敏捷过程“拉平”了变化曲线(图 3.1 ,阴影,实线) ,
批注[h4]:
批注[h5]:
剩余41页未读,继续阅读
资源评论
wxj15659998286
- 粉丝: 1
- 资源: 10万+
下载权益
C知道特权
VIP文章
课程特权
开通VIP
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功