敏捷开发 需求文档_敏捷开发需求文档 - CSDN
  • 背景需求文档解析成本太高。RD解析一遍,QA解析一遍。 我们的产品需求是用户真正需要的吗? 需求文档!=记录产品需求 应该代表用户需求。

    做这项调研的初心是什么?

    需求文档解析成本太高,还存在高风险。

    RD解析一遍,QA解析一遍。而且还存在风险

    让产品开发过程更加和谐,而不是紧张和对峙

    需求的用户视角,非PM,RD视角

    当自问心中的用户形象时,看到的是自己。

    先解释一些概念问题

    何谓“瀑布流式”开发模式

    何谓“敏捷”开发模式

    瀑布流式的需求文档存在哪些问题

    语言本身的歧义性

    对于产品团队的压力

    敏捷下的“需求文档”——用户故事

    做个比较

    传统需求文档

    用户故事

    用户故事包含哪些?

    为什么称呼为用户故事?

    使用用户故事的工作方式是如何运作的?

    //使用流图的形式。这里不具体去讲用户建模

    用户故事的限制

    我的看法

    背靠大平台下的小团队,
    市场敏感度极高

    我们的产品需求是用户真正需要的吗?

    对比 美团及去哪儿 ,
    请描绘一下我们的用户长什么样?对火车票行业十分精通,熟知代理商,自建概念。

    需求也需要性感

    需求文档!=记录产品需求 需求文档==用户需求。
    需求文档枯燥乏味,像是政府文件,

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

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

    需求调研阶段

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

    (需求的来源)

    1.从产品定位出发

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

    2.用户反馈

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

    3.竞争对手情况

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

    4.相关人反馈

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

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

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

    需求分析阶段

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

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

    1.定位分析

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

    2.场景分析

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

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

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

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

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

    3.深层挖掘

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

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

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

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

    4.价值评估

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

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

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

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

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

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

    需求确认阶段

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

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

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

    (用户需求的特性)

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

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

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

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

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

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

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

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

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

    (需求管理流程)

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

     

    资料借鉴:

    需求管理-百度百科

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

    1QCDgHLaJYqKFO.gif

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

    我们比较熟知的软件项目管理方法是瀑布。其基本流程是需求-&gt; 设计-&gt;开发-&gt;测试。基本假设只要把每一个环节都做正确,那么最终得到的结果也是正确的。瀑布开发有非常成功的案例,比如微软。但从总体来讲,瀑布项目失败率比较高。国外的软件先行者们针对瀑布开发中暴露出来的问题进行了一系列的探索、思考和总结,提出了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解除疑问。而且整个敏捷团队还需要召开发布计划会议、迭代计划会议、演示会议等内部会议及每日站立会议。每日站立会议上,团队成员依次回答昨天做了什么今天计划做什么,有什么问题,发现问题及时提出和解决。每个人发言完后,要走到任务看板前更新自己的燃尽图。这也是敏捷流程中不可缺少的环节。

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

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

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

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

     

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

    敏捷误区:敏捷并不意味着不需要文档

    在敏捷的过程中,会有一种叫做产品需要设计文档的东东,简称PRD。最近在一次公司组织的内部培训会上,老师提供了一份PRD文档的模板,个人觉得这个PRD模板比较轻量,现在分享给大家。 

    1、概述

    产品概述及目标

    名词解释

    数据词典

    文档阅读对象

    2、产品描述

    产品整体流程

    产品需求描述

    产品版本规划

    产品框架

    功能列表

    3、功能需求(开发人员可根据功能需求进行设计;测试人员可根据功能需求进行用例设计)

    流程图

    界面

    字段说明(包括数据字典)

    业务说明(用例)

    4、非功能需求

    安全需求

    统计需求

    性能需求

    可用性需求

    5、上线、下线需求

    上线需求

    验收标准AC

    下线需求

    6、运营计划

    后续运营方式及计划

    7、附录

    其他说明

    展开全文
  • 敏捷开发需要哪些文档? 需求说明 对功能、交互方式、出错或边界情况的表现进行总体描述 1.画面图 2.数据图 3.需求说明 来源张永光的博客
  • 开发要有开发文档(需求文档、数据库设计、概要设计)、开发计划(甘特图、燃尽图)、测试计划(时间、地点、人员、任务模块分配、禅道bug提交管理)都应该有一个时间段,在大家的一起商量之下可以每个人做到心中...
  • 敏捷开发学习总结: 思考开发文档的利与弊 文档是个好东西,这是不可否认的,但是太依赖文档也有弊端,下面我从不同的度来分析一下文档的利与弊,然后思考在敏捷开发时,文档又是如何进行的。从 公司的角度来看,...
  • 敏捷开发中文档的取舍 先说需求文档,分为两部分,一方面是框架性的需求文档,对功能、交互方式、出错或边界情况的表现进行总体描述,这种文档不需要过于细致,因为产品经理组织语言写文档,开发读文档,理解文档都...
  • 敏捷需求分析管理 需求管理(变更控制,版本控制,需求跟踪和状态跟踪)和需求开发(问题获取,分析,规格说明,验证) 系统变更频繁 系统上线时遇到很大阻力 系统上线后效果不佳 系统不可用甚至崩溃 •...
  • 其基本流程是需求-> 设计->开发->测试。基本假设只要把每一个环节都做正确,那么最终得到的结果也是正确的。瀑布开发有非常成功的案例,比如微软。但从总体来讲,瀑布项目失败率比较高。国外的软件先行者们...
  • 敏捷开发需求迭代

    2015-04-19 15:21:13
    迭代需求的整理是敏捷开发的第一步,也是敏捷开发很重要的一步,在这一步中我们需要把客户的业务需求按照优先级的顺序,整理成为一个个的迭代。然后把一个个的迭代拆成一个个可验收的故事卡。  在此需要说说什么是...
  • 这几年关于敏捷开发在互联网企业中越来越广泛被使用到,运用的比较多的当属scrum敏捷开发和xp敏捷开发,人人都在谈论敏捷开发。那什么才是敏捷开发呢? 目录 什么是敏捷开发? 传统的开发模式和敏捷开发模式的...
  • 在产品研发过程中经常需要编写很多文档,而敏捷宣言的第二条“可工作的软件胜于详尽的文档",那么需要编写文档吗?有没有简单的判断方法呢?
  • 敏捷项目没有需求分析吗?】 在很多人的印象中,敏捷软件开发是种类似黑客行为的过程,是程序员最爱的勾当。不写文档,不作需求分析,没有项目经理,做什么东西完全是程序员自己的行为。所以他们认为这样的过程...
  • 笔者正在学习《软件工程-实践者的研究方法...敏捷可以应用于任何一个软件过程(沟通、策划、建模、构建和部署),过程的设计应该使项目团队适应于任务,并且使任务流水线化,在了解敏捷开发方法的流动性的前提下进行...
  • 软件项目中有很多种文档,包括需求文档、设计文档、API文档、缺陷报告、进度报告、移交文档、验收文档等等。  在传统的软件项目开发中,每个团队成员都要花费很多时间和精力去维护文档及填写各种表格和报告。第...
  • 敏捷开发与没有规范,没有文档的代码编写者的区别 与某些观点相反,敏捷开发人员并非不按规则或限制编写代码的特立独行者。“牛仔编码”是缺乏规则和管理糟糕的迹象,并且很不专业。如果团队里面存在这样的编写代码...
  • 《程序员》2009年2月刊,第70页有一篇如题的文章,比较清晰的阐明了敏捷与传统方法在...摘抄要点如下: 传统需求分析敏捷需求分析需求分析时机更多地集中在项目早期近乎均匀地贯穿于项目的整个生命周期需求划分单位
  • 关于敏捷开发和CMMI的管理大家都各有心得,我就不在对各自具体管理做阐述了,紧紧针对文档裁剪说的看法,首先敏捷开发强调的核心的东西是交流,但对于当今的项目开发来说,个人交流恰恰是个难点,做开发的基本上都是...
  • 转载:...【敏捷开发】敏捷个人和敏捷开发敏捷开发实践总结(一):敏捷开发的核心思想。谈谈软件项目管理——敏捷开发从瀑布模型、极限编程到敏捷开发敏捷...
1 2 3 4 5 ... 20
收藏数 30,292
精华内容 12,116
关键字:

敏捷开发 需求文档