您的位置：首页 > 其它

软件过程与方法---课堂总结3 第四章敏捷过程模型

2016-01-07 15:34 453 查看

第四章敏捷过程模型

（1）敏捷软甲开发宣言（2001年，敏捷联盟）
个人和交互重于方法和工具
--Individuals andinteractions over processes and tools
可工作的软件重于完备的文档
--Workingsoftware over comprehensive documentation
与客户的协作重于合同谈判
--Customercollaboration over contract negotiation
响应变化重于严格遵照计划
--Responding to change over following a plan
（2）惯性过程模型忽视开发计算机软件的人的弱点

ü 软件工程师在技能水平，主动性，服从性，一致性，责任心，沟通能力方面的极大差异
ü 人不能一致连贯的做同一件事
（3）惯性过程模型利用纪律或宽容来处理人的问题
ü 高度纪律性的方法不容易被接受和保持，非常脆弱
ü 宽容有可能造成产能低下
（4）敏捷（Agile)方法是一种以人为核心，迭代，循序渐进的开发方法，核心是适应客户需求的快速变化，即拥抱变化。
（5）敏捷方法强调迭代式开发，客户参与，小版本

4.1敏捷

（1）敏捷包括以下内容
l 有效地响应变化
l 鼓励建立便于沟通的团队结构和协作态度
l 强调可运行软件的快速交付而不是中间产品
l 强调客户作为开发成员的持续参与
(2)敏捷技术
l 用户故事 user story
l 结对编程
l 测试驱动开发
l 持续集成（对每个人的开发结果放在指定的工作目录）
l 迭代开发
l 。。。。。。
(3)敏捷的主要创新在于“社会工程”
l 敏捷的主要贡献在于它更多的思考了如何去激发开发人员的工作热情，这是在软件工程几十年的发展过程中相对被忽略的领域。
l 坦诚合作起始才是敏捷的精髓。
（4）敏捷提倡回归理性，破除两个迷信
l 软件开发可以成为生产线：
n 每个岗位的职责可以被明确定义，各个岗位之间接口同样可以被明确定义，大家只要各司其职，高质量的软件就可以被生产出来；
l 软件开发过程可以像建筑一样被准确的预测和计划。
（5）敏捷是“第三可银弹”
软件工程领域专家们始终在努力不懈的寻找银弹：
l 第一颗：面向对象
l 第二颗：CMM/CMMI
l 第三颗：敏捷（Agile）
（6）如何使自己敏捷？---12条原则

1.最优先的目标是通过尽早的，持续的交付有价值的软件来满足客户
2.即使在开发后期也欢迎需求变化。敏捷过程利用变更帮助客户取得竞争优势
3.频繁交付可用的软件，间隔从两周到两个月，偏爱更短的时间尺度
4.在整个项目中业务人员和开发人员必须每天在一起工作
5.以积极主动的员工为核心建立项目，给予他们所需的环境和支持，信任他们能够完成工作
6.在开发团队内外传递信息最有效率和效果的方法是面对面的交流
7.可用的软件是进展的主要度量指标
8.敏捷过程提倡可持续的开发速度。发起人，开发者和用户应始终保持稳定的步调。
9.持续关注优秀的技术和良好的设计能增强敏捷能力
10.简化---使必要的工作最小化的艺术---是关键
11.最好的架构，需求和设计产生于自我组织的团队
12.团队定期的对如何更加有效工作进行反思，并相应的调整，校正自己的行为
（7）敏捷与社会属性有关

作为一个社会工程，它的许多建议适合欧美的世纪情况有关，对目前的中国兵部完全适合。
l 良好的替代执业发展道路（较容易达到敏捷对“自组织团队”的要求）
l 完善社会福利体系
l 相对扁平的薪酬体系
（8）敏捷的实现要点：
l 允许项目团队调整并安排任务
l 理解敏捷开发方法的易变性并制定计划
l 精简并维持最基本的工作产品
l 强调增量交付策略
l 快速提供适应产品类型和运行环境的可运行软件

4.2敏捷过程

（1）敏捷过程强调的三个关键假设：
l 难以预测需求（代码运行前难以预测哪些需求是稳定的，哪些会发生变化？）
l 难以预测设计（构建验证前部指导究竟有多少设计？哪些是必要的？）
l 难以预测计划（计划时难以预测后面的工作）
如何解决以上问题：建立具有自适应性的过程，自适应地调整以应对变化
（2）敏捷过程与传统软件工程过程之争：

敏捷阵营
传统方法学家陷入了误区，乐于生产完美的文档而不是满足业务需要的可运行系统。

传统软件工程阵营
敏捷方法学家是一小撮自以为乐不起的黑客，他们妄图将其手中的玩具软件放大到企业级软件而制造出一系列轰动。

问题：
Ø 什么是最佳实现途径？
Ø 如何构建满足用户当前需要的软件，同时展示具有能满足客户长期需求的扩展能力？
兼顾两派的优点则双方都能得到很多好处，而相互诽谤则而这都将一无所获。
（3）敏捷过程中“人的因素”
l 敏捷开发关注个人的才智和技巧，根据特定人员和团队来塑造过程。
l 敏捷过程是可以满足人员及团队需求的过程模型。
敏捷开发是以人为核心的，是迭代的，是循序渐进的。
（4）有效的敏捷团队，其成员应具备的特点
ü 基本能力
ü 共同目标
ü 精诚合作
ü 决策能力
ü 模糊问题解决能力
ü 相互信任和尊重
ü 自我组织

4.3敏捷过程模型

所有敏捷过程模型都遵循敏捷软件开发宣言和敏捷原则，每种模型又各有特点：
极限编程（XP） 8%
SCRUM 49%
自适应软件开发 22%

4.3.1 XP 1

（1）XP（极限编程，eXtremeProgramming)由KentBeck在1996年提出，是一个轻量级的，灵巧的软件开发方法，使用面向对象方法作为推荐的开发范型。
l 适用于10人一下项目组，开发地点集中的场合。
l 广泛用于需求模糊和挥发性强的场合。
（2）XP的基本观点
软件开发是人与人合作进行的过程，因此成功的软件开发过程应该充分利用人的优势，而弱化人的缺点，突出人在软件开发过程中的作用。
（3）XP的核心价值观
沟通问题往往是由于开发人员与设计人员，设计人员与客户之间的沟通不畅造成的。
简单在系统可运行的前提下，做最简单的工作。时刻保持代码的简单，无冗余。
反馈尽快获得用户反馈，越详细越好，使得开发人员能够保证自己的成果符合用户的需要。
勇气“拥抱变化”对于用户的反馈，要用于对自己的代码进行修改，丢掉坏的代码。

（4）XP适用范围
xp适合规模小，进度紧，需求变化大，质量要求严的项目
功能需求可以固定的，可以作比较精确的需求设计的，生命周期很长的，超大型软件项目不适于适用XP方法。
n XP是一种高度动态的过程，它通过非常短的迭代周期来应付需求的变化。
n XP体现开发团队的人员价值，激发参与者的情绪，最大限度地调动开发者的积极性，提高开发的软件质量。

（5）XP过程框架

4.3.1极限编程2

XP包含4个框架活动 策划设计编码测试
（1）策划
l 建立用户故事
l 确定故事权值（优先级）
l 确定故事成本（开发周数）
l 确定一下个发布版本，排序待开发故事。
第一个发行版本发布之后，XP团队将计算项目的速度。项目速度用来帮助团队建立后续发行版本的发布日期和进度安排，同时判断整个项目是否存在过分承诺。
（2）设计
l 严格遵循KIS原则（keep it simple)
l 提供故事的实现原则（不多也不少，不做额外功能性设计）
l 组织和当前增量相关的对象和类，CRC建模（类名，类的职责，类的协作关系）CRC卡片
l 对设计困难的故事提出Spike Solution
l XP鼓励构建重构和设计重构
设计和编码同时发生。设计随着系统的构建连续进行，构建又为设计提供指导。
(3)编码
l 测试驱动开发（TDD) 代码未动，测试先行XUnit JUnit NUnit CPPUnit
l 结对编程两个人一起组队
l 持续集成每日集成
(4)测试
l 建立通用测试集，每日集成
l 使用测试自动实施框架，支持即时回归测试（黄金测试集）
l XP验收测试
(5)XP的12个优秀实践

ü 现场客户
ü 计划博弈
ü 系统隐喻
ü 简单设计
ü 结对编程
ü 集体拥有代码
ü 测试驱动
ü 小型发布
ü 代码重构
ü 持续集成
ü 每周40小时工作制
ü 代码规范

**现场客户
l 随时能联系到客户是XP方法的基本要求之一
l 所有阶段要求客户强参与
u 编写需求
u Release反馈
u 参与测试

**计划博弈（Planning Game)
(1)划分迭代周期
(2)要求结合项目进展和技术情况，确定下一阶段要开发与发布的系统范围
技术人员作出具体的成本和科技估计
客户根据成本和商务价值来选择要实现的特性

**系统隐喻（System Metaphor)
l 通过一个简单的关于整个系统如何运作的隐喻性描述(story)指导全部开发
l 隐喻可以看做是一个高层次的系统构想，通常包含了一席可以参照和比较的类和设计模式。
l XP不需要实现进行详细的架构设计。

**简单设计（Simple Design)
l XP认为：需求是会经常变化的，因此设计不能一蹴而就，应该是一项持续进行的过程。
l 简单设计应满足以下原则：
n 向开发人员清晰描述编码及其内在关系
n 尽可能包含最少的类和方法
n 不包含重复的代码
n 成功执行所有测试
**结对编程(Pair Programming)
（1）

一企业管理层次：
l Pares更有效的交流，相互学习和传递经验
l Pair Programming能更好的处理人员流动
开发层次：
l Pairs能提供更你好的设计质量和代码质量
l Pairs更强的问题解决能能力
开发人员自身：
l Pairs一起工作能带来更多的信心
l Pairs一起工作能带来更高的满足感

两个程序员，同一套设备，一起工作一个驾驶，一个导航
（2） 角色
（3） WHY？可以提高质量
（4） Who not suitable do?
（5） Xper's Quality?
（6） HOW TO

二
l 提供不间断的Design review ,UnitTest Review,Code Review,Document Review提高代码质量。
l 互相督促可以提高代码的可读性和可维护性
l 培养Teamwork精神，避免个人英雄主义
l 频繁的交流，增进知识经验的交流

三
l 角色呼唤可以让程序员轮流工作，从而避免出现过度思考而导致观察力和判断力出现偏差。
l 同伴的潜在压力，使得程序员更认真的工作。
l 每个人每天的有效工作时段不超过3-4个小时。
l 潜意识的有利竞争。当人在一个团队中工作，总是下意识的努力展现自己的优点。
l 工作及时得到同伴的肯定，自信心和成就感增强。
l 觉得工作是一件愉快的事情

四不适合的人：

太过自负
l 不能容忍别人的一件
l 我总是对的
l 我吃盐多过你吃米
太过自卑
l 没主见
l 没责任心

五XPer应该具备的基本素质：
诚实，公正，开明，勇敢，谦卑
在这些素质的基础之上，才是对技术水平，能力和天分等的要求。

(6)HOW TO 结对编程?
l Driver
u 写设计文档（class diagram等）
u 编码（unit test and businessobject)
l Navigator
u 审阅Driver的文档
u 审阅代码
u 考虑Unit Test的覆盖程度
u 是否需要和如何Refactoring
u 帮助Driver解决具体的技术问题
l 不断轮换角色，每小时休息15分钟
l 主动参与
**集体拥有代码
（1）开发小组的每个成员都有更改代码的权利，所有的人对于全部代码负责
这并不意味着开发人员可以互相推诿责任，而是强调所有的人都要负责。如果一个开发人员的代码有错误，另外一个开发人员也可以进行BUG的修复
**测试驱动
（1）先测试，在编码，代码未动，测试先行
l Unit Test （正常性和异常性）
l Acceptance Test(Functional Test)
l Regression Test （重用已经建立的所有的测试单元）
l Nightly Test
l Stress Test
（2）所有的测试都应该独立的自动的运行
**小型发布
在非常短的周期内以递增的方式发布新版本，从而可以很容易地估计每个迭代周期的进度，便于控制工作量和风险；同时，也可以及时处理用户的反馈。
**代码重构（Refactoring）
（1）强调代码重构的作用，认为应该经常进行重构。
代码重构是指在不改变系统行为的前提下，重新调整，优化系统的内部结构以减少复杂性，消除冗余，增加灵活性和提高性能。
（2）Why Refacing？
l 是对软件内部结构的一种调整，目的是在不改变外部行为的前提下，提高其可理解性，降低其修改成本。作用：
l 改进软件设计
l 提高代码质量，使其更易被理解
l 提高开发速度
（3）When Refactoring？
1.添加新功能时
2修补错误时
3 Code Review时
通常有两个关键点应该进行重构；
一个功能实现前和实现后。
（4）When No Refactoring？
1.代码太混乱，设计完全错误
2明天是DeadLine
3 Refactoring的工作量影响最后的期限
（5）Refactoring Vs Add New Feature
Add New Feature：不应该修改既有代码，只管添加新功能。
Refactoring：不能再添加功能，只管改进程序结构。此外你不该添加任何测试（除非发现有先前遗漏的东西）
（6）Refactoring Vs Design
设计难以贯穿软件开发全过程
需求改变---------》设计变更，
How About our Codes？用重构去辅助设计！！
（7）Refactoring Vs Performance
重构常常会使软件运行更慢，但它也使软件的性能优化更易进行。
当你拥有了重构的经验，你也就有能力在重构的基础上来改进程序的性能。
（7） How toRefactoring ？
《重构—改善既有代码的设计》[美]Martin人民邮电出版社
l 重新组织你的函数
l 在对象之间搬移特性
l 重新组织数据
l 简化条件表达式
l 简化函数调用
l 处理概括关系
**持续集成
提倡在一天中集成系统多次，而且随着需求的改变，要不断的进行回归测试。因为，这样可以使得团队保持一个较高的开发速度，同时避免了一次系统集成的恶梦。
**每周40小时工作制
要求项目团队人员每周工作时间不能超过40小时，加班不得连续超过两周，否则反而会影响生产率。
不加班，不熬夜。
**代码规范
强调通过制定严格的代码规范来警醒沟通，尽可能减少不必要的文档。
没有一个统计的编码规范会造成团队的每一个成员无法迅速的掌握其它开发人员写出的代码，影响团队整体的协作性。

4.3.2 Scrum 1（橄榄球）

（1）Scrum是一个轻量级的敏捷开发框架，是一个增量的，迭代的开发过程。其核心准则就是自我管理和迭代开发。
l 自我管理：管理者不再发号施令，由团队自己寻找最佳的工作方式完成任务
l 迭代开发：项目由若干个开发周期构成，每个周期均提交一个系统的增量版本
（2）Scrum目标
ManageComplexity,Unpredictability and Change through Visibility,Inspection andAdaptation通过高透明性，检验和适应性来管理复杂性，不可预测性和变化。
（3）SCRUM的核心价值观
承诺：建立在目标之上的来自内心的接受和应许
专注：不准一注意力，把经理全部集中在承诺的事务上
公开：保持一直让任何有兴趣的人员都可以获知项目当前状况
尊重：每个团队成员都必须被尊重的看待，大家一起制定工作规范
勇气：为负责任的交付产品，有足够的勇气来说”不“
（4）SCRUM的运作原理
哲学基础
授权于开发团队，满足客户需求。
管理文化
帮助他人完成目标
技术工具
通过学习过程作出基于适时的决策。
沟通和反馈是一切的基础，即时的反馈是拥抱变化的前提条件。
（5）SCRUM框架

Scrum的三个角色、Scrum的五个仪式和Scrum的四个工作

（6）Scrum的产品Backlog

l 产品Backlog是按照商业价值排序的需求列表

l 列表条目的体现形式通常为用户故事

l 产品呢负责人负责产品Backlog的内容，可用性和优先级排序

l 产品Backlog的内容和排序都是动态的

（7）SCRUM的Sprint

ü Sprint的长度通常为2-4周，一旦确定不允许延长或缩短。

ü 每个Sprint中，团队从产品Backlog中挑选最有价值的需求进行开发，一个Sprint周期内需求不发生变更。

ü 团队构成和质量目标在Sprint中均保持不变

ü 在每个迭代结束时，Scrum团队将交付潜在可交付的产品增量。

ü Sprint之间没有时间间隔。

4.3.2 Scrum 2

（1）Scrum的三个角色
**产品负责人（Product Owner）
Ø 确定产品功能，负责提出和维护产品Backlog
Ø 决定产品的发布日期和发布内容
Ø 为产品的投资回报率（ROI）负责
Ø 根据市场价值确定功能优先级
Ø 在每个Sprint开始前调整功能和调整功能优先级
Ø 在Sprint结束时接受或拒绝接受开发团队的工作成果
**Scrum Master
Ø 保证团队资源完全可被利用并且全部是高产出的
Ø 保证各个角色及职责的良好协作
Ø 解决团队开发中的障碍
Ø 作为团队和外部的接口，屏蔽外界对团队成员的干扰
Ø 保证开发过程按计划进行，组织会议
Ø 记录每天完成的工作量，更新燃尽图
**Scrum团队
SCRUM团队负责在每个Spring中将产品Backlog中的条目转化成为潜在可交付的功能增量
Ø Scrum团队的规模控制在5-9个人
Ø Scrum团队是跨职能的团队
Ø Scrum团队是自组织的
（2）Scrum的五个仪式
**发布计划会议
Ø 确立项目整体发布目标和预期结果
Ø 确定具有最高优先级的产品Backlog条目，重大风险和发布所包含的全部特性和功能
Ø 确立大致交付日期和费用，以每个Sprint为基础调整发布计划
Ø 产品负责人确定产品Backlog的优先级排列
Ø 团队成员为产品backlog条目做工作量估算
Ø 使用计划指派进行工作量估算
Ø 工作量估算的单位为“故事点”
Ø 一个故事点相当于理想的1个人天的工作量
**Sprint计划会议（8小时以内）
Ø 把既定产品Backlog，Sprint时间表，Sprint评审会议的结果，Sprint回顾会议的结果公开给所有人
Ø 产品负责人向团队阐述产品愿景，介绍最高优先级的产品Backlog条目
Ø 团队选择产品Backlog条目，确定Sprint目标
l 利用“昨日天气”计算“投入程度”（focus factor)
(focus factor)=(actualvelocity)/(available man-days)
l 利用投入程度计算本次Sprint中可以完成的“故事点”
(availableman-days)*(focus factor)=(estimated velocity)
Ø 团队成员将Backlog分解为多个1天以内可以完成的任务，考虑所有工作细节，调整目标
Ø 任务列表构成Sprint Backlog
**每日站会（15分钟）
团队成员间工作进度的沟通和协调
Ø 维护Sprint Backlog上的所有任务（增删改，重新排序）
Ø 确认任务状态（“待处理”，“正在处理”，“已完成”）
Ø 问题：
ü 上次会议时的任务哪些已经完成？
ü 下一次会议之前，你计划完成什么任务？
ü 有什么问题阻碍了你的开发（如果有阻碍你开发进度的问题，把该障碍加入到障碍Backlog中）
“任务板”

**Sprint评审会议（4小时）
根据本Sprint所发布的版本，评审相关Backlog中的条目，检查是否已达到Sprint的目标。
Ø 团队按Sprint Backlog中的条目，逐个的介绍结果，演示新功能。
Ø 如果产品负责人想改变或对功能有新的想法，则添加新条目到产品Backlog中
Ø 如果小组报告项目遇到问题现在还没能解决则把该问题加入到障碍Backlog。

**Sprint回顾会议（3小时）
通过总结以往的时间经验来提高团队生产力
Ø 回顾会议以头脑风暴的方式Review Sprint过程和结果，发现和列举存在的问题
Ø 与会人员投票决定需要在下个Sprint中解决的1-3个问题，探讨解决方案，确定时间方式。
ü 本次Sprint中最为重要的是什么？
ü 成功经验是什么？
ü 有什么地方能够改进的？

（3）Scrum的四个工作
l 产品Backlog
l SprintBackLlog
l 发布燃尽图
l Sprint燃尽图
**Sprint燃尽图
燃尽图（BURN DOWN CHART)是在工作完成之前，对需要完成的工作的一种可视化表示。
**发布燃尽图
Ø 前期：产品负责人整理业务需求，形成Product Backlog库
Ø 执行：
ü 以Sprint为单位迭代式的完成Sprint Backlog
ü 每个Sprint以Sprint Planning开始，通过每日例会跟踪进度和issue
ü Spirnt结束时进行评审，交付可运行的产品
Ø 后期：
ü 每个Sprint完成后，通过Sprint回顾发现问题和改进点
ü 制定下个Sprint要引入的新的实践
（4）Scrum特点：
l Scrum规定了一个非常简单的开发流程，是现有设计流程的总结。
l Scrum以团队为基础，是一种在需求迅速变化情况下迭代的，增量的开发系统和产品的方法。
l Scrum是一个控制由利益和需求冲突导致的混乱的流程。
l Scrum是改善交流并最优化合作的方式。
l Scrum是一种检测产品开发和生产过程中障碍并将其取出的方式。
l Scrum是最大化生产率的一种方法。
Scrum适用范围
Scrum适用于打印的项目到整个企业，可以以控制并组织多个具有相关性的产品开发，拥有超过千名开发者和执行者的项目实施过程。
Scrum能让每个参与者都对自己所做的工作以及自己做出的贡献感到骄傲，并让他们发挥到最佳水平。

（5）Scrum VS XP
l XP与Scrum是敏捷方法中被业界采用最为广泛的郎中实践。
l Scrum注重的是管理和组织实践，而XP关注的是实际的编程实践，两者都聚焦于信息价值流和信息沟通除了迭代长度稍有差别外，大多数Scrum实践与XP是兼容且相互补充。
组合使用Scurm和XP会有显著收获！
结对编程，测试驱动开发，持续集成等XP的最佳实践仍然可以在Scrum中使用。

4.4小结

（1）敏捷开发是一种以人为核心、迭代、循序渐进的开发方法
l 敏捷过程强调适应性而非预见性
l 敏捷开发方法“面向人”而非“面向过程”
（2）敏捷过程模型有利于解决惯性过程模型中的问题：
Ø 版本发布的时间越来越长
Ø 无法按时发布
Ø 发布最后阶段让软件稳定的时间越来越长
Ø 制定计划时间长，不准确
Ø 发布期间难以进行变更
Ø 质量持续恶化
Ø 稳定化阶段拼命加班挫伤士气
（3）敏捷开发的误区
l 误解一：敏捷对人的要求很高
l 误解二：敏捷没有文档，也不做设计
l 误解三:敏捷好，其他方法不好
l 误解四：敏捷就是XP，就是Scrum
l 误解五：敏捷很好，要制定标准，所有项目都要遵循这个标准

内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理

标签：

相关文章推荐

新的分享

章节导航

软件过程与方法---课堂总结3 第四章 敏捷过程模型

目录

第四章 敏捷过程模型