2014-03-19 21:34:00 weixin_30940783 阅读数 0
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10404 人正在学习 去看看 CSDN讲师

       今天,老师给我们介绍了一下敏捷开发,并距离介绍。通过学习,我了解到,所谓敏捷开发,并不是完全脱离文档的。

        所谓敏捷开发,实际上是一种开发方法,它是一种以人为核心,循环,迭代的开发方法。它把一个大的项目分割成一个个小的独立的项目,并且使每项都能运行。

        敏捷开发的核心原则有:

1.主张简单

2.拥抱变化

3.第二个目标的可持续性

4.递增的变化

5.令Stakeholder投资最大化

6.有目的的建模

7.多种模型

8.高质量的工作

9.快速反馈

10.软件是主要目标

11轻装前进

        这些自己也不是太清楚,是从网上看来的。

        对于敏捷开发,很重要的一点是敏捷小组要每天开站立会议,通过每天的站立会议,每个人只需要说3句话,即昨天干了什么,今天干了什么,明天要干什么。一切跟这3句话无关的话题,都不需要讨论,通过站立会议,每个人都能明确自己做了什么,以及自己的目的,能够大大提高敏捷小组的效率。

        敏捷开发的主流方法主要有7种,分别是:

1.XP(极限编程)

2.SCRUM

3.Crystal Methods

4.FDD

5.DSDM

6.轻量型RUP

7.ASD

      以上就是自己通过课上的学习以及课下与度娘的交流得出的经验。

转载于:https://www.cnblogs.com/maguobin/p/3612411.html

2019-08-12 20:39:23 yjn1995 阅读数 759
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10404 人正在学习 去看看 CSDN讲师

前言

  

迭代开发

  敏捷开发的核心是迭代开发(iterative development)。敏捷一定是采用迭代开发的方式。那么什么是"迭代开发"呢?迭代的英文是 iterative,直译为"重复",迭代开发其实就是"重复开发"。
  对于大型软件项目,传统的开发方式是采用一个大周期(比如半年)进行开发,整个过程就是一次"大开发";迭代开发的方式则不一样,它将开发过程拆分成多个小周期,即一次"大开发"变成多次"小开发",每次小开发都是同样的流程,所以看上去就好像重复在做同样的步骤。
  举例来说,SpaceX 公司想造一个大推力火箭,将人类送到火星。但是,它不是一开始就造大火箭,而是先造一个最简陋的小火箭 Falcon 1。结果,第一次发射就爆炸了,直到第四次发射,才成功进入轨道。然后,开发了中型火箭 Falcon 9,九年中发射了70次。最后,才开发 Falcon 重型火箭。如果 SpaceX 不采用迭代开发,它可能直到现在还无法上天。
  迭代开发将一个大任务,分解成多次连续的开发,本质就是逐步改进。开发者先快速发布一个有效但不完美的最简版本,然后不断迭代。每一次迭代都包含规划、设计、编码、测试、评估五个步骤,不断改进产品,添加新功能。通过频繁的发布,以及跟踪对前一次迭代的反馈,最终接近较完善的产品形态。

增量开发

  迭代开发只是要求将开发分成多个迭代,并没有回答一个重要的问题:怎么划分迭代,哪个任务在这个迭代,哪个任务在下个迭代?这时,一般采用"增量开发"(incremental development)划分迭代。
  所谓的"增量开发",指的是软件的每个版本,都会新增一个用户可以感知的完整功能。也就是说,按照新增功能来划分迭代。
  举例来说,房地产公司开发一个10栋楼的小区。如果采用增量开发的模式,该公司第一个迭代就是交付一号楼,第二个迭代交付二号楼…每个迭代都是完成一栋完整的楼。而不是第一个迭代挖好10栋楼的地基,第二个迭代建好每栋楼的骨架,第三个迭代架设屋顶…
增量开发加上迭代开发,才算是真正的敏捷开发。

敏捷开发的好处

早期交付

  敏捷开发的第一个好处,就是早期交付,从而大大降低成本。
  还是房地产公司为例,如果按照传统的"瀑布开发模式",先挖10栋楼的地基、再盖骨架、然后架设屋顶,每个阶段都等到前一个阶段完成后开始,可能需要两年才能一次性交付10栋楼。也就是说,如果不考虑预售,该项目必须等到两年后才能回款。
  敏捷开发是六个月后交付一号楼,后面每两个月交付一栋楼。因此,半年就能回款10%,后面每个月都会有现金流,资金压力就大大减轻了。

降低风险

  敏捷开发的第二个好处是,及时了解市场需求,降低产品不适用的风险。
  请想一想,哪一种情况损失比较小:10栋楼都造好以后,才发现卖不出去,还是造好第一栋楼,就发现卖不出去,从而改进或停建后面9栋楼?
  对于软件项目来说,先有一个原型产品,了解市场的接受程度,往往是项目成功的关键。有一本书叫做《梦断代码》,副标题就是"20+个程序员,三年时间,4732个bug,100+万美元,最后失败的故事",这就是没有采用敏捷开发的结果。相反的,Instagram 最初是一个地理位置打卡 App,后来发现用户不怎么在乎地理位置,更喜欢上传照片,就改做照片上传软件,结果成了独角兽。
  由于敏捷开发可以不断试错,找出对业务最重要的功能,然后通过迭代,调整软件方向。相比传统方式,大大增加了产品成功的可能性。如果市场需求不确定,或者你对该领域不熟悉,那么敏捷开发几乎是唯一可行的应对方式。

如何进行每一次迭代

  虽然敏捷开发将软件开发分成多个迭代,但是也要求,每次迭代都是一个完整的软件开发周期,必须按照软件工程的方法论,进行正规的流程管理。

 &emssp;具体来说,每次迭代都必须依次完成以下五个步骤。

  • 需求分析(requirements analysis)
  • 设计(design)
  • 编码(coding)
  • 测试(testing)
  • 部署和评估(deployment / evaluation)
    每个迭代大约持续2~6周。

敏捷开发的价值观

《敏捷软件开发宣言》里面提到四个价值观。

  • 程序员的主观能动性,以及程序员之间的互动,优于既定流程和工具。
  • 软件能够运行,优于详尽的文档。
  • 跟客户的密切协作,优于合同和谈判。
  • 能够响应变化,优于遵循计划。

十二条原则

该宣言还提出十二条敏捷开发的原则。

  • 通过早期和持续交付有价值的软件,实现客户满意度。
  • 欢迎不断变化的需求,即使是在项目开发的后期。要善于利用需求变更,帮助客户获得竞争优势。
  • 不断交付可用的软件,周期通常是几周,越短越好。
  • 项目过程中,业务人员与开发人员必须在一起工作。
  • 项目必须围绕那些有内在动力的个人而建立,他们应该受到信任。
  • 面对面交谈是最好的沟通方式。
  • 可用性是衡量进度的主要指标。
  • 提倡可持续的开发,保持稳定的进展速度。
  • 不断关注技术是否优秀,设计是否良好。
  • 简单性至关重要,尽最大可能减少不必要的工作。
  • 最好的架构、要求和设计,来自团队内部自发的认识。
  • 团队要定期反思如何更有效,并相应地进行调整。
2014-03-14 09:28:40 gaomingqing 阅读数 31
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10404 人正在学习 去看看 CSDN讲师
[b]计划游戏:如今的SCRUM敏捷方法论的原型。核心概念是拆分软件开发任务,排优先级,迭代式增量开发。[/b]
 小规模发布:主要思想是软件发布/部署应该提高频度,增量发布/部署。

 简单设计:是指让系统保持越简单越好——无论将来的变化会让我们如何担忧。

 测试:是指程序员,甚至客户,应该编写自动化测试程序,来验证产品代码是否是按设计的方式运行。如今我们把它称作测试驱动开发(TDD)和确认测试驱动开发(ATDD)。

  重构:是指软件的内部结构可以、并且应该做持续的改进

  结队编程:是说团队成员如果各自独立工作就不能称之为团队。团队成员必须有规律的合作——在键盘上。这样,他们能充分分享团队其他成员应该知道的知识。

  集体所有制:是指代码归团队共有,不属于个人

 每周工作40小时:是说经常加班的团队是失败的团队。

  现场客户:是指来自业务方、负责需求的人,必须有准备的全程和开发团队保持畅通交流。

 编码标准:是指开发团队要采用一种固定的代码风格,用来提高代码整洁和方便交流。
2014-06-09 09:28:34 damys 阅读数 630
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10404 人正在学习 去看看 CSDN讲师

 

避免提交一个半成品。 

这一点大家似乎都知道,但这条原则必须列入任何一个开发指导里。 能够听取这些忠告进行开发测试然后提交代码的程序员一定不会发生代码提交到版本库使整个项目无法编译码通过情况。如果系统编译失败,那一定是有人抄近道到了。

 

不要在还没有任何使用案例的情况下设计通用模块。 

只有在你知道有具体用例的情况下,你才可以实现一个具体的类,而且你在该类中只应该实现当前该用例需要的方法。你也许会想到将来这个类会有其它的用途,你可以用注释的方式记录一下,但不要去实现它,只有在有了具体用例后你才可以实现它。

 

用例一完全能够运行后再开发用例二。

厨房里有一种说法正好可以印证这个问题:“做好一盘菜后你再做下一盘”. 对于软件开发来说一个最大的问题就是人们喜欢并行开发多个任务。因为不可避免的,我们设计的功能中总会有一部分会被放弃砍掉,如果提前开发,很可能做无用功。一次只开发一个用例(或很少几个用例,这根据你的开发团队的大小而定); 让这个用例功能完整; 让相应的测试用例都能通过; 相应的文稳都补齐; 只有在当前的用例完全开发完成后,才做为一个整体提交到版本库,才进行下一个用例。

 

一定不要在没有使用例的情况下往类里添加成员方法。 

这跟上面一条极其相似,除了这里针对的是数据成员。 开发人员很容易想到:一个‘客户记录’里应该有‘送货地址’的信息,但一定不要在没有任何用例要求这个属性的时候实现这个属性。

 

不要害怕做决定;不要害怕改变以前的决定。 

敏捷开发的目的是应对客户需求的不确定。 开发前期你不可能获到全部的信息。 你应该尽可能的拖延做决定的时间,但一旦到了你该做决定的时候,你应该当机立断,让项目向前推进。你不能说一直等到有了足够的信息才做决定。 相反,你要依赖现有的信息作出最正确们决定。 之后,当有新的信息出现后,不要害怕对以前的决定作出更改。(老辈人有的称之为触发器,但我称之为随环境而变)

 

不断的了解如何改进系统。 

这项工作没有尽头,你应该做好思想准备,持续不断的寻找可以改进的地方,收集各种关于如何找到质量问题、解决质量问题的案例。

 

审查,审查,审查。 

敏捷开发可以帮助我们应对需求在将来的不确定,但过去的事情也存在不确定性。 测试工作永远不能停下来。程序每次运行的表现都要被评审和记录。

 

软件的设计要以人为本,而不是系统。 

很多开发人员退而求其次、以技术为中心,让设计为技术服务。 永远不要忘记软件的终极目标是什么,是帮助人们完成工作。

 

测试是产品的一部分。

 许多开发人员和经理都认为产品就是你打包给客户的东西,其余的都不重要。 其实测试也应该看作是产品的实际一部分,应该在设计时给予相当的重视,甚至,在很多时候,测试功能也应该同产品一起提交给客户。(后面说的这部分很多人都不认可,一个内置的能自我测试软件包并不会占用多少额外的资源,但当你需要用到它时,你会发现它的巨大价值。)

 

先写测试用例,后写代码。 

测试用例可以用来精确的说明我们的设计需求。 很多时候我们都是通过运行测试用例后发现我们的设计中存在问题。想想吧,先写测试用例后编码能节省多少时间。 但是:写完测试用例1,然后编写用例1,完后才开始用例2。

 

清理垃圾代码。 

很显然,又是一个尽人皆知的道理,但它也必须写入任何的开发原则里,因为它是如此的重要。查找垃圾代码的工作永远没有尽头,找到它,消灭它。 要去除掉所有的不能给实际用户带来价值的代码。 如果你不能指出某段代码对用户有什么用处,那它很可能就是没用的。

 

培养对集成失败问题立即做出反应的习惯。 

你要明白,当集成构建失败时,它会影响项目中的每一个人,所以没有比让核心程序能正确的集成和测试通过更重要的事情了。我曾经见到过有的团队的集成构建中断几个月都不去管它,因为他们有其他的工作要做。 每个人都在忍受这种情况,但没人采取措施。 我们应该明白,应该广泛的认识到,只要做出一点点工作,整个的团队会因此得到非常大的回报。

 

团队的每个成员都要知道客户的需求。

大型复杂的项目必须要分割到几个独立的团队去开发,然后派发到每个开发人员的手中,但这绝对不能变成程序员可以不明白最终产品的使用用户的需求和目标是什么。

 

把意义相关的东西放在一起。 

组织好代码,让高度相关的东西都放在一起,也就是放在一个类里。 这是标准的面向对象设计原则里的封装的概念。理想情况下,类之外的程序并不需要知道类里面的工作细节。 有些开发人员喜欢把代码放到好几个文件里,这样是为了按另一种方式组织它们:例如把相同的数据类型的放到一起,或按字母顺序分类。举个例子,有人会把所有的常量放在单独一个包下的一个类里,他们这样做毫无必要,增加了程序的复杂性。 按照指导原则,它们应该按照相关性进行分组,从而减少复杂性。

 

先测试后提交代码。 

这个准则能让你确保“永远不要让集成构建失败”的准则。

 

过早优化是灾难之源 

这句话是引用Don Knuth的,今天听起来一点不错。在内核里的代码应该尽力的写好来避免不要的浪费,但针对高于单个方法的级别的优化应该在整个项目测试通过、针对最终实际用户的压力测试用例通过之后才能进行。 仅仅根据静态的代码来判断哪些是影响整个性能最主要的问题的论断往往是错误的。相反,评审整个系统的运行表现,找出真正影响性能的1%的代码,只针对这些代码做优化。

 

最小化未完成的编码任务的工作包(backlog)。 

当开发人员开发一个设计用例时,有的功能会牵涉到所有修改着的但未完全开发完成、充分测试的代码。把未修改完成的代码保存到本地数天或数星期,这样增加了工作浪费的风险,会出现返工。 想象有三个任务,每个估计都要一天。 如果三个一起开发,并行起来每个都需要3天,这样一累计会有9个’单位’的风险。 如果顺序的开发,一个开发完成后再开发另一个,只会有3个‘单位’的风险。 这个并不符合我们的直觉。 我们的直觉告诉我们,当我们在这种情况下时,我们希望三个一起完成。 但是软件不像盖房子。小的、迅速的、完整的任务不仅仅会降低我们的认知负荷,也减少了进行中的开发对其他人正在进行的开发的相互影响。

 

不要过度功能范化。 

程序员在编写一个类时喜欢料想:这个类可能在其它地方其它类中会有其它用途用. 如果这些用途是被当前的用例用到,那这样思考是没错的,但常常开发人员想到的这些用途都是目前不存在的用途,实际上可能是永远不会用到的用途。

 

如果两行代码能完成就不要写成三行。 

简洁的代码永远都会给需要阅读这段代码的人带来好处。 但千万不要把代码压缩的难以理解了。精简的、书写规范的代码易于维护和查找错误,冗长的、太多修饰的代码则相反。 尽可能的简化但不要过度。

 

永远不要按行数多少来评价代码头。 

编写某个任务所产生的代码行数会因程序员而异,因编码风格而异。 代码的行数不会提供任何关于程序完成情况和代码质量的信息。代码质量可以相差200倍之多,这是计算代码行数的方法不能胜任的。 应该计算功能性的用例数。

 

我们应不断的再设计、再分析。

 应用这一条时你要非常的小心,因为有些代码很脆弱、难以维护。但不要害怕修改这些代码、让它符合真正的需求。 一个数据成员以前是整数型的,但现在有个用例需要它是浮点型,不要害怕去改变它,只要你按步骤:测试,写文档,布署。

 

删除死代码。 

当发现有一大段不能理解的代码时我们习惯的做法是“让死狗躺在哪”。 比如说,我们需要往类里添加一个新方法来替换以前的旧方法,通用人们会保留老方法‘以防不测’。其实,我们应该花一些功夫去检查看看这个老方法是否还有用,如果没有证据显示它还有用,就该删掉它。 更糟糕的错误做法是把这些代码注释掉,留下一堆注释码。 注释掉的代码一旦发现就该被删掉,不能留到测试时还有、甚至提交到代码库。添加代码总是容易的,删除代码总是困难的。 因此,一旦发现有可能没用的代码,你应该花点时去确认它、删除它,这样会让代码更加可维护。

 

不要自创新语言。 

程序员喜欢使用文本文件来实现功能性的趋动,这样可以使程序变的可配置。 通过配置文件来改变软件行为所产生的后果是不过控的。 XML的诞生促使了一系列的特别的自定义的‘脚本语言‘的出现,人们试图通过文件的配置以让最终用户‘编程’来控制软件的功能、避免重新编译。这种设计上的缺陷是:软件里的各种操作的准确定义在脱离了具体上下文的特定实现的情况下不可能被准确的定义。这些各式各样的脚本型语言只是对那些对软件代码的内部工作机理有着相关的知识背景的人才会价值。所以,真正的最终用户是不可能知道软件的内部工作机理的,不可能推理出这些复杂的指令组合会产生什么样的预期结果。 脚本有它的用途,也不应该被抵制,但设计人员必须以非常非常安全的方式使用它们,尽可能使用现有的语言,必免使用新发明的语言。

 

只有当准备好了实现和测试才去确定设计。 

我应该有一个总体的认识我们要做什么,应该有个总体架构目标,而不是详细设计、详细的具体方法的实现,只有当开发迭代到一定程度后、足以让我们定下设计细节后才去把它表现成文档。详细设计只应该包括当前需求用例中需要覆盖的部分。 软件开发中最大的浪费就是你花时间设计出来东西后被告知不需要了,或者是你的设计一开始就建立在错误的假设上。

 

软件是可塑的。 

软件不像盖房子,我们可以轻易的改的面目全非。 无数事实表明软件比它的规格说明书善变的多。而且,软件产品和设计之间的互动明显比规格说明书有效率。 所以,你应该直接实现你的设计,这样客户就能很容易明白你的设计细节。 当发现有问题、要改变设计时,修改软件要比修改文档容易的多。更重要的是,当客户看到了能运行的程序后,你也就更能搞清客户的需求是什么了。

 

对被检测到的和被报告的异常情况请多花一点时间对其进行详细描述。 

程序员一般都非常的懒,抛出异常时只描述错误的表面现象。 设想如果只是作者自己会遇到这种错误,他会记得这种一直使用的错误描述信息是什么意思。但站在客服技术支持的处境,他们因为这种不准确的、不完整的错误描述浪费了大量时间。 这些信息应该达到让一个刚走进屋里没有任何经验的人能看明白的程度。 客户和客服基本都是对编程不懂的人。

 

不断更新中…


2019-03-13 14:37:56 tfy_2425482491 阅读数 352
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10404 人正在学习 去看看 CSDN讲师

一,根据以下几个问题来谈谈敏捷开发

1.什么是敏捷开发?

2.为什么使用敏捷开发?

3.如实使用敏捷开发?

4.采用敏捷开发的产品效果?

 

二.什么是敏捷开发?

  1. 敏捷开发是一种价值和原则,指导我们更加高效的开发。
  2. 敏捷开发以用户需求为核心,采用迭代,循序渐进的方式开发软件,目的在于快捷覆盖,响应市场需求。
  3. 大项目划分小项目,分别完成,独立运行。
  4. 敏捷开发特征。
  5. 敏捷开发原则。

2.1. 敏捷开发是一种价值观与原则

  敏捷开发是一种价值观与原则,指导我们更加高效的开发。

2.2.敏捷开发以用户需求为核心

  敏捷开发以用户需求为核心,采用迭代(时间周期),增量(循序渐进,功能模块)的方法开发软件,目的在于快捷覆盖,响应市场需求。

2.3.大项目划分小项目

 大项目划分小项目,分别完成,独立运行,如微服务的开发过程,就是将系统独立进行开发

2.4.敏捷开发特征

  •   迭代式开发(主体是时间周期)
  • 增量交付(主体是功能模块)
  • 开发团队和用户反馈推动产品开发
  • 持续集成
  • 开发团队自我管理

 2.5.迭代式开发

   项目按照时间周期进行迭代,比如A功能优先级比较高,则在第一个迭代周期内优先开发A功能,并上线。第二个迭代周期开发B功能.

2.6.增量交付(主体功能模块)

  瀑布式开发:需求评审,概要设计,详细设计,开发,单元测试,集成测试,上线。

增量式开发:则代表产品是在每个周期结束时被逐渐交付使用的。

2.7.开发团队和用户反馈推动产品开发

  敏捷开发提倡用户参与到产品或项目开发的整个流程当中,通过用户反馈使得产品更加符合用户频繁变动的需求。

2.8.持续集成

   采用敏捷开发产品在产品初期会上线基本功能,之后的功能是根据收集到的用户反馈进行开发的,实现功能模块的持续集成。

2.9.开发团队自我管理

  传统的开发模式,注重文档约束,而敏捷开发原则的推行原则需求团队内部交流便利,文化相对开发,除去必要的文档约束,如API接口文档,最注重的是团队成员的高效交流,以此来提高产品,项目的开发效率,开发质量。

2.9.1敏捷开发原则

  • 快速迭代
  • 需求评审
  • 编写story/验收标准
  • 多沟通,减少不必要的文档
  • 做好产品原型UE UI
  • 及早考虑测试

2.9.1.1快捷迭代

    小版本更新发布,更快覆盖当前市场,用户,需求

2.9.1.2需求评审

  • 需求评审阶段,需求PM,所有相关开发人员参与到需求评审当中
  • 需求评审阶段
  • 需求可行性分析
  • 确定需求功能范围
  • PM对需求中存在异议的细节进行解释

2.9.1.3编写story,验收标准

   PM编写story验收标准

2.9.1.4多沟通

   PM。开发人员之间需要多沟通,减少不必要的文档

2.9.1.5做好原则

   需求评审完毕后,PM与UE UI 人员进行紧密沟通,完成指导开发人员的UE UI

2.9.1.6及早考虑测试

  测试人员在这个阶段需要根据需求中划分的功能点,设计测试使用。

 

三.为什么使用敏捷开发

  1. 在用户需求不断变化的情况下能够保证软件开发质量,把多的时间点变成小的时间点。
  2. 把团队中职责定义清除,发挥最大效率。 

 

3.1 覆盖快速变化的市场,用户需求。快速响应变化需求

   在用户需求不断变化的情况下能够保证软件开发质量,把多的时间点变小的时间点

四.如何推行敏捷开发

  

 

五.采用敏捷开发的产品开发效果

  敏捷开发大大提高了我们部门的开发效率,开发人员各自关注自己负责的功能模块,并且通过高效的沟通,在保证产品质量的前提下,实现了产品的快速迭代!项目名称 斐讯路由!

敏捷开发实践总结

阅读数 179

浅谈敏捷开发

阅读数 240

没有更多推荐了,返回首页