敏捷开发不需要需求文件吗_敏捷开发需要需求评审吗 - CSDN
  • 有次去西安百度创业园谈项目,甲方直接丢了一句,我们需要敏捷开发。我们:放心,肯定高质量、短周期的交期。敏捷需要面对面沟通,随时沟通,计划紧凑,总之就是快准狠。 1、敏捷 敏捷软件开发宣言:个体和互动...

    今天学习了一波腾讯云里面的一篇文章:https://cloud.tencent.com/developer/article/1004881,你大概走了假敏捷:认真说说敏捷的实现和问题。

    有次去西安百度创业园谈项目,甲方直接丢了一句,我们需要敏捷开发。我们:放心,肯定高质量、短周期的交期。敏捷需要面对面沟通,随时沟通,计划紧凑,总之就是快准狠。

    1、敏捷

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

    敏捷遵循的原则:

    • 目标:持续不断地早交付有价值的软件使客户满意;
    • 随时应对需求变化;
    • 短周期交付可工作的软件;
    • 业务与开发相互合作;
    • 面对面交谈实现高效信息传递;
    • 进度是首要度量标准;
    • 减少不必要的工作量;

    去文档,去流程,高效沟通和合作。去文档,敏捷管理者需要维护更为精细的需求池;去流程,口头沟通成为常态,对团队的耦合度要求更高。

    agile:迅速,敏捷。这是敏捷的理念也是精髓:迅速响应需求,快速反馈结果。

    sprint:字面意思是短跑冲刺,一个开发阶段被认为是一次冲刺,一个个 sprint 首位相连,构成一个项目。也可以理解为短期目标,短周期计划。

    Scrum:指的是英式橄榄球中一股脑争球这一战术或行为。毕竟进展是最首要的度量标准;

    scrum 即为这样一种方式,大家一拥而上,团队是球员,球是产品目标,人员环环相扣,围绕着产品目标进行工作。这里面多少有点“统筹法”的影子,人员深入协作以达到最优化效果。统筹协作。

    Product Backlog:

    backlog 即需求池。待办事项列表。其内容包含:1.待开发任务。2.任务优先级。

    敏捷需要维护一份详尽的需求列表。这份列表常常要求 scrum 持有人(一般是产品经理)对所有待开发事项有深入了解,并且能够把待开发事项分解成更为细致的任务。众所周知,快速的开发需要责任到人,然后最有效的督促就是每天都有详细任务表,省得有偷懒的伙计。所以整个下来,会有一个详细的需求列表,每天都是deadline。

    story board:在开发中,故事板展现所有需求的工作流。

    burn down chart:燃尽图,一个 sprint 内,人/时是一个比较固定的值。在这个时间框架充分安排开发任务,每天进行时间结算,绘制时间燃尽图。项目成员通过燃尽图获知时间进展,若项目燃尽所用时间与预期时间契合,则需求时间预估和安排合理,若不契合则需要在下一个 sprint 进行调整。

    这种燃尽图就类似下图,

     

    2、 敏捷工具

    随着敏捷在行业内的不断融入,各种工具产品层出不穷。国外jira、redmine,Axosoft ,国内的leangoo 、禅道,三大家则都有自研的工具,百度的icafe,阿里的aone,我鹅自研tapd。

    项目协同软件还是很必须的,现在科普一下自己相关的工具

    clearcase: IBM Rational, 商用,贵

    perforce: P4,免费版支持5个license, 其他商用版

    cvs: 开源,旧

    subversion: 中小型公司常用,集中管控

    git: 开源,分布式,最新,代码托管于github,使用于非集中办公的情况(故开源软件开发多选用它)

    http://www.kuqin.com/shuoit/20141213/343854.html 【git开发流程好文】

    -------------------------------------------

    协同开发工具

    Source Control: CVS/SVN 
    Bug Tracking: Bugzilla, Trac, Roundup 
    交流工具: maillist, IM, Forum, IRC, Wiki 
    协同开发平台: sourceforge, BaseCamp

    禅道, redmine: 

    ---------

    Basecamp是37signals公司旗下的一款非常流行的基于云服务的项目管理软件。以简单易用和颠覆性的创新而出名。 Basecamp提供了消息板,待办事宜,简单调度,协同写作,文件共享。而不是甘特图,炫丽的曲线图,和繁重的电子表格。目前,成千上万的人同意这是一种更好的方式。来自的Farhad Manjoo说:“Basecamp代表了Web软件的未来。”

    禅道是第一款国产的优秀开源项目管理软件。它集产品管理、项目管理、质量管理、文档管理、组织管理和事务管理于一体,是一款功能完备的项目管理软件,完美地覆盖了项目管理的核心流程。先进的管理思想,合理的软件架构,简洁实效的操作,优雅的代码实现,灵活的扩展机制,强大而易用的api调用机制,多语言支持,多风格支持,搜索功能,统计功能——这一切,您通过禅道,都可以拥有!禅道在手,项目无忧!
    禅道百科地址:http://baike.baidu.com/view/7881832.htm

    Redmine是用Ruby开发的基于web的项目管理软件,是用ROR框架开发的一套跨平台项目管理系统,据说是源于Basecamp的ror版而来,支持多种数据库,有不少自己独特的功能,例如提供wiki、新闻台等,还可以集成其他版本管理系统和BUG跟踪系统,例如SVN、CVS、TD等等。这种 Web 形式的项目管理系统通过“项目(Project)”的形式把成员、任务(问题)、文档、讨论以及各种形式的资源组织在一起,大家参与更新任务、文档等内容来推动项目的进度,同时系统利用时间线索和各种动态的报表形式来自动给成员汇报项目进度。

    Redmine百科地址:http://baike.baidu.com/view/2228665.htm

    上面来自:https://www.cnblogs.com/vigarbuaa/p/4317266.html

    看了半天,没瞅见maven,

    Maven是一个项目管理和综合工具。Maven提供了开发人员构建一个完整的生命周期框架。开发团队可以自动完成项目的基础工具建设,Maven使用标准的目录结构和默认构建生命周期。

    在多个开发团队环境时,Maven可以设置按标准在非常短的时间里完成配置工作。由于大部分项目的设置都很简单,并且可重复使用,Maven让开发人员的工作更轻松,同时创建报表,检查,构建和测试自动化设置。

    第一次使用的工具就是这个,当时就知道可以版本管理,汗颜。

    敏捷工具的伟大作用,就是显而易见的需求、实时更新的计划、优先级明确的安排、详细的待开发列表。协同,最方便的是协同。

    在人保驻场工作那会,最大的感触就是到处都是的计划、任务、预估时间、燃尽图,看的人亚历山大呀。像我看见领导都脑波是燃尽图,根本不需要这种吧!但是变成老油条的时候,还是很需要的。

    3、设计师进入敏捷

    我也算是做设计出身的,人保的移动报价器就是我的第一个整体做设计的作品。那是龙哥辛勤教导才出来的正常设计。设计进入敏捷,就是每天都有计划、每天都有进度、每天都有沟通、每天都是deadline。要知道,你需要不停的改,不停,不停,不停。

    4、敏捷需要需求文档

    从短期收益上看,文档对于敏捷开发是非必须品,并且很有可能会拖慢进度。在一个 sprint 中,口头沟通显然效率更高,每个人都有精确到工时的任务,没人有等待文档更新的时间。强调文档就等于放弃灵活性。

    从长期和宏观上看,文档对于敏捷团队和敏捷的实施利大于弊——节省在一些常规问题上的沟通成本,同时降低错误的发生概率。对于一个将要长期实施敏捷的 团队来讲,文档让后续的工作效率更高。

    几个重要的文档:产品文档、概要设计、接口文档

    产品文档:1.需求;2.加入日期;3.开发版本;4.呈现和详细方案

    在非敏捷开发流程中,文档在评审会后完善并更新,形成一个给研发参考的实现目标。在敏捷中,需求本身在 sprint 周期内不断完善,你可以在一个 sprint 之后将文档补全。

    概要设计:敏捷的常规迭代中,概要设计不是一个必须的文档。但全新项目、重构以及重大新功能则必须输出概要设计文档。研发 leader 责无旁贷,这个落你身上了。

    接口文档:必要且重要。包括接口说明、字段定义、字段类型、值定义、数据上报、错误码等。一般来说约定之后由接口开发者更新文档,如果你们没有云端存储的能力,至少咱们人手一份,定期更新。

    在和客户对接过程中发现,文档真是个好东西,就像区块链一样,有着你不可篡改的规矩。有时候客户不断的改动需求,还就说你没按计划,所以,白纸黑字最好的证据。如果说可以灵活变动需求,那看钱也是能实现的。

    文档最大的好处就是有据可寻。

    5、大项目的敏捷

    既然是大项目,需求确定至关重要。所以先要多次沟通需求(此处重点)。团队必须不厌其烦地理解需求或修正产品经理“天真的幻想”,产品经理使用不断完善的原型同团队进(tao)行( jia )沟( huan )通( jia )。在最后的产品评审之前,至少敲定产品框架和大部分细节。这次评审邀请项目成员和所有协同团队,除了敲定的产品功能,技术上需要得到一些初步结论(比如“能不能做”。事实上,产品经理应该在产品规划阶段就知会协同团队将要做什么)。接下来进行概要设计(新产品、重构、重大新功能必须进行概要设计)。技术评审邀请除设计以外的项目成员和协同团队参会。

    首次接项目,遇到过一个奇葩,需求确定多次,这个不懂技术的客户,最后不要了。丢了一句,不符合需求。当时想一嘴巴子扇死他。后来也就咬咬牙,收手了。所以,多次确认需求,多次确认需求,无论项目大小,这是填坑最好的方式。

    大项目敏捷中:

    1.将 deadline 之前的时间分解为多个 sprint 。(deadline 之前必须留出一定“出血时间”用以解决时间预估不足的任务、返工任务以及 bug )

    2.将所有需求分解成任务,开一次全局 scrum 会。预估时间之后,分散任务到各个 sprint 中。在时间较紧的情况下,sprint 的容量就要相应增加。

    3.进入敏捷流程,常规 scrum 会、站会,燃尽图,故事版。未完成任务在 scrum 会上重新预估时间,滚入新 sprint 内,以此类推(按时完成 sprint 内的任务是目标。实在不行我们还有“出血时间”呢)

    4.别忘了文档。虽然被推崇备至,但敏捷并不是完美的开发方法。敏捷的最大的优势是灵活,而造成敏捷问题的根源也正是灵活。

    文末再总结本文重点:

    1.敏捷是一种流程、方法、理念,甚至信仰。

    2 用了敏捷管理软件不一定就是敏捷。敏捷的初衷是团队成员能够更加紧密地配合完成工作,线上的的流转如果削弱了这种配合性,反倒背离了敏捷的本意。实际上只要有白板纸张和笔,你的团队就能开始敏捷。

    4.我们敏捷了,不是不要文档了。在外部交流多、世代跨度长的情况下,文档的必要性显而易见。长期的面对面沟通最终会导致低效,这也是敏捷缺陷的根源。

    5.设计师可以完全介入到敏捷流程中,只需要做一些细心的安排。

    6.大项目开发中可以走敏捷,具体问题具体分析,需要根据项目特点制定敏捷计划。

    敏捷开发总结出来果然就是快、准、狠。

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

    千次阅读 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

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

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

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

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

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

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

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

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

    先解释一些概念问题

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

    何谓“敏捷”开发模式

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

    语言本身的歧义性

    对于产品团队的压力

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

    做个比较

    传统需求文档

    用户故事

    用户故事包含哪些?

    为什么称呼为用户故事?

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

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

    用户故事的限制

    我的看法

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

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

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

    需求也需要性感

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

    展开全文
  • 为什么要进行敏捷开发? 现在是互联网的时代,互联网产品的更新速度可谓是日新月异。互联网的开发模式也是主要围绕“快速迭代”的主题来开发产品。 在飞速发展的互联网行业里,产品是以用户为导向在随时演进的。...

    为什么要进行敏捷开发?

    现在是互联网的时代,互联网产品的更新速度可谓是日新月异。互联网的开发模式也是主要围绕“快速迭代”的主题来开发产品。 在飞速发展的互联网行业里,产品是以用户为导向在随时演进的。因此,在推出一个产品之后要迅速收集用户需求进行产品的迭代——在演进的过程中注入用户需求的基因,完成快速的升级换代,裂变成长,才能让你的用户体验保持在最高水平。不要闭门造车以图一步到位,否则你的研发速度永远也赶不上需求的变化。

    项目开发人员名称及职责

    PM:产品经理,项目负责人。一个产品,首先由PM来分析细分市场、目标客户的诉求,规划产品的卖点、杀手级应用,这个过程通常PD已经介入了,这个层面上,商业问题、业务逻辑的流畅是思考的焦点。
    擅长:PPT和高层确认战略。project。

    PD:产品设计师,也可能叫产品规划师、需求分析师。PD侧重于将一个个杀手级应用做功能级的设计,需要细化考虑到每一个场景下该应用的限制反应等,比如边界值、全选操作功能。在这个模块上,PD类似是一个小产品经理。技术团队中的架构师(或者系统分析师,也可能叫项目经理、开发组长)会与PD紧密合作,这时候开始考虑技术可行性,性价比。
    擅长:word写文档 。Visio、Axure(基于网站构架图的带注释页面示意图、操作流程图、以及交互设计,并可自动生成用于演示的网页文件和规格文件,以提供演示与开发)原型设计工具

    QA: Qualtiy Assurance,品质保证。QA的主要职责就是质量保证工作。

    RD:Research and Development engineer,研发工程师,对某种不存在的事物进行系统的研究和开发并具有一定经验的专业工作者,或者对已经存在的事物进行改进以达到优化目的的专业工作者。

    UE:User Experience 用户体验,可能称作交互设计师、界面设计师。UE负责产品和用户交互方面的设计,这方面在技术部门的配合角色应该是前端工程师(web表现层)。通常UE拿到case的时候,要做什么功能已经决定了,PD与UE要充分沟通,UE必须要了解很多商业层面的内容,理解功能的商业价值。举个例子,比如在商业目的是“注册用户数”的前提下,设计注册流程是一页搞定还是分几个“下一步”,出错提示是js弹出还是页面即时判断……
    擅长:Dreamweaver做网页

    UI:User Interface 用户界面,可能也叫界面设计师、视觉设计师,很多小作坊简称美工,与UE的界限在很多时候是模糊的。到了UI层面,基本是界面的表现,是用户第一眼看到的效果,比如配色、页面结构、按钮形状、字体字号等等。
    擅长:PhotoShop做图

    敏捷开发的大致流程

    1. PM负责收集产品需求,完成产品方案设计。
    2. PD完成技术方案设计。
    3. PM&RD&QA共同完成产品/技术方案初步评估,确认方案可行性。
    4. PM/RD进行需求梳理会,梳理需求优先级排序,规划下一版本进入迭代的需求,并与UE沟通完成UE交付设计。
    5. 进行需求评审以及工作量评估。
    6. 规划迭代排期,进行迭代排期会议。

    开发者说:

    在进行开发的时候,敏捷开发的目的是以用户为中心,要求开发者要以最快的速度拿出一个成品来让用户可以使用,而后,根据用户使用的反馈,进行不断地迭代,进而得出最优的成果。

    迭代周期示意图
    从上图中可以看出,实际上项目的开发时间只占了排期的一小部分,在开发完成之后,其实就已经开始了项目1.1版本的设计。而在交付之后,就可以开始进行下一个版本的开发迭代了。

    展开全文
  • android 敏捷开发系列(二)——《敏捷开发架构图》 首先为大家解释里面的几个概念 Frame 整个项目的框架、组织者。里面并没有实际的代码,只是通过配置文件决定了项目需要哪几个模块 Model 模块,项目的组成部分,...
  • 这是敏捷开发一千零一问系列的第三十三篇。(在这里提问,之一,之二,之三,问题总目录)也是敏捷开发用户故事系列的第十篇(栏目目录)。问题需求清晰到什么程度可以进行开发?一定要弄清楚需求才能开发吗?怎样...
  • 一、敏捷开发 “敏捷”是一种思想,与”瀑布“式(即传统开发模式)相比,敏捷开发有如下宣言 个体和互动高于流程和工具:意思是敏捷开发中每个人都可以提出自己的见解,而不必按照”流程“逐个向上级反应。目的是...
  •  随着Agile敏捷开发的流行,越来越多的公司采用敏捷开发用于软件产品和应用的开发。笔者的产品开发团队在两年前开始采用敏捷开发方法,一直实践到现在,并取得不错的成果,包括:产品功能更加符合市场和业务...
  • 框架简介: 软件开发,程序员就是不断地跟变量、方法、类、接口这些东西打交道,随着开发经验地积累,聪明的程序就会发现然开发出来的每个软件都一样,但是...力软敏捷开发框架就是在此基础上做了充分的优化,使...
  • 说一下你对敏捷开发的理解,为什么要使用敏捷开发? 》瀑布模型的典型问题就是周期长,发布烦,变更难。 》敏捷开发就是快速迭代,持续集成,拥抱变化。     所谓“敏捷”,顾名思义,可以通俗...
  • 敏捷开发,相对传统软件开发模式,它主要是针对快速变化的需求,不断优化管理流程,最终推出优质软件。 原文作者Ulf Eriksson,是一家在线问题跟踪软件公司的创始人之一,他是敏捷开发的忠实粉丝,已经进行了多年...
  • 敏捷开发,相对传统软件开发模式,它主要是针对快速变化的需求,不断优化管理流程,最终推出优质软件。    1. 快速迭代    相对那种半年一次的大版本发布来说,小版本的需求、开发和测试更加简单快速。一些...
  • Showcase(就是SprintReview,演示会、评审会)就是开发团队把开发好的功能给客户的Product Owner等业务相关人员演示,以获取他们对所开发系统的反馈,是敏捷开发的一个关键实践,一般一个迭代一次,也可以根据项目...
  • 敏捷开发模式

    千次阅读 2018-07-01 01:34:06
    1、敏捷开发的概念从1990年代开始逐渐引起广泛关注,是一种以人为核心、迭代、循序渐进的开发方法。强调以人为本,专注于交付对客户有价值的软件。是一个用于开发和维持复杂产品的框架。2、敏捷开发的流程(图为禅道...
  • 敏捷开发,QA面临的10个挑战

    千次阅读 2016-09-01 19:23:59
    敏捷开发,QA面临的10个挑战 1.没有MRD,如何管理好需求? 2.没有需求评审,怎么保证需求质量? 3.研发模式变更,怎么把握进度? 4.没有详细设计如何保证设计没有问题? 5.没有测试设计如何保证测试质量? 6...
  • JAVA敏捷开发环境搭建

    千次阅读 2016-05-19 18:06:23
    和传统C++开发不一样的模式是多了第一个开发本地环境。这是为什么呢,因为目前大部分开发人员还是比较熟悉windows下开发。对于mac和linux下直接使用软件并且开发的中国开发者还是少之又少,这套架构就这个现状做出
  • 在十年前,没有人会想到互联网会发展成今天这个样子,同样,也没有人料到软件开发行业也会经历如此大的巨变,在开发这一行业,停下学习就等于死亡并不是危言耸听,关注行业未来发展趋势的人可能错过了第一个十年...
  • 为什么我推荐敏捷开发

    千次阅读 2016-03-18 11:04:29
    当项目成员越多,我越推荐敏捷开发,原因在于「当连自己要做什么事、为什么这样做、这样做为了解决什么问题」都搞清楚前,就跳下去玩敏捷开发,那和比通灵还惨,通灵起码还有个目标物在前面,搞清楚状况的人...
  • <br /> 今天浏览51testing,有个讨论是“敏捷开发中,测试人员的工作成绩如何体现”,想想我们公司的项目就是敏捷开发吗?需求不确定,经常改,做的差不多了,产品就交付,用户再提意见,再修改。看到有个人...
  • 嵌入式系统软件敏捷开发

    千次阅读 2012-09-17 20:32:59
    本文综述了嵌入式系统敏捷开发(Agile Development),敏捷宣言,敏捷的原则,很多的敏捷开发的实践习惯,敏捷开发与瀑布开发流程的区别,敏捷的任务stories划分,并行开发、敏捷的时间安排,敏捷的通信交流方式等等。...
1 2 3 4 5 ... 20
收藏数 23,852
精华内容 9,540
关键字:

敏捷开发不需要需求文件吗