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

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

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

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

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

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

    使用代码表达设计,详细设计时直接通过编写代码以及代码注释来表达自己的设计思路。
    在详细设计过程中,产生如下具体产物:
    • 设计实体类
    • 设计前后端调用方式以及数据格式
    • 设计业务接口。就是定义输入和输出,以及业务接口的实现方式
    • 设计数据库访问层接口
    • 设计数据库表结构,字段、字段类型、索引等。
    UML:适用于系统设计、详细交流设计、设计评审、系统设计文档等。
    代码:适用于敏捷开发中的详细设计
    展开全文
  • 敏捷开发中文档的取舍 先说需求文档,分为两部分,一方面是框架性的需求文档功能、交互方式、出错或边界情况的表现进行总体描述,这种文档不需要过于细致,因为产品经理组织语言写文档,开发读文档,理解文档都...

    敏捷开发中文档的取舍

     先说需求文档,分为两部分,一方面是框架性的需求文档,对功能、交互方式、出错或边界情况的表现进行总体描述,这种文档不需要过于细致,因为产品经理组织语言写文档,开发读文档,理解文档都要消耗大量时间,最好是以总体概括的方式来做,开发在做需求设计时候与产品人员进行频繁密切沟通,最终一起形成完整文档,这中间开发、测试人员对于文档严谨性是有很大贡献,不必要求产品经理全部把边界细节都写出来。另外一方面,作为良好的协作习惯,任何沟通产生的结论都应该存档!邮件是一种比较好的形式。每次会议结束,问一句结论呢?谁出纪要?不是说文档不重要,而是通过见面沟通,把需要文档描述很细节的内容达成共识。概要设计详细设计,视需求逻辑难易,规模大小而定。逻辑复杂的项目,概要设计作为帮助开发理解需求的一种手段。大型项目,详细设计架构设计不可避免。一句话规模的需求,随便做做就算了。这其中都要不断的当面沟通!  
    

    文档的功能

    追本溯源,我们应该先问的是“为什么要文档?”,我相信答案应该是“为了沟通”。关于沟通,有一个图表,大家应该知道:“沟通渠道丰富度和沟通成效的关系”
    

    沟通

     图上的虚实两条曲线,大家只需要关心上下两个端点即可:最左下角“Paper”,也即基于纸面阅读的单向交流,是沟通效果最差的;而右上角“面对面交流”,则是效果最佳的。
    基本上也是因为这个原因,在[敏捷宣言](http://agilemanifesto.org/iso/zhchs/principles.html)遵循的原则中明确说到:“不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。”
    

    关于敏捷文档,敏捷大师 Scott Ambler 有一篇著名的文章详细探讨了这个话题:

    Agile/Lean Documentation: Strategies for Agile Software Development

    敏捷开发是不是不用写需求分析、概要设计、详细设计之类的文档了啊?
    概要设计文档、详细设计文档是源自传统软件工程的说法。  
    如今传统的 Word、PDF 版的详细设计文档通常可以省略,大部分这类文档可以结合代码注释用工具自动生成,Web/HTML 版的详细设计/代码参考文档才是更好的做法。在敏捷开发中,需求文档、概要设计(改成架构设计)文档通常是不能省略的。
    
    展开全文
  • 开发要有开发文档(需求文档、数据库设计、概要设计)、开发计划(甘特图、燃尽图)、测试计划(时间、地点、人员、任务模块分配、禅道bug提交管理)都应该有一个时间段,在大家的一起商量之下可以每个人做到心中...

    故事情节

        最近第二次迭代时,我们带领的开发小组长文哲,这两天在补需求文档、部署文档(二次迭代完成了哪些客户需求?未完成的?),在迭代开发之前就应该有一个文档即是不全,那该多好啊,不用现在这么着急的补充啦。

        思考:倘若没有文档,给客户迭代完后,如何表明我们所做的内容呢?客户是否满意呢?如果没有文档,和客户的交流验收时就很难办了?


    到底要不要写文档?


        记得合作开发的时候,前期花费了很长时间,我们是采用了传统的瀑布模型,需求文档、概要设计、详细设计、数据库设计、甘特图等文档都是前期设计全了,遵循着文档驱动开发,当我们开发过程中到最后,发现文档、图、解决方案根本对不上了,中间修改了很多,相差很多,再验收以前我们三个是饿补啊,在整个开发的过程中由于前期的设计不可能考虑的很详细,每一步不可能考虑的很清楚,最后的文档成了我们头大的问题。


    初设敏捷开发


        自从接触了敏捷开发,我们就体会到这个开发思想不提倡写文档(很爽啊,先开发,当初理解的浅显)我们现在根据客户的需求拿来就开始干了,在这个过程中确实使用着禅道等项目管理工具,但是现在体会还是有些乱,规划的还有很多不合理的地方,给大家的每天的目标还不是很明确(时间段、任务、弹性时间、困难、该完成什么功能?)没有明确的规划,可能会引发项目拖延,时间一长大家会有懈怠心里啦。

        项目一开始,根据客户的需求我们就开始干了,设计、开发、等真正给客户架过去之时发现需求理解的不是很到位、使用还有常见的bug(测试文档没有)等,造成了没有给客户部署成功、我们浪费时间、给客户留下不好印象等等一系列问题,敏捷开发确实可以应对一些变化,但是因为文档不全的问题又一些给大家带来了苦恼。



        今天抽些时间查了敏捷开发的相关资料,敏捷并非不写文档,而是重视文档的作用,也重视文档的维护;它认为文档宜少且精炼,不需要冗余的文档;文档也是作为细化部分,在每个迭代过程中不断重构;一般需求文档、概要设计、详细设计、数据库设计、项目管理文档(甘特图等等)都是必须的,在许多外企的迭代开发中都是这样的,倒是国内的公司确实提倡一种:敏捷无文档,开发效率慢, 基本的文档都是必须的;敏捷开发中的写文档,有了方向性的指导。

    总结

      

        开发要有开发文档(需求文档、数据库设计、概要设计)、开发计划(甘特图、燃尽图)、测试计划(时间、地点、人员、任务模块分配、禅道bug提交管理)都应该有一个时间段,在大家的一起商量之下可以每个人做到心中有数,对任务整体有个全局观,我们每天该干什么?紧急重要的需求?客户迫切需要上线的功能?都有一个好的规划,避免在不必要的文档上(官话、客套话)浪费更多的时间,劲使在刀刃上,提高我们的开发效率,有明确的目标、去按照我们的计划一步步的完成。

        各个工作流自有它的价值……努力吧,继续深入理解敏捷开发理念!

    展开全文
  • 敏捷开发学习总结: 思考开发文档的利与弊 文档是个好东西,这是不可否认的,但是太依赖文档也有弊端,下面我从不同的度来分析一下文档的利与弊,然后思考在敏捷开发时,文档又是如何进行的。从 公司的角度来看,...
  • 在产品研发过程中经常需要编写很多文档,而敏捷宣言的第二条“可工作的软件胜于详尽的文档",那么需要编写文档吗?有没有简单的判断方法呢?
  • 我们比较熟知的软件项目管理方法是瀑布。其基本流程是需求-&...国外的软件先行者们针对瀑布开发中暴露出来的问题进行了一系列的探索、思考和总结,提出了Agile Dev的概念,中文翻译为敏捷开发。一.什么...
  • 写不写文档? 敏捷宣言更强调“可以工作的软件胜过面面俱到的文档”,但并不是...要理解敏捷开发的出发点不是不写文档只写代码,而是减少浪费,以便能按照自己项目的特点,灵活选择文档的数量,在过度设计和返工之间找
  • 敏捷的过程中,会有一种叫做产品需要设计文档的东东,简称PRD。最近在一次公司组织的内部培训会上,老师提供了一份PRD文档的模板,个人觉得这个PRD模板比较轻量,现在分享给大家。 1、概述 产品概述及目标 名词...
  • 软件项目中有很多种文档,包括需求文档、设计文档、API文档、缺陷报告、进度报告、移交文档、验收文档等等。  在传统的软件项目开发中,每个团队成员都要花费很多时间和精力去维护文档及填写各种表格和报告。第...
  • 敏捷开发与没有规范,没有文档的代码编写者的区别 与某些观点相反,敏捷开发人员并非不按规则或限制编写代码的特立独行者。“牛仔编码”是缺乏规则和管理糟糕的迹象,并且很不专业。如果团队里面存在这样的编写代码...
  • 这几年关于敏捷开发在互联网企业中越来越广泛被使用到,运用的比较多的当属scrum敏捷开发和xp敏捷开发,人人都在谈论敏捷开发。那什么才是敏捷开发呢? 目录 什么是敏捷开发? 传统的开发模式和敏捷开发模式的...
  • 敏捷开发流程总结

    2010-07-20 15:36:00
     敏捷开发宣言—— 个体和交互 胜过 过程和工具 可以工作的软件 胜过 面面俱到的文档 客户合作 胜过 合同谈判 响应变化 胜过 遵循计划 虽然右项也有价值,但是我们认为左项...
  • 随着敏捷开发越来越流行,人人都在谈敏捷,人人也都在学习scrum等敏捷开发方法。。。当然,自己也是敏捷开发的实施者和受益者。
  • 最近被两次问到同一个问题:如果一...整体上讲,敏捷开发不希望存在设计和开发的分离,因为这样就会产生“设计文档”这种东西,而且因为两个团队分离,设计文档一定相当详尽,而且在交接的时候多半要进行评审,否则很难
  •  不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。  其中,敏捷测试部分也同以往的软件测试流程有所不同。这测试人员提出了新的要求,带来了新的挑战。 第一部分:敏捷软件开发简介 敏捷...
  • 1.严格把软件项目的开发分隔成各个开发阶段:需求分析,要件定义,基本设计详细设计,编码,单体测试,结合测试,系统测试等。 使用里程碑的方式,严格定义了各开发阶段的输入和输出。如果达不到要求的输出,下一...
  • 关于敏捷开发和CMMI的管理大家都各有心得,我就不在各自具体管理做阐述了,紧紧针对文档裁剪说的看法,首先敏捷开发强调的核心的东西是交流,但对于当今的项目开发来说,个人交流恰恰是个难点,做开发的基本上都是...
  • 这是敏捷开发智慧敏捷的第二篇。(之一,之二,之三,之四,之五,之六) 缘起“我们产品已经做完了,客户说要补上需求文档,可我们只有用户故事,这个文档应不应该写呢?”“没有这个文档,客户能验收吗?”“不能...
  • 敏捷开发的作用和设计方法 关于敏捷开发,大家可能会有如下疑问: 1、敏捷开发往往微小增量迭代,那么会不会忽视全局视图? 答:在敏捷开发中,全局视图和软件是一起演化,因为预测需求是徒劳的,所以更应该关注...
1 2 3 4 5 ... 20
收藏数 35,020
精华内容 14,008
关键字:

敏捷开发对详细设计文档