软件工程之敏捷方法回顾

最新推荐文章于 2024-03-13 07:30:00 发布

fanyamin

最新推荐文章于 2024-03-13 07:30:00 发布

阅读量577

点赞数

本文链接：https://blog.csdn.net/fanyamin/article/details/103160807

版权

软件工程发展历史上, 当软件变得越来越复杂时, 规模变得越来越大时, 失败的机率由此递增, 许多项目一再延期, 软件工程应运而生, 人们希望向建筑工程, 机械工程那样来定义和规范软件工程.

很难说在软件行业的过去流行一些做法不好, 软件工程中大部分理论都是对的, 但是由于软件本身所具有的复杂性和多变性, 僵化的流程, 硬性的规定难以适用所有的场景.

所以既然唯一不变的是变化本身. 我们的流程和方法也应该是着重于应对变化.

这里简单回顾一下我所经历的软件工程向敏捷过渡的过程.

软件开发一般有如下方法

1.编码修复方法Code-fix: 边写边改
2.瀑布式方法Waterfall: 概念-需求-设计-编码-测试
3.进化式原型化方法Evolutionary Prototypeing:迭代开发
4.分布交付方法Staged Delivery:
5.RUP方法: www.rational.com
6.MSF方法(Microsoft Solutions Framework): www.microsoft.com/business/services/mcsmsf.asp
7.敏捷方法: XP, FD, Scrum, ASD,DSDM,etc. 里程碑: FC,CC,CF,ER XP:http://www.extremeprogramming.org/

瀑布方法

我所在的公司中曾经长期施行一套软件工程周期方法 ERCM - Engineering Release Cycle Methodology

将软件开发过程分为需求分析, 设计,编码,测试等过程, 并以里程碑 milestone 来管理
共用如下里程碑

RC - Requirements Complete: 需求完成, 各方签署同意需求文档 (PRD/UI sign-off)
DC - Design Complete: 设计完成, 各方签署同意设计文档 (Design Spec sign-off)
FC - Feature Complete: 功能完成, 单元测试完成
CC - Code Complete: 代码完成, 集成测试完成
CF - Code Freeze: 代码冻结, 没有遗留严重的 bug
ER - Engineering Release: 工程项目正式发布

这套方法执行了若干年, 行之有效, 但是随着市场的变化, 竞争的激烈, 需求变化变更频繁, 它的问题暴露得愈加明显, 往往前松后紧, 不能及时的应对变化, 一旦在设计完成之后发生变化, 就会打乱原来井井有条的流程. 更要命的是, 在项目后期发现设计有重大缺陷, 或者与需求大相径庭, 需要推倒重来, 却发现时间已经远远不够了, 只能加班.

所以, 软件从业者逐渐认识到, 一次就全部想好,想周全, 并在项目开发过程中不再修改需求和设计, 几乎是一个不可能完成的美好梦想, 迭代式开发, 逐渐更新完善软件才是正道

IBM 公司为此提出了一套堪为完整的开发流程 RUP - Rational Unify Process
在

IterativeDevelopment

简单来说, 有四个阶段:

初始阶段
细化阶段
构建阶段
发布阶段

六个最佳实践:

1 迭代式开发

事先了解所有需求当然最好, 但是通常办不到, 分阶段增量式迭代开发的方案可降低返工成本

2 管理需求

永远铭记是用户设定需求, 可以引领和分析, 不可臆测, 需求应该有优先级, 有清晰的验收标准

3 使用组件

将整个系统拆分成组件, 在集成之前进行组件测试, 模块化的面向对象编程也有利于代码重用

4 可视化建模

用图表来表示所有主要的组件,用户, 和它们之间的交互, 比如UML 和简单的框图

5 验证质量

用单元测试, 集成测试, 端到端的测试, 以及度量分析来充分验证质量

6 控制变化

唯一不变的是变化, 变化对于项目应该是渐进的,可控的

敏捷方法

敏捷是一种方法, 代表一种精神, 让事情变得简单高效, 就象 XP 创始人 Kent Back 所说的快速地拥抱变化

所以敏捷的精神在于快速的应对变化, 告别冗长的流程, 专注于提供对于用户有价值的软件.

先回顾一下敏捷宣言及其提倡的原则

Agile Manifesto

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over Processes and tools
Working software over Comprehensive documentation
Customer collaboration over Contract negotiation
Responding to change over Following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Agile principles

The Agile Manifesto is based on twelve principles
Customer satisfaction by rapid delivery of useful software
Welcome changing requirements, even late in development
Working software is delivered frequently (weeks rather than months)
Close, daily cooperation between business people and developers
Projects are built around motivated individuals, who should be trusted
Face-to-face conversation is the best form of communication (co-location)
Working software is the principal measure of progress
Sustainable development, able to maintain a constant pace
Continuous attention to technical excellence and good design
Simplicity—the art of maximizing the amount of work not done—is essential
Self-organizing teams
Regular adaptation to changing circumstances

XP

在众多敏捷方法中, 最负盛名的当数极限编程 eXtreme Programming, 它所倡导的用户反馈, 持续集成, 测试驱动, 结对编程等最佳实践影响深远

Paste_Image.png

这是我当年作笔记时画的一张脑图

Paste_Image.png

参见 http://www.extremeprogramming.org

Kanban

看板据说最早来自丰田工作法, 有一个产品需求任务的优先级队列, PO(Product Owner 产品负责人) 负责需求分析并制定任务的优先级, 团队成员从中按优先级从高到低选取任务进行开发, 所有的任务都放在一个大的看板上

Paste_Image.png

Scrum

现在众多软件及互联网公司应用较多就是 Scrum 敏捷开发流程, 强调以相对固定的几周一个迭代周期(Sprint), 以跨职能,自组织的 Scrum team 持续交付对用户有价值的软件.
它比较强调节奏感, 仪式感, 可操作性强, 在多数互联网公司中广泛应用

Paste_Image.png

Scrum的过程

将整个产品的backlog分解成Sprint Backlog,这个Sprint Backlog是按照目前的人力物力条件可以完成的。
召开sprint planning meeting，划分，确定这个Sprint内需要完成的任务，标注任务的优先级并分配给每个成员。注意这里的任务是以小时计算的，并不是按人天计算。
进入sprint开发周期，在这个周期内，每天需要召开Daily Scrum meeting。
整个sprint周期结束，召开Sprint review meeting，将成果演示给Product Owner.
团队成员最后召开Sprint retrospective meeting，总结问题和经验。
这样周而复始，按照同样的步骤进行下一次Sprint.