2019-03-30 10:47:49 dickdick111 阅读数 287
  • SCRUM敏捷开发视频教程

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

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

对敏捷宣言的原则进行风险评估

题目要求:在敏捷宣言遵循的12条原则中挑选1条你感兴趣的原则进行风险评估。

风险评估

大型软件项目的风险管理:大型项目存在诸多风险因素,在不同程度上对软件开发过程和软件产品质量造成影响。风险不能全部消除,而只能采用避免、减轻、和接受三种应对策略。

  • 需求变更风险;
  • 进度风险、预算风险、管理能力风险、信息安全风险;
  • 应用技术风险、质量控制风险、软件设计与开发工具风险、员工技能风险;
  • 人力资源风险、政策风险、市场风险、营销风险。

敏捷宣言遵循的12条原则

  • 我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。
  • 欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。
  • 经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。
  • 业务人员和开发人员必须相互合作,项目中的每一天都不例外。
  • 激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。
  • 不论团队内外,传递信息效果最好效率也最高的方式是面对面交谈。
  • 可工作的软件是进度的首要度量标准。
  • 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
  • 坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。
  • 以简洁为本,它是极力减少不必要工作量的艺术。
  • 最好的架构、需求和设计出自自组织团队。
  • 团队定期地反思如何能提高成效,并依此调整自身的举止表现。

对于第十条原则进行风险评估

以简洁为本,它是极力减少不必要工作量的艺术。

  • 管理能力风险

    由于敏捷开发第十条原则强调简洁为本,这就放弃了一些管理文档,项目使用手册等一些指导性文档书写的工作。程序员一味盲目地进行开发,容易忽视管理整合项目,到项目最后总合或者出现bug的时候,无法快速定位错误的地方,额外增加后期的工作量。

  • 信息安全风险

    为了减少不必要的工作量,项目必然会出现关键信息未加密如身份证、手机号等,源代码未加密等问题。这样的问题可能会暴露用户的隐私信息,应用程序的后门容易被不法分子利用,信息安全不能被保证。

  • 应用技术风险

    使用简洁的开发,意味着使用简单的现成的技术进行开发。这样可能出现困难的需求无法通过该技术来实现,这时需要更换应用技术,导致前后技术不一致,应用的接口出现差异的问题。或者,该简单现成的技术可能会被当前环境所淘汰,存在着风险。

  • 质量控制风险

    简洁的开发不能保证处理所有情况的异常,软件的质量不能被百分之一百的保证,可能出现软件崩溃的情况。这就因为在测试过程减少了不必要的工作量,仅满足关键测试,而没有完整的进行检查。

  • 软件设计与开发工具风险

    软件设计过程为了追求简洁,设计不会非常完善,可能出现各种问题但是未被发现,而这些问题会在开发或者推广过程被发现。这些漏洞就是因为前期软件设计过于简洁所造成的,没有多采取多个设计方案进行比对。

对于第二条原则进行风险评估

欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。

  • 需求变更风险

    需求不断的改变,在敏捷开发过程的原则中也是可以接受的,这就导致需求更改前后不一致,导致开发过程变长,成本增加。在开发后期更改需求还会导致软件面临架构重构的问题,面临极大的风险。

  • 进度风险

    欣然面对需求的变化,必然会针对用户的需求不断修改软件项目,这样会导致软件的进度无法确定,经常出现变更,进度难以统一。在开发后期更改需求,还可能导致进度重置的问题。

  • 预算风险

    需求的变更可能导致一开始的预算完全不正确,需求的改变必然会使软件开发的成本提高,预算可能不能满足后续的开发,这最终会导致软件开发到半路就经费不足,项目无法继续下去。

  • 员工技能风险

    需求的变更有可能导致完成新需求的技术变更,开发员工并未掌握该新需求的技术,重新学习导致开发流程边长,也可能出现员工开发质量由于技术不精而导致下降的问题

  • 市场风险

    更改需求不一定满足市场一开始的需要,最后由于不断变更需求而开发出来的软件可能不被市场所接受,导致软件推广困难。

2019-04-01 21:01:00 Alva112358 阅读数 32
  • SCRUM敏捷开发视频教程

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

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

目录


在敏捷宣言遵循的12条原则中挑选1条你感兴趣的原则进行风险评估


敏捷开发的12条原则

  1. 我们最重要的目标,是通过尽早和持续地交付有价值的软件来使客户
    满意。
  2. 欢迎需求的变更—即使是在项目开发后期。要善于利用需求变更,帮
    助客户获得竞争优势。
  3. 不断交付可用的软件,周期从几周到几个月不等,且越短越好。
  4. 在整个项目过程中,业务人员与开发人员每天在一起工作。
  5. 激励项目人员,以他们为核心构建项目,给他们以所需要的环境和支
    持,并相信他们能够完成任务。
  6. 无论团队内还是团队间,最有效的沟通方法是面对面的交谈。
  7. 可工作的软件是衡量进度的主要指标。
  8. 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持
    恒久稳定的进展速度。
  9. 对技术的精益求精以及对设计的不断完善将提升敏捷性。
  10. 以简洁为本。简洁是尽可能减少不必要的工作量的艺术。
  11. 最佳的架构、需求和设计出自于自组织团队。
  12. 团队要定期反省如何能够做到更有效,并相应地调整团队的行为。

风险评估

  1. 需求变更风险。
  2. 进度风险、预算风险、管理能力风险、信息安全风险。
  3. 应用技术风险、质量控制风险、软件设计与开发工具风险、员工技能风险。
  4. 人力资源风险、政策风险、市场风险、营销风险。

挑选其中1条原则进行风险评估


不断交付可用的软件,周期从几周到几个月不等,且越短越好

  • 需求变更风险
    敏捷开发第三条原则,要求用尽可能少的时间交付软件,因为用户的需求可能会随着时间而不断发生变化,尽快地交付软件能够减少开发中途客户需求的突然改变而导致工程进程收到严重影响。

  • 进度风险
    尽可能早地交付软件,能够保证其中一个阶段的顺利完成,避免用户需求因为开发时间过长,收到市场影响而更改需求,对整个工程的进度造成影响。

  • 预算风险
    开发周期越长,投入的人力物力也就越多,需要的经费也越大,因此开发的周期越短,越能够减少预算风险。

  • 管理能力风险
    随着开发时间的增长,对软件各部分的功能、性能的管理也越来越复杂,对于项目的管理者的管理能力要求也越高,因此,尽早地交付软件能够有效地减少管理能力风险。

  • 信息安全风险
    随着软件开发周期的增长,软件中潜在的漏洞也可能会增多,这时候如果包含有客户数据的重要信息,则可能会被有计谋者诡探进行攻击,造成损失。因此尽可能早地交付能够有效地减少信息安全风险。

  • 应用技术风险
    软件开发周期的增长,可能面临着信息技术的革新,从而造成产品在一定程度上具有竞争劣势,因此尽早地交付产品,能够有效规避应用技术风险。

  • 质量控制风险
    软件开发周期的增长,必然会对质量的把控越来越难,因为软件规模也会随着周期的增长而不断增大,这时候对软件系统的质量把控变得更为复杂,需要工作人员的技术更加成熟。

  • 软件设计与开发工具风险
    软件开发周期的增长,初始设计的一些缺陷与不足可能就会呈现出来,而且开发规模可能会与预期有所不同,而造成原有开发工具不能适应,因此如果能够缩短软件开发的周期,就能够有效规避软件设计与开发工具风险。

  • 员工技能风险
    随着软件开发周期的增长,软件的规模不断增大,软件在继续开发,深度测试和系统分析方面对员工的能力要求也越来越大,如果员工的能力不能达到要求,就可能需要进行培训或者招募新的有能力的员工,而这些方面无不增加了软件开发的成本。

  • 人力资源风险
    软件开发周期增长,在开发初期的员工可能会因为各种原因而离开,这时候造成的代码重新理解、客户接触者更替等问题,这时候对人力资源的管理也更加困难和复杂,因此尽可能快地交付软件能够有效地规避这种问题。

  • 政策风险
    如果软件的开发周期过长,可能会因为政府的某些政策原因而导致最终的软件产品无法上线,这时候所有付出的资本都会流失,从而造成重大影响,因此尽可能早地交付软件,能够避免这些意外的发生。

  • 市场风险
    如果软件的开发周期过长,那么市场对于当前软件产品的定位就可能会发生变化,这时候当前开发软件的价值可能就会减少,因此尽可能早地交付软件,能够有效地在最适应的市场发挥最大的价值。

  • 营销风险
    如果软件的开发周期过长,那么由于市场需求的改变,对于营销者的压力也会明显增大,因为可能软件产品的竞争力与其他对手相比略有不足,在宣传力度上要花费的时间的金钱也越多,从而造成成本的增多,因此尽早地交付软件能够有效地避免这些事情的发生。

2019-03-24 20:14:54 qq_36290774 阅读数 187
  • SCRUM敏捷开发视频教程

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

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

前言:本篇纯属个人理解,很可能存在误导。

题目:

在敏捷宣言遵循的12条原则中挑选1条你感兴趣的原则进行风险评估。

(“原则”参见 Lec.5, slide 8-10;“风险”参见 Lec.3, slide 17)

 

答案:

12原则作为敏捷开发对于软件开发流程的指导性纲领,其实是对敏捷宣言进行了具有实际操作意义的解释。

下面是敏捷宣言12原则:

我们遵循以下准则:

  1. 我们的最高目标是,通过尽早和持续地交付有价值的软件来满足客户。
  2. 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更,帮助客户获得竞争优势。
  3. 要不断交付可用的软件,周期从几周到几个月不等,且越短越好。
  4. 项目过程中,业务人员与开发人员必须在一起工作。
  5. 要善于激励项目人员,给他们以所需要的环境和支持,并相信他们能够完成任务。
  6. 无论是团队内还是团队间,最有效的沟通方法是面对面的交谈。
  7. 可用的软件是衡量进度的主要指标。
  8. 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
  9. 对技术的精益求精以及对设计的不断完善将提升敏捷性。
  10. 要做到简洁,即尽最大可能减少不必要的工作。这是一门艺术。
  11. 最佳的架构、需求和设计出自于自组织的团队。
  12. 团队要定期反省如何能够做到更有效,并相应地调整团队的行为。

 

而主要针对大型软件项目开发的螺旋模型,其风险管理认为:大型项目存在诸多风险因素,在不同程度上对软件开发过程和软件产品质量造成影响。风险不能全部消除,而只能采用避免、减轻、和接受这三种应对策略。

主要风险有: 

需求变更风险;

进度风险、预算风险、管理能力风险、信息安全风险;

应用技术风险、质量控制风险、软件设计和开发工具风险、

员工技能风险;

人力资源风险、政策风险、市场风险、营销风险。

 

此处我选择分析的是十二原则中的第二条:

欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更,帮助客户获得竞争优势。”

风险评估:

我认为包括如下风险项:

  1. 需求变更风险:需求变更是一个无法避免的事实,它会导致软件开发过程中产生成本增加、质量不过关等风险,而且越往后的变更产生的风险将越大。而往往在软件项目中,最经常发生、也是最让人头疼的便是需求变更。由于对软件项目的影响实在巨大,特别是在大型长周期项目开发过程后期, 如果发生需求变更,尽管可能确实更有利于需求方,但是对于开发者很可能 意味着全部推倒重建。因此需要将需求分析文件做好,如果基准文件内涵盖 的范围含糊不清,被用户抓住空子,往往要付出许多无谓的牺牲。在项目后期,客户提出的变更若是超出了合同范围,理应还是避免变更,除非需求改 变而需求方软件开发的投入也随之增加。
  2. 进度风险:需求方对需求提出过多的变更,很可能会使项目无法在预期的交付时限内完成,由此也会带来新的损失。因此若是需求变更太多,也需要将项目延期来控制该风险对项目的影响。因此在时限上也会出现问题。
  3. 预算风险:需求变更,会导致工作量增加,同时会带来项目几乎必然的延期,以及项目预估实际开发成本很可能高于预算资金,这时候就要考虑是否要提高预算或者是缩减部分预算,若是没处理好,可能会导致项目质量下降,以及项目中断等情况。需要需求方与承办方提前协商等来避免。
  4. 管理能力风险:项目承办方可能并没有处理需求变更带来的组织、个人、以及工作进度等方面的问题的能力,需求方变更需求很可能导致项目中途出现无法解决的问题。最终导致项目本身出现问题。
  5. 应用技术风险:变更需求之后项目所需要使用到的实际应用技术可能在此前并没有包含在项目所需技术中,进而导致项目进度缓慢,甚至失败。
  6. 质量控制风险:变更需求较大或较频繁,会导致在相同时限内,项目为了按时交付,而在加快进度时忽视了项目质量,导致项目最终成品质量不如人意,甚至沦为失败项目。
  7. 软件设计和开发工具风险:与应用技术风险类似,可能没有相关技能或工具,进而导致需求变更后项目进度缓慢或者是无法进行,进而导致进度风险,导致项目延迟交付或者质量较低,甚至失败。
  8. 员工技能风险:类似的,进而导致需求变更后项目进度缓慢或者是无法进行,没有合适的员工能较好地完成变更需求之后的项目。甚至需要在项目变更需求后临时让员工进行技能培训。
  9. 人力资源风险:项目变更需求之后,原本的被委托方的已有人力资源可能无法完成需求方需要达到的项目要求,进而导致其它问题。
  10. 市场风险:可能需求方提出的新需求并不能更好地满足市场需求,反而使得项目市场竞争力劣化,进而导致需求方与受委托方都受到影响。形成某种意义上的项目失败。

 

而相对来说,政策风险信息安全风险 和 营销风险 可能性较低。

 

以上,是我个人对遵循第二条原则可能面临的风险的评估。

2018-12-24 12:52:25 qq_43152867 阅读数 137
  • SCRUM敏捷开发视频教程

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

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

网上有很多文章都在比较软件研发的瀑布模式、迭代模式和敏捷模式的区别,然而,敏捷其实不是一个技术,一个固化的模式,而是一种思想,一种宣言。敏捷软件开发关注保持简洁的代码,经常性测试以及及时地交付应用的功能模块。敏捷宣言的创建是为了替代文档驱动的繁重的软件开发流程,例如瀑布式方法。下面是我的理解。

一、概念

敏捷,把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。
敏捷是应对快速变化的需求的一种软件开发能力,以用户的需求进化为核心,关注互动沟通,强调最简方案,能尽量早的将尽量小的可用的功能交付使用,并在整个项目周期中持续改善和增强。敏捷思想可在SDLC 中的各环节体现出来,如下图是一个敏捷化的IPD模式。
在这里插入图片描述
在迭代内每个build的敏捷工作模式如下:
在这里插入图片描述

二、敏捷宣言

敏捷宣言,也叫做敏捷软件开发宣言,包括四种核心价值和十二条原则。
(一)敏捷的四种核心价值:
1.个体和交互胜于流程和工具
2.工作软件胜于理解文档
3.客户协作胜于合同协商
4.响应变化 胜过 遵循计划

(二)敏捷宣言遵循的十二条原则:

敏捷选择提出的12条原则已经应用于管理大量的业务以及与IT相关项目中,包括商业智能(BI)。12原则包括:
  1.通过早期和连续型的高价值工作交付满足“客户”。
  2.大工作分成可以迅速完成的较小组成部门。
  3.识别最好的工作是从自我组织的团队中出现的,
  4.为积极员工提供他们需要的环境和支持,并相信他们可以完成工作。
  5.创建可以改善可持续工作的流程。
  6.维持完整工作的不变的步调。
  7.欢迎改变的需求,即时是在项目后期。
  8.在项目期间每天与项目团队和业务所有者开会。
  9.在定期修正期,让团队反映如何能高效,然后进行相应地行为调整。
  10.通过完车的工作量计量工作进度。
  11.不断地追求完善。
  12.利用调整获得竞争优势。
  
三、典型的敏捷事件
1.Kanban:相当于板报,上边按照to do /doing/done划分成三部分,每个人将写有自己名字以及任务的便利贴贴在相应的区域,以便小组之间互相了解彼此的工作进度,便于上级督查是敏捷的一种落地体现。

2.Pair work:结对编程、结对测试。结对工作体现了合作精神,针对有难度需要汇集各方才智的工作会事半功倍,避免闭门造车,提高工作效率。

3.Cross action:交叉设计、交叉评审、交叉执行,有助于发现自己发现不了的缺陷。

4.Daily scrum meeting:每日例会。主要总结昨日完成了什么,遇到什么问题,怎么解决的,今日计划是什么。

5.SOS meeting:Scrum of Scrums,大规模敏捷模型。当多个scrum team工作在同一个产品上的时候,虽然我们努力想做到全功能的特性团队,希望能在一个团队里做完所有的事情,而不需要依赖其他的团队,但这明显只是一个非常理想的状态;团队之间不可避免会有依赖,需要协同。Scrum of scrums的做法就是每个scrum团队选出1-2个代表,团队的代表聚在一起分享进度和协同解决依赖。如果组织很大,scrum团队太多,也会出现先按部门的划分在不同的部门里做SoS,然后不同部门的代表再聚在一起做“Scrum of Scrum of Scrums”。也就是分层次的SoS。

2012-09-29 14:02:06 desert3 阅读数 53
  • SCRUM敏捷开发视频教程

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

    10423 人正在学习 去看看 CSDN讲师
敏捷软件开发的[b]四条价值观以及十二条原则[/b]

[url=http://agilemanifesto.org/iso/zhchs/][b]敏捷宣言 Agile Manifesto[/b][/url]
我们一直在实践中[color=red]探寻更好的软件开发方法[/color],[color=red]身体力行的同时也帮助他人[/color]。由此我们建立了如下[color=red]价值观[/color]:
[list]
[*][color=red]个体和互动[/color] 高于 流程和工具
[*][color=red]工作的软件[/color] 高于 详尽的文档
[*][color=red]客户合作[/color] 高于 合同谈判
[*][color=red]响应变化[/color] 高于 遵循计划
[/list]
也就是说,尽管[color=red]右项有其价值[/color],我们[color=blue]更重视左项的价值[/color]。

[b]敏捷宣言遵循的原则[/b]
[list]
[*]我们最重要的目标,是[color=red]通过持续不断地及早交付有价值的软件使客户满意[/color]。
[*][color=red]欣然面对需求变化[/color],即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。
[*][color=red]经常地交付可工作的软件[/color],相隔几星期或一两个月,倾向于采取较短的周期。
[*]业务人员和开发人员[color=red]必须相互合作[/color],项目中的每一天都不例外。
[*]激发个体的斗志,以他们为核心搭建项目。[color=red]提供所需的环境和支援,辅以信任[/color],从而达成目标。
[*]不论团队内外,传递信息效果最好效率也最高的方式是[color=red]面对面的交谈[/color]。
[*][color=red]可工作的软件[/color]是进度的首要度量标准。
[*]敏捷过程倡导[color=red]可持续开发[/color]。责任人、开发人员和用户要能够共同维持其步调稳定延续。
[*]坚持不懈地[color=red]追求技术卓越和良好设计[/color],敏捷能力由此增强。
[*]以[color=red]简洁[/color]为本,它是极力减少不必要工作量的艺术。
[*]最好的架构、需求和设计出自自[color=red]组织团队[/color]。
[*]团队[color=red]定期地反思[/color]如何能提高成效,并[color=red]依此调整[/color]自身的举止表现。
[/list]

软件测试作业2

阅读数 54

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