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

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

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

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

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

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

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


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

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

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

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

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

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

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

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


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

2018-04-22 23:09:48 qq_21791645 阅读数 1249
  • SCRUM敏捷开发视频教程

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

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

一、定义:

1.迭代开发:在迭代开发中,整个开发工作被组织为一系列的短小的、固定长度(如3周)的小项目,被称为一系列的迭代,这叫迭代开发。每一次迭代都包括了定义、需求分析、设计、实现与测试。

2.敏捷开发:敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。

二、区别:

1.性质不同:迭代开发是软件开发的生命周期模型,是一种开发过程;敏捷开发是多种软件开发项目管理方法的集合,是一种开发方法。这是两者最根本的区别。

2.开发方法模型不同:迭代开发对应的是瀑布模型,螺旋模型等;敏捷开发对应的是Scrum,XP(极限编程),Crystal(水晶编程)等开发方法。

3.对需求要求不同:迭代式开发适合那些需求信息不明确的项目;而敏捷开发是紧紧围绕用户需求,以用户为导向,以快速开发,快速验证,快速修正的迭代式开发打造大量精品。

三、联系:

1.开发方法:敏捷开发和迭代开发都有采用迭代的方法进行软件开发。

2.实际应用中的联系

a.敏捷开发的核心原则是拥抱变化,递增变化。迭代式开发适合那些需求信息不明确的项目,这样在开发过程中遇到需求的变化时,所带来的影响要比其他模型小。而现在的很多项目中,需求在项目进行中变化的事儿经常见,所以显得迭代式开发的优势更明显一些,这正符合敏捷开发的拥抱变化。而且迭代开发是不要求每一个阶段的任务做的都是最完美的,明明知道还有很多不足的地方,却偏偏不去完善它,而是把主要功能先搭建起来,以最短的时间,最少的损失先完成一个“不完美的成果物”直至提交,然后再通过客户或用户的反馈信息,在这个“不完美的成果物”上逐步进行完善,这正符合敏捷开发的递增变化。

b.敏捷开发只是一个总体概念,而迭代式开发只是几乎所有敏捷开发所采用的一个主要的基础实践。敏捷开发除迭代式开发外,还包含了其他许多管理与工程技术实践,如演进式架构设计、敏捷建模、重构、自动回归测试(ART)等等。总而言之,就是敏捷开发与迭代开发是整体与局部的关系,前者就像大家庭,而后者是大家庭中的一员

c敏捷迭代开发是对用户反馈的核心功能进行规划,从最小化可用产品 的用户试用反馈,到每个功能用户参与的反馈,形成 开发 、测试、 验证的快速循环。





2017-05-15 15:01:08 IBelieve1974 阅读数 281
  • SCRUM敏捷开发视频教程

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

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

如何在一个新的软件企业设计敏捷开发流程?


首先我认为敏捷是有刚需的,持续集成+自动测试是刚需。必须先具备这样的基础建设才能继续往下走。


如何设计敏捷开发流程,看看敏捷的要数,特别是5个活动:

首先定义Sprint周期,周期定了后,自然下面4个活动,就知道什么时候做了

  1. Sprint计划会议(Sprint Planning Meeting)
  2. 每日站会(Daily Scrum Meeting)
  3. Sprint评审会议(Sprint Review Meeting)
  4. Sprint回顾会议(Sprint Retrospective Meeting)
第5项活动是贯穿整个开发过程中的,通常在上一个Sprint就要把下一个Sprint的backlog梳理好。

   5. 产品Backlog梳理会议( Product Backlog Refinement)


角色和工件就不用说了。说一说除了代码开发过程中还要有什么产出:

1.  文档上,虽说敏捷是轻量化的流程,不代表没有文档。应该视不同团队,定义出足够用就好的文档。通常,需求文档是需要的,高层设计文档也是需要的。

2. DoD, 每完成一个backlog应该做完什么事,达到什么要求,这个是必须在PO和成员达成一致的认识,需要文档化下来。

3. 测试脚本,必须具备Fast Isolated Repeatable Self-verifying Timely (在代码之前写测试) 原则

4. 管理文档 Sprint计划表, Backlog依赖关系,集成计划,项目评审幻灯片等

5. 缺陷追踪记录  UT能cover的就不用记录了,如果是问题,但是现在不能解决的,要记录。



3个角色

  1. 产品负责人(Product Owner)
  2. Scrum Master
  3. Scrum团队

3个工件

  1. 产品Backlog(Product Backlog)
  2. SprintBacklog
  3. 产品增量(Increment)

5个活动

  1. Sprint计划会议(Sprint Planning Meeting)
  2. 每日站会(Daily Scrum Meeting)
  3. Sprint评审会议(Sprint Review Meeting)
  4. Sprint回顾会议(Sprint Retrospective Meeting)
  5. 产品Backlog梳理会议( Product Backlog Refinement)

2019-05-12 23:37:00 zhuyacheneagle 阅读数 326
  • SCRUM敏捷开发视频教程

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

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

什么是软件设计

软件系统的源代码是它的主要设计文档,我们可以使用各种工具比如UML来描绘软件系统结构,但它最终体现为源代码。

敏捷开发的作用和设计方法

关于敏捷开发,大家可能会有如下疑问:
1、敏捷开发往往微小增量迭代,那么会不会忽视全局视图?
答:在敏捷开发中,全局视图和软件是一起演化,因为预测需求是徒劳的,所以更应该关注当前需求。

2、如何设计,确保软件具有灵活性、可维护和重用性的结构?
答:
(1)迭代设计,不断改进使得它尽可能适合当前系统,确保灵活性。
(2)避免臭味,确保可维护。
(3)遵循面向对象设计原则,确保重用性。

拙劣设计的症状(臭味)

项目起初,系统设计也许还是清晰的,随着需求变化,臭味增多,系统越来越难维护,重新设计也大多失败。我们需要设法使得设计对需求变化具有弹性,并且应用一些实践防止设计腐化。使用单元测试辅助。团队持续的改进设计,每次迭代结束生成的系统最适合于本次需求。

僵化性:设计难以改变,因为即使简单的改动都会导致有依赖关系的模块的连锁改动。

脆弱性:设计易于破坏,对系统的改动会导致系统中与此无关的模块出现问题。

牢固性:设计难以重用,很难分离出可在其它系统重用的模块。

粘滞性:难以做正确的事情,比做错还难。

不必要的复杂性:过分设计,过多的为可能性的需求做准备,也许永远用不到。

不必要的重复:拷贝、粘贴,当同样的代码一再出现,表示忽视了抽象。

晦涩性:混乱的表达,代码难以理解。

面向对象设计原则

单一职责原则(SRP)

开放——封闭原则(OCP)

Liskov替换原则(LSP)

依赖倒置原则(DIP)

接口隔离原则(ISP)

臭味与原则的关系

上述的臭味往往就是违反了上述原则,应用原则可以消除臭味。 没有臭味就没必要死板遵循原则,随意乱用会造成复杂性。

什么是敏捷设计

敏捷设计是一个过程,而不是一个事件。它是一个持续的应用原则、模式以及实践来迭代的过程。它致力于保持系统设计在任何时候尽可能简单、干净、富有表现力。

如何做到敏捷设计

1、遵循敏捷实践去发现问题
2、应用设计原则去诊断问题
3、应用设计模式去解决问题

敏捷开发

阅读数 2946

敏捷开发实践总结

阅读数 179

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