2011-06-28 10:45:00 dollybol 阅读数 431
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10423 人正在学习 去看看 CSDN讲师

敏捷开发对软件架构设计产生了一定的影响,让人产生敏捷开发中"轻架构设计"的印象。文章就笔者经验,和大家一起讨论一下敏捷中的架构设计这个话题。 # G1 Y% K2 ~; ]; q% w
首先,笔者认为敏捷开发是一种软件过程方法和工具,敏捷开发本身并不能代表架构设计。这就好比建筑架构设计和建筑工程管理之间的差别一样,两者是建筑的两个方面。相同的软件行业也是类似的情况,软件架构设计描述的是事物本身,而敏捷开发描述的是创建这个事物的过程。所以敏捷开发和架构是没有直接替代关系的两个范畴。
% |, e: q! f' v
但敏捷开发后,架构设计(内容和形式上)还是有了一定程度的变化。
3 X0 E9 @' y3 U7 Q3 W7 Z& i( P1. 敏捷开发中架构设计的方式
# A% @' L0 j2 U1 M这里的架构设计方式,指什么时候进行架构设计,并以什么样的方式进行架构设计,如Iteration中新需求引入时,重构的方式,Code is Design的方式等。
! Z" C( n# {" Q5 C% p/ f( _# E* K! D/ d
下图描述了敏捷开发前和后架构方式:
8 y6 m) |/ n6 m1 Q* f/ d' c1 |

下载 (6.72 KB)

2009-7-7 09:16


0 O4 n& l& n+ H0 a8 ?# `

: L, I# ^$ I4 W" N1 [
上图中,敏捷开发后软件架构设计的方式产生了变化:敏捷开发把原先软件过程前期的架构设计,分散到了整个敏捷开发软件过程中
, ?6 p/ I. K& X  A+ E* v! l; M( T& [看到敏捷开发中分散化的架构设计,想起公司财务中的"马克威茨资产组合理论",用马克威茨这个诺贝尔大师的理论来解释敏捷开发中的分散架构形式,却也行得通。
' ]7 e) n  S3 }9 j7 I2 X; H
"马克威茨资产组合理论"中说道:可以通过分散投资使收益率不变而方差(风险)减少。通俗一点讲也就是不要把鸡蛋放在一个篮子里。资产组合分散化后,可以做到收益率不变的情况下,风险减少。
6 L! n8 L1 Y0 {" J9 m这里的风险指的是波动,也就是方差。这和软件工程中的风险有异曲同工之意,即软件工程中的风险指:需求的波动,数学化后就是需求的方差。然后可以按照统计定理推论出,把架构设计组合化,并分散化,有益于收益率不变的情况下,减少软件风险。(中间的推导过程省略,有兴趣的朋友参考相应文献)。
) A( S  q$ q2 h2 Q. Q如果按照资产组合理论,下面这些就是软件架构设计中的组合,把一次性软件过程前期30%(甚至更多)的架构设计,换成如下的软件架构组合:
5 a; D' m$ |( V% C) c! R; f
(1)引入新需求后的架构。每个Iteration中,新需求引入前,都可以进行构思和架构。
: c! o* y3 b+ _1 Z(2)重构产生架构。先让软件运行,再重构其代码。那么软件的架构随着重构自然而然的在软件过程中产生
2 [% J6 y7 N8 u* k2 V. y7 F(3)开发过程中的设计:以前是设计完后开发,现在是边设计边开发。
; D5 k2 h, N1 O  D(4)其他
! Y( d3 z: @7 L- D所以敏捷开发不是轻架构设计,而是依然注重架构设计。只不过架构的方式变化了,变得更加有效且风险更小。
: u% U" c8 a+ W* h$ k: m! x4 |! _0 X
2. 敏捷开发中架构设计的内容
' T+ w: V# K+ X/ z; a
传统的架构设计,包括架构和设计两个方面、其中设计可以包含详细设计,如详细的UML图(详细的类图,顺序图等),详细的API设计以及接口描述,存储层数据库表字段设计等等。
+ F2 }* |9 {% J3 f# W; L出于下面两个方面的考虑,敏捷开发不适合这种架构设计内容:
/ a& A6 R! ]: Z(1)在当今的快速变化的社会中,业务需求和技术也都快速变化着,在软件过程前期花费30%(甚至更多)的时间进行架构设计,要么开发出来的软件不符合市场需求,要么就是一旦需求变动,造成较大的改动成本。如,作者了解的一个电子商务产品,当前所做的功能都是两年前规划设计的,而且如有新需求发生,需要下个版本才会采纳,导致整个产品脱离市场和客户的需求。
. w. v& o) r6 /0 N. V; I+ J8 b
(2)架构设计包含两个方面,一是:架构,二是:设计。其中设计中的详细设计需要大量的时间,包含详细的流程,API,数据结构等设计。但软件开发阶段的Code编码阶段,同样蕴含了很多详细设计的内容,所以二者之间存在着Repeat Yourself的情况。换句话说,现在敏捷开发提倡Code is design,而以前是Design is code。但问题是,软件开发人员维护一套Design,外加一套Code,不堪重负,效率低。所以,现在是Code is Design盛行,敏捷盛行。
/ {9 L$ U7 |& @3 g& E
基于这两种原因,敏捷中将传统的架构设计分成:架构 + 设计
) P/ {$ P/ r+ }' l5 d(1)敏捷开发的架构保留架构部分
; V; W4 _8 V0 y
(2)转移设计到Code编码阶段、重构阶段、Unit Test阶段等。
! {4 L, B4 B, r1 o2 ~7 ~! z( [5 e
分离后,敏捷开发中的架构就轻装上阵,内容可以包括:
' k$ [0 G0 C! e9 }" [
(1)软件的架构层次,层次化是软件产品架构中很重要的一部分。
! I" v  ^9 E$ Z. D(2)产品和技术选型
2 p+ X/ B' D3 r& D; T3 T
(3)各个组件的结构,以及的关系
) v6 Q6 [( x2 ~
(4)重要模块,和重要类的说明。但无需设计全部的类,和类的方法。
" K. @# D& _$ C' z# R5 Z/ /9 o4 T! W(5)….
& /6 i8 c) d5 T" w
而详细设计阶段,则在Code编码和UT单元测试阶段进行。这个阶段重构很重要,重构使你的软件架构和组件结构自然呈现
; y( @+ P" X; l3 u0 f所以在敏捷开发中架构设计的内容发生了变化:敏捷开发中止于架构,轻详细设计。但详细设计不是消失不见了,而是转移到了开发阶段,也即是:Code is design。这样既能拥抱变化,又规避风险,又Don't Repeat Yourself。
8 H7 [' e# d+ v0 V5 e/ H
3. 敏捷开发中架构设计的人员
6 u& h: A4 D, {3 i& J% l. [
敏捷开发后,软件过程变化了,架构形式变化了,随之相应的人员的责任和需要素质也会变化。
5 `$ n  r+ K+ f
这里不说整个软件过程中的人员角色,以及职责和能力,如组长,经理,测试人员,开发人员等。这不是说这些的地方。可以另外的文章再继续。
% V2 /4 K- E4 ~1 L1 x, v& }/ j+ X
这里强调的是,敏捷开发架构设计变化后,对开发人员提出了更高的要求,要超越Code is Code阶段,达到Code is Design的要求。如上面我们分析,敏捷开发中架构设计内容变化后,一部分的设计职责转移到了开发人员身上。所以开发人员不仅需要是技术专家,不仅能够写很好的程序,还需要有架构设计思想和能力,能够在开发过程中不断重构出Design。
, |7 h* r  U! R. @/ M0 f* C总结
8 X: n' g8 j) W. ~  c, r" Y架构描述的是软件本身的结构,敏捷开发描述的是制造这个软件的过程,他们二者是软件科学的两条脉络,互相影响。不管敏捷与否,架构设计依然软件中最重要之一,是软件开发人员的进阶目标。

2013-09-11 14:29:06 rosemarylk 阅读数 33
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10423 人正在学习 去看看 CSDN讲师
http://developer.51cto.com/art/200907/134068.htm

软件架构设计描述的是事物本身,而敏捷开发描述的是创建这个事物的过程。所以敏捷开发和架构是没有直接替代关系的两个范畴。

 

 

敏捷开发对软件架构设计产生了一定的影响,让人产生敏捷开发中“轻架构设计”的印象。文章就笔者经验,和大家一起讨论一下敏捷中的架构设计这个话题。

首先,笔者认为敏捷开发是一种软件过程方法和工具,敏捷开发本身并不能代表架构设计。这就好比建筑架构设计和建筑工程管理之间的差别一样,两者是建筑的两个方面。相同的软件行业也是类似的情况,软件架构设计描述的是事物本身,而敏捷开发描述的是创建这个事物的过程。所以敏捷开发和架构是没有直接替代关系的两个范畴。

但敏捷开发后,架构设计(内容和形式上)还是有了一定程度的变化。

1. 敏捷开发中架构设计的方式

这里的架构设计方式,指什么时候进行架构设计,并以什么样的方式进行架构设计,如Iteration中新需求引入时,重构的方式,Code is Design的方式等。

下图描述了敏捷开发前和后架构方式:

敏捷开发前和后架构方式

上图中,敏捷开发后软件架构设计的方式产生了变化:敏捷开发把原先软件过程前期的架构设计,分散到了整个敏捷开发软件过程中

看到敏捷开发中分散化的架构设计,想起公司财务中的"马克威茨资产组合理论",用马克威茨这个诺贝尔大师的理论来解释敏捷开发中的分散架构形式,却也行得通。

“马克威茨资产组合理论”中说道:可以通过分散投资使收益率不变而方差(风险)减少。通俗一点讲也就是不要把鸡蛋放在一个篮子里。资产组合分散化后,可以做到收益率不变的情况下,风险减少。

这里的风险指的是波动,也就是方差。这和软件工程中的风险有异曲同工之意,即软件工程中的风险指:需求的波动,数学化后就是需求的方差。然后可以按 照统计定理推论出,把架构设计组合化,并分散化,有益于收益率不变的情况下,减少软件风险。(中间的推导过程省略,有兴趣的朋友参考相应文献)。

如果按照资产组合理论,下面这些就是软件架构设计中的组合,把一次性软件过程前期30%(甚至更多)的架构设计,换成如下的软件架构组合:

(1)引入新需求后的架构。每个Iteration中,新需求引入前,都可以进行构思和架构。

(2)重构产生架构。先让软件运行,再重构其代码。那么软件的架构随着重构自然而然的在软件过程中产生

(3)开发过程中的设计:以前是设计完后开发,现在是边设计边开发。

(4)其他

所以敏捷开发不是轻架构设计,而是依然注重架构设计。只不过架构的方式变化了,变得更加有效且风险更小。

2. 敏捷开发中架构设计的内容

传统的架构设计,包括架构和设计两个方面、其中设计可以包含详细设计,如详细的UML图(详细的类图,顺序图等),详细的API设计以及接口描述,存储层数据库表字段设计等等。

出于下面两个方面的考虑,敏捷开发不适合这种架构设计内容:

(1)在当今的快速变化的社会中,业务需求和技术也都快速变化着,在软件过程前期花费30%(甚至更多)的时间进行架构设计,要么开发出来的软件不 符合市场需求,要么就是一旦需求变动,造成较大的改动成本。如,作者了解的一个电子商务产品,当前所做的功能都是两年前规划设计的,而且如有新需求发生, 需要下个版本才会采纳,导致整个产品脱离市场和客户的需求。

(2)架构设计包含两个方面,一是:架构,二是:设计。其中设计中的详细设计需要大量的时间,包含详细的流程,API,数据结构等设计。但软件开发 阶段的Code编码阶段,同样蕴含了很多详细设计的内容,所以二者之间存在着Repeat Yourself的情况。换句话说,现在敏捷开发提倡Code is design,而以前是Design is code。但问题是,软件开发人员维护一套Design,外加一套Code,不堪重负,效率低。所以,现在是Code is Design盛行,敏捷盛行。

基于这两种原因,敏捷中将传统的架构设计分成:架构 + 设计

(1)敏捷开发的架构保留架构部分

(2)转移设计到Code编码阶段、重构阶段、Unit Test阶段等。

分离后,敏捷开发中的架构就轻装上阵,内容可以包括:

(1)软件的架构层次,层次化是软件产品架构中很重要的一部分。

(2)产品和技术选型

(3)各个组件的结构,以及的关系

(4)重要模块,和重要类的说明。但无需设计全部的类,和类的方法。

(5)….

而详细设计阶段,则在Code编码和UT单元测试阶段进行。这个阶段重构很重要,重构使你的软件架构和组件结构自然呈现

所以在敏捷开发中架构设计的内容发生了变化:敏捷开发中止于架构,轻详细设计。但详细设计不是消失不见了,而是转移到了开发阶段,也即是:Code is design。这样既能拥抱变化,又规避风险,又Don't Repeat Yourself。

3. 敏捷开发中架构设计的人员

敏捷开发后,软件过程变化了,架构形式变化了,随之相应的人员的责任和需要素质也会变化。

这里不说整个软件过程中的人员角色,以及职责和能力,如组长,经理,测试人员,开发人员等。这不是说这些的地方。可以另外的文章再继续。

这里强调的是,敏捷开发架构设计变化后,对开发人员提出了更高的要求,要超越Code is Code阶段,达到Code is Design的要求。如上面我们分析,敏捷开发中架构设计内容变化后,一部分的设计职责转移到了开发人员身上。所以开发人员不仅需要是技术专家,不仅能够写很好的程序,还需要有架构设计思想和能力,能够在开发过程中不断重构出Design。

总结

架构描述的是软件本身的结构,敏捷开发描述的是制造这个软件的过程,他们二者是软件科学的两条脉络,互相影响。不管敏捷与否,架构设计依然软件中最重要之一,是软件开发人员的进阶目标。

 

 

2016-02-03 17:00:08 wang15061955806 阅读数 5571
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10423 人正在学习 去看看 CSDN讲师

传统软件开发中的详细设计:

  • 模块内的数据结构进行设计。比如模块中类、结构体的设计
  • 对数据结构进行物体设计。比如数据库表的设计,文件存储的设计,文件存储目录的设计
  • 每个模块进行详细算法设计。比如每个方法的实现算法,对方法的实现画出流程图
  • 编写详细设计说明书。详细说明每个方法的输入和输出。
  • 详细设计评审报告。
现在公司都使用敏捷开发,认识敏捷开发:
  • 以用户需求进化为核心
  • 采用迭代、循序渐进的方法进行软件开发。
敏捷开发中详细设计的目标:
  • 让代码保持简洁。比如在详细设计时使用规范的命名来提高程序的可读性
  • 让设计拥抱变化。从需求的本质出发来设计类和方法,来提高它的灵活性
  • 在产品迭代中“越跑越块”。
详细设计对技术团队的好处:
  • 为构建高并发、高可用和高扩展的应用打下良好的基础
  • 在产品迭代中“越跑越块”。
  • 有效降低程序“推到重来”的概率
  • 减少产品运行中的错误。
详细设计对开发者个人的好处:
  • 更加清晰、严谨的逻辑思维能力。
  • 良好的面向对象设计能力。
优秀的详细设计,需要具备一下能力:
  • 良好的面向对象思维
  • 懂得如何在设计思路、开发周期、业务需求之间取舍
  • 熟悉产品技术架构模型
  • 深入了解产品行业,熟悉业务的细节,并能洞察业务未来
详细设计初学者的学习思路:
  • 从为每个方法、每个类起个好名字做起
  • 培养实现代码前,做详细设计的习惯
  • 让总结成为一种习惯
推荐书籍:
  • 代码整洁之道
  • 重构-改善既有代码的设计
  • 敏捷软件开发:原则、模式和实践
  • 设计模式(大话设计模式、设计模式之禅)
  • 高效程序员的45个习惯(团队管理、持续学习)
详细设计有“章法”,但没有“公式”
“章法”:规范,比如命名、注释等。
这些不是“公式”:设计模式、相同业务功能的经典案例等。

  • 详细设计永远把解决当前问题,放在第一位。
比如一个积分兑换系统实现使用积分可以兑换话费功能。此时我们会想到使用设计模式中的策略模式,以便支持各种规则的兑换。但是当前第一版的需求只是兑换话费,现在引入策略模式会增加代码的复杂性,是不值得的。
  • 详细设计中,欢迎“拿来主义”。优先考虑使用市面上的成熟产品。优点:节省大量的开发成本、时间成本、人力成本。缺点:个性化需求、依赖第三方,如果第三方软件不能使用,那么可能整个程序就无法使用。
如何表达设计
UML作为表达详细设计的缺点:
  • 团队成员都需要懂UML图
  • UML转换为代码,需要一定的时间
  • 在需求变化中,UML很难保持即时性
UML并不适合,在追求简单、快速、拥抱变化的详细设计中来表达设计。

文档作为表达设计的一种方式,完善的文档可以记录系统的设计过程和设计思路。在传统的软件开发中,通常把文档作为需求分析、概要设计、详细设计的产物。
优点:经验开发继承、加深系统了解、提高写作功底等。
缺点:开发周期增加、增加文档维护成本、很多开发人员不乐易等。

使用代码表达设计,详细设计时直接通过编写代码以及代码注释来表达自己的设计思路。
在详细设计过程中,产生如下具体产物:
  • 设计实体类
  • 设计前后端调用方式以及数据格式
  • 设计业务接口。就是定义输入和输出,以及业务接口的实现方式
  • 设计数据库访问层接口
  • 设计数据库表结构,字段、字段类型、索引等。
UML:适用于系统设计、详细交流设计、设计评审、系统设计文档等。
代码:适用于敏捷开发中的详细设计


2019-03-05 10:56:25 weixin_39835036 阅读数 305
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10423 人正在学习 去看看 CSDN讲师

敏捷开发对软件架构设计产生了一定的影响,让人产生敏捷开发中“轻架构设计”的印象。文章就笔者经验,和大家一起讨论一下敏捷中的架构设计这个话题。

浅谈敏捷开发中的架构设计!(干货)

 

首先,笔者认为敏捷开发是一种软件过程方法和工具,敏捷开发本身并不能代表架构设计。这就好比建筑架构设计和建筑工程管理之间的差别一样,两者是建筑的两个方面。相同的软件行业也是类似的情况,软件架构设计描述的是事物本身,而敏捷开发描述的是创建这个事物的过程。所以敏捷开发和架构是没有直接替代关系的两个范畴。

但敏捷开发后,架构设计(内容和形式上)还是有了一定程度的变化。

1. 敏捷开发中架构设计的方式

这里的架构设计方式,指什么时候进行架构设计,并以什么样的方式进行架构设计,如Iteration中新需求引入时,重构的方式,Code is Design的方式等。

下图描述了敏捷开发前和后架构方式:

浅谈敏捷开发中的架构设计!(干货)

 

上图中,敏捷开发后软件架构设计的方式产生了变化:敏捷开发把原先软件过程前期的架构设计,分散到了整个敏捷开发软件过程中

看到敏捷开发中分散化的架构设计,想起公司财务中的"马克威茨资产组合理论",用马克威茨这个诺贝尔大师的理论来解释敏捷开发中的分散架构形式,却也行得通。

“马克威茨资产组合理论”中说道:可以通过分散投资使收益率不变而方差(风险)减少。通俗一点讲也就是不要把鸡蛋放在一个篮子里。资产组合分散化后,可以做到收益率不变的情况下,风险减少。

这里的风险指的是波动,也就是方差。这和软件工程中的风险有异曲同工之意,即软件工程中的风险指:需求的波动,数学化后就是需求的方差。然后可以按照统计定理推论出,把架构设计组合化,并分散化,有益于收益率不变的情况下,减少软件风险。(中间的推导过程省略,有兴趣的朋友参考相应文献)。

如果按照资产组合理论,下面这些就是软件架构设计中的组合,把一次性软件过程前期30%(甚至更多)的架构设计,换成如下的软件架构组合:

(1)引入新需求后的架构。每个Iteration中,新需求引入前,都可以进行构思和架构。

(2)重构产生架构。先让软件运行,再重构其代码。那么软件的架构随着重构自然而然的在软件过程中产生

(3)开发过程中的设计:以前是设计完后开发,现在是边设计边开发。

(4)其他

所以敏捷开发不是轻架构设计,而是依然注重架构设计。只不过架构的方式变化了,变得更加有效且风险更小。

2. 敏捷开发中架构设计的内容

传统的架构设计,包括架构和设计两个方面、其中设计可以包含详细设计,如详细的UML图(详细的类图,顺序图等),详细的API设计以及接口描述,存储层数据库表字段设计等等。

出于下面两个方面的考虑,敏捷开发不适合这种架构设计内容:

(1)在当今的快速变化的社会中,业务需求和技术也都快速变化着,在软件过程前期花费30%(甚至更多)的时间进行架构设计,要么开发出来的软件不符合市场需求,要么就是一旦需求变动,造成较大的改动成本。如,作者了解的一个电子商务产品,当前所做的功能都是两年前规划设计的,而且如有新需求发生,需要下个版本才会采纳,导致整个产品脱离市场和客户的需求。

(2)架构设计包含两个方面,一是:架构,二是:设计。其中设计中的详细设计需要大量的时间,包含详细的流程,API,数据结构等设计。但软件开发阶段的Code编码阶段,同样蕴含了很多详细设计的内容,所以二者之间存在着Repeat Yourself的情况。换句话说,现在敏捷开发提倡Code is design,而以前是Design is code。但问题是,软件开发人员维护一套Design,外加一套Code,不堪重负,效率低。所以,现在是Code is Design盛行,敏捷盛行。

基于这两种原因,敏捷中将传统的架构设计分成:架构 + 设计

(1)敏捷开发的架构保留架构部分

(2)转移设计到Code编码阶段、重构阶段、Unit Test阶段等。

分离后,敏捷开发中的架构就轻装上阵,内容可以包括:

(1)软件的架构层次,层次化是软件产品架构中很重要的一部分。

(2)产品和技术选型

(3)各个组件的结构,以及的关系

(4)重要模块,和重要类的说明。但无需设计全部的类,和类的方法。

而详细设计阶段,则在Code编码和UT单元测试阶段进行。这个阶段重构很重要,重构使你的软件架构和组件结构自然呈现

所以在敏捷开发中架构设计的内容发生了变化:敏捷开发中止于架构,轻详细设计。但详细设计不是消失不见了,而是转移到了开发阶段,也即是:Code is design。这样既能拥抱变化,又规避风险,又Don't Repeat Yourself。

3. 敏捷开发中架构设计的人员

敏捷开发后,软件过程变化了,架构形式变化了,随之相应的人员的责任和需要素质也会变化。

这里不说整个软件过程中的人员角色,以及职责和能力,如组长,经理,测试人员,开发人员等。这不是说这些的地方。可以另外的文章再继续。

这里强调的是,敏捷开发架构设计变化后,对开发人员提出了更高的要求,要超越Code is Code阶段,达到Code is Design的要求。如上面我们分析,敏捷开发中架构设计内容变化后,一部分的设计职责转移到了开发人员身上。所以开发人员不仅需要是技术专家,不仅能够写很好的程序,还需要有架构设计思想和能力,能够在开发过程中不断重构出Design。

浅谈敏捷开发中的架构设计!(干货)

 

总结

架构描述的是软件本身的结构,敏捷开发描述的是制造这个软件的过程,他们二者是软件科学的两条脉络,互相影响。不管敏捷与否,架构设计依然软件中最重要之一,是软件开发人员的进阶目标。

2012-02-03 09:04:18 zhangym365 阅读数 495
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10423 人正在学习 去看看 CSDN讲师

敏捷开发作为当前越来越流行的开发流程,值得大家的借鉴和实践。但是对于敏捷开发中的架构师因该如何展开工作以及他们的工作职责是什么,查了一些资料,结合自己的实践做一些总结:


1、将系统分割成更小的部分,以及合理的架构边界和相互之间的接口

        在项目的执行任何时期,好的架构设计对于项目的健康的推进有着重要的意义,甚至决定了项目的成败,这个规律我觉得对于敏捷开发同样适用。通过将系统进行合理的划分模块可以将系统划分为更加简单的单元模块,降低系统的依赖和复杂新。通过合理的界定系统的边界和相互之间的接口定义等架构技巧,将系统分解为更小,更容易被实现和控制的单元,通过测试驱动开发(TDD)的方式推进,更容易降低产品的风险和加快开发进度。

2、时刻关注从更高的角度看待这些部分的重构和持续的改进工作

      项目执行过程中,不可避免的会产生所谓技术债务的问题,随着新的功能的加入,需求变更以及原先设计的不合理性以及问题更加明了等情况下,系统逐步变得更加复杂和难以维护。重构是持续改进是XP中对开发人员的基本要求。但是对于整个系统层面上大规模的重构需要经验丰富的架构师来进行搜索和评估。

3、亲自参与单元测试和程序的开发

      将大的结构分解成为小的,安全的步骤,并进行实现,是XP团队的重要挑战。但是架构师不能脱离具体的编程任务,通过自己的参与,才能更深层面的理解架构的演进以及把握重大重构的机会。

4、良好的团队沟通和信息共享

      架构师的架构设想需要在团队中进行贡献,个人觉得可以通过文档或者实现接口源码、沟通、会议的方式在组织中进行信息的传递和贡献工作。


这些职责我觉得同样适用非XP敏捷但是想借鉴敏捷开发理念的开发流程团队。

敏捷开发实践总结

阅读数 179

没有更多推荐了,返回首页