敏捷开发阶段 文档维护_敏捷开发最少需要维护哪些文档? - CSDN
  • 敏捷开发中如何维护文档

    千次阅读 2012-08-09 01:26:42
    软件项目中有很多种文档,包括需求文档、设计文档、API文档、缺陷报告、进度报告、移交文档、验收文档等等。 ...第二条敏捷宣言是"可工作的软件胜于详尽的文档",据此很多人想当然认为敏捷开发

    转自:http://www.infoq.com/cn/news/2009/02/agile-documents/

    软件项目中有很多种文档,包括需求文档、设计文档、API文档、缺陷报告、进度报告、移交文档、验收文档等等。

     在传统的软件项目开发中,每个团队成员都要花费很多时间和精力去维护文档及填写各种表格和报告。第二条敏捷宣言是"可工作的软件胜于详尽的文档",据此很多人想当然认为敏捷开发不重视文档。更有甚者,有人为逃避写文档而借口敏捷开发不需要文档,成为所谓的PAP(Pretty Adventuresome Programming)。其实这些人忽略了敏捷开发中有很多实践(比如坐在一起、现场客户、测试驱动开发、客户测试、结对编程、信息化工作间等等),敏捷借助这些实践进行信息交流,起到了文档在传统软件开发中的作用。本文通过分析项目开发中的文档类型与作用来说明敏捷开发中为什么很多文档是不需要的。

    首先,需要明确文档的用途,文档是用来交流信息的。关键是团队中信息分享是否及时准确,而这与文档的多少没有必然的联系。就比如James Shore在博文"文档之谜"(http://jamesshore.com/Blog/The-Documentation-Myth.html)里面指出的,很多人指责敏捷开发的文档不够。其实他们忽略了问题的实质,"丰富的文档并不一定是好事,能及时得到答案才是好的"(Myth: Document is good; Reality: Answer is good)。

    专业知识或者信息主要分为两类:

    • 可以被整理,文档化的知识,一般只占所有知识的30%。
    • 占70%的存在于人脑中的隐含(Tacit)知识,只能通过人与人之间的交流来分享,口口相传。因此促进团队内部以及团队之间的交流对信息的传播更加有效。

    软件项目文档通常有三种:

    • 项目文档,用于项目组内部信息交流,比如需求文档、设计文档、进度报告等。
    • 产品文档,通常是有业务价值的,是客户需要的,比如用户手册或者API文档。
    • 移交文档,在项目移交或者项目不同阶段之间移交的成果物。

    产品文档是客户需要的,是产品的一部分,有业务价值,绝对不能省略。应该在迭代中为其安排一个文档任务。

    从敏捷角度来看,另外两类文档中的很多种是可以简化或者省略的。

    在敏捷开发过程中,

    • 整个团队坐在一起,移交文档变得多余了。精益思想认为移交(Transportation)是很大的一种浪费(参见Mary Poppendieck,精益思想的原则http://www.poppendieck.com/papers/LeanThinking.pdf),首先移交文档会花费很大的精力,其次很多信息会在移交过程中丢失,另外每个阶段还总会添加一些新的信息。所有团队成员(PO, Dev, QA, Doc)坐在一起,用白板进行面对面的沟通,既省时又省力,还有效。(参见Alistair Cockburn,敏捷项目中的沟通 http://www.agilemodeling.com/essays/communication.htm
    • Product Owner跟团队坐在一起,随时回答团队成员的需求问题,是活的文档。
    • 在Sprint计划会议中,团队选择要完成的用户故事(Sprint Backlog上的小卡片),形成Sprint backlog,这其实就是迭代计划。
    • 在发布计划会议中,Product Owner会确定发布内容,形成故事墙,这其实就是较为长期的开发计划。
    • Dev和QA一起设计客户测试(一般用Fit类工具)。重要的用户逻辑被设计成客户测试。这种需求(客户测试)是可以运行的,因此永远不会过时(如果出现问题,持续集成系统立刻就会发出警报)。这比传统意义上的需求文档要有效得多。传统文档有太多的问题,比如很少会有人去测试文档的正确性,很少有人去及时更新文档,很少有人去检查需求覆盖率(其实根本没有办法检查,很多工具想当然的提供一些从需求到实现的追踪,但这岂不又是一种形而上学?)。
    • 在开发中微观的具体的逻辑可以设计成TDD(或者BDD,行为驱动开发http://behaviour-driven.org/))的用例,起到了详细需求文档或者设计文档的作用。
    • 开发人员使用结对编程(很多好处,参见"我喜欢结对编程" http://www.nomachetejuggling.com/2009/02/21/i-love-pair-programming/,以及 "结对编程:到底有多重要?"http://xprogramming.com/blog/2009/01/28/pair-programming-how-important-is-it/)。健康的系统架构应该是动态的,不断演进的。因此如果把它用文档固定下来,也会出现过期或者不全面的问题。在设计具体模块的时候,团队利用白板设计大体框架并确定方向,然后通过结对编程来具体实现。通过结对编程,可以很好的在团队中分享和演进系统架构信息。
    • 团队在每日站立会议中汇报进度,更新状态以及遇到的问题,所有信息会立刻反映到Sprint Backlog,Burdown chart以及各种图表上,成为信息化工作间的一部分,团队可以据此进行自我调整。
    • 每一次迭代之后举行反省会议,团队自我改进,也可以设计各种各样的手画表格(Ron Jeffries在个人网站上给了一些例子,http://www.xprogramming.com/xpmag/BigVisibleCharts.htm)来监控团队自身的问题。因此传统的审查及统计的文档就变得多余了。
    • 敏捷中高层次的需求通过愿景(Vision)文档体现,这种文档一般只有一页,变化的可能性不大,很容易维护。
    • 高层的系统架构图还是必要的。这种高层次系统架构变化的可能性也是很小的,维护成本也比较低。
    • 代码即文档。很多敏捷大师十分注重架构清晰度以及代码的可读性(比如Robert Martin总结的S.O.L.I.D原则,Robert Martin的Clean Code,以及Kent Beck的"实现模式")。在某种意义上我们写的代码其实就是指导计算机完成任务的式样书。式样书就是为了让别人容易读懂(要不然为什么不用二进制去编写程序,放到机器上就可以运行)。

    正如James Shore总结的,获得信息的手段有很多。

    最优的手段,代码清楚、单元测试完备、命名规范,因此根本不需要问;

    其次,只需要问一下旁边的人,或者打一个电话,就可以立刻得到答案,这也就是为什么敏捷鼓励“坐在一起”和“现场客户”r;

    再次,Google一下找到答案,这也不错;

    ……

    很次,可以通过读文档找到答案。可是为了找到答案,需要读的文档越多,效果越差...

    展开全文
  • 敏捷开发:编写开发文档的利与弊

    千次阅读 2018-09-03 16:49:35
    敏捷开发学习总结: 思考开发文档的利与弊 文档是个好东西,这是不可否认的,但是太依赖文档也有弊端,下面我从不同的度来分析一下文档的利与弊,然后思考在敏捷开发时,文档又是如何进行的。从 公司的角度来看,...

    敏捷开发学习总结: 思考开发文档的利与弊



    文档是个好东西,这是不可否认的,但是太依赖文档也有弊端,下面我从不同的度来分析一下文档的利与弊,然后思考在敏捷开发时,文档又是如何进行的。


    从 公司的角度来看,编写文档有如下好处: 
    a1) 公司使用的是瀑布生命周期(或序列式开发,传统开发),所以必然的,在某一个阶段,需要编写大量的文档作为进入下一阶段的输入。
    a2)过程改进的 需要,认为只要过程控制得足够细,例如只要文档编写得足够详细,那么人员是可以被替换的,也就是说,有了文档,人员的流动不会给项目带来大的风险。
    a3) 受到其它行业的启示,例如建筑行业,图纸制定好并确否没有问题后,施工队才能准确无误地施工,所以要求在编码之前先编写HD、DD文档,除了方便交叉 REVIEW,同时,文档用于指导资浅工程师的编码工作,文档只有编写的足够详细(DD最好给出伪代码),工程师才不至于走偏。
    a4) 企业知识库的建设需要,没有文档,技术就没有得到积累。


    从工程师的角度来看,为什么工程师有时不愿意写文档呢? 
    b1) 代码与文档的同步问题,很多设计文档在写完后就被代码远远地抛在后面了,开发人员只有二个选择,要不更新文档,要不任由文档逐渐地开始撒谎,如果选择维护 文档与代码同步,那么就会耗费大量的时间和精力在文档更新上面,而维护这份文档目的只是为了将来有可能有人需要阅读---也有可能无人问津。
    b2) 任务的工时安排得很紧,但编写文档又导致进度太慢。
    b3)认为文档太枯燥,不比编写代码有成就感。
    b4)没自信,怕文档写不好会误导别 人。
    b5)本身没有搞清楚思路,所以也就写不出文档。


    从敏捷开发思想的角度去看待上述的一些问题: 
    对应 a1) 这就是敏捷开发反对瀑布模型的原因之一吧。
    对应a2) 首先寄望于通过过程控制来达到开发人员可替换性目的这个想法,是有争议的 ,另外,极限编程中使用“代码集成所有权属于团队”的实践方法来保证团队内部的知识共享,从而减少人员流动对团队带来的风险。
    对应a3) 敏捷开发的建议是只写有用的文档,例如编写整个系统的HLD或架构文档是值得的,因为整个团队的成员以及新人都要阅读它来了解整个系统的架构和设计,而某 个模块的DD文档,它的读者只是负责该模块的程序员,敏捷开发的建议是面对面进行交流来传达设计比较来得快捷,不编写过于详细的DD文档的原因是它太容易 与代码脱节了,另外,面对面交流,并不是资深人员传达设计给资浅人员,而是让资浅人员参与到设计中来,是以平等的方式与资深人员一起讨论和确定最终的设 计。可是文档毕竟比起代码易于阅读,总得要有个载体描述模块的DD设计啊,一般来说是推荐“Self-Documenting ”的形式来代替DD文档。
    对 应a4) 轻量级的文档不代表不编写文档,所以这一点与知识库的建设不冲突。
    对应b1) 尽量使用“Self-Documenting”的形式,即将文档以注释的形式插入到代码中,来解决文档与代码的同步问题,需要文档时,再用工具从代码中提 取出文档,例如Java中的JavaDoc工具,而Qt的API文档也是这么干的,Qt的文档是用doxygen来生成的。
    对应b2) 这就是轻量级文档的原则所要解决的问题,除了避免编写无用的文档外,如何避免长篇大论的文档也是要解决的问题,我从UP开发方法的产出物(制品)中了解 到,UP开发方法使用的“用例驱动”方法将需求分析文档以“用例(Use Case) ”的形式来编写,减少了出现长篇大论的可能性。
    剩下的 b3,b4,b5是开发人员自身的原因。


    最好做个总结,文档是好东西,但它的弊端就是要花时间(包括写作和维护的时间),如果项目时间都比较紧,如何把握文档的量和细致程度,确实是值得思考和权衡的问题。

    展开全文
  • 敏捷开发与敏捷测试

    2020-07-02 15:25:48
    敏捷开发:1.敏捷型方法是“适配性”而非“预设性”。重型方法试图对一个软件开发项目在很长的时间跨度内作出详细的计划,然后依计划进行开发。这类方法在计划制定完成后拒绝变化。而敏捷型方法则欢迎变化。其实,...

     敏捷开发:1.敏捷型方法是“适配性”而非“预设性”。重型方法试图对一个软件开发项目在很长的时间跨度内作出详细的计划,然后依计划进行开发。这类方法在计划制定完成后拒绝变化。而敏捷型方法则欢迎变化。其实,它们的目的就是成为适应变化的过程,甚至能允许改变自身来适应变化。2.敏捷型方法是“面向人”的(people-oriented) 而非“面向过程”的 (process-oriented)。 它们试图使软件开发工作顺应人的天性而非逆之。它们强调软件开发应当是一项愉快的活动。

      我认为以上两个特点很好的概括了敏捷开发方法的核心思想:适应变化和以人为中心。

      敏捷开发其实借鉴了大量软件工程中的方法。迭代与增量开发,这两种在任何一本软件工程教材中都会被提到的方法,在敏捷开发模式中扮演了很重要的角色。再向前追溯,我们还也可见到瀑布式与快速原型法的影子,也许还有多。 改善,而非创新。敏捷开发可理解为在原有软件开发方法基础上的整合——取其精华,去其糟粕。因此敏捷开发继承了不少原有方法的优势。“在敏捷软件开发的过程中,我们每两周都会得到一个可以工作的软件,”Fowler介绍,“这种非常短的循环,使终端客户可以及时、快速地看到他们花钱构建的软件是一个什么样的结果。”

      敏捷开发的理念:

      · 个体和交互 胜过 过程和工具

      · 可以工作的软件 胜过 面面俱到的文档

      · 客户合作 胜过 合同谈判

      · 响应变化 胜过 遵循计划

      并提出了以下遵循的原则:

      · 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。

      · 即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

      · 经常性地交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好。

      · 在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。

      · 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持,并且信任他们能够完成工作。

      · 在团队内部,最具有效果并富有效率的传递信息的方法,就是面对面的交谈。

      · 工作的软件是首要的进度度量标准。

      · 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

      · 不断地关注优秀的技能和好的设计会增强敏捷能力。

      · 简单是最根本的。

      · 最好的构架、需求和设计出于自组织团队。

      · 每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。

      敏捷测试流程总结:

      在敏捷方法中,XP方法强调测试在整个项目开发过程中的重要性。针对敏捷开发方法的敏捷测试不同于以往针对传统开发模式的测试,在敏捷团队中,测试是整个项目组的“车头灯”,它告诉大家现在到哪了,正在往哪个方向走。测试员为项目组提供丰富的信息,使得项目组基于这些可靠的信息作出正确的决定。不仅是测试员要保证质量,而是整个项目组的每一个人都要对质量负责。测试员不跟开发人员纠缠错误,而是帮助他们找到目标,共同为达到项目的最终目标而努力。敏捷测试也需要高度迭代工作、频繁得到客户的反馈,需要动态调整测试计划、测试的执行。并且,敏捷测试人员参与到了更多的敏捷生产活动中,积极的影响了团队做出的决定和计划。

      根据公司项目目前采用的敏捷开发模式,相应的敏捷测试建议采用以下流程:

      1. 验证需求和设计

      需求和设计具体来说一般包括:(1)由项目经理根据需求文本而编写的功能设计文本(Functional Design Specification);(2)由开发人员根据功能文本而编写的实施设计文本(Implementation Design Specification)包括(Architecture Document, Project Scope Statement, Use Case )。作为测试人员,审核重点是检查文本对用户需求定义的完整性、严密性和功能设计的可测性.

      在测试初期,测试人员要学会做静态测试,做好需求分析,做好对设计逻辑的分析。测试人员要更多的思考需求的可实现性,将自身作为第一用户积极参与项目和系统的需求分析,设计和开发。积极地参与前期工作,并迅速反馈给设计和开发其静态测试结果。要尽早的开始测试,不要等待到功能完全做好才开始。

      产出物:测试需要提交评审结果文档,可以让测试更多的参与DB Design,框架的评审中来

      2. 测试计划,测试用例

      2.1 编写计划、测试用例

      在敏捷开发的过程中由于是根据每个user story来估算时间的。开发人员将对本次迭代所需要的完成的user story进行评估。开发人员可以和客户直接沟通,来确定每个user story的优先级。

      好处:

      客户可以很清楚的了解到哪些user story需要花费多长的时间,以及他们的优先级。

      问题:

      在user story的时间估算上,开发人员常会估算过少。引起版本无法按时发布或者必须进行加班才能进行发布。

      分析:

      由于版本更新很快,任务的时间都是以小时来进行估算的。开发人员一般会忽略掉开发以外的时间,比如开发中遇到问题的时间,开会,给其他成员提供帮助的时间,等等。

      举个例子:

      开发人员估算某个user story编码的时间需要1.5天,开发人员自己估算了其他时间为半天。于是开发人员给的估算时间是2天。

      开发阶段实际的花费时间如下,每天花费开例会的时间。在例会中项目的其他成员需要技术上的支持。于是发费了3个小时进行帮助。在开发的过程中遇到了一些没有预见到的问题,结果解决问题花费了4个小时。(也许更多)。需要处理一些公司突发性的事务等等。

      所以非常建议大家在估算时间上能充分的考虑到以外的因素,某本XP相关的书上写到,在时间估算上最好的时间是编码时间的2-3倍。听起来很吓人,但是实际的过程中,的确需要这么多的时间。

      测试人员根据已审核通过的需求和设计编制测试计划,设计测试用例。在前面提到的三种文本中,功能设计文本是主要依据。测试的这两个文本也要被项目经理和开发人员审核。

    3.1 每日提供bug趋势

      为方便衡量项目的进度,测试可每天测试完毕后提供测试的bug趋势,即将每天新生成的Bug数和每天被解决的Bug数标成一个趋势图表。一般在项目的开始阶段新生Bug数曲线会呈上升趋势,到项目中后期被解决Bug数曲线会趋于上升,而新生Bug数曲线应下降,到项目最后,两条曲线都趋向于零。PM会持续观察这张图表,确保项目健康发展,同时通过分析预测项目Bug,对于每个版本的bug,开发都应该想想为什么会出现这样的问题,特别是很低级的bug,对于同类的bug,是否可以避免。

      测试需要考虑:探索性测试用例的编写

      3.2 测试用例的维护

      在执行测试阶段中,测试人员需要对已有的测试用例进行及时的维护。通常以下两种情况下要新增一些测试用例:一是对于当初测试设计不周全的领域,二是对于外部的Bug(比如从Beta客户报告来的),没有被现有测试用例所覆盖。当产品的功能设计出现更改时(敏捷项目中功能设计的更改频繁),所涉及的测试用例也要相应地修改,使测试用例保持和现有的功能需求同步。

      3.3 根据项目不断补充Common Sense

      在项目进行过程中,测试人员需要不断积累经验,不断补充、完善各类目的Common Sense标准。例如,由CTTS项目总结出的Common Sense for USA标准,在以后的美国项目中要严格按照它来执行测试,保证以前出现过的失误在以后的项目测试中不会再出现。在保证项目质量的同时,不断积累新的经验。

      3.4 控制中间版本

      为更好地保证软件质量,规避风险,必须加强对中间版本的控制。例如,客户要求或者计划周五要提交版本,则周三一定要提交一个中间过程的版本进行测试,也就是控制中间版本,避免所有的工作都压到后期最紧急的时候去完成。以前的项目中出现过项目前期很轻松,到后期bug越来越多,开发人员和测试人员都异常忙碌,经常加班的情况。为减少后期工作量,规避风险,建议开发进行Daliy Build,或者按照完成一个feature就进行一次build,针对这个feature进行测试,这样就可以有效避免后期bug越来越多的状况发生,后期工作量也就会相应减少,项目的质量也会更有保证。

      3.5 发布版本前编写Release Note

      在每次发布版本之前,测试人员要根据待发布的版本情况编写Release Note,使客户对发布的版本情况一目了然。Release Note主要包括三方面的内容:Fixed,New Features,Known Problems。其中,Fixed部分写明此版本修复了上个版本中存在的的哪些比较大的bug;New Features部分写明此版本新增加了哪些功能;Known Problems部分写明此版本尚存在哪些比较大的问题,有待下个版本改善;或者列出需求不太明确的地方,有待客户给出明确答复意见,在下个版本中完成。

      4. 需求管理

      采用敏捷开发模式的项目中,客户对于需求的变更很频繁。因此,需求管理是十分必要和重要的工作。整个项目进行过程中,对不断变化的需求,一定要作跟踪,每次的需求变更都要有相应的历史记录,方便后期的管理和维护工作。可将每次的变更整理记录到需求跟踪文档中,并使该文档始终保持最新更新的状态,与需求的变化保持同步。

      问题:

      客户可能会在一个功能点上来回修改他们的需求,也许开始需要某个功能,结果做完以后又觉得不好,于是让去掉这个功能。后来又由于一些原因,有需要加上。在整个过程中可能来回修改了很多次。那一定要记录下变更的内容和日期。可能后期客户会觉得一个功能怎么会花那么多的时间,不是以前很早就做过了吗?这时这些记录才是解决客户疑虑的最好证明。说白了,是有证据证明我们做了很多的变更。大家可能觉得,怎么会有这个问题。其实当一个项目长达半年以上,也许大家的记忆力都不可靠了(:p)

      建议:

      目前采用的是vss工具,对每天的Email中提到的需求变更做一次backup,文档以当天收到Email的日期命名

      5. 项目开发末期开展“bug大扫除”

      在项目开发的末期,可以开展“bug大扫除”活动。划出一个专门的时间段,在这期间所有参与项目的人员,集中全部精力,搜寻项目的Bug。注意以下要点:(1)尽管这是一个测试活动,但参与者并不仅限于测试人员。项目经理,开发人员甚至于高层管理人员都应参加,如同全民动员。目的是要集思广益;(2)要鼓励各部门,领域交叉搜索,因为新的思路和视角通常有助于发现更多的Bug;(3)为调动积极性,增强趣味性,可以适当引入竞争机制,比如当活动结束时,评出发现Bug最多,发现最严重Bug的个人,给以物质和精神奖励。(4)可以分专题展开,比如安全性、用户界面可用性、国际化和本地化等等。

    展开全文
  • 敏捷开发和瀑布开发的区别

    千次阅读 2016-07-20 17:45:42
    敏捷开发强调以人为中心,快速迭代,客户参与多沟通,减少不必要的文档,包括Scrum和XP 优点:快速适应变化,做出的项目比较接近客户需要的 缺点:文档不多,如果人员流动大,维护相对更难 瀑布开发强调文档,就是...

    个人觉得

    敏捷开发强调以人为中心,快速迭代,客户参与多沟通,减少不必要的文档,包括Scrum和XP
    优点:快速适应变化,做出的项目比较接近客户需要的
    缺点:文档不多,如果人员流动大,维护相对更难


    瀑布开发强调文档,就是不同阶段按照顺序自上而下而来,如需求、设计、编码、测试(单元测试、系统测试)、维护,每个阶段尽量做得最好
    优点:每个阶段可作为检查点,前一阶段完成只需关注后一阶段
    缺点:缺少沟通、反馈,文档比较多,不适应需求快速变化,在生命周期后期才看得到结果,如果有一阶段出了大问题,会影响最终成功

    展开全文
  • 敏捷开发 vs 传统模式

    万次阅读 2015-05-28 22:41:00
    说起敏捷开发,并不是因为敏捷而敏捷。这几年的敏捷开发已经被很多敏捷咨询服务商神话了,这个东西并不是神器,实施了就可以解决所有软件公司的问题,而是要结合自己公司的特点和问题摸索出适合自己的一套模式。 ...
  • 敏捷开发中的测试人员敏捷开发团队介绍测试人员需要具备的素质测试人员的主要职责定义质量 (Define Quality)交流缺陷(Communication)及时反馈 (Feedback):敏捷开发中QA的职责之敏捷中的QA敏捷QA的日常活动敏捷QA与...
  • 瀑布式开发和敏捷开发区别

    万次阅读 2017-09-27 21:42:41
    1.严格把软件项目的开发分隔成各个开发阶段:需求分析,要件定义,基本设计,详细设计,编码,单体测试,结合测试,系统测试等。 使用里程碑的方式,严格定义了各开发阶段的输入和输出。如果达不到要求的输出,下...
  • 随着软件开发技术的不断发展,现在出现了很多种不同的开发模式,其实敏捷开发已经成为现在很多企业开发应用程序都想要选择的开发方案。那么什么是敏捷开发呢?下面一起来了解一下相关的知识吧!  常用的 4 种开发...
  • 敏捷开发项目管理规程

    千次阅读 2017-05-08 09:49:19
    1.目的规范互联网软件产品开发项目管理过程,指导开展项目研发、管理等活动。2.适用范围本章程的作用范围为互联网软件产品开发立项至结项管理过程。1.对项目经理开展产品规划及设计活动以及项目管理手段和应遵循的...
  • 什么是敏捷开发

    2019-10-31 15:50:18
    本篇分享的是:【什么是敏捷开发 】 目录: 1.几种开发方法 1.1瀑布式开发 1.2迭代式开发 1.3螺旋式开发 2.敏捷开发 2.1 敏捷开发的诞生 2.2敏捷开发宣言 2.3 敏捷开发 3.敏捷开发方法 ...
  • 敏捷开发的优缺点

    万次阅读 2017-06-20 14:39:52
    近期试用了一下华为最新推出的项目管理工具-华为软件开发云,接触了敏捷开发,产生一些想法。以下是使用体验,仅供同行们参考。 一、敏捷开发技术的几个特点和优势: 1.个体和交互胜过过程和工具 2....
  • 试论敏捷开发方法的共同特征

    千次阅读 2016-06-21 21:15:58
    本文将为你介绍敏捷开发方法框架的共同特征,理解与传统软件工程的联系和不同。短迭代的生命周期模型生命周期是事物发展的客观规律,软件同样存在生命周期。早期的软件生命周期往往是说“软件从计划、需求开始,经历...
  • 什么是敏捷开发和瀑布式开发?

    千次阅读 2019-06-13 11:15:41
    1.严格把软件项目的开发分隔成各个开发阶段:需求分析,要件定义,基本设计,详细设计,编码,单体测试,结合测试,系统测试等。 使用里程碑的方式,严格定义了各开发阶段的输入和输出。如果达不到要求的输出,下一...
  • 敏捷开发的流程

    千次阅读 2015-08-31 20:27:22
    随着带的团队做的事情越来越多, 发布的产品也越来越多, 关于软件开发的流程的思考也越来越多.... 一个软件从开发到上市(我们抛去维护部分), 一般需要经历阶段有 需求分析, 方案设计, 开发方案设计(包括概要
  • 敏捷开发FAQ(文档还是要有的)

    千次阅读 2015-01-07 11:03:53
    敏捷开发与没有规范,没有文档的代码编写者的区别 与某些观点相反,敏捷开发...敏捷开发最少需要开发和维护哪些文档? 但现实中的情况是大多数人不喜欢编写文档、也不太喜欢研读文档,因此太多的文档只会消耗团队有限
  • 谈谈敏捷开发模型

    2019-08-01 23:36:56
    谈谈敏捷开发模型 我对敏捷开发是源于10多年前看了一本关于迭代开发的书,从而对迭代开发有了一些兴趣。从那时开始有了迭代开发的概念。随着项目经验的增加迭代的重要性也越发觉得明显。随后进入了提倡敏捷开发的...
  • 敏捷开发优点和缺点

    千次阅读 2019-07-04 16:04:18
    一、敏捷开发技术的几个特点和优势: 1.个体和交互胜过过程和工具 2.可以工作的软件胜过面面俱到的文档 3.客户合作胜过合同谈判 4.响应变化胜过遵循计划 二、敏捷开发技术的12个原则: 1.我们最优先要做...
  • 1.严格把软件项目的开发分隔成各个开发阶段:需求分析,要件定义,基本设计,详细设计,编码,单体测试,结合测试,系统测试等。 使用里程碑的方式,严格定义了各开发阶段的输入和输出。如果达不到要求的输出,下一...
  • 敏捷开发智慧敏捷系列

    千次阅读 2012-02-07 16:29:59
    敏捷开发智慧敏捷系列之一:序言 这是智慧敏捷系列的第一篇。(之一,之二,之三,之四,之五) 本文将解决各种敏捷中需要辩证思考的问题,包括:写文档还是不写文档?拥抱变更还是迭代期内无变更?持续交付的产品...
1 2 3 4 5 ... 20
收藏数 11,210
精华内容 4,484
关键字:

敏捷开发阶段 文档维护