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

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

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

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

     

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

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

    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。

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

     

    总结

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

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

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


    总结


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

    
    展开全文
  • 最近被两次问到同一个问题:如果一个软件需要大量密集的设计工作,导致存在独立的设计和开发团队,应如何实施敏捷开发?整体上讲,敏捷开发不希望存在设计和开发的分离,因为这样就会产生“设计文档”这种东西,而且...

    最近被两次问到同一个问题:如果一个软件需要大量密集的设计工作,导致存在独立的设计和开发团队,应如何实施敏捷开发?

    整体上讲,敏捷开发不希望存在设计和开发的分离,因为这样就会产生“设计文档”这种东西,而且因为两个团队分离,设计文档一定相当详尽,而且在交接的时候多半要进行评审,否则很难保证开发团队能理解并按其编写代码,最终还可能会导致两个团队的矛盾。

    在敏捷开发中一般这样处理这种情况:将设计人员下放到开发团队中,由于他们一般技术水平高于开发人员,所以可以作为139团队的骨干(请参考“139团队”相关的博文),一方面继续自己的设计工作,另一方面带领自己的小组进行开发。由于两者关系拉近,设计文档即使不能被取消,也不会需要编写得过于详尽,尤其可以忽略那些“没有就开发不出来产品,而产品开发出来后就没用了”的内容。此外设计人员的高水平也会在日常工作中带动开发人员的设计意识,达到“设计人员在设计的同时考虑到如何开发,开发人员在开发的同时理解为何如此设计”的水乳交融的状态。

    对于真的需要多个人碰头才能完成的架构设计工作,则需要这几个负责设计的人员共同完成(就是139中的13人员)。这里顺便说另外一个刚刚被问到的问题:倘若敏捷团队是一个新建的项目人员还在扩张,应如何计划人力资源?答案是应该优先选择和招募骨干人员,让他们先把需求分析/架构设计这些困难的工作做起来(在Sprint0里边打基础,之后每个Sprint完善),之后在迭代中逐步吸纳初级人员,做过游戏开发的一定对这个过程不陌生。

    另一个相关的问题是:不要把一堆新手凑一个开发团队来独自做低级编码工作。这个喜欢玩球类运动的人一定知道:如果团队中没有高手带着,大家的水平并不会因为工作经验积累而有实质性的提升,相反引入若干高手指导其工作,才是让团队尽快成长的良策。这一点也支持将设计与编码团队合并的方案。

     

    点击下载免费的敏捷开发教材:《火星人敏捷开发手册

     

    展开全文
  • 开发要有开发文档(需求文档、数据库设计、概要设计)、开发计划(甘特图、燃尽图)、测试计划(时间、地点、人员、任务模块分配、禅道bug提交管理)... 各个工作流自有它的价值……努力吧,继续深入理解敏捷开发理念!
  • 在产品研发过程中经常需要编写很多文档,而敏捷宣言的第二条“可工作的软件胜于详尽的文档",那么需要编写文档吗?有没有简单的判断方法呢?
  • 这几年关于敏捷开发在互联网企业中越来越广泛被使用到,运用的比较多的当属scrum敏捷开发和xp敏捷开发,人人都在谈论敏捷开发。那什么才是敏捷开发呢? 目录 什么是敏捷开发? 传统的开发模式和敏捷开发模式的...
  • 敏捷开发需要哪些文档? 需求说明 对功能、交互方式、出错或边界情况的表现进行总体描述 1.画面图 2.数据图 3.需求说明 来源张永光的博客
  • 什么是敏捷开发

    2019-05-31 10:49:56
    简单地来说,敏捷开发并不追求前期完美的设计、完美编码,而是力求在很短的周期内开发出产品的核心功能,尽早发布出可用的版本。然后在后续的生产周期内,按照新需求不断迭代升级,完善产品。 是谁这么厉害,提出了...
  • SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践...
  • 敏捷开发流程总结

    2010-07-20 15:36:00
    Agile——敏捷开发,作为CMM神话崩溃后被引入的一套新的软件开发模式,这几年来被广泛引起关注,并被寄予厚望。敏捷开发在其他业界的应用是否理想不得而知,但以下总结了我所在公司的敏捷开发试验,希望可以...
  •  不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。  其中,敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求,带来了新的挑战。 第一部分:敏捷软件开发简介 敏捷...
  • 敏捷开发和迭代开发

    2018-07-10 17:20:56
    敏捷开发与迭代式开发是整体与局部的关系   敏捷开发敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发,在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过...
  • 敏捷开发与迭代开发

    2018-04-22 23:09:48
    2.敏捷开发敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。二、区别:1.性质不同:迭代开发是软件开发的生命周期模型,是一种开发过程;敏捷开发是多种软件开发项目管理方法的集合,是一...
  • 随着敏捷开发越来越流行,人人都在谈敏捷,人人也都在学习scrum等敏捷开发方法。。。当然,自己也是敏捷开发的实施者和受益者。
  • 敏捷开发 vs 传统模式

    2015-05-28 22:41:00
    说起敏捷开发,并不是因为敏捷而敏捷。这几年的敏捷开发已经被很多敏捷咨询服务商神话了,这个东西并不是神器,实施了就可以解决所有软件公司的问题,而是要结合自己公司的特点和问题摸索出适合自己的一套模式。 ...
  • 原型法和敏捷开发 原型法 定义:又称快速原型法,不属于敏捷开发。 根据需求用IDE实现基本功能,然后用户试用、补充和修改的重复过程,最后的版本再决定是demo还是正式版本。 分类 1. 抛弃型原型 - 此类原型在...
  • 敏捷开发初步了解

    2019-09-02 10:34:44
    敏捷开发  敏捷开发,现在大多数团队都在推崇敏捷开发模式  笔者最开始理解的时候,也在疑惑到底什么是敏捷开发,带来的好处又是什么?  笔者也只是一个入行没多久的新手,以下只是笔者自己对于敏捷开发的一些...
  • 传统的软件开发模式需要经历问题评估、计划解决方案、设计系统架构、开发代码、测试、部署和使用系统、维护解决方案等过程,如下图↓ 采用传统软件开发模式的最大问题是开发周期过长,迭代速度慢。移动互联网行业...
1 2 3 4 5 ... 20
收藏数 87,650
精华内容 35,060
关键字:

敏捷开发需要详细设计吗