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

    敏捷开发中文档的取舍

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

    文档的功能

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

    沟通

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

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

    Agile/Lean Documentation: Strategies for Agile Software Development

    敏捷开发是不是不用写需求分析、概要设计、详细设计之类的文档了啊?
    概要设计文档、详细设计文档是源自传统软件工程的说法。  
    如今传统的 Word、PDF 版的详细设计文档通常可以省略,大部分这类文档可以结合代码注释用工具自动生成,Web/HTML 版的详细设计/代码参考文档才是更好的做法。在敏捷开发中,需求文档、概要设计(改成架构设计)文档通常是不能省略的。
    
    展开全文
  • 敏捷项目没有需求分析吗?】 在很多人的印象中,敏捷软件开发是种类似黑客行为的过程,是程序员最爱的勾当。不写文档,不作需求分析,没有项目经理,做什么东西完全是程序员自己的行为。所以他们认为这样的过程...

     

    【敏捷项目没有需求分析吗?】

    在很多人的印象中,敏捷软件开发是种类似黑客行为的过程,是程序员最爱的勾当。不写文档,不作需求分析,没有项目经理,做什么东西完全是程序员自己的行为。所以他们认为这样的过程无法满足真正大型项目和复杂项目的需要,因此在经过考虑后,放弃了敏捷方法。 项目经理圈子真的是这样吗?敏捷过程到底是如何做需求分析?用户故事和用例有什么区别?敏捷过程如何去管理需求的?这些是一些想要实践敏捷的人一直在困惑的事情。

    我们常常看到书中讲,程序员拿到一个用户故事后,怎么计划,怎么分解,怎么写单元测试,怎么小步前进,怎么持续集成。这是典型的程序员视角。事实上,敏捷方法分为三部分,敏捷项目管理,敏捷需求分析,敏捷软件开发。上述书中提到的完全是敏捷开发中的实践,很多人了解到的敏捷,只是敏捷的三分之一。

     

    【敏捷项目中谁来做需求分析?】

    在敏捷的团队中,作一个敏捷程序员确实是非常舒服的事情。从程序员的角度来看,只需要选择一张他感兴趣的故事卡片,了解清楚该卡片的需求,开始从功能测试写代码,等通过了所有测试就完工。基本上不需要考虑太多的事情,非常轻松愉快。但程序员向谁去问清楚需求?故事卡片是怎样写出来的呢?让我们来关注开发前发生的事情。

    了解敏捷过程的人都知道,Kent Beck在XP过程中提到了现场客户,如果一个敏捷团队能够有现场客户,这当然是最棒的事情。但多数情况下,客户都是很忙碌的,很难全力投入到软件开发过程中。这时候,我们就需要商务分析师这个角色,来充当客户的角色。

    我在公司的团队中曾担任的就是商务分析师这个角色。商务分析师最重要的职责就是与客户交谈,了解和分析需求,将其制作成用户故事并将需求转述给程序员。同时,商务分析师也要代替客户负责功能验收测试。

     

    【敏捷项目中如何进行需求分析?】

    敏捷思想的核心是人与交流。需求问题实际上是一个交流问题。商务分析师要和客户交流,搞清楚客户到底需要什么,到底为什么需要这些东西。商业价值是商务分析师关注的最终目标。有了目标的指向,就可以不迷失方向。和客户进行交流,最终目的就是挖掘出客户的商业目标。可能大家会经常有这样的经验,客户说,我要这个功能,我想要怎么怎么样。这时候要特别注意,他说的这些东西并不是真正的需求。商务分析师需要详细的问客户为什么,挖掘出他真正的目标。

    在这个目标下,商务分析师开始进行需求的分析:我们到底是否真的需要这个需求?有没有更好的解决方案?有没有简单并且低廉的方式?换一种形式是不是也能达到这样的需求?这个需求有多少地方涉及到以前的软件变更?

    搞清楚这些事情后,就可以写出用户故事。用户故事的书写遵循一定的原则,一般包括三部分:"作为(系统的一个涉众),我想要(做一件事),从而(达到一个商业价值)"。在书写的时候格式比较随意,可以在故事卡背面写上注释或疑问,甚至画上界面原形图。

    举一个最常见的用户故事例子,“作为一个普通用户,我希望能够用用户名和密码登录,以便我能享受到个性化的服务”。其中,用户是系统涉众,登录是他想要做的事情,而他的目标是获得个性化的服务。

    从这个例子我们可以想象到,这个页面可能存在两个文本框,用于输入用户名和密码,有一个按钮来登录,并且不登录就不能看到个人资料,另外,如果用户输入错误需要提示“登录失败请重试”。这就是可见性,也可以称为可测试性。我们可以根据这样的可见性写出功能测试,从而驱动这个用户故事的开发,这被称为 Acceptance Driven Development。

    用户故事的作用有两个,一个是作为进度跟踪的依据,一个是作为与人交谈的备忘录。用户故事卡片并不是很精确的需求,因此不需要把事情描述的非常清楚。将需求的详细分析推迟到实现前夕来完成,这是敏捷需求分析的精华所在。任何提前做好的东西都会导致浪费,敏捷过程提倡足够就好,避免浪费。

    不少人对用户故事和用例的区别感到疑惑。用户故事的作用是备忘功能,而不是文档。而用例需要详细的描述其操作步骤,以及每个异常路径,因而起到了文档的作用。用户故事是可见的商业价值,而不是功能描述。每个用户故事的粒度和工作量都相差不多,这和用例有很大的区别。用户故事是小粒度的,可测试的,可见的,并且是有价值的。

     

    【敏捷项目需求分析案例】

    公司有个项目组作的是一个网游物品交易平台。该平台是典型的互联网项目,在开工的时候客户对功能需求还不明确,但需要快速推出抢占市场,正是最适合敏捷过程的项目。

    在项目伊始,商务分析师和客户做了深入的谈话,了解他的商业构想,他的盈利模式,搞清楚宏观的结构,然后思考并整理获得的结果,花1-2天时间将客户需求大略整理为几十个用户故事。这些用户故事并不完善,不足以做好整个系统。但对于我们开始项目的前一阵,已经足够了。我们可以从这里开始项目。敏捷方法希望快速交付可用的软件。实现软件的快速交付是通过迭代来完成。在迭代开始前,由一组有经验的开发人员大致评估一下用户故事,标记出不同的难度和风险,并提出问题供商务分析师来获得更详细的信息,商务分析师会和相关涉众去讨论。然后商务分析师将推荐优先级最高的一组用户故事给客户来挑选,客户可以选择这些用户故事,或者指出从他的视角看到的优先级更高的用户故事。这些将成为下一个迭代的内容。 项目经理圈子客户看到每个迭代交付的可运行的软件后或者得到用户反馈后,常常会有新的想法冒出来。有些想法是好的,有些想法就属于看到别家网站有这个功能,不假思索的提出的功能。这些不同的需求都需要经过认真的分析,找出哪些是值得我们立即考虑的,哪些是不用急迫的去实现的

    有一次和客户谈话时,他说到希望增加拍卖功能。那么,我们为什么需要拍卖呢?客户说希望让用户拍卖物品以获得最高价格。经过考虑,我们发现网游物品的实时性和唯一性决定了系统不适合使用拍卖机制。拍卖的时效性无法满足实时交易的要求,因此,用户最终放弃了这个特性。

    另一次,客服人员提出增加一个查询用户交易的功能,而此时我们有其他更加重要的功能需要先去考虑,查询用户交易功能可以由技术人员临时通过数据库直接代为查询,因为项目运营初期交易不是很多,暂时还不需要专门的后台功能来支持客服的工作。所以把这个需求卡片一直贴在墙壁上,始终没有排到最高的优先级。 客户一开始也不是很能够接受敏捷需求中强调商业价值和优先级的做法。但经过几个月的磨合,客户也逐渐适应了许多敏捷思想,甚至我在和客户讨论时,偶然提起了后期的某种可能的情况,他们还能够帮我纠正应当考虑目前的情况,为近期的情况作计划。

    用户故事的跟踪和管理是由项目经理来进行。每个迭代跟踪卡片的进展,是否已经开始实现?是否已经完成代码开发?是否已经开始功能测试?不同的卡片在迭代前都会评估为不同的大小。我们一般分为大中小三级。等实践过几个迭代后,团队的开发速度基本保持恒定,我们就可以很容易的知道每个迭代能做多少个用户故事,这样就可以安排下一迭代的开发。

    每个迭代内分析好恰好足够下一个迭代开发的需求,就是商务分析师每个迭代的主要工作内容。商务分析师的需求分析工作在上一个迭代完成,包括需求的了解,分析,评估和排列优先级。

    在每个迭代开始的时候,由商务分析师主持召开迭代计划会议,在会议上向所有的程序员解释这个迭代要完成的用户故事,然后由程序员自由提问,知道他们能够获得足够开始实现该功能的信息。

    在程序员完成一个用户故事后,商务分析师还要来代表客户做功能验收测试,查看是否完成了预计的功能,是否有程序员还没有想到的异常情况。如果存在问题需要退回给程序员继续完成。这在一定程度上保证了系统完成的需求不偏离客户的要求。当然,更多的测试还需要QA来完成。

    我们的实践充分表明了,敏捷过程并不是没有需求分析,而是把需求分析过程分散到整个开发的过程中,让开发和需求分析并行进行。这就是公司敏捷方法实施成功的秘诀之一。而商务分析师在这个过程中,起到了纽带和桥梁的作用,是一个团队不可缺少的角色 。


    http://www.uml.org.cn/RequirementProject/201108261.asp


    展开全文
  • 《程序员》2009年2月刊,第70页有一篇如题的文章,比较清晰的阐明了敏捷与传统方法在...摘抄要点如下: 传统需求分析敏捷需求分析需求分析时机更多地集中在项目早期近乎均匀地贯穿于项目的整个生命周期需求划分单位

     

    《程序员》20092月刊,第70页有一篇如题的文章,比较清晰的阐明了敏捷与传统方法在分析时机、划分单位、细化过程、文档要求和应对变更五个方面的差异。摘抄要点如下:

     

     

    传统需求分析

    敏捷需求分析

    需求分析时机

    更多地集中在项目早期

    近乎均匀地贯穿于项目的整个生命周期

    需求划分单位

    基于功能分解,划分模块或子系统,一个模块或子系统的颗粒度通常较大

    基于能否独立业务价值,切割成一个个用户故事,一个故事有时会跨越传统的模块或子系统边界;故事的颗粒度较小

    需求细化过程

    一步到位,可供开发人员设计开发

    逐步细化,仅就下一个迭代需要实现的部分进行详细分析

    需求文档要求

    正式文档,往往有明确的格式要求。既作为设计开发人员必须严格遵守的规约,也作为向客户提交的必备产出物之一。难维护,难验证(跟踪)

    非正式文档。仅仅是辅助开发团队与客户沟通,不作为规约,也不作为必备产出物。更多强调通过自动化功能测试用例来跟踪系统需求

    应对需求变更

    有严格的控制流程,视变更为风险

    视变更为必然或预期中的事情

     

    敏捷方法中需求文档的作用和传统方法不同:

    需求文档不是需要严格评审的项目产出物 不用担心需求文档过时或已经与系统不符 文档没有固定的格式,视沟通的需要而定 鼓励非文档方式的沟通

     

    选择敏捷或传统过程与方法的考虑因素

    需求易变

    需求稳定

    客户或业务人员随时可找到并与之沟通

    客户或业务人员较难接触到

    客户更在意产品投入市场或系统投入运营所需的时间

    客户更在意产品或系统是否覆盖了制定的需求或功能范围

    团队(包括交付团队和客户团队)成员分布在同一地域

    团队成员分布在不同地域

    交付团队拥有更多的开发过程自动化技能及工作环境,诸如自动化测试、持续集成等

    交付团队拥有较少的开发过程自动化技能及工作环境

     

     

    展开全文
  • 文档是个好东西,这是不可否认的,但是太依赖文档也有弊端,下面我从不同的度来分析一下文档的利与弊,然后思考在敏捷开发时,文档又是如何进行的。从 公司的角度来看,编写文档有如下好处:  a1) 公司使用的是瀑布...

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



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


    从 公司的角度来看,编写文档有如下好处: 
    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是开发人员自身的原因。


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

    展开全文
  • 敏捷开发文档

    2019-06-20 06:43:35
    需求不写文档只写故事卡片,一般我也会写验收条件,或者写改动点(看具体情况,目的是开发能理解需求到底是什么),通过大量的Conversation完成细节。这些动作都是按Story的3C原则落实的。同时继续维护Use Case文档...
  • 敏捷开发中的需求管理大致分为三个阶段:需求调研,需求分析和需求确认。 需求调研阶段 产品立项后,产品经理便开始了和需求打交道的漫长过程。第一步就是需求的调研工作。需求调研的质量,会直接影响到后续产品...
  • 敏捷需求分析管理 需求管理(变更控制,版本控制,需求跟踪和状态跟踪)和需求开发(问题获取,分析,规格说明,验证) 系统变更频繁 系统上线时遇到很大阻力 系统上线后效果不佳 系统不可用甚至崩溃 •...
  • 敏捷需求分析

    2008-02-13 10:19:00
    不写文档,不作需求分析,没有项目经理,做什么东西完全是程序员自己的行为。所以他们认为这样的过程无法满足真正大型项目和复杂项目的需要,因此在经过考虑后,放弃了敏捷方法。 真的是这样吗?敏捷过程到底是如何...
  • 敏捷开发与没有规范,没有文档的代码编写者的区别 与某些观点相反,敏捷开发人员并非不按规则或限制编写代码的特立独行者。“牛仔编码”是缺乏规则和管理糟糕的迹象,并且很不专业。如果团队里面存在这样的编写代码...
  • 敏捷开发模式下需求分析岗 BA 传统的瀑布开发模式下需求分析岗是必不可少的。那么敏捷项目没有需求分析吗?在很多人的印象中,敏捷软件开发是种类似黑客行为的过程,是程序员最爱的勾当。不写文档,不作需求分析,...
  • 软件项目中有很多种文档,包括需求文档、设计文档、API文档、缺陷报告、进度报告、移交文档、验收文档等等。 ...第二条敏捷宣言是"可工作的软件胜于详尽的文档",据此很多人想当然认为敏捷开发
  • 这几年关于敏捷开发在互联网企业中越来越广泛被使用到,运用的比较多的当属scrum敏捷开发和xp敏捷开发,人人都在谈论敏捷开发。那什么才是敏捷开发呢? 目录 什么是敏捷开发? 传统的开发模式和敏捷开发模式的...
  • 敏捷开发需求迭代

    2015-04-19 15:21:13
    迭代需求的整理是敏捷开发的第一步,也是敏捷开发很重要的一步,在这一步中我们需要把客户的业务需求按照优先级的顺序,整理成为一个个的迭代。然后把一个个的迭代拆成一个个可验收的故事卡。  在此需要说说什么是...
  • 就目前我所待过的两个项目组,包括我了解到其他一些项目组的情况,基本都遵循了瀑布模式的实施方式,简单来说就是需求分析--设计--开发--测试--投产。 从入场开始需求调研到交付详细需求文档,我们称之为需求分析...
  • 笔者正在学习《软件工程-实践者的研究方法...敏捷可以应用于任何一个软件过程(沟通、策划、建模、构建和部署),过程的设计应该使项目团队适应于任务,并且使任务流水线化,在了解敏捷开发方法的流动性的前提下进行...
  • 敏捷开发和详细设计

    2013-03-28 10:23:57
    传统的软件开发过程,总要按需求分析,可行性分析,概要设计,详细设计,测试,维护 的软件周期来进行,随着敏捷开发方法和敏捷开发工具和技巧的发展,软件过程中的 一些步骤被新的开发颠覆甚至忽略。 模块耦合度...
  • 在产品研发过程中,《需求文档》与《需求分析报告》以及《需求规格说明书》是产品研发的辅助文档,必不可少。遗憾的是不但外行人傻傻分不清,有时候相关从业者乃至被神化了的产品经理也是分不清楚。是什么导致了分歧...
  • 需求分析是软件开发过程的核心,其结果直接影响到整个的软件开发过程,对开发的成败起决定作用。因此,做好需求分析是软件开发的关键。传统的软件工程理论主张开发方派专门的需求分析人员或小组到委托方进行长期的...
  • 敏捷开发实践总结

    2018-11-25 23:46:06
    敏捷开发实践的认识什么是敏捷开发敏捷开发的原则多种敏捷开发的方法一个敏捷团队敏捷开发中常用的术语迭代的典型流程致谢 什么是敏捷开发 敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发...
  • 敏捷开发的核心思想

    2015-10-12 10:39:08
    敏捷开发的核心思想主要是迭代式开发,将整个项目分解为数个短期的迭代周期,快速相应需求进行增量开发。 结合我们公司的开发经验来看,我个人觉得敏捷开发主要包括几个步骤: 需求制定——》需求分析——》设计...
1 2 3 4 5 ... 20
收藏数 20,615
精华内容 8,246
关键字:

敏捷开发 需求分析文档