2016-07-20 17:45:42 nuli888 阅读数 1691
  • SCRUM敏捷开发视频教程

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

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

个人觉得

敏捷开发强调以人为中心,快速迭代,客户参与多沟通,减少不必要的文档,包括Scrum和XP
优点:快速适应变化,做出的项目比较接近客户需要的
缺点:文档不多,如果人员流动大,维护相对更难


瀑布开发强调文档,就是不同阶段按照顺序自上而下而来,如需求、设计、编码、测试(单元测试、系统测试)、维护,每个阶段尽量做得最好
优点:每个阶段可作为检查点,前一阶段完成只需关注后一阶段
缺点:缺少沟通、反馈,文档比较多,不适应需求快速变化,在生命周期后期才看得到结果,如果有一阶段出了大问题,会影响最终成功

2018-10-06 07:42:27 yaojiawan 阅读数 388
  • SCRUM敏捷开发视频教程

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

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

瀑布模式和敏捷模式

     瀑布和敏捷模式是软件开发的两种方式,十多年前软件工程的书上介绍软件生命周期总是描述成“需求,分析,设计,编码,测试和维护几个不同的阶段。这就是瀑布模式(Waterfall Model),主张在动手编码之前,将所有的事情搞明白,编写详细的文档,很多开发人员好象是在开发文档,而不是开发软件,因为要到开发的后期,才可以看到软件的“模样”。

       瀑布模式能够保证软件的质量。它适合目标确定的软件开发,比如军事软件,汽车电子产品,仿制一个现有的产品。而且需要一位能力非常强大的系统分析员,编写出各种文档。

   但是当你开始设计一个创新的产品,或者为客户设计一个全新的产品,使用 瀑布模式就不适合了,比较再高明的系统分析师也不可能将事情完全想明白,况且客户对自己想要的产品也是模糊不清的。在提需求的时候往往像一个小男孩进入了玩具店,什么都想要。但是一旦产品出来后,又发现这些功能又不是它想要的。

  于是,人们又提出了所谓敏捷模式(Agile Model)。这里,我们谈谈在嵌入式系统开发中如何推行敏捷模式。

我们关心敏捷模式的另一个原因是 小团队本来就缺乏系统分析员这样的大牛。不如转向敏捷模式吧!

软件敏捷开发方法

网络上有大量关于软件敏捷开发的内容,好像都只是说一些概念。维基百科上讲的比较全面了,核心大约下面几点。

敏捷开发的理念

  • 个体和交互胜过工具和过程(Individuals and Interactions over processes and tools
  • 可以运行的软件胜过详细的文档(Working Software over comprehensive documentation
  • 客户合作胜过合同谈判(Customer Collaboration over contract negotiation
  • 响应变化胜过遵循计划(Responding to Change over following a plan

敏捷开发的概念

  • 从早期开始就向客户持续递交有价值和测试过的软件
  • 欢迎修改需求,哪怕是在后期。
  • 频繁递交可以运行的软件(将从每月缩短到每周)
  • 通过持续的客户/研发者校正,来管控需求。
  • 提倡面对面交流。
  • 评估进度的主要尺度是可工作的软件。
  • 商务人员和开发人员每天都相互合作。
  • 简洁是基础,是尽量减少工作量的艺术。
  • 最佳的架构,需求和设计来自于自我组织的团队。

嵌入式系统的敏捷开发

嵌入式系统涉及了软件和硬件。而且硬件是不那么容易不断迭代的活。 在嵌入式系统设计过程中采纳敏捷开发方式呢?我们觉得的可行,下面谈谈我们的做法和体会。

  • 采用top-down 设计方式。

     为了尽快地向客户呈现产品的性能,采取自顶向下的设计方式是最有效的。在桌面系统,移动App和web 应用程序开发中,首先是完成前端用户界面设计。让客户第一时间看到产品的样子,以便和客户确定需求中偏差。然后再开发后端系统。

  • 使用面向对象程序设计语言。

     同样地,在代码开发中,为了和团队其它成员之间的交流,明确API 定义。最好的方式是采用面向对象程序设计语言。第一步首先定义各种类(class),程序主要数据和成员函数。必要的时候,可以使用仿真的方法,在类成员函数中生成仿真数据。团队其它成员可以在第一时间首先调用和测试这些类,是否符合需求。

      对于基于网络的产品而言,在设计的初期,首先定义协议的方式,消息的数据结构和语义。使前后端尽早实现通信。

    团队成员之间通过类定义和消息定义实现沟通和交流。

  • 软件仿真硬件。

      嵌入式软件工程师痛苦的事情是长时间等待硬件的完成,而且由于硬件设计的拖延,往往留给软件工程师软硬件调试的时间十分有限。为了不被硬件开发拖后腿,影响敏捷设计的实施,比较好的方式是使用软件来仿真硬件。虽然增加了代码的工作量,但是完全是值得的。千万不要等待硬件板子来了才开工,那往往就免不了加班了。

  • 模块化硬件

     为了尽快地实现硬件底层驱动的开发,使用模块化电脑板是一个好的方法,在实践中,软件工程师已经大量地使用类似arduino这样的开发板以及各种接口扩展板来搭试硬件平台,调试底层驱动程序,一旦完成之后,移植到目标硬件系统上轻松多了。

Mbed OS 适合敏捷开发

Mbed OS 是Arm 公司为其Cortex-M 处理器开发的一个开源操作系统。我觉得它是更适合作为嵌入式设备敏捷开发的OS。

使用C++ 程序设计语言的RTOS

      Mbed OS 的程序库,硬件接口驱动都使用了类来定义。学习和使用起来十分方便,使应用程序的开发者摆脱了硬件细节。事实上,我们在开发应用程序的过程中,也采取了类似Mbed OS API 的方式,使用类定义软硬模块,将实现细节封闭了起来,使团队的其它人员很块可以重复调用这些类。这一做的另一个好处是我们团队中原来编写JavaScript/HTML5 前端的工程师和NodeJS 的软件工程师也毫无障碍地编写起嵌入式设备的软件了。使全栈工程师延申到了嵌入式设备。他们可以一气呵成实现设备到云端的架构实现。

生态和社区已经建立

尽管Mbed OS 在国内还不普及,但是它在国外已经有了大量的开发者,社区中可以找到大量可以直接使用的程序库和应用程序的实例。

比arduino 更强大

      Mbed OS 毕竟是在32位 cortex-M 系列处理器上运行的OS,cortex-M 比起8位 CPU 性能更高,外围电路更好丰富。另一方面,Mbed OS 对于网络和安全的支持也非常强大,能够轻松实现HTTP RestFull API,MQTT,SSL等。Arm 公司也提供了 pelion 云端服务。

硬件:模块化电脑

     嵌入式系统开发过程中,硬件永远是拖后腿的角色,我常常开玩笑说,等它等到我把写的代码都忘了。如何提高硬件的研发速度,是必须解决的瓶颈问题。

解决这些问题的好方法就是采取模块化设计方式。实际上,模块化是敏捷架构的重要组成部分。前面提到:改变是敏捷开发的重要部分,甚至宣称”欢迎改变“,其实硬件是最难改变的,而模块化设计使的改变更加容易。

事实上,大量的嵌入式设备的硬件都是大同小异的,无非需要一些串口,Ethernet,wifi,以及数字IO,ADC 等等。真正不同的是其中的软件。硬件工程师不断地从事重复性的设计工作。当产品不是大批量生产的,完全可以使用模块电脑来作为嵌入式设备的硬件平台。modular-2 就是这样的一台模块化嵌入式电脑。我们为软件开发者提供了大量常用的IO接口模块和网络通信模块。如果遇到特别的接口电路,硬件工程师也只要设计一块IO模块就完成了,大大减少了硬件开发的工作量。

   modular-2 不仅提高了嵌入式设备的研发效率,使敏捷开发的方法能够在嵌入式设备研发中得到有效地应用。同时,它可以作为产品快速部署到应用现场。快速地呈现给客户一个完整的软硬件结合的产品。这是modular-2 模块化设计带来的好处。

使用了modular-2 之后,我们原先需要开发数个月的项目压缩到了一到两周就完成了。实际上,有的项目我们一个晚上就完成了,使得客户非常吃惊。

  另一方面, 面对客户项目,许多工程师一个人就可以独立地完成。减少了大量协调,沟通的麻烦。降低了嵌入式系统研发的入门门槛,大学毕业生经过短期培训,阅读一些前辈的代码,就能够独立工作。公司的研发力量大大加强。

2008-09-06 18:26:00 routent 阅读数 634
  • SCRUM敏捷开发视频教程

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

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

敏捷方法横空出世

传统计划驱动的开发方法不仅没有获得良好的效果,并且由于强调过分过程控制,所以在开发过程中要产生大量的文档,以跟踪,检查设计各阶段的进度,设计状态,因此给程序员,管理者带来很多额外的工作量,这也是计划驱动方法一直为人诟病的地方,因此被称为重量级方法。这种方法的一个后果就是大量的开发时间被用在开发文档的撰写和维护上,而真正花在代码上的时间就相对少了;另外一个后果就是由于主要依赖过程控制,而不是程序员自我管理,开发过程的管理非常复杂和低效。程序员怨声载道,但是不得不服从。在计划驱动方法中,过程和工具不是为人(指程序员)服务的,而是为管理者服务的,程序员成了工具和过程的奴隶。这些都极大地阻碍了软件生产率的提高,这种开发模式越来越不适应现代瞬息万变的商业需求了。因此,在近几年,一种被成为敏捷方法的开发思想开始流行起来。

敏捷方法正是针对传统计划驱动方法的弊端而发展起来的。它是一类方法的总称。它有若干种不同的方法模型,比如水晶模型,scrum模型,XP编程。其中最著名的就是XP编程方法。虽然实际形式不同,但他们都有相同的思想。敏捷方法从另外的角度重新认识软件开发,颠覆了计划驱动方法的两个假设前提。就是我们在前面讲述过的1,需求固定。和2,人是可替换的。

敏捷开发的特征

 

敏捷方法有两个主要特征:敏捷方法的第一个特征是开发采用适应性方法,经过多次小型迭代开发过程逐步逼近实际需求,从而为客户提供实际需要的软件。这种开发方法的核心是,小型发布,不断集成和严格回归测试。每一次的小型发布都经过严格测试后集成到最终产品中,保证每一次小型发布都是经过测试的高质量的代码。在每一次小型发布后和客户沟通,得到客户反馈,不断修改,增加新的客户需要的功能,从而生产出符合客户需要的产品。开发过程以代码为核心,而不是以文档为核心。传统的以文档为主要输出的设计过程(需求分析,高层架构设计,概要设计,详细设计等)被大大压缩,以最快的速度进入代码的生产过程。设计以简单为原则,不进行多余的设计活动,小组通过密切而有效率的交流达到对设计的统一理解和认识。文档作为交流工具的作用被弱化,文档作为管理监督的功能被取消。一切以代码为核心,代码的编写,测试,发布,重构,然后进入第二次迭代。

敏捷开发的第二个特征是以人为本。这是革命性的转变。21世纪最重要的是什么?人才。这是一个连葛优这样的小偷团伙领导人都知道的道理。可是传统计划驱动方法却企图以文档,过程为核心,从而抹杀人的重要性。在敏捷方法里,程序员在软件开发中不再是单纯被管理的对象,而是开发的主体。所有的主要设计策略的制定,开发方法的选择,需求的确定都由程序员决定,因为他们才是真正生产软件的人,他们最了解如何开发软件。以往开发过程中的对开发过程的严格控制,检测,软件的各种测量等等都大大简化,因为这些措施都是为了监督程序员的。开发过程管理是为了更好地进行软件开发,而不是单纯为了管理者监测开发者的工作效率服务。开发者痛恨的官僚管理作风被统统取消,大家可能知道IBM, Microsoft, XEROR研究院的情况。在这些研究院里,公司只管为科学家提供足够的经费,良好的环境和诱人的待遇,但是公司从不干涉科学家的研究内容和方向,也不问科学家的生产率是都多少,科学家对自己的研究有决定权。敏捷开发在某种程度上借鉴了这种所谓科学家管理模式的思想。因为软件开发和科学研究一样都是高智力活动,它们生产的产品都依赖于参与者的主动参与而不是僵化的管理。虽然让一般人看起来似乎有点不可靠,但这可能是管理高智力活动的一种比较适合的方式。

 

敏捷开发的价值与局限

敏捷方法如何保证开发进度,开发效率,开发质量呢?这是一个传统开发方法想解决而没有解决好的问题。这个问题的答案就是靠人自我的管理,团队自我的管理。人是不可靠的,人不会像机器一样整齐划一,不犯错误;但人同时也是最可靠的,拥有超强个人能力,自律精神和充满信念和热情的人比任何机器都更有生产率。

但是任何方法都是有适用条件的。敏捷方法抛弃了繁琐的文档管理,就必须依靠程序员主动,开放,平凡的面对面的高效交流来达成对需求,目标,设计实现的理解;敏捷方法抛弃了机械、严格的过程控制,就必须依赖于程序员和开发团队的高标准自我要求:严格的自律,团队合作精神,个人高度自觉的主动性,责任感。敏捷方法的高效和高质量实际上是以程序员的高素质和开发团队的高度合作的开发文化为基础的。

因此敏捷方法的实施前提是必须找到愿意并有能力实施敏捷方法的团队。XP的创始人Beck也曾建议过有些情况是不适合采用XP方法的:比如,不能接受XP文化,团队规模过大,重构开销过大,等等。关于如何在一般组织中实施敏捷方法的讨论还在进行之中。

不管怎样,敏捷方法提供了一种崭新的,不同于以往的软件开发过程方法,敏捷方法提倡的简化设计,简化流程,迭代方法,以人为本的思想都是非常值得任何软件组织研究和借鉴的,它也是以往的软件开发大师们的开发实践成功经验的总结,我们必须学习,领会其根本思想,然后根据本组织的情况,有条件的借鉴其实践方法,把敏捷方法和传统开发方法结合起来,不断改进,持续提高,才能建立起一套适合自己的,具有本组织特色的,行之有效的软件开发过程体系。

 

 

2017-02-08 17:00:00 weixin_30491641 阅读数 0
  • SCRUM敏捷开发视频教程

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

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

敏捷开发与瀑布开发的对比

  • 瀑布模型开发:

  严格把软件项目的开发分隔成各个开发阶段:需求分析,设计,编码,测试,维护等,使用里程碑的方式,严格定义了各个开发阶段的输入和输出,如果达不到要求的输出,下一段阶段就不展开。

  强调文档,在开发的后期才会看到软件的模样,在这种情况下,文档的重要性似乎已经超过了代码的重要性。既然叫瀑布,就意味着不应该走回头路,如果出现返工,付出的代价会很大。

  • 敏捷开发:

  核心是迭代,迭代周期一般为1到4周,因为最终目标是让客户满意,所以能够主动接受需求变更,这就使设计出来的软件具有灵活性,可扩展性。

  瀑布模型需求确定,时间确定,最后实在完不成任务,可以加人;而敏捷开发时间确定,人员确定,到最后实在不行可以砍掉不是很重要的需求。

Why Agile?

软件开发中的不确定性和复杂程度决定了方法论,软件项目中的两个复杂度:简单项目=熟悉的技术+固定的需求;复杂项目=技术不确定+需求的变更;一句话,如果需求不确定,为了拥抱变化,就选择敏捷吧。

Agile 5 Core Value:openness,courage,respect,focus,commitment.

Scrum 角色

核心的三个角色:

1.Product Owner 产品负责人:

  • 帮助团队理解新软件的商业元素(需求);
  • 根据商业价值,把Product Backlog中的功能/产出 划分优先级;
  • 推动Backlog Grooming会议;
  • 选择发布日期和内容;
  • 根据需要调整功能产出和优先级;
  • 接收或者拒绝工作结果。

2.Scrum Master-一个公仆型的带头人,帮助团队对自己负责,对象他们的承诺。

  • 保证Scrum process被正确地应用并遵守;
  • 指导团队,让团队朝字组织的道路上前进;
  • 保护团队不受外界干扰,并且去除团队遇到的障碍;
  • 帮助提高团队的生产率(Velocity);
  • 促进各方面密切合作,移除障碍;
  • 组织会议,并且邀请相关人参加;
  • 培训客户,最大化投入产出比,并且满足他们的目标;
  • 改善工作环境。

3.Scrum团队

  • 团队理想尺寸是5-9人(太少,能完成的工作太少;太多,难以沟通);
  • 团队选择Sprint目标,并且明确工作结果;
  • 团队自我组织交付成果,完成承诺的工作;
  • 团队向PO和相关人员展示完成的User Stories。

Agile Process

在敏捷转型中最难的部分,其实是团队思维方式的变化,Scrum的核心价值是:

  • 时间盒;
  • 优先级驱动的增量方式;
  • 赋权 和 团队自我管理;
  • 应该是公仆/带头促进者而不是命令/控制的管理模式;
  • 信任,透明,不用担心失败;

从团队决定敏捷转型的起初6个Sprint,Scrum团队严格实施Scrum的敏捷实践。敏捷评估将由团队自己来衡量团队的敏捷有效性。团队掌握了Scrum的基本要领之后,团队可以尝试新的敏捷挑战:比如结对编程,提高完成的定义,在Sprint中实施有目的性的回归测试,在Sprint中引入自动化测试,测试驱动开发等等。

产品Backlog

Backlog是产品需求的堆叠。所有在backlog中的内容必须定义优先级。每项用户需求不能有相同的优先级。 排列在上面的的项目拥有更高的优先级。当backlog中的一项内容被完成后,它需要被从backlog中移除。在定义需求优先级时需要考虑的因素有: 商业价值;相关知识/不确定性/风险;实际可行性;相关联性。

  • 最小化可市场化的功能集合 – 缩小User Story的内容集
  • 商业价值优先 – 焦点放在高价值功能上
  • 投入产出比优先 – 先做简单的价值高的
  • 技术风险大的优先 – 不欠技术债
  • 规避风险 – 在后面做困难的Story,或者永远不做。
  • 投票 – 向你的用户咨询

切记很多PO只非常宏观地排一下优先级。 (考虑的内容很庞大– 需要花一个月或者更多时间来完成这些内容). 并且一旦他们被分解 – 在这个庞大的话题下的所有内容都被赋予同样的优先级, 这是彻底错误的。不是在大的话题下的所有内容都是和一个发布相关的- 有些Story可能根本不重要,应该完全从发布中剥离。记住:根据价值来定义User Story的优先级。

下面介绍一个需求优先级排序的方法,MoSCoW分区图法。 把你的Story放入4个区域中的一个,并且通过使用图中的数值来定义优先级。

 

  • M – MUST 一定要有的功能 – 没有这个功能,产品将不能满足用户要求。 
  • S – SHOULD 应该有的功能– 一个重要功能, 通过一个可接受的变通方案.
  • C – COULD 可能会有的功能 – 愿景列表内容
  • W – WON’T 不能在当下实现的功能– 也许在将来放入’必须’,’应该’或者’可能’ 的功能集合。

如何写一个有效的User Story

 

I

Independent

独立的

User Story 应该是内包含的,也就是说不应该存在另外一个User Story和它有内在的依赖关系。

N

Negotiable

可以商榷的

直到User story被放入一个Sprint之前, 它们都是可以被改变或者被重写的。

V

Valuable

有价值的

一个User Story必须对用户有价值。

E

Estimable

可以预估的

User Story的大小应该是能够被预估的。

S

Sized appropriately or Small

大小正好的或者小的

User Story 不应该太大以至于无法针对它做有意义的计划/拆分任务/定义优先级。

T

Testable

可测试的

User Story或者它的相关描述必须提供测试和开发所需要的必要信息。

梳理产品 Backlog

梳理Backlog的目标是获取专家意见,解决业务人员与技术人员的隔阂,使需求更加清晰, 最终利用整个Scrum团队的智慧与创造力, 创建认同的,共同的责任。

在开始梳理Backlog之前,User Story是已经被排好优先级的。

  • 定义或更新影响到的软件架构.
  • 分解那些太大的User Story (epics) – 哪些架构需要被模块化,重构或者需要被设计?
  • 定义初步的接受条件(acceptance criteria) – 指导Scrum团队理解如何设计, 如何根据既定的设计进行代码编写和测试.
  • 初步预估(基于 Story Points) – 一旦架构设计被定义的足以满足团队开始工作的程度, Backlog梳理团队应该提供初步的预估.  

User Story的接受条件

团队必须清楚要产出什么样的交付物,即满足User Story描述的需要的交付物.团队与产品经理之间建立’合同’ – 在工作结束之前不会再有变化! 敏捷是拥抱变化的,但在Sprint开工后到Sprint结束前不要变化需求。接受条件的作用是:

  • 定义User Story/功能的界限
  • 帮助产品经理回答团队关于新功能的价值相关的问题,(这些基本上都是最小的功能点)
  • 帮助团队得到一个对功能需求的认同.
  • 帮助开发人员和测试人员设计测试方案.
  • 帮助开发人员界定什么时候停止向一个User Story加入更多的功能.

 

接受条件应该是什么样的:

  • 描述想要什么而不是一个解决方案. 例如, “用户可以选择一个帐号” 而不应该描述为 “用户可以从下拉列表中选择一个帐号”
  • 可度量的
  • 可被测试的
  • 是一个高层次的描述,而不是具体的需求
  • 对于期望结果的描述 > 实现方法
  • 逐项都是可被实现的,同样也可以组合起来一起实现
  • 期望(特别是针对客户的期望的描述)

什么样的接受条件是不应该的:

  • 设计细节
  • 实现方法
  • 软件系统中的语言
  • 规格描述过细以及干扰信息

以上的标准可能并不适用所有的user story. 有时一些实现细节也是必需的. 有时也需要一些软件系统的语言,. 每件事对于你的团队都是特殊的, 不同的项目有不同的特点(甚至Story和Story之间也不尽相同)这并不妨碍好的接受条件的指导思想. 放轻松, 用你最好的判断力去调整至最好.

预估User Stories大小

软件研发是一个错综复杂的过程。从逻辑上讲,尤其对于未知事物,我们是不可能计划的。你越想预估得精确,你预测得就越不准确。Scrum方法论提供 了一个更好的方式: Story Point相对大小预估。使用Fibonacci 数列 (Story Points)  - 1,2,3,5,8,13 和21来估算User Story的大小。这个办法消除了对于我们还没有理解的东西,就得做出“实质的”预估的压力。一个 “努力水平”的积累的比例,需要考虑一下几点:经验,复杂度,规模,风险。不要把它和实际工作小时直接联系在一起。既然Story Point和实际小时数没有联系,这使得Scrum Team对于完成一个Story进行抽象思考需要多少努力变得更加容易。小时预估仅适用于Task的预估。一旦我们到达那个水平,小时数会给我们现实世界的精确度。Story Points 和小时数的结合,给我们提供了在软件中与最困难的事情(预估)做斗争的利剑。 

估算User Stories – 为什么用Story Points?

  • 因为通常情况下越大块儿的工作,复杂度越高,引入的风险也越高, 我们把它细化成小的模块级别的部分 (通过这样把不可预估的东西变成小的相对可预估的东西)– 当然,仍然可能有一些其他的一些悬而未决的决定,会对完成这个任务所需要的工作量的级别产生影响。
  • 任务越大, 你能够准确预估为了完成它所需要的确切分钟或者小时数的可能性越小。例如:电话打断, 与领导的单独谈话, 推迟的会议, 向上反映问题, 等等……
  • Story Points 能够衡量我们无法用小时数衡量的东西 – 例如 将来要做的工作的复杂度,风险,大小和经验。
  • 通过 Story Points 来做预估,给你提供了一种方法,让你把你虽然在现阶段不能十分确定的,但是却能凭直觉感觉到的一些不可见的各种因素考虑在内。

进行Story Point预估的考量和方法

 

 因素

Development

QA

经验

没有经验13

没有经验 13

复杂度

不复杂 8

非常复杂 21

规模

少的代码改动 5

很多测试用例 21

风险

风险大13

风险大 21

Story Point 预估

8

21

团队最终预估

21

    • 复杂度 – 如果有可能, 参考与现在做的user story类似的工作.  比较两者之间的复杂度。从架构角度看,哪一个更加复杂: 模块和子模块? 识别代码相互作用和依赖性。
    • 大小 – 先考虑测试 – 需要写多少新的手动测试用例?  现在预测可能需要改变的代码行数。
    • 风险 – 代码变化是如何蔓延的; 受影响的模块的缺陷历史是怎样的?
    • 经验 – 我们以前做过么?经验是一个很棒的老师 – 一旦能用,就用。但是,如果工作是全新的,因为有不确定性,所以建议提高Story Point。

Sprint计划

Sprint 计划会议

Spring的第一天, 所有团队成员聚集在一起召开Sprint计划会议。Sprint 预计划和Sprint计划是有区别的。Sprint计划会议在Sprint 预计划之后, User Story的接受条件和预估已经由团队完成.  团队的初步的生产力(capacity)已经确定,足以让我们了解需要的人员和工作量 (70-80 %). 团队从最高优先级的User Story开始, 根据团队的速率(Velocity),将相应Story Points的User Story从Product Backlog中移至Sprint Backlog.团队的速率(Velocity) 是4个以上历史Sprint完成Story Point的平均值。Sprint计划会议不需要PO参与,因为这是任务分解的时候,需求澄清工作已经在预计划阶段完成。PO并不做编程和测试的工作,所以任务分解PO也帮不上忙。团队紧密合作, 为每个User Story列出所有已知的任务。我们不是算命先生, 没有人可以准确的预测未来. 参考DoD定义,列出当下已知的工作。每个任务应该可以在一个工作日内完成。如果任务需要12 小时. 在你的团队日平均工作量为8小时的情况下, 那么这个任务应该被分解为2个任务.  只有这样做,才能够基于天为单位来跟踪团队的进度. 进而更快的达到最终的完成.

Sprint预计划会议

在会议之前, Product Owner 把product backlog中的故事定义优先级。同样在会议之前, Product Owner 定义下个sprint的Sprint Goal使teamvelocity, 计划下个sprint可以放入哪些User Story
每个user story 应该包括:
  • 标准描述(角色, 功能和益处) –  “作为一个<类型的用户> 我需要 <一些功能> 以便得到<益处>”;
  • 接受标准;
  • 预估– 使用story points method, 预估这项工作需要的工作量
  • 生产力 (人员的分配).
  • 确定好优先级的product backlog
  • 重新审视并且更新(DoD).

速度 Velocity – 在一个Sprint中完成的工作

速度是一个有效的用来衡量长时期内个个Sprint完成工作工作量的指标。速度不是针对于每个sprint所完成工作量的度量。速度是使用团队对Product backlog项目进行预估时的单位来度量的. 通常为StoryPoint.

 

使用Velocity进行发布计划的好处是:

  • 容易度量
  • 纠正预估的错误
  • 容易反映项目的状态
  • 做计划的主要参数

上图展示了一个团队的三种平均速度:

  • 长期平均值, 指的是最近的8个sprint的平均值。
  • 最差情况平均值, 指的是在最近的8个sprint中选出的最差的3个的平均值。
  • 最好情况平均值, 指的是在最近的8个sprint中选出的最好的3个的平均值。

每日例会Daily Standup 会议

会议目的是根据Sprint目标, 跟踪每日Sprint进展。要使日例会进行得高效,使会议进程快速而专注。好的stand-up会议是令人感到被互相支持的而且是团队能够自我管理的。一旦声称完成了意味着定义的工作项,流程全部完成了.  

会议模板:

  • 我昨天做了什么? – 基于昨天承诺过要做什么, 这是我的进展;
  • 今天我将要做什么? – “准备开始”, “尝试当天完成”, “继续进行的”, 这些不是对工作的承诺. 而是类似 ”我今天将会完成xxx任务” 的承诺.  这是你对其他成员的承诺; 而不是对Scrum Master的承诺. 如果一项任务需要很多天来完成, 请将它细化到天.  这将有助于做出以天为单位的承诺,也更容易来跟踪每天的进展;
  • 有什么阻碍 – 今天承诺将解决的困难. 
    • 需要什么样的帮助? 
    • 有没有及时在当天与整个团队沟通你遇到的困难?
    • 有没有及时记录你的困难,谁来帮助解决困难,有什么样的计划解决困难?

参考团队的燃尽图,并及时检查Sprint是不是有任何延迟,能否按时交付. Sprint进度评估应该每天都在进行。

完成的定义 Definition of Done

设定团队任务完成的定义的目的是为了量化的衡量交付的软件质量。

  • DoD 必须是现实的, 在sprint中可以达成的。
  • 保证工作的软件的质量
  • Done 就是完成了! 没有妥协的余地.
  • 提高DoD用以满足不断变化的产品需求= 对产品的高质量的追求是永无止境的

可借鉴的User Story 的DoD 检查表:

  1. 代码完成 (所有要做的内容的编码工作都完成了)
  2. 代码注释完备, 提交并且在最近的版本上能够运行。
  3. 通过伙伴评审 (或者通过结对编程实现) 并且满足开发标准
  4. 编译中没有错误
  5. 单元测试被编写,并且测试通过。
  6. 部署到系统测试环境中,并且通过系统测试。
  7. 通过用户接受性测试,(用户)签署达到了需求。
  8. 任何版本/部署/配置变化都是被实施了的/通过文档记录的/沟通过的。
  9. 相关的文档/图标都被提供和更新了。
  10. 相关任务的剩余时间设置为零,并且任务被完成。

进度跟踪

每天:

所有的Scrum团队都需要每天开15分钟的 daily standup 会议, 在Rally中填写任务/责任人/耗时, 在每个sprint结束前,填写defects并且修复S1-2的缺陷, 使用burndown chart (燃尽图)来跟踪任务和问题, 使用burnup chart (燃耗图) 来跟踪已经完成的user stories的情况.  Scrum Master帮助移除前进中的障碍. 

每周:

  • 为了在多个团队中共享宏观状态,需要召开一个Scrum of Scrums 会议 (至少每周一次) 。召开频度根据需要而定: 每周一次,或者最多一周三次.
  • 通过预计划会议来更新当前发布的计划, 同时计划下个软件发布。
  • 每一个Scrum team都要进行预计划会议, 为下一个或者下下个sprint夯实基础。

Sprint状态报告:

Scrum Master 帮助Scrum团队跟踪sprint进度(至少去更新维护燃尽图和燃耗图)。将会有专人负责帮助管理层提供研发进度报告。

Sprint状态关键指标:

  • Daily burndown chart – 跟踪打开的和关闭了的问题和任务
  • Burnup chart – 跟踪接受了的user stories (为团队, PO 和管理层提供信息)

Scrum of Scrum:

目标: 1. 移除障碍 2. 解决或者移除团队之前的依赖 3. 快速的文档跟进。

细节:

  • 你的团队自从我们上次会议以后,做什么了?
  • 到下次开会前,你的团队打算做什么?
  • 有什么让你的团队效率变低,或者有什么阻挡你们的团队前进么?
  • 你是打算把一些事情放在其他团队前进的路上么?

参与者:

发布经理Release Manager, 相关Scrum 团队代表和Scrum Master。

Sprint 审查 - Review

Sprint审查的目的是在Sprint回顾过程中,以Sprint 计划会议中设定的Sprint目标为参考评估项目。理想情况下,团队已经完成了Product Backlog中,引入到本Sprint中的所有项目,但是更重要的是他们已经完成了这个Sprint的整体目标。

Sprint review要保证:

  • 保证所有的User Story都完成了 – 以DoD标准来衡量任务是否完成; 以接受标准来衡量User Story是否完成.
  • 没有Open状态的S1或者S2缺陷的存在.
  • 更新JIRA中的内容– 关闭进行的讨论, 记录最终的burndown和burnup图, 正式结束这个Sprint.

Sprint审查的参与者:

一般包括:PO, Scrum Master和Scrum团队,以及经理,客户和其他项目的工程师。

回顾 Retrospective - 持续改进的关键

  • 哪些方面在上个Sprint中我们做的好的,需要在以后的工作中继续 ?在上一个Sprint中,那些好的实践,应该被识别出来,并且在以后的Sprint中保持。
  • 哪些在上个Sprint中做得不好的,需要在以后工作中杜绝? 团队或者客户应该识别出,在上个Sprint中,哪些实践是有悖于团队的,并且应该把注意力放在如何在接下来的Sprint中杜绝。
  • 我们应该开始做什么?团队识别出可以在下一个Sprint应用, 能够帮助团队更好地协同工作的最佳实践。

 

转载于:https://www.cnblogs.com/hunter-56213/p/6378996.html

2015-09-10 16:56:13 maranran_dream 阅读数 285
  • SCRUM敏捷开发视频教程

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

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

第一章只知识点:
第一:软件的概念:由数据、文档、程序组成

第二:软件生命周期:定义——设计——实施——测试——部署——运行——维护

第三 瀑布模型:计划(定义阶段)——需求分析——设计——编码(开发阶段)——测试——运行维护(维护阶段)

第四:V模型:需求分析——概要设计——详细设计——编码 ——单元测试——集成测试——系统测试——验收测试

第五:敏捷开发过程:1:敏捷开发是一种以用户的需求进化为核心、迭代、循序渐进的开发方法,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。

2:特点  变,早,快

第六:软件系统体系结构:主体终端模式、文件服务器模式、C/S模式(客户端模式)、B/S模式(浏览器模式)

第七:WEB应用三层模式架构模式:用户界面表现层、业务逻辑层、数据访问层

第二章知识点

第一: 为什么需要软件测试:人本身容易犯错、时间的压力、复杂的外部系统、复杂的代码、复杂的系统架构

第二:软件测试的定义:简单来说是为了发现错误而执行程序的过程,复杂来说是对软件需求、设计、编码的进一步复查,是软件质量保证的关键步骤

第三:软件测试的目的:1.发现缺陷,提高质量

2.验证是否满足需求

3.建立软件质量信心

第四:软件测试的原则:1。测试显示缺陷的存在

2.尽早介入的原则

3.穷尽测试时不可能的

4.测试依赖于测试背景

5.缺陷集群性

6.杀虫剂悖论

7.缺陷不存在的谬论

第五:软件工作最为重要的事:1.测试工具            2.测试方法、流程             3.测试人员的素质

第六:软件测试的流程;测试计划和控制——》测试需求和测试用例——》实行和执行测试用例——》评估测试报告——》测试活动结束

第七:软件测试职业:国内测试职业正处于发展中,具有很大的前景。测试人员需要掌握一定的编程语以及测试工具,在职场应该具有较好的沟通能力和团队 能力

开发人员与测试人员的关系:合作、中性、相互理解

 

 

第三章知识点

第一:生命周期测试过程:测试计划——测试方案——测试要点——开发用例——执行用例——测试报告评估

第二:基于生命周期的测试特点:

在软件开发过程中持续的测试

在尽可能早的时候去介入

需要正式的开发流程支持

组建专门的测试团队

当软件整体开发活动开始的时候,测试活动就可以开始

 

 

第四章知识点

第一:软件配置CSCI:是为独立的配置管理而设计的且能满足最终用户要求的一组软件。软件开发过程中,产生的所有信息或构成软件设置,它们是:代码、文档、报告等,统称为配置项。

第二:基线:指受配置的某个研制阶段的结束点时软件成分的技术状态,是已经通过正式审核和同意,是下一步软件开发的基础。任何一个软件配置项,一旦通过形成文档并审议通过,即成为基线。

第三:软件测试分类:

是否关心内部结构   白盒测试赛、黑盒测试、灰盒测试

开发过程级别  单元测试、集成测试、系统测试、验收测试

是否执行程序  静态测试、动态测试

执行是否人工干预   手工测试、自动化测试

测试实施组织   开发测试、用户测试、第三方测试

 

 

第五章知识点

第一:软件缺陷的定义:

1  软件为实现产品说明书要求的功能

2  软件出现了产品说明书指明不应该出现的错误

3  软件实现了产品说明书未提到的功能

4  软件未实现产品说明虽未明确提及但应该实现的目标

5  软件难以理解,不易使用,运行缓慢

第二:软件缺陷基本信息:缺陷ID、标题、报告人、报告日期、程序的名称、严重性、优先级、缺陷描述、重新步骤、结果对比

第三:缺陷管理一般流程

1:主线   发现一个新的缺陷——打开缺陷——经理分配给开发人员——开发人员修改——重新测试(没有问题)——关闭缺陷

支线1:发现一个缺陷,测试人员不确定是不是缺陷——管理委员会(是缺陷)——按照主线流程进行

(不是缺陷)——关闭

支线2:发现一个相同类型的缺陷——关闭

支线3:发现一个一般性问题——到下一个版本再修改

 

 

第六章知识点

第四:软件测试过程模型

1V模型    特点:不同测试阶段和开发过程期间各阶段的对应关系,强调阶段性

2W模型   特点:增加了软件开发阶段中应同步进行的验证和确认活动,基于“尽早地和不断地进行软件测试”的原则

3H模型    特点:软件测试时一个独立的构成,贯穿整个生命周期。强调独立性

第五:软件测试过程中关键活动   提取测试需求——制定测试计划——制定测试策略和方案——开展测试设计——执行测试用例-分析测试结果

 

 

第七章知识点

第一:软件静态测试:在不运行软件的情况下进行软件测试

特点:1。不必动态地进行程序

2.可以人工进行,充分发挥 人的想象力

3.不需要特别的条件,容易展开

4.对测试人员要求比较高

第二:同行评审:临时评审、同级评审、走查、小组评审、审查。审查为级别最高的,最正式的。

第三:代码检查方法:代码走查、代码审查、桌面检查、技术审查

 

 

软件过程模型

阅读数 145

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