敏捷开发中关于文档_敏捷开发中的设计文档 - CSDN
  • 在产品研发过程经常需要编写很多文档,而敏捷宣言的第二条“可工作的软件胜于详尽的文档",那么需要编写文档吗?有没有简单的判断方法呢?

    easypm-敏捷开发

    在产品研发过程中经常需要编写很多文档,例如:需求文档、设计文档、API文档、验收文档等等。团队成员要花费很多精力去维护众多的文档,甚至有“兄弟,我替你写代码,你替我写文档”的无奈。

    敏捷开发宣言
    * 个体和互动 胜于 流程和工具
    * 可以工作的软件 胜于 详尽的文档
    * 客户合作 胜于 合同谈判
    * 响应变化 胜于 遵循计划

    敏捷宣言的第二条“可工作的软件胜于详尽的文档”,很多人理解为敏捷开发不重视文档,甚至以此为借口逃避写文档。同样,在对待”敏捷开发是否需要架构设计”的问题上也有类似极端的看法。

    敏捷宣言在写什么样的文档以及如何写方面并没有给出任何刚性的指导原则,那么在敏捷管理的项目中我们该如何编写文档呢?

    首先,我们需要理解敏捷宣言背后的思想。
    敏捷4条宣言都是在强调“价值”、“快速交付价值”、“为客户提供价值”的理念。换句话说,研发团队要把精力放在能够为客户带来价值的地方,避免在不产生价值或者ROI(投入回报率)低的任务上浪费时间。

    其次,我们要理解文档的作用是什么?文档是用来准确传递信息,帮助理解事物,沉淀知识。

    基于以上理解,在遇到是否要写文档的疑问时,可以通过回答两个问题来判断

    • 是否有比写文档更高效传递信息的方式?
    • 简陋的文档是否满足需要?

    从文档的读者来划分

    • 读者是项目组外人员
      这类文档往往是需要编写的而且不能“简写”的。例如:用户手册、验收文档、API文档等。

    • 读者是项目组内人员
      这类文档能省则省,能简则简。如果能够在每天站会上沟通的,就可以不写。建议高层的系统架构图、内部API文档可以简写。
      如果项目Leader通过类似EasyPM这样管理工具能够查询到的信息,可以在周报中简写甚至省略。


    对于可以“简写”的文档,可以考虑使用Markdown格式。

    Markdown是一种简单易用的标记语言,用户可以使用这些标记符号以最小的输入代价生成极富表现力的文档。

    EasyPM 的文档编辑器使用Markdown语法,并且实时保存/预览、支持代码高亮、文档评论以及全文搜索。在版本管理上,支持手动和自动进行版本管理。文档评论也支持@功能,可以高效地对文档进行评审。

    展开全文
  • 开发要有开发文档(需求文档、数据库设计、概要设计)、开发计划(甘特图、燃尽图)、测试计划(时间、地点、人员、任务模块分配、禅道bug提交管理)都应该有一个时间段,在大家的一起商量之下可以每个人做到心中...

    故事情节

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

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


    到底要不要写文档?


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


    初设敏捷开发


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

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



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

    总结

      

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

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

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

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

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

     

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

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

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

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

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

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

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

     

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

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

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

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

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

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

     

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

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

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

     

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

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

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

     

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

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

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

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

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

     

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

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

     

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

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

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

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

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

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

     

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

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

     

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

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

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

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

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

     

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

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

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

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

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

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

     

    敏捷开发与CMMI最大区别:

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

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

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

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

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

    敏捷开发中文档的取舍

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

    文档的功能

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

    沟通

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

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

    Agile/Lean Documentation: Strategies for Agile Software Development

    敏捷开发是不是不用写需求分析、概要设计、详细设计之类的文档了啊?
    概要设计文档、详细设计文档是源自传统软件工程的说法。  
    如今传统的 Word、PDF 版的详细设计文档通常可以省略,大部分这类文档可以结合代码注释用工具自动生成,Web/HTML 版的详细设计/代码参考文档才是更好的做法。在敏捷开发中,需求文档、概要设计(改成架构设计)文档通常是不能省略的。
    
    展开全文
  • 我们比较熟知的软件项目管理方法是瀑布。其基本流程是需求-&...国外的软件先行者们针对瀑布开发暴露出来的问题进行了一系列的探索、思考和总结,提出了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解除疑问。而且整个敏捷团队还需要召开发布计划会议、迭代计划会议、演示会议等内部会议及每日站立会议。每日站立会议上,团队成员依次回答昨天做了什么今天计划做什么,有什么问题,发现问题及时提出和解决。每个人发言完后,要走到任务看板前更新自己的燃尽图。这也是敏捷流程中不可缺少的环节。

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

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

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

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

     

    展开全文
  • 敏捷开发需要哪些文档? 需求说明 对功能、交互方式、出错或边界情况的表现进行总体描述 1.画面图 2.数据图 3.需求说明 来源张永光的博客
  • 敏捷开发学习总结: 思考开发文档的利与弊 文档是个好东西,这是不可否认的,但是太依赖文档也有弊端,下面我从不同的度来分析一下文档的利与弊,然后思考在敏捷开发时,文档又是如何进行的。从 公司的角度来看,...
  • 软件项目有很多种文档,包括需求文档、设计文档、API文档、缺陷报告、进度报告、移交文档、验收文档等等。 ...第二条敏捷宣言是"可工作的软件胜于详尽的文档",据此很多人想当然认为敏捷开发
  • 这几年关于敏捷开发在互联网企业越来越广泛被使用到,运用的比较多的当属scrum敏捷开发和xp敏捷开发,人人都在谈论敏捷开发。那什么才是敏捷开发呢? 目录 什么是敏捷开发? 传统的开发模式和敏捷开发模式的...
  • 敏捷的过程,会有一种叫做产品需要设计文档的东东,简称PRD。最近在一次公司组织的内部培训会上,老师提供了一份PRD文档的模板,个人觉得这个PRD模板比较轻量,现在分享给大家。 1、概述 产品概述及目标 名词...
  • 写不写文档? 敏捷宣言更强调“可以工作的软件胜过面面俱到的文档”,但并不是...要理解敏捷开发的出发点不是不写文档只写代码,而是减少浪费,以便能按照自己项目的特点,灵活选择文档的数量,在过度设计和返工之间找
  • 敏捷开发流程总结

    2010-07-20 15:36:00
     敏捷开发宣言—— 个体和交互 胜过 过程和工具 可以工作的软件 胜过 面面俱到的文档 客户合作 胜过 合同谈判 响应变化 胜过 遵循计划 虽然右项也有价值,但是我们认为左项...
  • 背景需求文档解析成本太高。RD解析一遍,QA解析一遍。 我们的产品需求是用户真正需要的吗? 需求文档!=记录产品需求 应该代表用户需求。
  • 关于敏捷开发和CMMI的管理大家都各有心得,我就不在对各自具体管理做阐述了,紧紧针对文档裁剪说的看法,首先敏捷开发强调的核心的东西是交流,但对于当今的项目开发来说,个人交流恰恰是个难点,做开发的基本上都是...
  • 敏捷中文档

    2012-01-16 10:32:05
    我们听到敏捷开发中文档都内容比较简练,篇幅相对比较少. 敏捷有句名言是"个体和交互 胜过 过程和工具可以工作的软件 胜过 面面俱到的文档"。   这句话说的有道理,但是容易给人们造成一种误解,就是文档的...
  • 什么是敏捷开发中的Spike? Spike,如果需要翻译的话,中文可以翻译成“探针”,但是一般不会翻译而直接使用Spike这个词。 Spike可以理解为:以回答问题或收集信息为目的的任务,而不是生产非专业产品的任务。有时...
  • 随着敏捷开发越来越流行,人人都在谈敏捷,人人也都在学习scrum等敏捷开发方法。。。当然,自己也是敏捷开发的实施者和受益者。
  • 敏捷开发 以人为核心、迭代、循序渐进的开发方式 简化文档,提取文档重点,主要在于人与人之间的沟通, 对开发产品进行迭代,最终完成开发。 迭代:迭代是指把一个复杂且开发周期很长的开发任务,分解为很多小...
1 2 3 4 5 ... 20
收藏数 43,671
精华内容 17,468
关键字:

敏捷开发中关于文档