敏捷开发文档_敏捷开发 需求分析文档 - CSDN
精华内容
参与话题
  • 敏捷开发中的文档怎么写

    千次阅读 2018-06-05 13:19:13
    我们比较熟知的软件项目管理方法是瀑布。其基本流程是需求-&...国外的软件先行者们针对瀑布开发中暴露出来的问题进行了一系列的探索、思考和总结,提出了Agile Dev的概念,中文翻译为敏捷开发。一.什么...

    我们比较熟知的软件项目管理方法是瀑布。其基本流程是需求-> 设计->开发->测试。基本假设只要把每一个环节都做正确,那么最终得到的结果也是正确的。瀑布开发有非常成功的案例,比如微软。但从总体来讲,瀑布项目失败率比较高。国外的软件先行者们针对瀑布开发中暴露出来的问题进行了一系列的探索、思考和总结,提出了Agile Dev的概念,中文翻译为敏捷开发。
    一.什么是敏捷开发
    敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。
    换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。相对于瀑布开发模式,敏捷开发更加灵活可操作。
    二.敏捷开发方式及流程
    敏捷开发有很多种方式,如scrum,XP,LSD,FDD等,其中scrum是非常流行的一种。
    scrum将产品的开发分解为若干个小sprint(迭代),其周期从1周到4周不等,但不会超过4周。参与的团队成员一般是5到9人。每期迭代要完成的user story是固定的。每次迭代会产生一定的交付。
    scrum的基本流程如图所示:

    po(product owner指产品负责人)负责整理user story,形成左侧的product backlog(按优先顺序排列的一个产品需求列表)。
    发布计划会议:po负责讲解user story,对其进行估算和排序,发布计划会议的产出就是制定出这一期迭代要完成的story列表,叫做sprint backlog。
    迭代计划会议:项目团队对每一个story进行任务分解,分解的标准是完成该story的所有任务,最终每个任务都有明确的负责人,并完成工时的初估计。
    每日例会:每天sm(scrum master指项目负责人)召集站立会议,团队成员回答昨天做了什么今天计划做什么,有什么问题。
    演示会议:迭代结束之后,召开演示会议,相关人员都受邀参加,团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来,由po整理,形成新的story。
    回顾会议:项目团队对本期迭代进行总结,发现不足,制定改进计划,下一次迭代继续改进,已达到持续改进的效果。
    敏捷流程中的三个关键要素是:product backlog(产品需求)
    sprint backlog(本期迭代任务)
    burn-down chart(燃尽图,进度的体现)
    呈现了任务下达-拆分-推进的整个过程。

    三.“轻文档,重沟通”的敏捷
    我们知道,瀑布开发是以文档为驱动,文档是一切工作的核心,po需要写非常多而复杂的文档,例如:需求文档、设计文档、API文档、验收文档等等。
    敏捷宣言说,“可工作的软件胜于详尽的文档”。敏捷反对这种 “重文档”的方法,而是强调成员之间的紧密协作、面对面的沟通、频繁交付的新版本、紧凑而自我组织型的团队。可见,敏捷开发是更实际,更注重操作性的开发方式。
    但这并不意味着敏捷开发完全抛弃文档,敏捷开发遵循“轻文档,重沟通”的原则。
    “轻文档”体现在,敏捷开发只关注文档中的重要点,尽可能的简化文档,或者用软件工具呈现另一种形式的文档。
    以传统文档来说,一个PRD(产品需求文档)中包含对多个成员的诉求,比如前端工程师、后端工程师、测试人员。众多的产品需求导致文档厚重繁琐,而且在实际工作中,很多开发人员并不喜欢看文档。因为常常一个PRD中可能有好几页内容都是与自己无关的,但是要看过才知道是否与自己有关,这在无形中就造成了时间的浪费。
    敏捷管理中采用了用户故事的方式进行product backlog的呈现,“用户故事(称作user story)”是采用用户熟悉的术语来表达需求的一种方法,是用户讲给开发人员的故事(实际由po搜集用户需求并整理成用户故事)。
    例如“作为禅道用户,我希望能实现自动登陆功能,这样能更方便的登陆系统。“这就是一个具体的需求描述。
    在这个需求描述中,涉及到三个要素“用户角色(禅道用户)”、“达成的目的(自动登陆功能)”、“开发价值(更方便的登陆系统)”
    当然除了这三个要素,还需要涉及到验收标准、优先级、评审人等。

    借助软件工具实现product backlog的信息传达是敏捷开发最普遍的做法。po把功能点拆分,导入到项目管理软件中,相关人员只需要按照需求目录一条条执行即可,不再需要一页一页的看PRD了。后端只需要与提供接口相关的,前端主要看与功能相关的部分,而不需要查看与自己无关的内容。如果开发人员在具体的sprint backlog开发中存在问题和疑问怎么办呢?沟通!
    “重沟通”体现在以结果为导向,以人为核心。通过面对面沟通的方式快速反应,推动进度。
    你可以随时一对一沟通po解除疑问。而且整个敏捷团队还需要召开发布计划会议、迭代计划会议、演示会议等内部会议及每日站立会议。每日站立会议上,团队成员依次回答昨天做了什么今天计划做什么,有什么问题,发现问题及时提出和解决。每个人发言完后,要走到任务看板前更新自己的燃尽图。这也是敏捷流程中不可缺少的环节。

    任务看板一般包含未完成、正在做、已完成的工作状态,假设你今天把一个未完成的工作已经完成,那么你要把小卡片从未完成区域贴到已完成区域。每个人的工作进度和完成情况都是公开的,如果有一个人的工作任务在某一个位置放了好几天,大家都能发现他的工作进度可能出现了什么问题。

    如今的任务看板和燃尽图已经由实物形式转变为项目管理软件。表现形式基本延续实体看板的形式,禅道中分为未开始、进行中、已暂停、已完成、已取消、已关闭几种状态。在看板页面,成员完成某项任务后即可从进行中拖拽到已完成列,跟实体看板的作用如出一辙。

    比起传统开发模式,敏捷更加强调去流程化,文档不再必须,变得可以简化和被取代。因为在敏捷开发中,最简单的解决方案就是最好的解决方案,最高效的工作方式就是最好的工作方式。

    相关观点及图片来源:
    敏捷开发-百度百科
    禅道-开源项目管理软件
    谈谈我理解的敏捷开发-许大虾

     

    展开全文
  • 敏捷开发中软件与文档的思考

    千次阅读 2005-02-05 08:05:00
    后来尝试过,制订完善的规范,用了大量的软件开发文档模板,可惜仍然无法减轻开发者的负担,另一方面令人尴尬的是,情况并没有比不带文档好多少,因为在项目的实施中,很少有文档与软件能够完全同步的。一份简单的...
    也曾尝试过,不带文档的“裸体”前进,可想而知,最后经常造成项目的返工,新来的人员要拼命读以前的人留下的几乎没有注释的源码。 

           后来尝试过,制订完善的规范,用了大量的软件开发文档模板,可惜仍然无法减轻开发者的负担,另一方面令人尴尬的是,情况并没有比不带文档好多少,因为在项目的实施中,很少有文档与软件能够完全同步的。一份简单的需求文档从项目开始到项目结束,往往会改动得面目全非,在此同时,要花费专门的软件开发人员去整理文档,不得不说是一种资源浪费。

           与其做着虚假的文档,穿着皇帝的新衣,不如就干脆裸体,这是我的想法,但一直没这个胆子去实施。

           不知是谁说过:软件=程序+文档,我持一半的赞同一半的不赞同,软件最终就是要给用户用的东西,用户只要用了满意,就是一个好软件,不满意就不是好软件。对于用户来说,他需要付出的是软件的费用,另一部分软件开发过程中的文档等,是公司为了产品以后的升级、维护、扩展而准备,用户没有义务为此付费。

          一直以来,我们都采用Case工具,采用UML图进行交流,有时候尽是这些工具很难满足我们的需要,我们也会想尽一切办法去表达自己的意思。使用了这些工具后,我的感觉是,大家都已经由原来的正常人变成了哑巴。有时候,明明一句话可以解决问题的,却要比上半天的手势。

      新技术与新工具的采用,带来的应该是人与人之间更通畅的信息交流,如果效果正好相反,那么我们不得不考虑一下,为什么会这样。

           直到接触敏捷开发,才觉得开朗了一些,软件开发尽管没有银弹,但在不同的形势下,总有合适的方法来让开发人员爬出焦油坑外。

           在《 敏捷建模 极限编程和统一过程的有效实践 》这一本书上,开头作者就指出了,他们在快速交流中,并不使用Case工具,他们使用的不过是几张纸片,而且抓了支笔就开始画草图,甚至,在书中的后半部分,在设计用户界面时,也居然是用草图画出来的。

          也许我看起来很可笑,但是说实话,我真的没有这样去做。向来我都认为,严格地管理,严格地遵循规范才能够出高质量的产品,现在看来,好像是我误解了些什么东西。软件设计的目标是成功开发出一个成品,让用户可以使用它。

          在做项目的过程中,我们往往过份关注了软件的扩展性与易用性,以致于过度的分析需求,不但提供了一些用户用不着的功能,也让用户投入了不需要花费的资金,同时,我们还浪费了大量的时间。
      
      在XP实践中,有许多实践是令人兴奋的,不说其它的,虽然XP中不反对文档,但根据它的思想,给了开发人员一个尽量少写或不写文档的借口。 我一直没有机会去实践结对编程,但直觉上认为它是一个好东西,虽然并不相信,可以提高百分之几十的效率,但软件的开发毕竟是一个脑力活动,做个小功能,转换一下思路,是一个好办法。

      但结对编程中,有一个让我迷惑不已的地方:一般而言,人要进行做某事,要进入状态,大约要15分钟左右的启动时间,然后,无论是任何打扰(包括电话,有人问话),都会造成思路的中断,从而使得人要重新调整状态,这又有几分钟的时间耗费。我不认为这样会使得人更专注(有人在旁边监视也一样)。

      因为没有绝对编程的经验,所以也不过妄言几句。  
    展开全文
  • 我们比较熟知的软件项目管理方法是瀑布。其基本流程是需求-> 设计->...国外的软件先行者们针对瀑布开发中暴露出来的问题进行了一系列的探索、思考和总结,提出了Agile Dev的概念,中文翻译为...

    我们比较熟知的软件项目管理方法是瀑布。其基本流程是需求-> 设计->开发->测试。基本假设只要把每一个环节都做正确,那么最终得到的结果也是正确的。瀑布开发有非常成功的案例,比如微软。但从总体来讲,瀑布项目失败率比较高。国外的软件先行者们针对瀑布开发中暴露出来的问题进行了一系列的探索、思考和总结,提出了Agile Dev的概念,中文翻译为敏捷开发。

    一.什么是敏捷开发

    敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。

    换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。相对于瀑布开发模式,敏捷开发更加灵活可操作。

    二.敏捷开发方式及流程

    敏捷开发有很多种方式,如scrum,XP,LSD,FDD等,其中scrum是非常流行的一种。

    scrum将产品的开发分解为若干个小sprint(迭代),其周期从1周到4周不等,但不会超过4周。参与的团队成员一般是5到9人。每期迭代要完成的user story是固定的。每次迭代会产生一定的交付。

    scrum的基本流程如图所示:

    f_0fd8695b8a9e7e60fe3fef3603c1d733&t=png

    • po(product owner指产品负责人)负责整理user story,形成左侧的product backlog(按优先顺序排列的一个产品需求列表)。
    • 发布计划会议:po负责讲解user story,对其进行估算和排序,发布计划会议的产出就是制定出这一期迭代要完成的story列表,叫做sprint backlog。
    • 迭代计划会议:项目团队对每一个story进行任务分解,分解的标准是完成该story的所有任务,最终每个任务都有明确的负责人,并完成工时的初估计。
    • 每日例会:每天sm(scrum master指项目负责人)召集站立会议,团队成员回答昨天做了什么今天计划做什么,有什么问题。
    • 演示会议:迭代结束之后,召开演示会议,相关人员都受邀参加,团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来,由po整理,形成新的story。
    • 回顾会议:项目团队对本期迭代进行总结,发现不足,制定改进计划,下一次迭代继续改进,已达到持续改进的效果。
    敏捷流程中的三个关键要素是:

    product backlog(产品需求)

    sprint backlog(本期迭代任务)

    burn-down chart(燃尽图,进度的体现)

    呈现了任务下达-拆分-推进的整个过程。

    三.“轻文档,重沟通”的敏捷

    我们知道,瀑布开发是以文档为驱动,文档是一切工作的核心,po需要写非常多而复杂的文档,例如:需求文档、设计文档、API文档、验收文档等等。

    敏捷宣言说,“可工作的软件胜于详尽的文档”。敏捷反对这种 “重文档”的方法,而是强调成员之间的紧密协作、面对面的沟通、频繁交付的新版本、紧凑而自我组织型的团队。可见,敏捷开发是更实际,更注重操作性的开发方式。

    但这并不意味着敏捷开发完全抛弃文档,敏捷开发遵循“轻文档,重沟通”的原则。

    “轻文档”体现在,敏捷开发只关注文档中的重要点,尽可能的简化文档,或者用软件工具呈现另一种形式的文档。

    以传统文档来说,一个PRD(产品需求文档)中包含对多个成员的诉求,比如前端工程师、后端工程师、测试人员。众多的产品需求导致文档厚重繁琐,而且在实际工作中,很多开发人员并不喜欢看文档。因为常常一个PRD中可能有好几页内容都是与自己无关的,但是要看过才知道是否与自己有关,这在无形中就造成了时间的浪费。

    敏捷管理中采用了用户故事的方式进行product backlog的呈现,“用户故事(称作user story)”是采用用户熟悉的术语来表达需求的一种方法,是用户讲给开发人员的故事(实际由po搜集用户需求并整理成用户故事)。

    例如“作为禅道 用户,我希望能实现自动登陆功能,这样能更方便的登陆系统。“这就是一个具体的需求描述。

    在这个需求描述中,涉及到三个要素“用户角色(禅道用户)”、“达成的目的(自动登陆功能)”、“开发价值(更方便的登陆系统)”

    当然除了这三个要素,还需要涉及到验收标准、优先级、评审人等。

    借助软件工具实现product backlog的信息传达是敏捷开发最普遍的做法。po把功能点拆分,导入到项目管理软件中,相关人员只需要按照需求目录一条条执行即可,不再需要一页一页的看PRD了。后端只需要与提供接口相关的,前端主要看与功能相关的部分,而不需要查看与自己无关的内容。如果开发人员在具体的sprint backlog开发中存在问题和疑问怎么办呢?沟通!

    “重沟通”体现在以结果为导向,以人为核心。通过面对面沟通的方式快速反应,推动进度。

    你可以随时一对一沟通po解除疑问。而且整个敏捷团队还需要召开发布计划会议、迭代计划会议、演示会议等内部会议及每日站立会议。每日站立会议上,团队成员依次回答昨天做了什么今天计划做什么,有什么问题,发现问题及时提出和解决。每个人发言完后,要走到任务看板前更新自己的燃尽图。这也是敏捷流程中不可缺少的环节。

    任务看板一般包含未完成、正在做、已完成的工作状态,假设你今天把一个未完成的工作已经完成,那么你要把小卡片从未完成区域贴到已完成区域。每个人的工作进度和完成情况都是公开的,如果有一个人的工作任务在某一个位置放了好几天,大家都能发现他的工作进度可能出现了什么问题。

    f_cb103833a116aca8e24b8a2daa6947ae&t=png

    如今的任务看板和燃尽图已经由实物形式转变为项目管理软件。表现形式基本延续实体看板的形式,禅道中分为未开始、进行中、已暂停、已完成、已取消、已关闭几种状态。在看板页面,成员完成某项任务后即可从进行中拖拽到已完成列,跟实体看板的作用如出一辙。

    比起传统开发模式,敏捷更加强调去流程化,文档不再必须,变得可以简化和被取代。因为在敏捷开发中,最简单的解决方案就是最好的解决方案,最高效的工作方式就是最好的工作方式。


    相关观点及图片来源:

    敏捷开发-百度百科

    禅道-开源项目管理软件

    谈谈我理解的敏捷开发-许大虾

    1Q8Zf40c5UhKFO.gif
    展开全文
  • 敏捷开发FAQ(文档还是要有的)

    千次阅读 2015-01-07 11:03:53
    敏捷开发与没有规范,没有文档的代码编写者的区别 与某些观点相反,敏捷开发人员并非不按规则或限制编写代码的特立独行者。“牛仔编码”是缺乏规则和管理糟糕的迹象,并且很不专业。如果团队里面存在这样的编写代码...

    敏捷开发与没有规范,没有文档的代码编写者的区别

    与某些观点相反,敏捷开发人员并非不按规则或限制编写代码的特立独行者。“牛仔编码”是缺乏规则和管理糟糕的迹象,并且很不专业。如果团队里面存在这样的编写代码的现象,为了客户的利益着想,您应该竭尽全力地改变这种情况。

     

    敏捷开发最少需要开发和维护哪些文档?

    但现实中的情况是大多数人不喜欢编写文档、也不太喜欢研读文档,因此太多的文档只会消耗团队有限的时间,并不能带来多大的好处;

    一份概要性的高阶的文档是用户和开发团队之间的契约,双方的一致理解有助于沟通和互动;用户只关心他要什么,不关心如何实现,更不关心实现有多难,所以我们不能奢求用户理解我们遇到的技术问题,甚至读懂我们的代码或者注释;

    敏捷开发重视文档的作用,也重视文档的维护;它认为文档宜少且精炼,一般情况下建议开发并维护三份文档:

    《软件需求规格说明书》或者《产品规格说明书》:定义软件应该具有的功能、边界等,使软件相关的涉众对软件有一致的理解,它作为用户同开发团队之间共同的讨论基础,并在开发过程中不断的更新维护;

    《架构设计文档》:软件如何实现,内部之间是什么关系?

    《项目管理计划》:计划如何分期实现、测试、发布等;

     

    敏捷开发是否需要系统设计?

         敏捷开发是以小周期代替大周期,小周期包括:需求、设计、开发、测试、发布,这个过程中是包括设计环节的,也就是说需要做系统设计;

         由于做完整的设计需要有相对完整的资料和比较长的时间,与小周期是相对立的,因此敏捷开发不主张高度细化和完整的设计,提倡做出一个大粒度的框架性设计,一般指架构设计或者系统设计或功能模块的概要设计,避免在以后的重构中发生架构级别的变化,然后在逐步实现的过程中逐渐深入展开、细化;

           做到概要设计即可,不用到详细设计。[即可划分模块,类,公共接口]。

           类的实现可以由编码人员直接确定,完成项目后,可以通过后处理工具得到类的实现模型和类关系图。

        传统的一些设计方法比如结构化设计、面向对象分析(OOA)、面向对象设计(OOD)、自顶向下、快速原型法都是可以融入敏捷开发过程中加以使用的;

     

    敏捷开发是否需要项目计划?

         商业软件开发需要承担获取利润的责任,因此对产品的功能完整性、稳定性、即时性等都有较高的要求, 它是一种有组织有目标的行为,因此它需要项目计划,但这个计划是一个短程计划,根据未实现的功能情况、前一个版本的反馈和组织目标制定开发计划;唯有这样才能不断的融入新的变更;

           年度规划,月度实现计划。[年度规划一般不可变,月度计划则可以依据实际情况对需求实现进行进度安排]

     

    敏捷开发的迭代周期大概多长?

           对于通用小项目而言,可以每月交付一个大的功能版本,每两周交付一个变更或Bug版本。在进行项目开发进度估算时候需要对交付的内容大致有一个规划。

    当然也不能频繁的发布,特别是重大Bug的紧急发布,这样会降低用户的期望并提高用户成本,给用户心理上带来额外的负担:他会认为产品质量低,质量控制不严谨等;

     

    敏捷开发为何提倡小版本?小版本有哪些优势?

         小版本的目的就是分解复杂度、降低风险,改善团队士气等;小版本有众多优势:

    Ⅰ、总体风险比较少:小版本变化小,总是在上一个版本基础上局部调整和增加,技术复杂度低;由于规划的功能较少,工作量也易于估算,所以其总体风险比较少,常常能如期发布;

    Ⅱ、需求的接纳能力强:由于小版本快速实现并发布测试,然后就进入下一个版本的规划实现周期,这样新需求一旦提出就能快速进入开发视野,就能尽快实现;

    Ⅲ、测试和开发高效协作:开发和测试可以并行工作,当开发实现第一个版本时,测试设计测试方案和用例;发布第一个版本后,开发就进入下一个版本轮次,测试就应用测试方案测试刚才发布的版本,提交Bug;开发在下一个版本结束时修正所有上一轮发现的Bug,然后发布新版本,如此循环往复,开发和测试实现高效协作;

     

    敏捷开发与重构的关系如何?

    敏捷开发以重构为基础,时时刻刻处于重构过程中;

     

    敏捷开发为何强调团队人员的参与、用户的参与?

    人是一切关系的主体,是生产力提升的主体;敏捷强调团队成员的高度参与就是要统一认识,把团队的目标变成每个人的工作目标,使之为每个团队成员的认同,形成高度的凝聚力,以达到群策群力、高效协作的效果;

         由于没有高度细化的文档,成员之间交换信息的唯一渠道就是面对面沟通,良好的团队氛围和协作关系促进这种沟通,并使消息准确有效传达;

         用户由于缺乏专业训练,无法清晰、准确的表达其意图,导致需求的歧义和模糊;用户的参与使模糊、边界不确定的需求在互动的过程中得到确认和完善;

         我们努力做的事情就是实现用户需要的东西,并最终让用户喜欢它,唯有用户喜欢它才能用好它,那么我们怎能不认真听取用户的意见呢?

         一句话总结就是:用户参与帮助我们做正确的事情!

     

    怎么才能评估我们团队和开发过程已经敏捷了?

         由于敏捷开发没有标准的可供参考的实践过程,所以很难通过某个过程而断定其开发过程敏捷了,那么我们如何来评估我们的团队和开发过程是敏捷的呢?这里采用办法是根据团队呈现出来的氛围、项目运作状态、团队成员的感性认识等方面来评估团队和其开发过程是否敏捷,我们认为评估项目团队和开发过程是否已经敏捷的方法如下:

     

    1、团队有共同的愿景,并且对这个愿景充满信心

    2、团队有明确的阶段目标并且为每个成员所知晓;

    3、团队知晓当前计划:做什么、何时完成、预期效果等

    4、团队任务是低耦合的,并且紧密协作;

    5、发布过程是轻松愉快的,构建版本并不断测试是常态行为之一;

     

    敏捷开发能缩短项目时间并提高质量吗?

         敏捷开发能缩短项目周期并提高整体质量吗?能,但我目前无法提供量化的数据做参考,只能从几个方面评估和推断:敏捷开发是能缩短项目时间并提高质量的;

    1、用户的参与帮助团队把功能一次性完成并做正确,缩减了返工的时间;

    2、不断的重构和测试发布能把问题发现在早期,整体质量显著提高;

    3、过程目标导向,使团队高度集中于项目目标,提高了生产力;

    4、不断的发布对团队是种正向激励,荣誉感和成功欲使团队保持持续的激情;

     

    敏捷开发与CMMI最大区别:

    我觉得CMMI是由大及小的过程,Agile是由小及大的过程。

    CMMI是给出所有可能需要考虑的点,让你从中选择你可能需要的

    Agile是给出所有必须考虑的点,然后让你再在其上进行扩展

    方法无所谓好坏,关键要选对、用对方法,如果只是对于这些书籍上的理论进行讨论,本身就是有缺陷的。

    展开全文
  • 敏捷误区:敏捷并不意味着不需要文档敏捷的过程中,会有一种叫做产品需要设计文档的东东,简称PRD。最近在一次公司组织的内部培训会上,老师提供了一份PRD文档的模板,个人觉得这个PRD模板比较轻量,现在分享给...
  • 敏捷开发之设计文档

    2019-04-28 00:45:51
    对于设计文档的一点体会就是,明确需求、...在产品研发过程中经常需要编写很多文档,例如:需求文档、设计文档、API文档、验收文档等等。团队成员要花费很多精力去维护众多的文档,甚至有“兄弟,我替你写代码,你替...
  • 敏捷开发需要哪些文档

    万次阅读 2018-01-17 07:39:23
    敏捷开发需要哪些文档? 需求说明 对功能、交互方式、出错或边界情况的表现进行总体描述 1.画面图 2.数据图 3.需求说明 来源张永光的博客
  • 敏捷开发 介绍 文档

    2020-03-10 23:30:43
    敏捷开发敏捷开发 介绍 文档 学习无止境
  • 敏捷开发中文档的取舍

    千次阅读 2017-11-24 11:15:19
    敏捷开发中文档的取舍 先说需求文档,分为两部分,一方面是框架性的需求文档,对功能、交互方式、出错或边界情况的表现进行总体描述,这种文档不需要过于细致,因为产品经理组织语言写文档,开发读文档,理解文档都...
  • 敏捷开发:编写开发文档的利与弊

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

    万次阅读 多人点赞 2014-04-04 08:29:47
    开发要有开发文档(需求文档、数据库设计、概要设计)、开发计划(甘特图、燃尽图)、测试计划(时间、地点、人员、任务模块分配、禅道bug提交管理)都应该有一个时间段,在大家的一起商量之下可以每个人做到心中...
  • 软件开发模式之敏捷开发(scrum)

    万次阅读 多人点赞 2018-08-08 19:25:59
    这几年关于敏捷开发在互联网企业中越来越广泛被使用到,运用的比较多的当属scrum敏捷开发和xp敏捷开发,人人都在谈论敏捷开发。那什么才是敏捷开发呢? 目录 什么是敏捷开发? 传统的开发模式和敏捷开发模式的...
  • 敏捷开发流程总结

    万次阅读 多人点赞 2010-07-20 15:36:00
     敏捷开发宣言—— 个体和交互 胜过 过程和工具 可以工作的软件 胜过 面面俱到的文档 客户合作 胜过 合同谈判 响应变化 胜过 遵循计划 虽然右项也有价值,但是我们认为左项...
  • 敏捷开发需要编写文档吗?

    千次阅读 2016-03-21 16:41:26
    在产品研发过程中经常需要编写很多文档,而敏捷宣言的第二条“可工作的软件胜于详尽的文档",那么需要编写文档吗?有没有简单的判断方法呢?
  • 该死的“代码就是文档

    万次阅读 热门讨论 2014-02-10 14:37:16
    我在《专业嵌入式软件开发》一书中指出,编写言简意骇的文档是实施高质高效软件开发的关键要素之一。在此结合自己的工作体会,再谈一谈软件开发活动中文档的重要性。切入正题之前,先让我们浏览二个工作场景。 A君...
  • 敏捷开发中如何维护文档

    千次阅读 2012-08-09 01:26:42
    软件项目中有很多种文档,包括需求文档、设计文档、API文档、缺陷报告、进度报告、移交文档、验收文档等等。 ...第二条敏捷宣言是"可工作的软件胜于详尽的文档",据此很多人想当然认为敏捷开发
  • 关于敏捷开发和CMMI的管理大家都各有心得,我就不在对各自具体管理做阐述了,紧紧针对文档裁剪说的看法,首先敏捷开发强调的核心的东西是交流,但对于当今的项目开发来说,个人交流恰恰是个难点,做开发的基本上都是...
  • 敏捷开发实践(一)--谈谈我对敏捷开发的理解

    万次阅读 热门讨论 2015-05-31 09:58:51
    随着敏捷开发越来越流行,人人都在谈敏捷,人人也都在学习scrum等敏捷开发方法。。。当然,自己也是敏捷开发的实施者和受益者。
  • ios敏捷开发的理解

    2019-03-13 14:37:56
    一,根据以下几个问题来谈谈敏捷开发 1.什么是敏捷开发? 2.为什么使用敏捷开发? 3.如实使用敏捷开发? 4.采用敏捷开发的产品效果? 二.什么是敏捷开发敏捷开发是一种价值和原则,指导我们更加高效的...
  •  不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。  其中,敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求,带来了新的挑战。 第一部分:敏捷软件开发简介 敏捷...
1 2 3 4 5 ... 20
收藏数 44,517
精华内容 17,806
关键字:

敏捷开发文档