敏捷开发 需求_敏捷开发 需求分析 - CSDN
  • 敏捷开发中的需求管理大致分为三个阶段:需求调研,需求分析和需求确认。 需求调研阶段 产品立项后,产品经理便开始了和需求打交道的漫长过程。第一步就是需求的调研工作。需求调研的质量,会直接影响到后续产品...

    产品的源头是需求。一切伟大产品的实现都是从需求管理开始的。敏捷开发中的需求管理大致分为三个阶段:需求调研,需求分析和需求确认

    需求调研阶段

    产品立项后,产品经理便开始了和需求打交道的漫长过程。第一步就是需求的调研工作。需求调研的质量,会直接影响到后续产品设计的工作。产品经理可以从以下渠道来调研需求:

    (需求的来源)

    1.从产品定位出发

    从产品定位出发指的是,产品经理应当对自己的产品有足够认知和把控。简单来说,就是我的产品是为了满足哪些人的哪些需求而做的。每款产品必定有其核心价值,基于此考虑往往能得到一些核心需求,摒除价值不大的需求。

    2.用户反馈

    用户反馈包括用户直接的反馈和间接的反馈。直接反馈指的是用户直接提出需求,如在产品的交流论坛,官方QQ群等用户提出的建议和需求。另外,用户访谈、调查问卷等方式也是比较常用的搜集用户需求的方法。间接反馈指的是通过对用户行为习惯(如习惯、偏好、使用流程等)的分析来获取用户的需求信息。

    3.竞争对手情况

    知己知彼百战不殆。竞争对手的产品优势及不足也是产品经理需求来源的重要渠道。竞争对手好的功能我们如何借鉴优化,不足如何规避,在反复探讨中也能获得好的灵感。

    4.相关人反馈

    这里的相关人包括任何对产品需求有贡献的人。主要有运营人员、客服人员、市场人员和开发人员的反馈。

    产品经理在收集需求的过程中需要注意的一点是,尽量保证需求的精准性,一是用户意图的准确,一是语言描述的精炼,否则接下来的需求整理工作必然变得非常吃力。用户需求在敏捷开发中称之为用户故事(user story)。通常的格式为:作为一个<角色>,我想要<功能>,以便于<商业价值>。这也是产品研发中用户需求描述的最标准格式。

    (禅道项目管理软件中的用户需求界面)

    需求分析阶段

    通过需求调研,此时产品经理已经掌握了很多用户需求,但这并不代表所有的需求都会为产品所用。产品经理需要对这些需求进行整理、分析与设计。需求分析主要有两个目的,一是挖掘用户的真正需求,二是评估可行性。

    在做需求分析时,产品经理可以从以下几个角度着手:

    1.定位分析

    产品定位就是满足什么样的用户在什么条件下的什么需求。如,购物网站是为了满足购物需求,社交软件是为了满足社交的需要。购物网站的社交需求,社交产品的购物需求一定是与产品的核心服务不统一的。在做需求分析时一定要多问一问是不是符合产品定位?好需求但不一定是适合的需求,说的就是这个道理。

    2.场景分析

    场景分析指的是要考虑什么环境(时间、地点、情境)下什么类型的用户基于什么动机,希望达到什么目的而采取的一系列行为。比如:

    基于什么环境:办公室/家里/公共场合/上下班途中/户外/室内/白天/夜晚……

    基于什么用户:老人/小孩/男士/女士/上班族/学生/家庭主妇……

    基于什么动机:省钱/省时/省力/打发时间……

    想达到什么目的:彰显个性/炫耀/获得认可/变美/变瘦……

    3.深层挖掘

    挖掘每个需求产生的原因:用户基于什么原因才提出这个需求?

    挖掘每个需求背后隐含的需求:用户提出这个需求,是为了达到什么目的?

    挖掘每个需求的重要性:这个需求是必须的吗?如果没有这个需求会怎样?

    通过深层挖掘往往会发现比原始用户需求更加合理的方案,也能发现那些用户没有说出口和没有想到的需求,而往往这些需求才是用户的真正需求。

    4.价值评估

    价值评估是指这个需求需要多少开发资源或运营能力,技术难度如何,时间花费如何等。可以从四个维度考虑:

    广度:该需求能覆盖多少目标用户?

    频率:该需求的使用频率是怎样的?

    强度:该需求对用户来说有多强烈?

    时机:该需求是否符合产品目前的规划?在当前的资源情况下能否具备可行性?

    (产品经理需要不断提出这样的疑问)

    需求确认阶段

    经过分析整理,产品经理已经获得了初步的需求列表,接下来需要对这些需求设计用例场景,并进行用例描述、流程分析、角色分析等。如,模块如何划分、流程如何设计、业务如何转换等,一般通过绘制行动图、状态图、用例说明来配合呈现,并最终形成《产品需求说明书》。

    很多时候,用例分析工作是产品经理、架构师、设计师等共同协作完成的,因为除了要考虑技术能否实现,还需要考虑产品性能、响应时间、设计风格等非功能性的需求。

    最后才是需求确认工作,确认工作一般通过需求评审会议来实现,由于是最终确认,参会人员可能包括运营、开发、设计、测试等成员,共同对需求说明书中描述的需求的正确性、一致性、完整性、可行性、必要性、可测试性进行确认。

    (用户需求的特性)

    在正式需求评审之前,产品经理可以提前与项目负责人做需求初评,目的是提前收集问题,沟通是否有技术难点,确认开发成本及是否有考虑不全的逻辑漏洞等。

    由于敏捷开发是快速迭代的开发模式,敏捷开发中一般由产品经理根据需求优先级整理近期待做需求,进行需求评审。评审会议叫做发布计划会议,在会上,由产品经理或产品负责人负责讲解需求,并对其进行估算和排序,制定出这一期迭代要完成的需求列表。

    需要提的一点是,在需求确认中一定要考虑到需求变更的确认。当需要进行需求变更的时候,一定要有书面的文档和签字手续。由于流程复杂,现在很多研发团队直接通过在项目管理软件中来记录需求的变更。如,禅道中凡是对需求 标题、描述、验证标准和附件的修改,都应该走变更流程。

    (禅道中的需求变更流程)

    至此,需求管理工作基本完成,接下来便步入产品设计环节。但这并不代表产品经理工作的结束,需求评审完成后,还需要进一步和开发、设计了解实现细节以完善产品方案并跟踪需求的实现。

    需求跟踪的目的是为了建立和维护从用户需求开始到测试之间的一致性和完整性。在整个开发过程中,确保所有的实现是以用户需求为基础的。

    需求跟踪有两种方式,正向跟踪与逆向跟踪:

    正向跟踪:以用户需求为切入点,检查《产品需求说明书》或《需求规格说明书》中的每个需求是否都能在后继工作产品中找到对应点。

    逆向跟踪:检查设计文档、代码、测试用例等工作产品是否都能在《需求规格说明书》中找到出处。

    (需求管理流程)

    需求管理恰如裁缝的量体裁衣,它直接关系到最终产品的成型。需求管理的过程,其实是从需求分析开始贯穿整个项目始终,力图实现最终产品同需求性的最佳结合。

     

    资料借鉴:

    需求管理-百度百科

    禅道项目管理—产品经理篇

    1QCDgHLaJYqKFO.gif

    展开全文
  • 敏捷开发需求迭代

    2015-04-19 15:21:13
    迭代需求的整理是敏捷开发的第一步,也是敏捷开发很重要的一步,在这一步中我们需要把客户的业务需求按照优先级的顺序,整理成为一个个的迭代。然后把一个个的迭代拆成一个个可验收的故事卡。  在此需要说说什么是...

    迭代需求的整理是敏捷开发的第一步,也是敏捷开发很重要的一步,在这一步中我们需要把客户的业务需求按照优先级的顺序,整理成为一个个的迭代。然后把一个个的迭代拆成一个个可验收的故事卡。

           在此需要说说什么是故事卡,故事卡和业务需求之间的关系。故事卡是一个个独立的,可验收的功能,一个业务需求可以拆分为多个故事卡。比如:我们常见的账号管理需求,需要对账号进行增、删,改、查。因为添加、修改、删除、查询都是一个个可单独验收的场景,我们可以把账号管理需求拆分为四个故事卡。因此把需求拆分为故事卡的原则是:

         1.故事卡是可以独立验收的场景

          2.故事卡包含的点数应该尽量小,一般划分为1、3、5个点,如果超过了应该重新拆分该故事卡。给故事卡评点的标准是什么了?我们可以按照一个查询完成的工作量是1个点,然后衡量该故事卡的工作量而适量的评点。

          3. 注意故事卡完成的工作量中包括自我测试和联调的时间。而不是单独的只是开发完成。

            敏捷开发强调成员之间的交互而不强调文档,但这并不意味着不需要文档,需求说明的好坏直接影响着客户价值的交替,我们先来看看下面的一张图:

            image

    客户      : 客户高兴的把具有5个价值点的需求交代给需求人员

    需求人员: 需求人员由于理解的不同,只从顾客那里接受了3个价值点

    程序员   : 由于需求人员表述的不清晰,最终程序员只理解了1个价值点,并交互给客户

    客户      : 当客户拿到只有1个价值点的产品后,客户哭了!!

    因此作为需求人员,当在向程序员解析需求的时候,需要做到以下几点,防止价值点的丢失。

    a.  功能点:需求包含了那些功能点

    b.  约束条件: 每个功能点有什么约束条件

    c.  流程图 :功能点的业务流程是怎样的

    d. 如果有界面的话,需要有页面元素图以及说明。

    e. 验收:验收不同于测试用例,主要用来模拟用户的行为以及期望的响应

    现在我们就以一个简单的登录界面,来讲讲应该怎样去描叙需求:

    功能点:

             1. 用户可输入用户名、密码。可选择自动自动登录、记住密码。响应登录按钮

             2. 当点击登录时: a. 判断用户名、密码是否有为null,有则提示用户。

                                       b. 记录用户名、密码以及记住密码、自动登录的状态

                                       c.  发起登录请求,并响应登录状态。成功则调转到下一个界面,失败则提示用户

             3. 启动登录界面的时候,读取配置文件,访问记住密码和自动登录状态。如果记住密码为true,自动登录为false,则启动登录界面的时候,用户名和密码为上次登录退出时的用户名和密码。如果自动登录为true,则直接执行点击登录的事件。

    约束条件:

             1. 用户名必须以字母开头,并且包含字母、数字,长度不小于6位,当焦点切换到密码的时候,自动验证输入的用户名的合法性

             2. 密码以*号隐藏

    流程图:

             image

    界面(低保真--界面元素草图):

          image

    验收

    image

    以上对敏捷开发的阐述,摘自网上!

    展开全文
  • 简介 这几年关于敏捷开发在互联网企业中越来越广泛被使用到,运用的比较多的当属scrum敏捷开发... 敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。 在敏捷开发中,软件项目在构建初期被...

    简介

    这几年关于敏捷开发在互联网企业中越来越广泛被使用到,运用的比较多的当属scrum敏捷开发和xp敏捷开发,人人都在谈论敏捷开发。那什么才是敏捷开发呢?

    目录

    1. 什么是敏捷开发?
    2. 传统的开发模式和敏捷开发模式的对比?
    3. 敏捷开发scrum的实施。

    什么是敏捷开发

    敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。

    在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

    传统的开发模式和敏捷开发模式的对比

    瀑布模型:
    这里写图片描述
    优点:
    1. 为项目提供了按阶段划分的检查点。
    2. 当前一阶段完成后,您只需要去关注后续阶段.
    3. 它提供了一个模板,这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。

    缺点:
    1. 各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量。
    2. 由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发风险。
    3. 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
    4. 瀑布模型的突出缺点是不适应用户需求的变化。

    敏捷模型:
    这里写图片描述
    优点:

    1. 敏捷开发的高适应性,以人为本的特性。
    2. 更加的灵活并且更加充分的利用了每个开发者的优势,调动了每个人的工作热情。

    缺点:

    1. 由于其项目周期很长,所以很难保证开发的人员不更换,而没有文档就会造成在交接的过程中出现很大的困难。

    敏捷开发scrum的实施

    Scrum的英文意思是橄榄球运动的一个专业术语,表示“争球”的动作;把一个开发流程的名字取名为Scrum,相当于大家像打橄榄球一样迅速、富有战斗激情。而Scrum就是这样的一个开发流程。

    Scrum开发流程中的三大角色
    – 产品负责人(Product Owner)

    主要负责确定产品的功能和达到要求的标准,指定软件的发布日期和交付的内容,同时有权力接受或拒绝开发团队的工作成果。

    – 流程管理员(Scrum Master)

    主要负责整个Scrum流程在项目中的顺利实施和进行,以及清除挡在客户和开发工作之间的沟通障碍,使得客户可以直接驱动开发。

    –开发团队(Scrum Team)

    主要负责软件产品在Scrum规定流程下进行开发工作,人数控制在5~10人左右,每个成员可能负责不同的技术方面,但要求每成员必须要有很强的自我管理能力,同时具有一定的表达能力;成员可以采用任何工作方式,只要能达到Sprint的目标。

    scrum开发流程图

    这里写图片描述

    1、我们首先需要确定一个Product Backlog(产品需求列表),这个是由PO负责的(如图(一));

    2、有了Product Backlog列表,我们需要通过 Sprint Planning Meeting(Sprint计划会议) 来从中挑选出一个Story作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog;

    3、Sprint Backlog是由Scrum Team去完成的,每个成员根据Sprint Backlog再细化成更小的任务(细到每个任务的工作量在2天内能完成);

    4、在Scrum Team完成计划会议上选出的Sprint Backlog过程中,需要进行 Daily Scrum Meeting(每日站立会议),每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 Sprint burn down(Sprint燃尽图)(如图(二)和如图(三));

    5、做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本。

    6、当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品。

    7、最后就是 Sprint Retrospective Meeting(回顾会议),也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中;

    如图(一):
    这里写图片描述

    如图(二):
    这里写图片描述

    如图(三):
    这里写图片描述

    如图(四):
    这里写图片描述

    敏捷开发管理工具:teambition
    teambition

    参考

    敏捷开发之Scrum扫盲篇
    百度百科
    敏捷开发 模型讲解

    展开全文
  • 敏捷需求分析管理 需求管理(变更控制,版本控制,需求跟踪和状态跟踪)和需求开发(问题获取,分析,规格说明,验证) 系统变更频繁 系统上线时遇到很大阻力 系统上线后效果不佳 系统不可用甚至崩溃 •...

    敏捷的需求分析管理

    需求管理(变更控制,版本控制,需求跟踪和状态跟踪)和需求开发(问题获取,分析,规格说明,验证)

    1. 系统变更频繁
    2. 系统上线时遇到很大阻力
    3. 系统上线后效果不佳
    4. 系统不可用甚至崩溃

    敏捷的需求过程

    1. 需求获取:通过与用户的交流,对现有系统的观察及对任务进行分析,从而开发、捕获和修订用户的需求;
    2. 需求建模:为最终用户所看到的系统建立一个概念模型,作为抽象描述,并尽可能多的捕获现实世界
    3. 需求规格:生成需求模型构件的精确的形式化的描述,作为用户和开发者之间的一个协约;
    4. 需求验证:以需求规格说明为输入,通过符号执行、模拟或快速原型等途径,分析需求规格的正确性和可行性,包含有效性检查,一致性检查,可行性检查和确认可验证性;
    5. 需求管理:支持系统的需求演进,如需求变化和可跟踪性问题。

    需求的概念和需求分析的任务:软件需求是用户解决问题或达到目标所需条件或能力。

    敏捷的需求类型:

    1. 业务需求( business requirement)反映了组织机构或客户对系统、产品高层次的目标要求,它们在项目视图与范围文档中予以说明。
    2. 用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务,这在使用实例(use case文档或方案脚本(scenario)说明中予以说明。
    3. 功能需求(functional requirement)定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足了业务需求。

    敏捷的需求分析与软件生命周期的关系

    敏捷的需求分析方法总结:

    收集用户需要产生的单据和报表 ;表单及报表的适用对象;

    画出业务流程图,并认真检查和核对每条路径中是否完备,异常情况怎样处理(系统的动态特性);

    依据流程图收集每个步骤需要的使用和操作的数据,确定数据的类型和范围(系统的静态特性);

    画出业务实体及其关系,并估计业务实体的产生频率和数据量;

    评估业务流程和实体中需求变化的可能性;用户权限;

    信息系统建设现状;收集用户对系统界面风格、版式、颜色的偏好和需求;

    对系统将来使用的硬件、操作系统、网络情况进行了解;收集系统初始化数据,或者要求客户进行收集和整理,明确期限时间;

    编制简单界面原型(该步骤也可放在需求分析之后完成,再次和用户进行沟通);

     

    展开全文
  • 于是不少团队开始怀疑敏捷开发的好处,要是按照传统瀑布模式,就没有这些烦恼了。 之所以会有这样的问题,我觉得最主要的是需求没有拆分到足够细,这里总结一下需求拆分的几个好处吧。 更方便安排工作 如果每个...

    经常碰到迭代结束了,还很多任务未完成,若按照敏捷的原则,得将未完成的任务延期到下一个迭代,但会导致不少重复工作量;若不这么做,就得延长迭代周期,变得不伦不类。

    于是不少团队开始怀疑敏捷开发的好处,要是按照传统瀑布模式,就没有这些烦恼了。

    之所以会有这样的问题,我觉得最主要的是需求没有拆分到足够细,这里总结一下需求拆分的几个好处吧。

    更方便安排工作

    如果每个需求能拆分到足够小,可以有效防止任务遗漏,避免到迭代末才陆陆续续冒出来没有考虑到的任务。也方便大家领任务,且小需求可让大家均衡的工作,不会一阵忙一阵松,改善团队的绩效。

    及时发现风险

    需求拆分越细,思考就越多,识别的风险就更充分,这样有更多时间去减缓风险的发生,凡事预则立不预则废。

    更快获得反馈

    敏捷最大的好处之一就是通过频繁交付,快速获得反馈,而这最主要还是通过需求细化来实现。如果需求太大,多于一周甚至一个迭代,那么就必然会出现到迭代末还有大量需求未完成的情况,也就无法获得PO或客户的反馈,所以我在团队内一直强调,需求要细化到1-3天内。特别是,迭代内要求同时要完成测试任务的,就要拆的更细,否则到迭代末才有可测试的版本。

    发现问题更及时修复

    迭代内发现的BUG,在迭代内修复效率是最高的,超过一个迭代,可能开发已经忘记自己写的代码了,再去定位要花费更多时间。

    便于优先级的排列

    需求越细,PO越容易排列优先级,原有大需求中的高价值部分可能会被排前面,而低价值部分会排后面。这样团队将会持续在开发“更精确的”高优先级需求,防止到迭代末还有高价值的需求未实现。

    节约估算时间,提高估算准确度

    需求粒度越小,需求间的差距就会越小,这样团队就不需要估算每个故事的大小了,可以直接算故事个数。迭代结束未完成的需求也会小很多,防止有大粒度需求未完成,这样迭代交付率就会很高。

    提高信用度

    试想一下,假若每个迭代跟干系人承诺的需求实际完成率都很低,下次还会有人信任你们的团队吗?只有每个迭代都按期完成了,才能提高团队的可信度,而便于团队形成稳定的迭代速率,团队的信心也会增强。每个迭代90%以上的交付率,总比50%的交付率给人的感觉更舒服吧。

     

     

     

    展开全文
  • 敏捷开发是快速迭代,快速交付的开发模式。这也就要求迭代周期内任务量不宜过大,以保证在预期内能够按时完成开发计划。敏捷开发中怎样保证开发任务的适宜呢?答案是任务分解。而任务分解的前提则是需求确认。   ...
  • 敏捷开发需求澄清

    2015-04-19 15:27:12
    SE整理完一个迭代的需求以后,进入下一个流程需求澄清,需求澄清的主要目的是给开发人员澄清需求,确认开发点。  需求澄清的一般流程为:  1. SE给开发人员讲解需求点  2. 开发人员评论需求点是否合理,完善...
  • 敏捷开发,如何敏捷?我们需要一系列成熟的工具帮助我们敏捷。敏捷开发工具的适合以及选用,对开发项目起着关键性的作用。 此篇介绍我们在scrum敏捷开发中发掘的几款工具,方便更多新加入的开发者上手。 1. ...
  • 敏捷开发 需求澄清

    2011-06-12 11:08:00
    SE整理完一个迭代的需求以后,进入下一个流程需求澄清,需求澄清的主要目的是给开发人员澄清需求,确认开发点。 需求澄清的一般流程为: 1. SE给开发人员讲解需求点 2. 开发人员评论需求点是否合理,完善 3. 开发...
  • 《程序员》2009年2月刊,第70页有一篇如题的文章,比较清晰的阐明了敏捷与传统方法在...摘抄要点如下: 传统需求分析敏捷需求分析需求分析时机更多地集中在项目早期近乎均匀地贯穿于项目的整个生命周期需求划分单位
  • 背景需求文档解析成本太高。RD解析一遍,QA解析一遍。 我们的产品需求是用户真正需要的吗? 需求文档!=记录产品需求 应该代表用户需求
  • 我们比较熟知的软件项目管理方法是瀑布。其基本流程是需求-&...国外的软件先行者们针对瀑布开发中暴露出来的问题进行了一系列的探索、思考和总结,提出了Agile Dev的概念,中文翻译为敏捷开发。一.什么...
  • 典型的问题在于:敏捷开发倡导“迭代期内无变更”以换取“团队承诺”,而实际上产品负责人却会不断地来提变更,打乱开发计划了。我们应该怎么办呢?产品负责人说“敏捷就是拥抱变化,我现在来提变化了,你们却关门了...
  •  精益敏捷开发以轻量级的文档与团队协作, 提高开发的效率◦ 另一方面, 许多人对于精益敏捷开发在轻量级的文档下, 如何保证开发的质量存在著许多的质疑与困惑◦  本文将从 “度量” 的角度, 运用一轻量级度量的...
  • amp;mid=401739882&amp;idx=1&amp;sn=531e9ea49456e55a8437cd8b995c5237&amp;mpshare=1&amp;scene=23&...srcid=0306Xub1QrGlx3FpBAAux7W1#rd莎士比亚戏剧《哈姆雷特》中的名...
  • 敏捷开发与测试流程

    2019-07-08 16:12:47
    1、敏捷开发:包含各个工程师并发进行 传统交付的流程: 低效率 客户不可以提前使用 无法相应需求变化 敏捷开发的迭代流程: 什么是敏捷开发 将一个项目的模块分为多个相互联系但是可以独立运行的小...
  • 敏捷”在互联网和软件开发领域从涓涓细流逐渐演变为行业潮流,往小了说是改进了开发方法,往大了说是革了瀑布流式的命——把产品开发引向了快速迭代、小步快跑的路线上。我们使用 tapd 写 feature,流转、跟踪任务...
  • 需求变更管理  需求变更是要经过申请、审批、执行、确认等流程。  为什么要做需求变更的管理?主要原因有两个: 1. 防止范围蔓延引起的进度、成本、质量上,甚至严重时导致项目全面失败的问题; 2....
  • 这是敏捷开发一千零一问系列的第三十三篇。(在这里提问,之一,之二,之三,问题总目录)也是敏捷开发用户故事系列的第十篇(栏目目录)。问题需求清晰到什么程度可以进行开发?一定要弄清楚需求才能开发吗?怎样...
  • 敏捷开发已经有着超过20年的历史,国内也热起来有五年了,理论和方法学的文章网上数不胜数,但真正深入解决问题的却少之又少,全靠团队自己琢磨,比如下面我们要讨论的如何解决敏捷化开发和需求跟踪和记录的问题。...
1 2 3 4 5 ... 20
收藏数 75,676
精华内容 30,270
关键字:

敏捷开发 需求