敏捷开发中的详细设计_敏捷开发需要写概要设计和详细设计文档吗 - CSDN
  • 敏捷开发详细设计

    2013-03-28 10:23:57
    的软件周期来进行,随着敏捷开发方法和敏捷开发工具和技巧的发展,软件过程的 一些步骤被新的开发颠覆甚至忽略。 模块耦合度低的项目,开发人员往往在概要设计、项目结构建立之后,就拿着需求文档在做各自的子...
    传统的软件开发过程,总要按需求分析,可行性分析,概要设计,详细设计,测试,维护
    的软件周期来进行,随着敏捷开发方法和敏捷开发工具和技巧的发展,软件过程中的
    一些步骤被新的开发颠覆甚至忽略。
    模块耦合度低的项目,开发人员往往在概要设计、项目结构建立之后,就拿着需求文档在做各自的子模块,
    需要程序依赖和数据依赖不大,但是总体没有详细设计,这样的开发,表面上看来是比较快,开发周期短,
    代码一旦提交到测试环节,项目测试人员和项目经理就会发现,测试周期比计划中要长,长得多。
    在集成测试中,模块之间会出现数据同步性和完整性问题,引发的程序错误,这是必然的。
    不管你需求分析文档再怎样准确和完整详细,由于开发人员的水平不同,相同的需求,在不同人的手里,会有截然不同的实现,
    采用敏捷开发方法的开发,为了达到敏捷的目的,可采用两种方法
    第一种:设计人员应完成概要设计之后,把需求
    分给开发人员,让其完成详细设计,最后提交 类图,状态图,及IPO到设计人员,这个方法要求开发人员水平相对要高,有开
    发经验,设计人员在审核过程中可以开发人员交流使设计趋向完整并具全局性,适合模块较多的大项目,
    第二种方法:设计人员提交比详细设计简单的‘简明设计’,主要着重于比较复杂的详细算法,全局的业务管理,合法输入,预期输出,
    其它实现细节将被忽略,由开发人员自己完成。
    敏捷开发,在设计和实现上占用的时间,将是个矛盾,合理处理这个矛盾,将决定项目的成功与否,
    对于本人设想的开发方法,您如果有什么意见和想法,请您给我留言
    展开全文
  • 敏捷开发对软件架构设计产生了一定的影响,让人产生敏捷开发中“轻架构设计”的印象。文章就笔者经验,和大家一起讨论一下敏捷的架构设计这个话题。 首先,笔者认为敏捷开发是一种软件过程方法和工具,敏捷开发...

    原文地址: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。


    总结


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

    
    展开全文
  • 敏捷开发对软件架构设计产生了一定的影响,让人产生敏捷开发中“轻架构设计”的印象。文章就笔者经验,和大家一起讨论一下敏捷的架构设计这个话题。 首先,笔者认为敏捷开发是一种软件过程方法和工具,敏捷...

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

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

     

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

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

    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。

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

     

    总结

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

    展开全文
  • 这几年关于敏捷开发在互联网企业越来越广泛被使用到,运用的比较多的当属scrum敏捷开发和xp敏捷开发,人人都在谈论敏捷开发。那什么才是敏捷开发呢? 目录 什么是敏捷开发? 传统的开发模式和敏捷开发模式的...

    简介

    这几年关于敏捷开发在互联网企业中越来越广泛被使用到,运用的比较多的当属scrum敏捷开发和xp敏捷开发,人人都在谈论敏捷开发。那什么才是敏捷开发呢?

    目录

    1. 什么是敏捷开发?
    2. 传统的开发模式和敏捷开发模式的对比?
    3. 敏捷开发scrum的实施。

    什么是敏捷开发

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

    在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

    传统的开发模式和敏捷开发模式的对比

    瀑布模型:
    这里写图片描述
    优点:
    1. 为项目提供了按阶段划分的检查点。
    2. 当前一阶段完成后,您只需要去关注后续阶段.
    3. 它提供了一个模板,这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。

    缺点:
    1. 各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量。
    2. 由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发风险。
    3. 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
    4. 瀑布模型的突出缺点是不适应用户需求的变化。

    敏捷模型:
    这里写图片描述
    优点:

    1. 敏捷开发的高适应性,以人为本的特性。
    2. 更加的灵活并且更加充分的利用了每个开发者的优势,调动了每个人的工作热情。

    缺点:

    1. 由于其项目周期很长,所以很难保证开发的人员不更换,而没有文档就会造成在交接的过程中出现很大的困难。

    敏捷开发scrum的实施

    Scrum的英文意思是橄榄球运动的一个专业术语,表示“争球”的动作;把一个开发流程的名字取名为Scrum,相当于大家像打橄榄球一样迅速、富有战斗激情。而Scrum就是这样的一个开发流程。

    Scrum开发流程中的三大角色
    – 产品负责人(Product Owner)

    主要负责确定产品的功能和达到要求的标准,指定软件的发布日期和交付的内容,同时有权力接受或拒绝开发团队的工作成果。

    – 流程管理员(Scrum Master)

    主要负责整个Scrum流程在项目中的顺利实施和进行,以及清除挡在客户和开发工作之间的沟通障碍,使得客户可以直接驱动开发。

    –开发团队(Scrum Team)

    主要负责软件产品在Scrum规定流程下进行开发工作,人数控制在5~10人左右,每个成员可能负责不同的技术方面,但要求每成员必须要有很强的自我管理能力,同时具有一定的表达能力;成员可以采用任何工作方式,只要能达到Sprint的目标。

    scrum开发流程图

    这里写图片描述

    1、我们首先需要确定一个Product Backlog(产品需求列表),这个是由PO负责的(如图(一));

    2、有了Product Backlog列表,我们需要通过 Sprint Planning Meeting(Sprint计划会议) 来从中挑选出一个Story作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog;

    3、Sprint Backlog是由Scrum Team去完成的,每个成员根据Sprint Backlog再细化成更小的任务(细到每个任务的工作量在2天内能完成);

    4、在Scrum Team完成计划会议上选出的Sprint Backlog过程中,需要进行 Daily Scrum Meeting(每日站立会议),每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 Sprint burn down(Sprint燃尽图)(如图(二)和如图(三));

    5、做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本。

    6、当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品。

    7、最后就是 Sprint Retrospective Meeting(回顾会议),也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中;

    如图(一):
    这里写图片描述

    如图(二):
    这里写图片描述

    如图(三):
    这里写图片描述

    如图(四):
    这里写图片描述

    敏捷开发管理工具:teambition
    teambition

    参考

    敏捷开发之Scrum扫盲篇
    百度百科
    敏捷开发 模型讲解

    展开全文
  • 传统软件开发中详细设计: 模块内的数据结构进行设计。比如模块类、结构体的设计对数据结构进行物体设计。比如数据库表的设计,文件存储的设计,文件存储目录的设计每个模块进行详细算法设计。比如每个方法的...
  • 什么是敏捷开发

    2019-05-31 10:49:56
    敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。 简单地来说,敏捷开发并不追求前期完美的设计、完美编码,而是力求在很短的周期内开发出产品的核心功能,...
  • 敏捷开发和迭代开发

    2018-07-10 17:20:56
    敏捷开发敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发,在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。...
  • SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践...
  • 敏捷开发流程总结

    2010-07-20 15:36:00
    Agile——敏捷开发,作为CMM神话崩溃后被引入的一套新的软件开发模式,这几年来被广泛引起关注,并被寄予厚望。敏捷开发在其他业界的应用是否理想不得而知,但以下总结了我所在公司的敏捷开发试验,希望可以...
  • 敏捷开发中文档的取舍 先说需求文档,分为两部分,一方面是框架性的需求文档,对功能、交互方式、出错或边界情况的表现进行总体描述,这种文档不需要过于细致,因为产品经理组织语言写文档,开发读文档,理解文档都...
  •  不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。  其中,敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求,带来了新的挑战。 第一部分:敏捷软件开发简介 敏捷...
  • 敏捷开发与迭代开发

    2018-04-22 23:09:48
    2.敏捷开发敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。二、区别:1.性质不同:迭代开发是软件开发的生命周期模型,是一种开发过程;敏捷开发是多种软件开发项目管理方法的集合,是一...
  • 敏捷开发中QA如何做质量管理? 经常有人会问我,敏捷模式下,QA的职责是什么?QA有什么价值?我们还需要QA吗?敏捷转型遇到的问题,QA能帮助解决吗?这些问题以前也思考过,笔者就是QA出身的,曾经在中兴通讯做过...
  • 软件研发中敏捷开发和迭代开发的异同 在讲敏捷开发之前,先了解几个常见的软件研发模式 瀑布模型:瀑布模型的软件研发过程与软件生命周期一致,由文档驱动,两相邻之间存在因果关系,需要对阶段性的产品进行review。...
  • 在我的理解敏捷开发中最先需要实施的三项重要工作需求用户故事化,沟通站会制以及进度看板化,这三个如果实施好了,不管你是否在实施真正敏捷还是对当前项目管理方式的一种改进,都能在研发管理过程取得很大的...
  • 敏捷开发中的测试

    2017-03-20 16:24:16
    敏捷开发过程,很多时候测试人员就时常被当成项目无法加快的阻力,一下这边爆一个bug,那边有个缺陷,所以项目经理痛恨测试,程序员们也巴不得测试快快放行,让程序好好上线,但我们都知道没有测好的东西是不能硬...
  • 我们比较熟知的软件项目管理方法是瀑布。其基本流程是需求-&...国外的软件先行者们针对瀑布开发暴露出来的问题进行了一系列的探索、思考和总结,提出了Agile Dev的概念,中文翻译为敏捷开发。一.什么...
1 2 3 4 5 ... 20
收藏数 87,559
精华内容 35,023
关键字:

敏捷开发中的详细设计