敏捷开发流程怎么回答_爆发式开发流程对比敏捷式开发流程 - CSDN
  • 敏捷开发流程总结

    2010-07-20 15:36:00
     敏捷开发宣言—— 个体和交互 胜过 过程和工具 可以工作的软件 胜过 面面俱到的文档 客户合作 胜过 合同谈判 响应变化 胜过 遵循计划 虽然右项也有价值,但是我们认为左项...

    Agile——敏捷开发,作为CMM神话崩溃后被引入的一套新的软件开发模式,这几年来被广泛引起关注,并被寄予厚望。敏捷开发在其他业界的应用是否理想不得而知,但以下总结了我所在公司的敏捷开发试验,希望可以达到管中窥豹的目的。
    
    敏捷开发宣言——
    个体和交互 胜过 过程和工具
    可以工作的软件 胜过 面面俱到的文档
    客户合作 胜过 合同谈判
    响应变化 胜过 遵循计划
    虽然右项也有价值,但是我们认为左项具有更大的价值。

    以上的宣言比较抽象,基于该理念,以下是ThoughtsWork咨询公司的推崇的n个敏捷开发实践:
    Iteration
    迭代开发。可以工作的软件胜过面面俱到的文档。因此,敏捷开发提倡将一个完整的软件版本划分为多个迭代,每个迭代实现不同的特性。重大的、优先级高的特性优先实现,风险高的特性优先实现。在项目的早期就将软件的原型开发出来,并基于这个原型在后续的迭代不断晚上。迭代开发的好处是:尽早编码,尽早暴露项目的技术风险。尽早使客户见到可运行的软件,并提出优化意见。可以分阶段提早向不同的客户交付可用的版本。
    IterationPlanningMeeting
    迭代计划会议。每个迭代启动时,召集整个开发团队,召开迭代计划会议,所有的团队成员畅所欲言,明确迭代的开发任务,解答疑惑。
    Story Card/Story Wall/Feature List
    在每个迭代中,架构师负责将所有的特性分解成多个Story Card。每个Story可以视为一个独立的特性。每个Story应该可以在最多1个星期内完成开发,交付提前测试(Pre-Test)。当一个迭代中的所有Story开发完毕以后,测试组再进行完整的测试。在整个测试过程中(pre-test,test),基于Daily build,测试组永远都是每天从配置库上取下最新编译的版本进行测试,开发人员也随时修改测试人员提交的问题单,并合入配置库。
    敏捷开发的一个特点是开放式办公,充分沟通,包括测试人员也和开发人员一起办公。基于Story Card的开发方式,团队会在开放式办公区域放置一块白板,上面粘贴着所有的Story Card,按当前的开发状态贴在4个区域中,分别是:未开发,开发中,预测试中,测试中。Story Card的开发人员和测试人员根据开发进度在Story Wall上移动Story Card,更新Story Card的状态。这种方式可以对项目开发进度有一个非常直观的了解。
    在开发人员开始开发一个Story时,ta需要找来对应的测试人员讲解Story功能,以便测试人员有一致的理解,同时开始自动化系统测试脚本的开发。
    Standup Meeting
    站立会议。每天早上,所有的团队成员围在Story Wall周围,开一个高效率的会议,通常不超过15分钟,汇报开发进展,提出问题,但不浪费所有人的时间立刻解决问题,而是会后个别沟通解决。
    Pair Programming
    结对编程是指两个开发人员结对编码。结对编程的好处是:经过两个人讨论后编写的代码比一个人独立完成会更加的完善,一些大的方向不至于出现偏差,一些细节也可以被充分考虑到。一个有经验的开发人员和一个新手结对编程,可以促进新手的成长,保证软件开发的质量。
    CI/Daily Build
    持续集成和每日构建能力是否足够强大是迭代开发是否成功的一个重要基础。基于每日构建。开发人员每天将编写/修改的代码及时的更新到配置库中,自动化编译程序每天至少一次自动从配置库上取下代码,执行自动化代码静态检查(如PCLint),单元测试,编译版本,安装,系统测试,动态检查(如Purify)。以上这些自动化任务执行完毕后,会输出报告,自动发送邮件给团队成员。如果其中存在着任何的问题,相关责任人应该及时的修改。
    可以看到,整个开发组频繁的更新代码,出现一些问题不可避免。通过测试部又在不停地基于最新的代码进行测试。新增的问题是否能够被及时发现并消灭掉,取决于自动化单元测试和系统测试能力是否足够强大,特别是自动化系统测试能力。如果自动化测试只能验证最简单的操作,则新合入代码的隐患将很难被发现,并遗留到项目后期,形成大的风险。而实际上,提升自动化测试的覆盖率是最困难的。
    Retrospect
    总结和反思。每个迭代结束以后,项目组成员召开总结会议,总结好的实践和教训,并落实到后续的开发中。
    ShowCase
    演示。每个Story开发完成以后,开发人员叫上测试人员,演示软件功能,以便测试人员充分理解软件功能。
    Refactoring
    重构。因为迭代开发模式在项目早期就开发出可运行的软件原型,一开始开发出来的代码和架构不可能是最优的、面面俱到的,因此在后续的Story开发中,需要对代码和架构进行持续的重构。迭代开发对架构师要求很高。因为架构师要将一个完整的版本拆分成多个迭代,每个跌倒由拆分成很多Story,从架构的角度看,这些Story必须在是有很强的继承性,是可以不断叠加的,不至于后续开发的Story完全推翻了早期开发的代码和架构,同时也不可避免的需要对代码进行不断完善,不断重构。
    TDD
    测试驱动开发。正如上面讲的,迭代开发的特点是频繁合入代码,频繁发布版本。测试驱动开发是保证合入代码正常运行且不会在后期被破坏的重要手段。这里的测试主要指单元测试。
    
    敏捷方法反思:
    自己参与的敏捷开发项目总的来说不是很成功,这可能也是业界遇到的通病:
    1、对于全新的软件,在项目早期测试人员就参与并实现自动化测试脚本,但实际上软件的界面等非常不稳定,导致测试人员返工的工作量很大。
    2、对于全新的软件,资料人员过早参与,后期返工工作量大,原因同第一点。
    3、自动化系统测试工作量大,测试人员投入大量的精力在使测试自动化起来,而没有足够的精力放在真正的测试软件的功能是否正常。即便是这样,自动化系统测试脚本也多流于形式,测不出深层次的问题。
    4、代码动态检查工具执行不理想,流于形式。没有人对Purify有深刻的理解和应用经验,报告中查出来很多告警,但不知如何消除。
    5、由于快速搭建原型,没有在架构上进行严谨的设计,导致后期一直堆砌代码。
    6、异地开发模式下无法实现快速构建、快速交付,团队普遍感觉很疲惫。
    7、敏捷开发不提倡加班,但实际上不管是CMM还是Agile哪一种开发模式跟是否加班都没有必然联系。

    展开全文
  • 什么是敏捷开发流程

    2019-05-11 19:34:29
    【什么是敏捷开发流程 】 这个词猛一听起来感觉很高大上,其实现在已经是主流的团队开发流程 了。 一. 先说一下官方的定义: 敏捷不是指某一种具体的方法论、过程或框架,而是一组价值观和原则。符合敏捷价值观....

    这里是修真院后端小课堂,每篇分享文从

    【背景介绍】【知识剖析】【常见问题】【解决方案】【编码实战】【扩展思考】【更多讨论】【参考文献】

    八个方面深度解析后端知识/技能,本篇分享的是:

    【什么是敏捷开发流程 】

    这个词猛一听起来感觉很高大上,其实现在已经是主流的团队开发流程 了。
    一. 先说一下官方的定义:

    敏捷不是指某一种具体的方法论、过程或框架,而是一组价值观和原则。符合敏捷价值观和原则的开发方法包括:极限编程(XP),Scrum,精益软件开发(Lean Software Development),动态系统开发方法(DSDM),特征驱动开发(Feature Driver Development),水晶开发(Crystal Clear)等等。所有这些方法都具有以下共同特征:

    1. 迭代式开发。即整个开发过程被分为几个迭代周期,每个迭代周期是一个定长或不定长的时间块每个迭代周期持续的时间一般较短,通常为一到六周。

    2. 增量交付。产品是在每个迭代周期结束时被逐步交付使用,而不是在整个开发过程结束的时候一次性交付使用。每次交付的都是可以被部署到用户应用环境中被用户使用的、能给用户带来即时效益和价值的产品。

    3. 开发团队和用户反馈推动产品开发。敏捷开发方法主张用户能够全程参与到整个开发过程中。这使需求变化和用户反馈能被动态管理并及时集成到产品中。同时,团队对于用户的需求也能及时提供反馈意见。

    4. 持续集成。新的功能或需求变化总是尽可能频繁地被整合到产品中。一些项目是在每个迭代周期结束的时候集成,有些项目则每天都在这么做。

    5. 开发团队自我管理。拥有一个积极的、自我管理的、具备自由交流风格的开发团队,是每个敏捷项目必不可少的条件。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制,而非把过程和机制强加给人。

    二. 然后是我理解的敏捷

    主要说一下我们公司自己的开发流程,因为接触时间尚浅,所以有点地方可能说的不是很到位,希望大家多多包含。

    需求评审(参与人员是 客户+产品+UI+开发+测试,也就是所有人员)
    主要是产品人员讲解需求,用户需要给出反馈或者提出意见,其他人员可以相应的提出自己的见解。

    Story划分(产品+UI+开发)
    产品根据UI做出来的原型图给开发人员讲解系统构成和运行,将整个网站按照功能划分成一个个细粒度的story来说明,开发人员(前端和后端)也需要明白自己应该关注那些关键点。

    人员划分(leader+开发)
    主要是项目小组的leader 根据story划分,给前端和后端开发人员划分story,开发人员根据自己的情况去估算所需时间。

    方案设计(数据库设计文档、接口设计文档、方案设计文档)
    先根据系统的实际情况去设计DB,包括数据库和表的名字,以及具体的字段。
    然后设计接口文档,按照页面和功能进行设计,包括具体的请求地址和入参出参。
    最后是根据接口文档中出现的疑难点去做方案设计文档,对遇到的问题进行分析并拿出至少两种具体的解决方案。

    方案评审(所有人员)
    对前端和后端给出的方案评审其它人员给出各自的意见,有问题的话下次再次开始。

    禅道任务拆分(开发人员)
    方案评审通过以后开发人员就需要按照预估的总开发时间去拆分story,可以分成多个小的任务,但是一个任务的时间最好不要超过4个小时。

    开发(项目日报+工作日报+进度邮件)
    每天实际开发过程中遇到问题可以写成项目日报;每天的任务完成情况写成工作日报;相比较整个系统的进度完成情况需要写进度邮件。

    端对端(接口)测试(开发人员)
    前端写好了页面,后端完实现了接口,就可以进行端到端的测试,可以远程测试,也可以本地测试。

    压力测试+集成测试
    系统完成以后需要用Jmeter 进行模拟用户访问,通过设置线程来提高并发量的方式达到一定的效果,测试生成的数据需要总结成测试报告。

    Demo
    对于复盘来说,这就是最后一个程序了,在前后端大师兄的评审下,主要是前端人员进行系统演示,各个功能是否实现、页面是否达到用户要求、有没有什么需要完善的地方。点评过之后如果有问题那就修改之后再次评审;如果没有问题那就算完成复盘项目了。

    这么一个流程走下来,特别期间各个环节的良好运行以及团队合作的情况都是确保项目能够正常实现并交付的重要因素,敏捷开发强调的是人的充分能动性,通过这种相互合作的开发模式,相信在前后端分类开发的盛行时代,公司或者团队可以在约定的时间内较好地完成用户委托的项目。

     

     



     

    【欢迎加IT交流群565763832与大家一起讨论交流】

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

    简介

    这几年关于敏捷开发在互联网企业中越来越广泛被使用到,运用的比较多的当属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扫盲篇
    百度百科
    敏捷开发 模型讲解

    展开全文
  • 敏捷开发流程

    2020-07-21 09:56:30
    敏捷开发流程,详细的介绍,可以很方便的让开发人员了解
  • 敏捷开发流程需求理解方案评审日常任务性能测试CodeReviewDemo 需求理解 理解需求背景 确认需求明确,无逻辑遗漏 确认所有需求方案都有实现方案 合理预估时间 需求不明确或者不清晰的点,可以当场提出来,或者稍后整理...

    需求理解

    • 理解需求背景
    • 确认需求明确,无逻辑遗漏
    • 确认所有需求方案都有实现方案
    • 合理预估时间
    • 需求不明确或者不清晰的点,可以当场提出来,或者稍后整理
    • 快速整理出未实现过的功能,逻辑,技术点,可以和leader一起讨论交流方案
    • 确认验收标准是否完善
    • 确认Story优先级和粒度无疑问,有问题反馈给leader

    方案评审

    • 前后端快速整理出接口,哪些可复用,哪些需要合并
    • 接口遵循RESTful风格,考虑扩展性
    • 参数和返回值都清晰明确,遵循接口定义规范
    • 关键业务逻辑画业务流程图
    • DB设计完备,SQL语句完善,索引完整,常量标注清晰,表名和字段名符合规范
    • DB设计中预估数据量和增长速度
    • 制作出架构图
    • 后端预估并发数
    • 前端给出公共组件
    • 前端给出浏览器兼容版本
    • 确定是前后端分离还是不分离
    • 明确开发,测试,线上三个环境的IP,内存,域名等资源分配
    • 给出多种解决方案和推荐方案
    • 方案应该在两三天之内完成
    • 评审通过后,Task在两小时之内拆解完成,Task的粒度不超过2小时,Task无遗漏

    日常任务

    • 3次Todo List
    • 下班前提交代码,部署开发环境,测试当天完成的内容
    • 寻找影响Story完成的阻碍点
    • 晨会演示昨天完成的内容
    • 测试正常的数据和边界数据
    • 晨会审核燃尽图,更新Demo时间,找出延期原因,给出解决办法
    • 每天随时测试完成结果,遵循测试方法

    性能测试

    • 明确结论,通过或不通过

    CodeReview

    • 是否符合编码规范
    • 是否和设计方案一致
    • 是否有逻辑漏洞和潜在风险

    Demo

    • 确保所有关键业务逻辑全部走通
    • 确保异常数据处理正常
    • 确保各种兼容性
    • 确保最终研发出来的产品符合用户使用逻辑
    展开全文
  • 最近在整理敏捷开发项目的流程和管理制度,其整理的项目管理规程如下,这份规程也不完全算是敏捷专属的项目管理规程,主要是在结合我们公司实际的情况下编写出来的,大家在实际嵌入到公司的过程中可以参考下,不能...


    前段时间给大家整理了敏捷开发的流程,最近在整理敏捷开发项目的流程和管理制度,其整理的项目管理规程如下,这份规程也不完全算是敏捷专属的项目管理规程,主要是在结合我们公司实际的情况下编写出来的,大家在实际嵌入到公司的过程中可以参考下,不能照搬。

    1.  目的

    规范互联网软件产品开发项目管理过程,指导开展项目研发、管理等活动。

    2.  适用范围

    本章程的作用范围为互联网软件产品开发立项至结项管理过程。

    1.对项目经理开展产品规划及设计活动以及项目管理手段和应遵循的开发流程提供了指导;

    2.对项目团队的日常管理活动及内容进行了指导;

    3.  角色及职责定义

    项目经理:

    进行产品开发过程中的业务目标、进度、成本、质量控制。

    挑选项目团队并进行团队建设,激发、鼓舞和改进团队的生产效率。

    识别项目干系人,定期向干系人汇报,并作为团队和外部的接口,屏蔽外界对团队的干扰。

    确保项目中流程被遵循,组织、监督、培训项目各实践活动。

       

    产品策划

    确定产品的功能,拆分用户故事。

    需求功能确定优先级。

    接受或拒绝开发团队的工作成果。

    参与产品开发过程中的有关会议。

    UI

    根据用户故事,负责产品的功能交互及界面设计

    组织开展人机交互及用户体验,不断跟踪改进,提高产品表现力。

    参与产品开发过程中的有关会议。

    开发

    根据用户故事,负责产品的技术架构设计及功能开发

    评估、设计及维护产品相应模块,确保模块的稳定性、易用性、高效性。

    参加产品开发过程中的有关会议。

    测试

    根据用户故事,设计产品测试标准,确保产品品质满足市场需求。

    合理分配测试资源,组织产品测试并优化测试流程及测试标准,提高测试效率。

    编写产品测试用例,提交测试问题,编写测试总结报告,以测试角度来确定产品版本是否发布。

     

    4. 项目管理过程

    按照互联网软件产品项目开发过程,可将整个项目管理过程分为立项过程、规划过程、执行与监控过程、结项过程。下面分别阐述在每个阶段过程中该如何进行项目管理。

     

    4.1 立项过程

        互联网软件产品开发项目的立项过程,通常是指从准备项目启动会到召开会议这个阶段,在立项过程中,需要完成项目目标,需求范围的初步确认,项目团队成员,其他资源的安排。

         确定项目的初步目标并达成共识

         对于项目目标,需要和干系人在以下几点上达成共识:

         项目的背景、目标用户、核心人员及产品定位是什么

         项目的资源投入预算是多少

         项目的资源投入是多少

         各人员在项目中扮演的角色和对项目的作用是什么

         准备启动会议文档

         文档内容包括:

           用户画像

           产品定位

           市场策略

           业务目标

           技术可行性

           研发成本预算

           路标规划

        召开项目启动会 

         参加人员包括:

           管理层代表

           项目经理及项目团队

           其他干系人代表

         主要议题包括:

           申明项目目标范围及对组织目标的贡献。

           管理层正式任命PM,设定期望,统一思想

           文档内容的宣讲。  

         与PM小组确定项目管理要求

           项目启动会完成后,需要与PM小组成员确定项目立项机制以及公司项目管理要求。

     

    4.2  规划阶段

    在规划阶段,团队需要共同完成产品的版本规划,迭代计划

    版本规划

    从产品的关键特性列表中按照优先级规划产品每个版本需要完成哪些特性,在规划完成后需要在项目干系人内达成共识。具体可参考《版本规划样例》

    迭代如何划分

    迭代划分是指将特性列表拆分形成用户故事列表,并将其对应的主要任务划分到各个迭代中去,形成粗粒度的项目迭代计划。这个过程主要考虑以下几个因素:

        有些任务间是有依赖关系,某个任务的开始或结束是以另一个任务的开始或结束为前提,在划分时必须考虑这种前后依赖关系。

        在安排每个迭代的任务时,需要对各种因素进行综合考虑,如平衡每个迭代中任务的技术难度和价值差异。

        除了进行初步的迭代任务划分,还需要确定项目过程中迭代任务调整的规则,如迭代任务未完成时是将剩余任务延至下一迭代还是延长迭代周期。

    确定人员分工

    项目经理需要根据每个人员的能力和特点,初步拟定大致分工。在进行任务分工时需考虑以下因素:

        任务难度与人员能力相匹配,对于明显超出能力范围或过于简单的任务容易造成负面影响。

        耦合度高的尽量分配给同一个人,避免不必要的沟通消耗。

        鼓励团队内部“任务认领”,提高人员的工作积极性和主动性。

    确定迭代运行模式

            如一周迭代、两周迭代,每个迭代包含的工作内容等。

           具体的迭代计划可参考《迭代计划样例》

    制定其他辅助计划

        制定沟通计划、风险计划和质量计划是必要的,沟通计划主要包含以下几个方面:沟通对象、沟通方式、沟通频率即可,如:


        风险计划包括风险项、负责人、重要性、应对措施,如下:


     

    质量计划包括:bug分布满足何种条件可以发布,有几个致命bug必须停止开发新特性等。。

       搭建基础技术架构

        如果是一个全新的项目,需要重新开发系统框架,则这个工作应该在迭代0完成,否则会影响后期的工作开展。系统框架的每次改动必然会导致大量的重复工作量,从而给稳定的团队节奏带来很大的毛刺。

    3.3    项目执行和监控过程

    迭代N的执行

    A、迭代N的需求细化

    考虑每个迭代需要完成的用户故事;

        用户故事需包含几个部分,工作量评估、功能性需求、非功能性需求。具体的可参考《用户故事模板及样例及拆分说明》

        用户故事编写完成后需要在团队内部进行需求评审,一方面是为了向团队成员解读该需求,另一方面团队成员也可在评审时给出指导性意见。

    B、测试用例评审

        测试人员根据用户故事要求编写对应的测试用例,并组织项目团队进行测试用例评审。根据评审意见修改测试用例

    C、开发

        将用户故事的需求开发的过程。

    D、开发自测

        在开发过程中,每完成一个功能点,都需要及时的进行开发自测并通知产品策划人员进行验收体验。

    E、验收

        开发完成后,产品策划需要对开发完成的成果进行验收,验证其是否符合用户故事的要求,验证通过后方可流到测试环节,否则需与开发详细讨论其不符合性,其验收的checklist可以参考《产品验收checklist及模板》

    F、测试和回归

            提交测试时,必须要有正确的版本。测试人员根据测试用例进行测试,在IT平台中提交测试bug,并根据测试的角度给出产品是否发布的意见,输出《测试报告》

    G、bug修改

        在IT平台中获取分配给自己的bug进行修改。

    H、showCase

        阶段性必须有可体验版本进行showCase.需要

    确定showCase时间:某个迭代开发、自测完成,准备提交测试前

    会议前1-2天发出体验版给到参与人员

    会议期间,由项目经理组织大家体验、反馈问题、记录问题。

    项目经理根据问题情况,与开发或产品确定问题的解决时间并发出会议纪要。

     I、灰度发布

           迭代一定版本后,由项目经理与团队共同决定是否需要进行灰度发布。

     

    监控方式 

    每日站立会

        主持人轮流担任,负责控制节奏,记录问题,以备会后跟踪。

        每人讲自己昨天做了什么,有什么问题,今天的计划是什么;

        其他人了解别人的工作情况,并发现指出可能存在的问题。

        对于发现的问题,鼓励认领,其余由项目经理指定责任人。

        时间通常控制在15分钟内。

        会议期间,更新任务墙,任务墙样式如下:

     

    周报

        反馈项目计划的执行情况,强调本周工作要达成的目标

        暴露出项目的问题,特别是需要领导或其他团队需要协助的问题。

        周报可在IT平台中输出。

    月报

        反馈项目当月的执行情况,包括进度、人力及质量。

        反映项目存在的问题和风险。

    迭代回顾

        每人讲述本次迭代做的好的地方和不好的地方

        回顾上个迭代不好的地方,看看改进情况。

        让每个人发言。

        每次迭代回顾会议完成后,可更新燃尽图

    3.4    结项阶段

    项目经理指导产品策划收集总结项目的产品运营数据,同时指导团队成员从自身角色进行总结,包括测试、开发、UI等。

    项目经理与项目团队成员给出项目总结报告,内容可参考《项目经验教训总结-项目团队》,《项目经验教训总结-项目经理》

    召开结项会议,各成员进行结项汇报。

    PM小组将过程文档和经验教训总结进行归档。

    展开全文
  • 今天给大家分享一下,java项目中需要使用的敏捷开发流程   1.背景介绍   在很久以前,软件项目的开发都是以年来计算的,这代表什么意思呢 ?需求设计了半年多,方案设计做了半年多,开发了三年多, 测试了半年...
  • Scrum敏捷开发流程

    2017-05-01 14:17:56
    Scrum敏捷开发流程的要点
  • 敏捷开发(scrum)是一种软件开发的流程,强调快速反应、快速迭代、价值驱动。 Scrum的英文意思是橄榄球运动的一个专业术语,表示“争球”的动作;运用该流程,你就能看到你团队高效的工作。 敏捷开发的特点就是...
  • 敏捷开发 迭代流程

    2011-06-12 07:46:00
    现在很多公司都说自己在用敏捷开发,很多程序员也说自己懂敏捷开发!简单的认为敏捷就是站立会议,就是迭代的开发,到最后敏捷变成了混乱,然后开始说敏捷的不好等等。其实他们都只是表面上的敏捷,而没有真正的理解...
  • 为什么要进行敏捷开发? 现在是互联网的时代,互联网产品的更新速度可谓是日新月异。互联网的开发模式也是主要围绕“快速迭代”的主题来开发产品。 在飞速发展的互联网行业里,产品是以用户为导向在随时演进的。...
  • 什么是敏捷开发

    2019-05-31 10:49:56
    敏捷开发(Agile)是一种以人为核心、迭代、循序渐进的开发方法。 在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。 简单地来说,敏捷开发并不追求前期完美...
  • 敏捷开发和迭代开发

    2019-06-27 17:05:44
    敏捷开发与迭代式开发是整体与局部的关系 敏捷开发敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发,在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试...
  •  不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。  其中,敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求,带来了新的挑战。 第一部分:敏捷软件开发简介 敏捷...
  • 敏捷开发流程

    2015-08-31 20:27:22
    随着带的团队做的事情越来越多, 发布的产品也越来越多, 关于软件开发流程的思考也越来越多.前段时间的高效虚拟自适应团队是在历经困难后磨练出来的方法的总结, 在此基础上,又经过几个版本发布的洗礼,对之前的认识...
  • SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践...
  • 敏捷开发的价值观 敏捷开发应遵循的12条原则 敏捷开发的原则 敏捷团队运作机制 关键的团队角色 产品负责人(Product Owner) Scrum Master(流程主管) 关键的团队活动 敏捷团队的五个约定 约定1. 业务分析师...
  • 一旦涉及版本控制系统,Git实际上代表敏捷开发的水平。Git作为一款强大的开源系统,有较强的灵活性,可以按需匹配任何开发团队的工作流程。而这种分布式相比较集中式来说,自然赋予系统更好的性能特征,且允许开发...
1 2 3 4 5 ... 20
收藏数 95,374
精华内容 38,149
关键字:

敏捷开发流程怎么回答